wmb at laptop.org
Wed Jun 3 23:55:46 EDT 2009
Guylhem Aznar wrote:
> Approx timings from pressing on the power button on my test machine
> using an old 2.6.22 on a jffs2 partition
> 2 seconds with the screen turned off
There is very little that can be done to reduce that 2 seconds, which is
dominated by the time it takes to read the firmware from the SPI FLASH.
SPI FLASH access is very slow because it is done a byte at a time over
the LPC bus, mediated by the embedded controller which is between the
LPC bus and the SPI FLASH. That is the lowest-cost hardware solution.
> 8 seconds to the end the jingle
Okay, right here you may be making an invalid assumption about what is
happening. It is tempting to think that the jingle is taking all this
time. But really what is happening is that the jingle sound is loaded
from SPI FLASH into memory (takes 0.3 sec) and then played autonomously
by the AC97 DMA hardware while other startup operations are being performed.
The end of the jingle is not a useful milestone.
> 11 seconds to the first OFW mesages and boot delay
The 11 second milestone reflects the following operations, which begin
at the 2-second point, i.e. when the jingle starts playing:
a) Init'ing the keyboard - takes about 1 second due to the startup
characteristics of PS/2 keyboards. Can be reduced only at the risk of
unreliable keyboard operation.
b) Probing the USB bus. Takes from 0 to several seconds depending on
what is plugged in. Some USB devices take up to 5 seconds before you
can access them without hangs.
c) Checking for a key to interrupt the boot sequence to get to the ok
prompt. Takes 2 seconds, can be shortened only at the expense of making
it harder to interrupt auto-boot.
d) Checking for developer keys and bootable images on SD and USB.
Usually very fast.
e) Mounting JFFS2 from NAND and searching it for /boot/olpc.fth. This
is the step that takes most of the time. On a minimal installation with
no activities loaded - about 300 MB of NAND occupied- the JFFS2 mount
takes 6 seconds. That time can increase quite a lot as more stuff is
added to NAND and especially if the NAND gets badly fragmented.
The interval from 2 to 11seconds is accounted for by the times mentioned
If an SD card with Windows is installed, the time from power-on to the
first Windows loader screen is 5 seconds, consist with progress through
step (d) above.
At the expense of some utility/reliablity, steps (a) and (c) above could
be reduced, bringing the total time from power-on to transfer of control
from OFW to the OS down to perhaps 3 seconds. But that last 2 seconds
(from 5 down to 3) is not the low-hanging fruit ...
If you want to boot from NAND, the clear win is to make a separate small
boot partition and store the kernel on it in uncompressed form.
Mounting a JFFS2 partition containing 3 MB of data is 100 times faster
than mounting one with 300 MB, so 6 seconds reduces to 60 milliseconds.
Gzip decompression goes at 3 MB/sec on a Geode, which is slower than
NAND access time, so it's a win if the kernel isn't compressed (but with
the standard kernel bzImage build procedures, you don't get an easy
option to do that).
> 18 seconds to initrd load
dominated by decompression time. Eliminate the initrd ...
> 25 to leds blinking
The kernel remounts JFFS2 to get its root FS. Another 6 or so seconds.
UBIFS in the system partition might help...
> 37 seconds to the kernel black screen
JFFS2 is slowed down by the decompression time. Storing the stuff that
is touched during startup in uncompressed form would help
> 45 seconds to mesh initialisation
> 52 seconds it init 2 starting its daemons
> 58 seconds to startx
> 1:04 seconds to having X loaded
> 1:10 seconds to having opera loaded and displaying the page
> Pretests results show a usage pattern where doctors prefer to power on
> the laptop when some specific information is needed. This behaviour is
> based on multiple factors, but in the end having a minute of delay is
> considered too long and could discourage users.
> IMHO jffs2 is only responsible for ~20 seconds (between initrd load
> and kernel black screen). I see ~10 other seconds before that which
> could be cut, if the boot status was saved and reused (something that
> old eeepcs do, saving HW status to the a special partition. Maybe ofw
> can also do that too?)Then there's 5 seconds of boot delay that a ofw
> recompilation can fix.
As detailed above, the conjecture that you can shave 5 seconds by
recompiling OFW is incorrect.
> The kernel init improvements will certainly bring 15 other seconds.
> Maybe some parallelisation of the sysvinit will save some time, say 5
> seconds (low end estimation)
Parallelization will not help at all if you are using JFFS2. The low
level NAND driver that JFFS2 uses busy waits for I/O, and then JFFS2 is
CPU-bound on the decompression step, preventing any useful concurrency.
The busy-wait could be changed to an interrupt - if only someone had
time to do the work and test it extensively. The decompression is going
to be CPU bound no matter what you do, so the only option is to arrange
for the important files not to be compressed (thus increasing the NAND
> So I see a boot delay that could be easily
Easily? Yeah, right.
> cut by half, and maybe
> reach 20 seconds while doing some moblin-like preinitialisation for
> the x server, etc.
More information about the Devel