4

I am trying to improve the kernel boot time of my device and I would like some help. I am using OMAPL138 with kernel version 2.6.37 and it takes about 50 seconds until the boot process is finished, and I think it is a long time. Below is the image of some stages of the boot process. As you can see, there is a delay of 19 seconds until the message EMAC: MII PHY CONFIGURED shows up and I think this is the main problem of my boot time.

kernel boot process

After some tests I discovered that this delay is during the unpacking of the initramfs.cpio.lzma . I discovered it by printing some messages in the initramfs.c file, and this delay happens in the while loop inside the unpack_to_rootfs function. The initramfs.cpio.lzma has 5.3MB and the total kernel image (uImage) has 7.3MB .

My question is: Am I doing something wrong or the only way to improve this is by reducing the size of my kernel? Maybe some of you had to deal with this problem before so I would like some suggestions on how to proceed to improve my boot time. Thank you very much.

2
  • 1
    if copying would be faster than decompression, you could use GZIP's level 0, which just stores without compressing Apr 27 '15 at 19:31
  • Thank you Janus, I will try this and post the result here
    – theGabor
    May 5 '15 at 12:00
1

Possibly not a CPU bottleneck but slow flash media access time? Found this thread below on the TI forums talking about flash throughput being limited to 0.6 MB/sec. OMAP-L138 EVM SPI Flash read performance and boot time

For a test (as Janus suggested), see if you can compress a kernel image and/or the initramfs with gzip -0 if possible. Or might be simpler to (on another workstation), get a copy of your initramfs.cpio.lzma file, uncompress it to initramfs.cpio, then recompress with lzma -0. Overwrite the new recompressed file back to your flash media. I would expect the file should be slightly larger. If boots faster, then probably CPU was a bottleneck. If it boots slower, then likely IO was the bottleneck.

Maybe even repeat the test with lzma -9, but beware can require lots of memory for both compression and decompression.

Here's an excerpt from the lzma (v5.07) man page:

     On the same hardware, the decompression speed is approximately
     a constant number of bytes of compressed data per second.   In
     other words, the better the compression, the faster the decom-
     pression will usually be.  This also means that the amount  of
     uncompressed output produced per second can vary a lot.

     The following table summarises the features of the presets:

            Preset   DictSize   CompCPU   CompMem   DecMem
              -0     256 KiB       0        3 MiB    1 MiB
              -1       1 MiB       1        9 MiB    2 MiB
              -2       2 MiB       2       17 MiB    3 MiB
              -3       4 MiB       3       32 MiB    5 MiB
              -4       4 MiB       4       48 MiB    5 MiB
              -5       8 MiB       5       94 MiB    9 MiB
              -6       8 MiB       6       94 MiB    9 MiB
              -7      16 MiB       6      186 MiB   17 MiB
              -8      32 MiB       6      370 MiB   33 MiB
              -9      64 MiB       6      674 MiB   65 MiB
3
  • Thank you Joshua, I did not see this thread on TI. I will follow your instructions and post results here.
    – theGabor
    May 5 '15 at 12:02
  • Joshua, I compressed using lzma -0 and now it boots slower. I was using lzma -9 before and the intiramfs.cpio.lzma size was 5.3MB, now with lzma -0 the size is 7.1MB and it takes a little more time to boot. So do you think this is a slow flash media access time?
    – theGabor
    May 5 '15 at 13:35
  • Per the man page, it says that lzma decompression is actually faster with higher compression levels. So not able to make a definite conclusion whether it's CPU or media IO. Just based on the TI forum thread above, it seems that the media access might be done 1 byte at a time, so with 50 MHz clock on the media interface, this would explain a max 0.6 MB/sec transfer from flash memory to system memory. Here's a page with possible ways to optimize that transfer: processors.wiki.ti.com/index.php/… May 5 '15 at 16:57
0

If the IO speed is not the bottleneck, then another option is to use LZ4 compression, which gives files a bit bigger than gzip, but decompression is extremely fast.

The kernel config option to compress the kernel with this is CONFIG_KERNEL_LZ4=y.

http://events.linuxfoundation.org/sites/events/files/lcjpcojp13_klee.pdf

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.