HowTo -convert Puppy to OLPC

How to do things, solutions, recipes, tutorials
Message
Author
User avatar
mavrothal
Posts: 3096
Joined: Mon 24 Aug 2009, 18:23

Re: HowTo -convert Puppy to OLPC

#21 Post by mavrothal »

Yogi12 wrote:I think the OLPC XO-1 is a marvellous piece of hardware, let down badly by the software. (I bought 6) A while ago I tried running puppy, but was continuously frustrated with applications requiring a more up to date kernel. I really wanted to know: In what way is the OLPC so different from any other laptop? I know it doesn't boot the same way. (Rather than load an MBR at 0000:0007ch & run it, it has this forth driven load system), but are the other BIOS INT calls different? I thought Linux did not use these calls anyway once up and running. Why does the kernel need patching, and what does this do? Why does the rest of puppy need changing?
XOs need a specific kernel because some of the hardware drivers and mods are not upstream yet.
The rest of puppy does not really needs modification but for space savings a lot of useless stuff is removed (kernel, video drivers).
Some user space modifications (power management, udev with extras, chrome driver for the XO-1.5 and a couple little apps and configurations) are done to improve functionality
Yogi12 wrote:I thought this thread, (which I have only just discovered) would let me answer this, but I am confused. It starts with 'Create_xo_puppy-0.3.tar.bz2' which seems to be a broken link & I can't find it anywhere. Then there is XOpup_kernel_builder-4.sh.gz. This seems to patch the Kernel source code using downloaded patch instructions, but little indication as to what this achieves. However, it seems to work on the kernel & that alone. Then there is, the Pox_git entry, create_xo_puppysh.html which when separated from the HTML seems to be a script that is claimed to magically do the whole thing from just an ISO download (which surely does not have the kernel sourcecode). It appears to modify many things, but not the kernel. (well if it does, I have not found where.) Duh????? I have not actually run any of them yet.
This thread evolved with development...
Pox_git scripts is the latest development and it does build an XO specific puppy "magically". Just download, expand (or git clone) and run.
To take out the magic you may want to read the readme file :wink: .
Yogi12 wrote:In order to take a short cut and actually upgrade my OLPC's, if converting any puppy is now supposed to be so easy, (even if time consuming), could someone who has done the latest two ISO's not make the result available for direct download?

Please help.

Yogi12
A couple of years now there is XOpup based on Lupu 5.x
There are also the more resent (Pox-git based) Racy-5.2.2, -5.3/Saluki-10, -13 and Slacko 5.3.3 builds
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==

Yogi12
Posts: 7
Joined: Sun 03 Apr 2011, 11:43
Location: Wales, UK

#22 Post by Yogi12 »

Thank you very much indeed for your message. Much information leading to much thought: and much time (that I simply do not have) consummed but in an interesting way.
My background/perspective: Electronic researcher & hardware designer before microprocessors were invented. When they came, a god send. Much less hardware, connect everything using numbers. However, programming style my own, which developed to quite large projects. Code re-used extensively, but using copy-paste NOT headers or libraries etc. Very 'KISS' 'Keep It Simple, Stupid'. (sarcasm on: I often think Make files are more complicated than the application they are trying to make need be. sarcasm off.)

