XOpup Interest Group. Puppy Linux for the OLPC XO-1 laptop

[mavrothal]

Looks like this project needs to be renamed to "Get the XO-1 firmware to boot small Linux like Puppy".

As you keep saying, the only hope for speeding up the XO-1 is to be able to load applications in RAM. And only small Linuxes can do that.

And as I keep saying, those who stand to benefit from the XO-1 should be willing to shoulder the cost of programming the BIOS for that purpose.

About 10 different distros including windows run on the XO-1 and its OFW.
Small linux distros DO NOT have any special BIOS requirements that I know of. Do you? (Please answer this question)
OFW is just as free, open and functional as any other part of Linux. You just have to have a clue about it. It is actually easier to develop for it compared to any other proprietary piece of bios or specific driver (look what is happening with a lot of linux video or wifi drivers).

Now having said that if you have any BIOS for the XO-1 boards or you (or anybody else) can develop one, and have a way to flash it in the XO-1, PLEASE go ahead.
If you are saying that ttuuxxx, BK or any other puppy developer does not have the ability to make the puppy init script OFW aware, the way all the other distros do, I'm sorry to hear it.
If you just say that you can not teach an old dog new tricks. I believe you are wrong. The dog is actually very young
If you are saying that they just do not want to bother, I hope you are wrong. But then again you might be right...
Finally if you just say the either OLPC runs or a "normal" BIOS or they can forget about Puppy, let's forget it.
XO is doing very well what it is designed to do with OFW in a way that no BIOS can. Half a megabyte of code can do as much as the BIOS the kernel and the OS together and still have room to run some games!... Is actually too bad that mannerism, lack of knowledge and going mainstream-Linux (RedHat was a major sponsor), stopped OLPC software engineers to take full advantage of it. It would be blazing fast...

BTW is the first time that I hear that a FOSS piece of software must be replace by a proprietary one so another FOSS piece of software can run! Of course I'm new to Linux

[hailpuppy]

HI Mavrothal, why cant we seek help of Mitch Bradley who developed OFW for xo ( He can be reached at Wmb@firmworks.com ). In a previous post you had wished we had a FORTH programmer to help us with this if my memory is correct. Then after that we may be able to seek the help of Barry in this regard. Mavrothal, I ve seen you being very active on OLPC related issues . You may have even contacted Mitch by now.

http://wiki.laptop.org/go/OFW_FAQ

http://wiki.laptop.org/go/User:Wmb%40firmworks.com

Hope above links would help you guys.
Good luck!!!

[mavrothal]

hailpuppy
The "problem" with linux developers is unless you ask an informed, precise and interesting (for them ) question they usually are too busy to answer... and if your first question has an RTFM answer they might just delete your future mails as junk

If I knew what to ask I would have, but is not an issue of something that the OFW does not do, or doing it wrong, or doing it differently, is an issue of knowing what the OFW does do.

The "smbios" option that is usually activated, does just that simulates a "normal" bios so "normal" OSs (windows and linux) can see it as such. And evidently they do!
Now, the fact that puppy does not, is not necessarily a problem of the OFW...
I'm sure if BK put his mind to it and drop all his other projects can finish it in few days. Please convince him

