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. > > _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
