[OLPC-devel] just verified: 2306 + olpc + linux kernel works.

[Jim Gettys]

I'll be satisfied if there is *one* iron-clad recovery method that does
not depend on the NAND flash.  If it is copy from a USB key to the
flash, so be it.

As far as I'm concerned, we can go wild on other games for convenient
booting and wireless install in a partition on NAND once we've assured
the one recover mode that does not depend on it.  So we can certainly
load modules, have additional code in NAND to make life easy.  And we
can make that flash unwritable (to first order).  

It's just the internet virus making the machines require jtag for repair
that makes me not sleep.

The flash on the iPAQ had bits you could set that would write protect
sectors of the flash (does the NAND flash we have have similar
capabilities?  I dunno). That meant you couldn't write from Linux
without first unprotecting those sectors
                            - Jim


On Thu, 2006-05-25 at 21:16 -0300, Marcelo Tosatti wrote:
> On Thu, May 25, 2006 at 05:22:18PM -0600, Ronald G Minnich wrote:
> > Marcelo Tosatti wrote:
> > 
> > >The statically linked program results in 37112 bytes, and compressed
> > >ext2 rootfs used as RAMDISK (olpc-boot-loader + necessary /dev files)
> > >results in 19458 bytes.
> > >
> > >bzImage (no PCI, no USB, no networking) is about 380k in size,
> > >compressed.
> > 
> > So we're three, right? Wow, Do you think once usb is in we will still be 
> > under (512-64)*1024? This is pretty cool.
> 
> Taking into account that the real boot loader shall contain
> 
> - wireless firmware
> - wireless driver
> - IPv6 stack
> - userspace code to talk over network (DHCP, TFTP, etc).
> - framebuffer driver + nice graphical interface (images).
> - USB
> 
> I'm skeptical about fitting such complete set into 512KB.
> 
> > Stupid question: a friend tells me there is a way to get a kernel build 
> > that results in a Giant Elf that has kernel, initrd, command line in one 
> > blob. Is this true ? I had not seen this (well, I've seen it on Plan 9, 
> > but not on Linux).
> 
> Neither have I... it should not be hard though: stick the offsets of
> such segments relative to the base binary image in the startup code.
> 
> But I don't see much point in doing that?
> 
> LinuxBIOS knows how the kernel's protocol for cmdline/ramdisk
> configuration works, right?
> _______________________________________________
> Devel mailing list
> Devel at laptop.org
> http://mailman.laptop.org/mailman/listinfo/devel
-- 
Jim Gettys
One Laptop Per Child