[OLPC-devel] OLPC "bootloader"

[Jim Gettys]

I think Ray has an excellent point here, and we implement install over
ethernet in time for B-Test.  It is exactly how Brightstar deals with 27
million cell phones/year; they connect a cable and download bits into
each phone, which have to have unique contents (codes for each phone).
Brightstar can tell you exactly which bits have been loaded into exactly
which serial number device.  It means you can write a program from a
central server that can *know* exactly what image was installed on what
machine (since we have a wireless MAC address, we have an electronic
serial number we can access).

So as soon as we have assembled the pieces we have all working already
(which I think is our immediate milestone to bring LinuxBIOS to full
use), I recommend we implement install via wired ethernet from USB
*before* moving on to install over wireless (where the security issues
are harder).  It is the natural progress of development, in any case.
                                       Regards,
                                           - Jim

On Fri, 2006-06-23 at 09:43 +0800, Ray.Tseng at quantatw.com wrote:
> >From manufacture point of view:
> 1. Re-install from USB Flash Drive: it's hard to control the image distributed on many many USB flash drive  
> 2. Re-install from Wireless: Lot of wireless communication may interfere, and throughput will slow down.
> 
> Do we consider the option#3?
> 3. Re-install from USB Wired LAN
> Stable, high speed and central control.
> 
> Ray Tseng 6/23/06
> 
> -----Original Message-----
> From: devel-bounces at laptop.org [mailto:devel-bounces at laptop.org] On Behalf Of Christopher Blizzard
> Sent: Monday, June 19, 2006 9:49 PM
> To: Jordan Crouse
> Cc: devel at laptop.org
> Subject: Re: [OLPC-devel] OLPC "bootloader"
> 
> 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
> _______________________________________________
> Devel mailing list
> Devel at laptop.org
> http://mailman.laptop.org/mailman/listinfo/devel
> _______________________________________________
> Devel mailing list
> Devel at laptop.org
> http://mailman.laptop.org/mailman/listinfo/devel
-- 
Jim Gettys
One Laptop Per Child