PS: and just in case someone might be interested the entire code is in svn (svn co svn://openbios.org/openfirmware ). The running q2e41 XO-1 firmware is version 1145 and the config-olpc.fth is this

Code: Select all

\ See license at end of file
purpose: Configuration for loading from a USB key via Syslinux on OLPC

create olpc             \ OLPC-specific SPI FLASH programming

\ --- The environment that "boots" OFW ---
\ - Image Format - Example Media - previous stage bootloader

\ - (Syslinux) COM32 format - USB Key w/ FAT FS - Syslinux
create syslinux-loaded

\ create serial-console
create pc

\ create pseudo-nvram
create debug-startup
create resident-packages
create addresses-assigned  \ Don't reassign PCI addresses
\ create virtual-mode
\ create use-root-isa
create use-timestamp-counter
create use-pci-isa
create use-isa-ide
create use-ega
create use-elf
\ create use-ne2000
create use-watch-all
create use-null-nvram
create no-floppy-node

fload ${BP}/cpu/x86/pc/biosload/addrs.fth

\ LICENSE_BEGIN

And in case that someone is REALLY into bios stuff I attach the smbios microcode

[Aitch]

follow-on from hailpuppy's link

Mitch Bradley on fastboot/XO

http://wiki.laptop.org/go/User_talk:Wmb ... m#fastboot


good suggestion, hailpuppy, though he may want a contract....?

OLPC's 5th principle: Free and Open Source

All children are learners and teachers, and this spirit of collaboration is amplified by free and open source tools.

A child with an XO is not a passive consumer of knowledge, but an active participant in a learning community. As children grow and pursue new ideas, their software, content, resources, and tools should be able to grow with them. The global nature of OLPC requires locally-driven growth, driven in part by the children themselves. Each child with an XO can leverage the learning of other children. They can teach each other, share ideas, and support each other's growth.

There is no inherent external dependency in being able to localize software into their language, fix the software to remove bugs, and repurpose the software to fit their needs. Nor is there any restriction in regard to redistribution; OLPC cannot know and should not control how the tools we create will be re-purposed in the future.

OLPC's goals require a world of great software and content, both open and proprietary. Children need the chance to choose from all of it. In the context of learning, knowledge should be free. Further, every child has something to contribute; we need a free and open framework that supports the human need to express and share.

http://wiki.laptop.org/go/Core_principles/lang-bg

Now let's let ttuuxxx play.....

Aitch

[raffy]

hailpuppy
The "problem" with linux developers is unless you ask an informed, precise and interesting (for them ) question they usually are too busy to answer... and if your first question has an RTFM answer they might just delete your future mails as junk

If I knew what to ask I would have, but is not an issue of something that the OFW does not do, or doing it wrong, or doing it differently, is an issue of knowing what the OFW does do.

"Could you help us boot Puppy in the XO-1?" is an honest enough question, isn't it?

But you chose to froth instead:

BTW is the first time that I hear that a FOSS piece of software must be replace by a proprietary one so another FOSS piece of software can run!

Developing free software can cost the intended user, right?

I guess you should begin trusting people rather than associating prejudices with them.

[mavrothal]

"Could you help us boot Puppy in the XO-1?" is an honest enough question, isn't it?

Actually no, if you do not have a response on the answer "ok, what is your problem"? And _I_ do not. I'm sure when it comes to that, questions will be asked and answers will be given.

But you chose to froth instead:

BTW is the first time that I hear that a FOSS piece of software must be replace by a proprietary one so another FOSS piece of software can run!

Developing free software can cost the intended user, right?

Wrong. Development of free software _does_ cost (maybe more than the commercial) but the cost is not enforced on the end user, which is the intended user. Specially if you consider the XOpup intended users.
No government or other organization is "asking" for an XOpup.
Unless you want me to pay

I guess you should begin trusting people rather than associating prejudices with them.

I believed I made all the arguments I could. In contrast you never offered any argument for the _need_ of a BIOS. Please do instead of resorting to prejudice accusations.
Flames can not cover it. Tell us why a bios is mandatory for puppy.

[raffy]

HI Mavrothal, why cant we seek help of Mitch Bradley who developed OFW for xo ( He can be reached at ~snip~ ). In a previous post you had wished we had a FORTH programmer to help us with this if my memory is correct. Then after that we may be able to seek the help of Barry in this regard. Mavrothal, I ve seen you being very active on OLPC related issues . You may have even contacted Mitch by now.

http://wiki.laptop.org/go/OFW_FAQ

http://wiki.laptop.org/go/User:Wmb%40firmworks.com

Hope above links would help you guys.
Good luck!!!

OK, I sent an email to Mitch CC ttuuxxx. Please reply to Mitch directly.

[amigo]

If I understand all this correctly, it is not a BIOS problem at all. If the Puppy kernel even begins to boot, then there is no BIOS problem. As mavrothal has suggested, the problem lies within Puppy's init sequence. He correctly states that the Puppy init process is extremely complex. It is not tailored for use on the XO, and usage from hard-drives or removeable reas-write media is an afterthought. from the start, the Puppy init process was conceived for a LiveCD distro. In general, this process is *very* different from a normal boot sequence. To get Puppy running on the XO, it will probably be necessary to start from scratch with the intrd and init scripts. Not doing so means that an extra layer of complexity will have to be added to the existing scripts -and for a situation which is completely unforseen by the curent init sequence. Adding to the existing setup would mean a much slower boot than what is necessary. Replacing the init scripts with a more 'normal' init routine -modified for use with BIOS-less XO, would yeild a better result and be easier to implement.

I am still of the opinion that trying to make the OS run from RAM on such low-powered hardware is a mistake. Sure, it will be hard to improve on what other distros have done as far as boot-times. But there is still plenty of room to implement other facets of the Puppy paradigm -the desktop with the GUI helpers, the root-only or power-user concept. I think that the desktop concept that Puppy uses should be separated from the boot concepts it uses. In other words, a more normal installation -fully read-write and running from the installed read-write media, but with a Puppy desktop interface.
One size does not fit all, and it is a waste of time to try and make the XO act just like a PC running from a LiveCD. To reach the goal, one should be willing to abandon any pre-conceptions which stand in the way.

[mavrothal]

In other words, a more normal installation -fully read-write and running from the installed read-write media, but with a Puppy desktop interface.

This is done with palydayz' uPup451 (and hopefully 453 in a couple of days).
The problem is that running an OS from a (camera) SDcard or USB stick, even in a fast machine, is slow because of the extremely slow random read writes of small files in these media. Adding the fact that nobody really knows what the actual erase block in these media is (needed to format them optimally for ext2/3) and that you have to erase and move the entire block if you need to write something else that crosses block boundaries, makes things even worse. I have experienced delays of 1-3 seconds waiting for the read/writes.
The sfs loading into RAM has three additional advantage. a) When read and writes are needed, involve big continuous files where SDcads/USBs can comfortably go up to 6-8MB/sec. b) You do not need to reformat the card/stick maintaining the factory block optimized vfat formatting. c) you minimize wear and tear of the card and reliability of the install.
It is not really the boot times that "worry" me, you boot your machine once every day or every few hours. Is the actual continuous use delays and overly sluggish feeling that is the problem.