The actual Puppy I wanted to put on my OLPC (lupu-528.005.ISO) did not seem to be available, so I decided to simply use the offered 'Magic' of create_xo_puppy.sh, in my system Edubuntu 8.04.4LTS., kept up to the latest 'update'. This seems to replace the kernel every other month so that I assumed it would be up to date. Result: 'export: 18: Illegal option -f'. Apparent reason: the first line line of the script (so called shebang line) causes the shell 'dash' to be used. Dash does not support export of functions. (Not that this is necessary from the user's point of view.) My solution: edit the first line to be #!/bin/bash. (I defy any newbie to suss that one out!). Now it complained about the kernel version. Thought this must be a 'test error', but no: I can create & mount squash filesystems, but not the latest! As I didn't want to do heart surgery on this system just to run a script (if it didn't create problems somewhere why wasn't it already done?). Abandoned. Found a more up to date Edubuntu. (11.10 Oneric Ocelot) (Ugh! Horrid GUI) 'Dash' problem still applied. Script failed this time with "cp: cannot stat (working directory)/XO_sfs/* no such file or directory, and a similar line but with a list of initial letters. Looking at script I could see where $XOSFS is defined, but could not easily spot where it creates a directory from it. Temporary give up, too involved for the time I had. Decided to take the hint given when the script runs about not using Puppy, so decided to try again using the lupu release I wanted as a base. It gave the usual moan that there was no pks_remrc file in the working directory and simply returned a command prompt (I assume pks_remrc is an _optional_ configuration file????). Investigation indicated that not being able to find this file aborts the script. Why I do not know. My solution: commented out the . $CWD/pkgs_remrc line. Now had the same outcome as the second Ubuntu attempt. That ended exactly the same way as the second Edubuntu attempt.

Oh well, I decided to work with the ready made releases available. (There seemed to be 5). I would like to compare them to find the differences, (is that documented anywhere?). Just a little forth script, or so I thought. Failed miserably. Simplified my script to this point:- Selecting the original script, modified to unambiguously display what went to boot_file, boot_device and ramdisk booted racy5.3 fine. Selecting a simplified script that just consisted of three lines putting exactly that to those three places (and booting, with or without unfreeze) I got:-

FAIL
Dumping last lines of /tmp/bootinit.log
hwclock: can't open /dev/misc/rtc :no such file or directory
ls: /lob/keymaps2/du*.gz : no such file or direcory
Dumping last lines of kernel log
Freeing unused kernel memory 240k freed
mmco: new high speed SDHC card at address d5e0
mmcblk0: mmc0:d520 $D04G 3.9Gib
mmcblk0: p1 p2
Pausing 60 seconds
Loading drivers needed to access disk drives done
Searching for puppy files ... puppy_racy_5.3sfs not found
dropping to initial ramdisk console.

(The approach works fine with lupu 5.1.1!)

Tried to find what it is about the body of the original script that makes a difference. I like forth, but it only really works if words added beyond the widely documented ones are themselves well documented. Please - is there any where on the internet where words such as 'get-package-property' are documented? (I found one possible broken link lead only.) Tried examining with the only tool I know, 'see', but could not find anything that was a clue as to my problem.

Help with my frustrations would be most appreciated: I would love to 'understand' this lot, (and possibly contribute) but feel I am spending a lot of time not really getting there.

User avatar
mavrothal
Posts: 3096
Joined: Mon 24 Aug 2009, 18:23

#23 Post by mavrothal »

Yogi12 wrote:The actual Puppy I wanted to put on my OLPC (lupu-528.005.ISO) did not seem to be available
Lupu 528 is evolution of Lupu5x that the original XOpup is based on. Newer apps in lupu528 can be downloaded with the Puppy Package Manager and installed in XOpup, usually without any problems.
A lot of the improvements in Lupu relate to hardware detection and implementation and are not really relevant to XO laptops.
Yogi12 wrote: Result: 'export: 18: Illegal option -f'. Apparent reason: the first line line of the script (so called shebang line) causes the shell 'dash' to be used.
I use the Pox_git scripts in Puppies or Fedora. It looks like that Ubuntu has dash as the default shell script. I guess changing to shebang in all the scripts to /bin/bash is the way to go on that. Or you could symlink /bin/sh in Ubuntu to bash instead of dash (sudo ln -sf /bin/bash /bin/sh).
But is a good point. I changed the scripts to bash in Pox_git
Yogi12 wrote: so decided to try again using the lupu release I wanted as a base. It gave the usual moan that there was no pks_remrc file in the working directory and simply returned a command prompt (I assume pks_remrc is an _optional_ configuration file????).

To build a puppy you must clone or download the Pox_git tarball extract it and then you can either run the scripts individually or run the master script. The pox_git directory besides the scripts has also patches the pkgs_remrc and other XO files needed for the builds. The scripts by themselves will not do it.
Also make sure you have at least 1GB space if you are going to build the kernels

One "wired" thing is that you can not run the master script (make_build) from within the directory you downloaded but from a level above. eg

Code: Select all

./mavrothal-Pox_git-80b09cb/make_build -b /path/to/iso/puppyname.iso
(The idea is that this is a git repository for the development of the build scripts and not for the puppy XO builds, so we leave it alone).

The master script will make the working directory named "puppyname_XO_build" and make everything in there. When it finishes the build files are found in the build directory within the puppyname_XO_build folder.

Also if you run the other scripts individually from within the directory you cloned/downloaded "{mavrothal-}Pox_git{-commit}" will fail since other needed files are not in the right path. Running them from the "puppyname_XO_build" directory that make_build generates works fine
(Hmm... OK I put some safeties for that in the scripts in case the Readme is not clear enough)
Yogi12 wrote:Oh well, I decided to work with the ready made releases available. (There seemed to be 5). I would like to compare them to find the differences, (is that documented anywhere?).
The differences between the different puppies (and their respective XO versions) is binary compatibility and the repertoire of apps/desktops that each developer adds to the given puppy.
Yogi12 wrote:Just a little forth script, or so I thought. Failed miserably. Simplified my script to this point:- Selecting the original script, modified to unambiguously display what went to boot_file, boot_device and ramdisk booted racy5.3 fine. Selecting a simplified script that just consisted of three lines putting exactly that to those three places (and booting, with or without unfreeze) I got:-

FAIL.
Is not clear to me what you did here. Maybe you can post your olpc.fth file but the original olpc.fth passes a number of arguments to puppy, including the boot device ant thus the location of the sfs files.
You should also make sure that you use the correct initrd.img for the build since the puppy version, and sfs to look for, is defined there.
Yogi12 wrote:Please - is there any where on the internet where words such as 'get-package-property' are documented? (I found one possible broken link lead only.) Tried examining with the only tool I know, 'see', but could not find anything that was a clue as to my problem.
Try http://wiki.laptop.org/go/Forth_Lessons
Or http://pages.cs.wisc.edu/~bolo/forth/ for more technical info
The entire OFW code is in http://tracker.coreboot.org/trac/openfirmware/browser
while you can look here for bootloaders

You could also ask directly in the OLPC devel list that has many very knowledgeable OFW/Forth developers including Mitch Bradley himself
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==

Yogi12
Posts: 7
Joined: Sun 03 Apr 2011, 11:43
Location: Wales, UK

#24 Post by Yogi12 »

Thank you very much once again for your reply. Once again much to think about and work on. I obviously have not got the knack of sorting the Internet gems from vast quantities of scarcely relevant in this subject area yet.

You suggested I posted my olpc.fth. The following is my script, (stored in /boot as olpc.fth in the XO-1.0).
The SD card has may things, but relevant is that /boot10 is the original racy /boot10, containing its config file, initrd.im and vmlinuz. /boou10 is the original /boot10 from the lupu, containing its config, System.map initrd.img and vmlinuz. Currently lupu-511.sfs and puppy_racy_5.3.sfs together with sfs files created by them are all in the root directory of the card. Options 1 and 8 work (8 boots racy), 2 does not, producing the effect reported above.

Code: Select all


\ olpc2fth.rbk dated 20Jun12 temp boot script, pruned to illustrate problem with racy
\
visible cr
." 1 for orig lupu511" cr
." 2 racy53" cr
." 8 orig script" cr
cr key  dup 31 = if
" ro root=/dev/mmcblk0p1 rootdelay=1 console=ttyS0,115200 console=tty0 fbcon=font:SUN12x22" to boot-file
" sd:\boou10\vmlinuz" to boot-device
" sd:\boou10\initrd.img" to ramdisk
unfreeze boot

then dup 32 = if 
\ " ro root=/dev/mmcblk0p1 rootdelay=1 console=ttyS0,115200 console=tty0 fbcon=font:SUN12x22 no_console_suspend" to boot-file
\ " sd:\boot10\vmlinuz" to boot-device
\ " sd:\boot10\initrd.img" to ramdisk

\ following three lines created by manually copying verbatum the visual results of running option 8:-
" console=ttyS0,115200 console=tty0 fbcon=font:SUN12x22 no_console_suspend PDEV1=mmcblk0p1" to boot-file
" /pci/sd@c,1/disk@1:\boot10\vmlinuz" to boot-device
" /pci/sd@c,1/disk@1:\boot10\initrd.img" to ramdisk
\ unfreeze
boot 

then drop ( 38 is now "any other key" default option )
\ OLPC boot script

\ visible
\ Returns a number identifying the XO version - 2 for XO-1, 3 for XO-1.5
: xo-version  ( -- n )  fw-version$ drop 1+ c@ [char] 0 -  ;

\ To pass hardware specific arguments we define the xo-1? and xo-1.5? flags   
The script is now exactly as the original olpc.fth until:-

Code: Select all


   " PD" $set-macro

   check-ofw

   " console=ttyS0,115200 console=tty0 fbcon=font:SUN12x22 ${PD}" expand$ to boot-file

\ Uncomment the next 2 lines to see the command line
   ." cmdline is " boot-file type cr
\   d# 4000 ms

   " ${DN}${PN}\vmlinuz"    expand$ to boot-device
   " ${DN}${PN}\initrd.img" expand$ to ramdisk

\ added by RBK to also see boot-device and ramdisk
." boot-device is " boot-device type cr
." ramdisk is " ramdisk type cr
." Press any number to continue" cr
key .
   boot
;
olpc-fth-boot-me

\ end of script

I am now suspicious that boot is passing parameters from further down my script rather than from boot-file, but I have not followed this line of enquiry through yet.

User avatar
mavrothal
Posts: 3096
Joined: Mon 24 Aug 2009, 18:23

#25 Post by mavrothal »

Regarding option 2, I really do not know why. You may want to ask the OFW people.
But why not just use "sd:" as in option 1?

BTW when you say lupu-511 you mean from XOpup-2.2 or indeed the Lupu-511 initrd/vmlinuz?
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==

Yogi12
Posts: 7
Joined: Sun 03 Apr 2011, 11:43
Location: Wales, UK

#26 Post by Yogi12 »

Mavrothal wrote:-
But why not just use "sd:" as in option 1?
As you can see from the commented out lines, that is how I initially had it. Upon failure, in order to try and work out if the problem was anything to do with the formation or syntax of the lines, I tried using exactly (as far as I could copy) what worked after executing the original script.

Mavrothal wrote:-
BTW when you say lupu-511 you mean from XOpup-2.2 or indeed the Lupu-511 initrd/vmlinuz?
All I know is I obtained lupu-511.sfs and the boot10 folder (renamed by me to boou10) from file XOpup-1.0.tar.gz downloaded on or before 28th November 2010. The folder inside is dated 16th October 2010.

User avatar
mavrothal
Posts: 3096
Joined: Mon 24 Aug 2009, 18:23

#27 Post by mavrothal »

Yogi12 wrote:Mavrothal wrote:-
But why not just use "sd:" as in option 1?
As you can see from the commented out lines, that is how I initially had it. Upon failure, in order to try and work out if the problem was anything to do with the formation or syntax of the lines, I tried using exactly (as far as I could copy) what worked after executing the original script.
I see.
Do try

Code: Select all

" console=ttyS0,115200 console=tty0 fbcon=font:SUN12x22 no_console_suspend PDEV1=mmcblk0p1" to boot-file 
" sd:\boot10\vmlinuz" to boot-device 
" sd:\boot10\initrd.img" to ramdisk 
\ or 
" console=ttyS0,115200 console=tty0 fbcon=font:SUN12x22 no_console_suspend PDEV1=mmcblk0p1" to boot-file 
" ext:\boot10\vmlinuz" to boot-device 
" ext:\boot10\initrd.img" to ramdisk 
If you didn't

XOpup-1.0 and slacko_xo_5.3.3 have considerably different init and I do not think "root=/dev/mmcblk0p1 rootdelay=1" is something that the puppy init understands.
Some times is also card timing issues that XOs may have problem with.
I trust that you are running a recent firmware on your XO-1 (preferably q2f11 or 12) that tries to address some of these issues.
You may also try your files in a USB stick to see if indeed is a card problem

BTW XOpup-2.2 is considerably better and closer to lupu-525
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==

Yogi12
Posts: 7
Joined: Sun 03 Apr 2011, 11:43
Location: Wales, UK

#28 Post by Yogi12 »

Code: Select all

" console=ttyS0,115200 console=tty0 fbcon=font:SUN12x22 no_console_suspend PDEV1=mmcblk0p1" to boot-file
Oops. I intended the commented out lines in my script to be my original, but when trying all kinds of different things, (including things "borrowed" from other places) I got the script messy. When I pruned it for the post I left in the wrong commented out line. Sorry. (Tests would not have found that error.) My original offering, which I thought would just 'work', was in fact exactly your first suggestion. Checked by testing it again, failure as reported above. Tried the substitution of ext: for sd: in the other two lines, and the result was the same.
Some times is also card timing issues that XOs may have problem with. I trust that you are running a recent firmware on your XO-1 (preferably q2f11 or 12) that tries to address some of these issues.
You may also try your files in a USB stick to see if indeed is a card problem
Q2E45. Perhaps I should update. I am still interested in the approach that boot is passing something read from the script. boot calls boot-getline which calls parse. parse does not seem to behave like the parse I am used to. I have tried leads from you but I still cannot find an index document of the words in the olpc prom like I am used to having when a third party has added to forth. (I have not so far downloaded the entire source to create one for myself.)

moan mode:
All this escalated from trying to by-pass an issue with python code, and the required python release not running with the kernel in the olpc, and not being able to easily change it. The python code is only required because of the way a particular person wrote the user interface to control a driver that that does not need or directly use python at all. Why such a simple use of something simply used to make pretty pictures should be so release dependent is beyond me. Somehow, I am feeling I am still deep in the old Linux 'monolithic' complexity of EVERYTHING being dependent on several large chunk things that cannot be adapted without breaking unpredictable things that currently work, and are completely irrelevant to the problem in hand. Most of the dependencies themselves are side effects and not directly relevant to the objective of the software. Somehow, the way the entire system works to achieve what it does is far too complex, which produces documentation issues. /moan mode

I will next follow your suggestion of trying XOpup-2.2, and possibly just simply put all the releases on different sticks or cards. Thank you a great deal for all your help, you have enabled me to learn a lot.

User avatar
mavrothal
Posts: 3096
Joined: Mon 24 Aug 2009, 18:23

#29 Post by mavrothal »

Yogi12 wrote: I am still interested in the approach that boot is passing something read from the script. boot calls boot-getline which calls parse. parse does not seem to behave like the parse I am used to. I have tried leads from you but I still cannot find an index document of the words in the olpc prom like I am used to having when a third party has added to forth. (I have not so far downloaded the entire source to create one for myself.)
Once more I would recommend the olpc-devel list for FORTH/OFW related issues. They are usually helpful, though you may want to get a sense of the list "culture" first :wink:
And if you get a super-bootloader going please post it here or maybe the aforementioned olpc wiiki page
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==

Post Reply