[OLPC-devel] OLPC "bootloader"

Christopher Blizzard blizzard at redhat.com
Mon Jun 19 09:48:45 EDT 2006


Jordan Crouse wrote:
> Is this still what you are thinking about using to bootstrap from LinuxBIOS
> to the kernel on the NAND flash?  Now that LB seems to be fairly sane, and 
> we've moved to the 1MB ROM, I think its time to start pulling everything 
> together.

Agreed on this point.  I've challenged Marcelo and David to get to the 
point where we're "telling the whole story" on the re-install.  This 
means going from the BIOS to a boot image to a re-install onto the NAND 
flash and actually running our software off the internal flash.

We haven't seen working LinuxBIOS down at the office yet so the idea was 
to use an external flash drive to boot a kernel that gets up and running 
enough to load and boot a kernel off the NAND flash using kexec.

> 
> One thing I noticed is that we need a good way to write a new image to
> the NAND flash.  I'm sure this has probably been discussed in other
> e-mail threads or on IRC, but as far as I know, there really isn't a
> consensus on how we want to do this.
> 
> I think the initrd is as good a place to do it as any - we could pull
> a new .jffs2 image from a USB key or the network (or, heaven help us,
> zmodem) and write it to the MTD block.  The code isn't at all complicated,
> its just a matter of agreeing on how things will be done.

We've spent some time talking about the experience, but not so much 
about the mechanisms.  We've been focused on a couple of areas:

1. Re-install from USB Flash Drive

This could take the form of a .jffs2 image or we could blast a 
filesystem from the USB flash onto a pre-formatted .jffs2.  The IBM 
thing that's listed after this message on this thread gives us more 
options.  I'm glad that's public now.

2. Re-install from Wireless

This is the one that needs the most work and thought, and one of the 
main reasons why we went to 1MB. :)  My thought was to build a very 
simple client on the target machine and then build a reasonably complex 
server on a host machine that "takes over" the machine and manages the 
entire install experience.  The idea being that it's easy to make a 
small client that doesn't change often, but the server is something that 
will change over time.  Plus you're always going to re-install with 
someone you know sitting next to you, both for security and bandwidth 
reasons.

As for the underlying technology for the wireless, I imagine something 
similar to the USB flash drive experience, once you pull down a second 
stage image.  It's getting that image that makes things a little 
challenging.

--Chris



More information about the Devel mailing list