5 sec boot

Mitch Bradley wmb at laptop.org
Sun Oct 5 14:36:15 EDT 2008

NoiseEHC wrote:
> When I will finally have some time (currently I am working even on 
> weekends) I will finish my half made zlib decompression code.

To what end?  AFAIK the zlib decompression (both in OFW and in the OS) 
is not one of the primary problem areas.

> Where is that Security hash's code?
The computation code is at http://dev.laptop.org/git?p=bios-crypto .  It 
is based on LibTomCrypt.

The specific hashes and signatures that we use are detailed in the 
"Computation" column of http://wiki.laptop.org/go/Firmware_security#Summary

The security computation code has undergone an audit by outside security 
experts.  Any changes to the core code would require an additional audit.

> Mitch Bradley wrote:
>> Memory to memory copy: 500 MB/s
>> Raw NAND FLASH read:    20 MB/s
>> Security hash:           4 MB/s
>> So overlapping hash calculation with NAND FLASH read is of limited 
>> value, and trying to overlap anything with memory copy is almost 
>> certainly counterproductive.
>> This discussion seem to be degenerating into a brainstorming session 
>> about an sub-problem that is pretty well under control (the firmware 
>> component of the boot time).  I've been working diligently on that 
>> sub-problem for nearly 2 years now, and I think I have an excellent 
>> grasp of where the cycles are going and what can be done to improve 
>> it.  The only significant opportunity at this point is to reduce the 
>> JFFS2 time, which will require either partitioning or abandoning 
>> JFFS2 for the boot files, or both.  UBI+UBIFS is one workable 
>> approach in the context of a Linux-only machine.  There are some 
>> others, such as Redboot partitions with a small boot partition and a 
>> large system partition, with various FS possibilities for the two 
>> partitions.  The quickest path to a deliverable system would be 
>> Redboot + JFFS2 boot partition + UBI system partition.
>> The rest of the "fruit" on the tree is solidly in the OS domain, 
>> encompassing kernel startup, userland startup/initscripts, X startup, 
>> and Sugar / application startup.  I would encourage each of you to 
>> address the areas in which you have special expertise, and then to 
>> take action.

More information about the Devel mailing list