Bootloader question

[Mitch Bradley]

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 
above.

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 
footprint).
> 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.
>
>