Bootloader question

[Mitch Bradley]

> As for speedups, I see 2 different ways :
>  a) using a SD with a fat partition + ext2 filesystem
>  b) using the nand with a fat partition + ubifs - this requires 2.6.29
> which is not ready yet.
>   

A FAT partition will not work well on the raw NAND of XO-1, because of 
blocksize, erase block size, and wear leveling issues.  It would be 
better to use a smallish boot partition of say 10 MB, formatted in 
JFFS2.  JFFS2 is fine for small partition sizes.  It only starts to be 
troublesome with large partitions.

> It's hard to chose at the moment. I guess I'll stick to b) and hope
> 2.6.29 makes it better, and if it doesn't go for a)
>
> Mitch says there's very little time to gain and provides an excellent
> analysis. I just have a final question there : regarding the 2 seconds
> SPI flash slowdown, is there a way to boot from the NAND (without
> reading the full SPI) if there's a special partition at the beginning,
> or if there isn't or if a special key is pressed at boottime, go back
> to SPI OFW?
>   

That won't work.  The only way that the CPU can start is by fetching 
from SPI FLASH.

If you wanted to get into the firmware business, you could write a 
smallish NAND reader that loads from SPI FLASH then reads the rest from 
NAND.  Doing so would require a substantial amount of detailed knowledge 
about the hardware, would be difficult to debug and maintain, would 
require great care to prevent "bricking" the machine if the NAND 
contents were overwritten, and might reduce the startup time by 1 second.
> To sum up what I've read in this thread, what should be done in any case :
> a) discarding jffs2
> b) discarding initrd
> c) storing the kernel uncompressed in an uncompressed small partition
>   

Actually, there is an alternative to discarding the initrd.  The trick 
would be to ensure that most of the stuff in the initrd is reused during 
runtime, thus avoiding the need to reload the same stuff later.  I've 
done that with embedded systems, in which the entire filesystem is 
included in initrd, copied to a ram FS, and used forever.

Loading initrd from a small JFFS2 partition is just as fast as loading 
the same amount of code/libraries/files from any other filesystem, and 
perhaps even faster, since the reads are likely to be sequential and can 
be done in large chunks.

The case in which initrd is wasteful is when a large amount of stuff 
from initrd is discarded and then reloaded again from a different FS.

> And yes, this seems trivial to do - the low hanging fruit.
>   

Please, can we stop using the word "trivial"?  Although you might not 
mean it that way, the subtext of saying things are "trivial" or "easy" 
is that the people who didn't do these "obvious" things in the past are 
stupid or lazy.

It is true that many of the speedup techniques that have been discussed 
are individually easy to understand and think about, but putting 
together all the pieces and making them work together flawlessly 
requires a substantial amount of effort.  I would be pleased to see 
someone make that effort, but asserting that the whole deal is "easy" is 
disrespectful to the people who have spent countless hours packaging the 
various OLPC distributions and sorting out many hundreds of "little" 
problems.