Android Boot Time Optimization

Content is no longer maintained and is being kept for reference only!

Introduction

This wiki gives a high level overview of some of the possible approaches to reduce the boot time for TIs Android releases. Boot time for the purpose of this document is defined as the time taken from the “power on till android lock screen comes up”. Following three factors were considered in reducing the boot up time.

• Use a faster file system
• Remove unnecessary initializations
• Improve system throughput to reduce time taken for copy

Android Boot Sequence

The following modules run while android boots. For more details refer [1], [2] or [3] in the references section.

BootRom

Small piece of code that is hardwired in the CPU ASIC which loads x-loader

X-loader

Initial bootloader which initializes memory and loads u-boot from mmc/nand/serial

U-boot

Bootloader code which does memory and peripheral initialization and loads kernel to RAM

Kernel

Is the main component here, this involves uncompressing the kernel, initializing the processor, initializing the platform, initializing the peripherals we need etc. Kernel also mounts file system and runs the first userpace process "init"

Android

The init process started by kernel parses init.rc. It starts several services and daemons including zygote. Zygote preloads classes which are shared between applications thus reducing the memory usage and application launch time, initializes dalvic virtual m/c and starts system server The system server is the first java component to run in the system. It will start all the Android services

Measuring Boot Time

There are many methods available to measure the time. Grabserial utility was used to measure the boot time with logelvel in init.rc being changed to 8 from 3 to get more logs. Grabserail prints time for each serial message it recieves on the console. Few other options are:

• PRINTK_TIME option in kernel can be used to measure time taken for kernel booting
• Bootchart is graphical representation of boot process.This bootchart can be used to analyse boot process
• stop watch

Speeding Up Things

Optimizing X-loader

Please refer wiki http://processors.wiki.ti.com/index.php/Optimize_Linux_Boot_Time  for general x-loader optimization. One of the most importants point to note here is that we need to make sure that processor clock rate is set to the maximum possible rate. This will greatly reduce the time taken.

Optimizing U-Boot

To optimize u-boot, follow the below steps. Without optimization normally u-boot execution takes approximately 6s

• Copying the kernel to the RAM location and uncompressing the kernel image takes approximately 4s. To reduce this, focus on optimizing the NAND driver to increase the throughput. Enable hardware ECC if that possibility is available; similarly use NAND part specific optimizations if such an option exists. Once throughput has been increased you could look at using an uncompressed kernel which will further reduce boot up time by saving on the time taken to uncompress the kernel
• Remove unnecessary modules from u-boot.
• By default, kernel is copied into a location in RAM and from there its moved into another location. This double copy of the kernel image should be disabled. This can be achieved by optimizing the "bootm" command in u-boot
• And just like in the other phases, we should make sure that RAM timing values are adjusted properly so as to achieve optimal RAM throughput.
• Turn on I-Cache

Please refer wiki http://processors.wiki.ti.com/index.php/Optimize_Linux_Boot_Time for general bootloader optimization techniques

Optimizing Kernel

Please refer wiki http://processors.wiki.ti.com/index.php/Optimize_Linux_Boot_Time  for general kernel optimization techniques. In addition, we should make sure that the processor is clocked at the highest value, RAM timings should be optimal to ensure maximum RAM throughput and also NAND driver throughput should be optimized to ensure the best performance.

Optimizing Android

Quite a big chunk of Android boot up time goes into booting Android itself. To reduce this, the focus should be to improve the NAND throughput and the RAM throughput. Once this has been achieved, we can focus on moving the file system to ubifs if there is support for NAND on your system. If there is no NAND on your system, try to use the fastest card possible, and always make sure to shut down the system properly.

If there is support for NAND on your system, moving to UBIFS file system can significantly reduce the boot up time for e.g., on AM 37x approximately 10s were saved just by moving to UBIFS (nos given below for proof on a sample system). [4] talks about how to create UBIFS images.

After migrating to UBIFS, you can try to identify modules which are not relevant for your system. For e.g., Telephony, Bluetooth. Removing these packages reduces the time taken to parse and initialize these packages. This does not reduce the boot time significantly though.

Another option is to trade off boot time with performance. Analyzing the android boot process, using bootchart or logcat reveals that zygote pre-loading and the package scanning are two time consumers. We can disable pre-loading of classes which will reduce the boot time. You have to note that there will be a performance penalty attached with this approach, including greater application load time and memory usage after boot up. During testing we found that there was approximately 5s saved without pre-loading any classes. For details on pre-loading refer [5] from Reference section

Boot Time Numbers For Different File system

	ext3	ext4	ubifs
AM37x	40s	39s	29s

Note: These numbers are without x-loader/u-boot/kernel/android optimization

• x-loader, u-boot and kernel optimization can reduce boot time upto 8s
• Removing android pre-loading can reduce the number by approximately 5s

Conclusion

From our study on boot time, we found out that in order to reduce Android boot up time, most effort has to be spent on improving NAND throughput and RAM throughput, This has to be done at x-loader, u-boot and kernel levels. UBIFS file system also greatly reduces the boot up time. Optimizations at the Android layer do not yield much reduction in boot up time except for disabling preloaded classes which reduces the boot up time by 5s.

References

[1] http://www.androidenea.com/2009/06/android-boot-process-from-power-on.html

[2] http://elinux.org/Android_Booting

[3] http://bootloader.wikidot.com/linux:boot:android

[4]  http://processors.wiki.ti.com/index.php/TI-Android-GingerBread-2.3.4-DevKit-2.1_UserGuide#Creating_ubifs_images

[5] http://elinux.org/Improving_Android_Boot_Time_Outline