Reducing Boot Time in Embedded Linux Systems

Using some reasonably simple techniques, you may be able to reduce dramatically the boot time of your embedded Linux system.

Bootloader Considerations

Virtually every embedded system has some type of bootloader, and there are
many bootloaders from which to choose. Some of the more popular include U-Boot
for PowerPC, MIPS and ARM processors, and RedBoot, which is frequently found on ARM
processors. Most popular bootloaders today contain far more functionality
than actually is required for the task of initializing a system. Indeed,
they have become valuable tools used by developers during initial board bring-up and
system development.

Modern bootloaders are packed with features, such as Flash erase and program
utilities, memory management utilities, network capabilities for loading
images and for self-configuring (DHCP and BOOTP for example), drivers for PCI,
IDE, USB and support for various partition types and filesystems. Some
even have scripting language support useful for development, manufacturing
(production test, image load and so on) and system upgrade.

These features make bootloaders an indispensable tool during product
development. However, the size of bootloader images has significant impact
on boot time. Bootloaders are stored in nonvolatile storage media, most
commonly NOR Flash. However, embedded systems rarely execute code directly
from Flash, mostly because it is far too slow. Read times of DRAM are
orders of magnitude faster than read times from Flash.

The first job of the bootloader is to load itself into DRAM and continue
execution from there. Consider the operating environment of early boot
code. There is no stack, no C context (meaning all this code is written
in the processor's native assembly language), and quite often, the
processor's instruction and data caches are not yet enabled. This means
the size of the bootloader image, which needs to be copied into RAM,
will have a major impact on startup time.

The quickest path to performance improvement in your bootloader is to keep
it small. Remove features that are unnecessary in a production
environment. Some bootloaders, such as U-Boot, make it easy to do this. Its
features are driven by a board-specific configuration file that contains
directives to enable or disable features. Your requirements will
ultimately rule, but prudent trimming of all but the most essential
features will yield significant savings in boot time.

Uncompressed Kernel

When you build a Linux kernel image, it is virtually always compressed as
one of the final build steps. It is the responsibility of your bootloader
(or a small bootstrap decompression loader that is appended to your kernel
image) to decompress the kernel image and place it into system memory. One
of the single largest easy gains you can achieve is to remove the
decompression stage. Some architecture/bootloader combinations don't
bother to enable caches, making decompression take much longer. It is not
uncommon to find systems that take several seconds to perform the
decompression and relocation stage. Using an uncompressed kernel can
significantly reduce your system boot time.

Eliminate initrd/initramfs

Linux distributions use initrd/initramfs (hereinafter referred to as simply
initramfs) primarily as a tool to enable a generic kernel to be used across
a huge variety of system configurations. It is the job of the initramfs to
provide the necessary device drivers to enable the devices that are
required to complete system boot. Because embedded systems often
are restricted to limited well-known configurations, they usually can eliminate
initramfs with a corresponding reduction in boot time. Furthermore,
removing support for initramfs in the kernel results in a smaller
kernel (and, thus, faster boot.)

Smaller Kernels Boot Faster

If you compile a kernel with a “default” configuration, it often
contains a vast number of features your system may not need. You may
be surprised to discover how many features are enabled by default that your
embedded system does not need. Spend some quality time with your favorite
kernel configuration editor (menuconfig, gconfig and so on), and go through each
and every kernel configuration parameter. Evaluate whether your system
requirements can do without it. Yes, it may take you the better part of a day (or even
more if you add in some research time), but your savings in boot time
reduction can be substantial. Some examples of features found in many
default kernel configs include IPv6, RAID, support for many filesystems
you may not need, extended partition support and many more. There
also may be numerous device drivers compiled into the kernel for devices
that
are not present in your system. They are harmless, but each driver runs
initialization code, including registration functions, and some spend
lengthy milliseconds (or more) in device probe routines for devices that
are not present—precious boot time can be spent probing for
non-existent devices.