+1 for the rest

[Aitch]

mavrothal

The problem is that running an OS from a (camera) SDcard or USB stick, even in a fast machine, is slow because of the extremely slow random read writes of small files in these media

that sounds more like slow 1st generation sd card to me

check out OCZ, I posted a link in the AAO thread here

http://www.murga-linux.com/puppy/viewto ... 663#380663

They make fast SSDs & excellent flash drives

SDs for cameras need to be 300x or so for good write speeds, e.g. Sandisk Extreme 3, but flash is fastest I think

Don't use SDHC as they crawl IMHO

Aitch

[mavrothal]

Aitch
Thanks for the info. AnandTech had actually a nice article on these drives

SDs for cameras need to be 300x or so for good write speeds, e.g. Sandisk Extreme 3, but flash is fastest I think

Don't use SDHC as they crawl IMHO

Aitch

XO-1 can only use SDHC cards and USB sticks. SD slot is nicely tacked under the screen and a perfect place for a "permanent" drive as oppose to a usb stick that can be removed at any point by mistake.
Normaly I use class 6 cards on the XO even if I have a SanDisk Extreme. A $60 card is an overkill for a $200 laptop but even worse, it does not perform any better than the $10 Transcend or Kingston class 6 card. XO-1's card reader is also pretty "picky"... (long story)
Anyway the bottom line is that talking about the XO-1 (and the upcoming XO-1.5) SDHC cards is the likely way to go. Thus RAM-running-puppy a good option.
(see here an extensive discussion regarding SD storage for the XO specifically, if interested)

[raffy]

