wmb at laptop.org
Thu Jun 4 19:59:23 EDT 2009
> 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"
More information about the Devel