[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