Please find Mitch Bradley's reply (attached).

[hailpuppy]

hi bUddies,
Thanks raffy you've managed to get Mitch also involved in this effort it seems. . I see only one missing piece in this,Barry to see this thread!!!. Im sure if he sees this he l to join in. Like Raffy did if a BIG GUY in the puppy field like ttuuxxx can invite Barry to join in this would get much easier i guess. by the way as I said i am no tech guy have zero knowledge in linux compared to you guys.if raffy can get Mitch to realy get involved in this it would be even greater.In his mail he himself has said that he was too interested in porting puppy. So we can keep our hopes up i guess.

[ttuuxxx]

Hi guys I read mitch's reply, I'll give it another shot tonight or tomoorow, I usually get frustrated with Xo and go back to another project and come back again, lol Its just that it takes so long to compile a kernel, change the settings, build a release, transfer to a sdcard, test it and within 5 seconds it fails, lol we are talking 4-5 hrs of very borring stuff just to see it go up in smoke in 5 seconds, lol sometimes I do this 1-2 times and skip over to another project for a day or 2, etc but at least I keep trying
ttuuxxx

[hailpuppy]

hi ttuuxxx,

Please keep it up ttuuxxx,if you get puppy to run in ram on xo puppy will be the all time most successful linux distro to ever reach xo.We are all with you,Im sure Mitch will join hands with you if you reach him with your success so far with xo.Nobody can resist a being impressed at such consistent "never say die"effort!!! Damn!! not a day passes without me regretting that I do not have the necessary skills to help you out in this project.

[mavrothal]

Raffy good you e-mailed Mitch (I'm serious).
However, his answer have us exactly where we are. To be specific.
I do use an OLPC kernel with aufs2 and squashfs support and the proper olpc.fth for paths ect. All these are well known. With these (and an olpc initrd) I can get puppy to work in full install which means that OFW is OK with puppy.

Last night I tried lemimah's Puppeee which is designed to boot from an SD/USB after I changed vmliuz and zp431315.sfs (the kernel modules) to an OLPC's ones as well as the "version" with the corrected md5sums . Boots and guess what? "Can not find the sfs files" as all the other pupplets...

Let me repeat once more. Is the damn init script people! (obviously damn only for the XO )
The problem is that the init script (and the entire initrd) is the exclusive territory of Burry Kauler (ok maybe Big_Bash too). Very few people even attempt to touch it. So I think hailpuppy you are ritght, BK is the man for this.

Now ttuuxxx, kernel building is 30 min work and I already send you an easy howto. I can also send you an already compiled kernel with squashfs and Aufs2 support all you need is to rpm -i it and is installed. But is not going to cut it! Is the initrd, not the kernel not the bios not the OFW not anything else! If there is something that needs work, is the init. You do not need to build anything else and spend 5 hours work each time. Just get an initrd to find the sfs files in the stick. Even if the SFS files are the wrong ones for the XO doesn't matter. You are done! Then is all downhill.
PS: If you seriously want to look at puppy init, $pmedia and/or $pdev1 is where the problem lays I believe.

[raffy]

Quirky originally started as a one-file implementation. That way, the program sfs will be there in RAM and must be easy to find. (From previous posts, ttuuxxx is trying Quirky on the XO-1.)

[mavrothal]

Quirky originally started as a one-file implementation. That way, the program sfs will be there in RAM and must be easy to find. (From previous posts, ttuuxxx is trying Quirky on the XO-1.)

Yes, but is not implemented yet and as far as I know ttuuxxx is not trying(ed) quircky/woof builds yet.

[hailpuppy]

Hi Mavrothal,

Why dont you try to contact BK on this. Iv PM him yesterday on this and still its in outbox.

[raffy]

We already have Barry's attention:

"Test single-file Quirky"
http://bkhome.org/blog/?viewDetailed=01337

..if you can get the kernel to start booting, that's it, you should get a desktop..

..the parameters are very simple, something like this to boot from a USB Flash drive:

kernel quir004.t00
append pmedia=usbflash