[OLPC-devel] OLPC "bootloader"

Ray.Tseng at quantatw.com Ray.Tseng at quantatw.com
Sun Jun 25 23:41:06 EDT 2006


Jim,
	You point out electronic serial number issues.
In manufacture process
1) We have the rule to generate the ESN, and print its bar code at flow control card.
2) Every machine is tied with a flow control card.
3) We will use the scanner to read the ESN bar code.
4) Write the ESN into system with utility
5) We can dowload the right image from server accroding to the ESN.

	Here comes a few question?
1) You will follow the System Management BIOS(SMBIOS) standard?
2) Your ESN format?
3) Have you reserved the room in SPI flash to keep these information?

Ray Tseng 6/26/06

	

-----Original Message-----
From: Jim Gettys [mailto:jg at laptop.org] 
Sent: Friday, June 23, 2006 11:17 AM
To: Ray Tseng (曾文瑞)
Cc: blizzard at redhat.com; jordan.crouse at amd.com; devel at laptop.org
Subject: RE: [OLPC-devel] OLPC "bootloader"

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




More information about the Devel mailing list