Optimizing the boot time of android embedded devices

[NilesH]

I actually referred a paper and the summary of our idea is a follows

Fast boot is essential for consumer devices in automotive, medical and
entertainment markets. I describe an efficient bootloader design and
explain how to optimally configure Android’s Linux based kernel for
embedded systems. The basic idea to detail Android userspace design
changes to reach the home screen quickly and allow users to execute
crucial applications first.

BASIC IDEA:
In embedded systems, existing bootloaders run in three stages. But the
main focus should be on the vendor bootloader and the third stage
bootloader. U-boot and Barebox are examples of third stage bootloaders
that provide a rich set of features. It propose to eliminate the third
stage bootloader by combining its essential features into the vendor
bootloader, creating a single stage bootloader. The single stage
bootloader is small enough to run in the SRAM of 14KB on our setup and
its design constructs are as follows:
# Add capability to load kernel from non-volatile memory. U-Boot or
Barebox only duplicates these activities.
# Configure only those hardware devices that are genuinely
indispensible for system startup such as
system clock setting, RAM initialization, and configuration of NAND.
# System clock should be set to highest possible stable

I FEEL TO USE COMPRESSED IMAGE. BECAUSE THE EXISTING U-BOOT LOADER HAS
LZMA COMPRESSION/DECOMPRESSION TECHNIQUE AND THERE'S A SLIGHTLY
IMPROVED NEW COMPRESSION/DECOMPRESSION TECHNIQUE CALLED XZ TECHNIQUE.


WE FIRST NEED TO MAINLINE THAT .XZ technique IN U BOOT LOADER AND USE
COMPRESSED IMAGE OF KERNEL.

I also feel to remove some modules that take much time to load and are
not necessary at the boot time. Reducing kernel size will shorten the
load time of kernel from slow non-volatile memory.


Other than XZ we can also use other technique that uncompresses image
fast..

I heard that mainlining the Bootloaders is not allowed.
Please can somebody help me with this...

[Tim Bird]

On 08/22/2011 01:59 AM, NilesH wrote:
> BASIC IDEA:
> In embedded systems, existing bootloaders run in three stages. But the
> main focus should be on the vendor bootloader and the third stage
> bootloader. U-boot and Barebox are examples of third stage bootloaders
> that provide a rich set of features. It propose to eliminate the third
> stage bootloader by combining its essential features into the vendor
> bootloader, creating a single stage bootloader.

Just a comment on this. While improvements to bootloader performance
are helpful, the kernel and bootloader are not the difficult problem
areas in Android boot time. Techniques for achieving boot times
for the bootloader and kernel in the 1 to 2 second range are
well-documented (see http://elinux.org/Boot_Time for resources).
Of course there's always a good amount of effort required getting
the specific solutions working on your hardware ;-)

However, the big problem with Android boot time is the user-space
portion of the boot. The overall init system, involving
loading and initializing multiple daemons (some with networking
waits), as well as initializing zygote and preloading classes,
and doing the package scanning and manifest/security validation --
these are where the big time is spent in Android boot time
(in a cold boot situation).

These are, IMHO, more difficult to work on, but have the potential
for bigger impact (across a wider variety of platforms).

In case people haven't seen it, there is some information at:
http://elinux.org/Android_Booting

Just my 2 cents.
-- Tim

=============================
Tim Bird
Architecture Group Chair, CE Workgroup of the Linux Foundation
Senior Staff Engineer, Sony Network Entertainment
=============================

[NilesH Somani]

Thank u sir
So basically the init process slow downs the android boot up time..
Recently i came accross a link which showed the booting of android that is the display of the home screen in 1 sec..

http://www.linuxfordevices.com/c/a/News/Ubiquitous-QuickBoot/?kc=LNXDEVNL032410
 

--
unsubscribe: android-kerne...@googlegroups.com
website: http://groups.google.com/group/android-kernel

[Tim Bird]

On 08/24/2011 10:54 AM, NilesH Somani wrote:
> Thank u sir
> So basically the init process slow downs the android boot up time..

I would word it differently. The part of the boot where 'init' is
running is usually the longest part.

> Recently i came accross a link which showed the booting of android that
> is the display of the home screen in 1 sec..
>
> http://www.linuxfordevices.com/c/a/News/Ubiquitous-QuickBoot/?kc=LNXDEVNL032410

This is using the "snapshot boot" approach, which is one way
to address the problem. It's basically a specialized un-hibernate,
which bypasses many tasks normally done during a cold boot.

It's not the same as optimizing the boot-time processing, and
has both pros and cons. (e.g. one drawback is a fairly large
reserved space in flash for the snapshotted system image).

[NilesH Somani]

I agree about the memory problems in flash.

But next generation smartphones will be having SSD's.. Not much restriction on number of writes plus access time.
and samsung and toshiba have already started with the release.

http://www.trustedreviews.com/news/Toshiba-Reveals-128GB-Smartphone-Flash-Memory

and even with better compression techniques like lzma that compresses 33% more than that of gzip.
and with processor's like snapdragon and hummingbird (both 1GHZ now and will be more powerful in future) that can uncompress the images faster than ever shouldn't the focuss must be given here. Its just an opinion.

As u mentioned previously and i even went through your presentation at LinuxCon North America, August 2010 that said more boot time is consumed in user space portion of boot.
But i suppose even if we do optimize some start up services or package scanning or network initialization delays.. In future there are going to be more packages no doubt.. and there might be a case where u cant optimize it further and still the boot time is more.

So shouldn't we try what these Ubiquitous QuickBoot did and make it opensource as Quickboot is not