Top Technology 1 seconds to start Linux tips

Starting the system as fast as possible is very important for automation equipment. The system is able to start at a time that the user cannot perceive, which means that the power supply can be completely disconnected when no work is needed, rather than suspend into hibernation. Based on the Atmel AT91 series on-chip systems and NAND flash, after a series of optimizations, Linux system startup time, from the initial 11 seconds, down to the final 656 milliseconds.

Background knowledge

The system has to go through a lot of processes from power up to full start-up. A simplified start-up process might include:

• Hardware Reset

• Boot loader (bootloader)

• Operating system initialization

• Application Execution

Hardware is critical, but hardware is generally difficult to change. Subsequent optimizations, primarily for the bootstrapper, Linux kernel, and application deployment.

Bootstrapper optimizations

The bootstrapper mainly completes the basic CPU setup, handles ARM tags (atags,arm tags) or the device tree (device trees), and switches the storage snap-in (mmu,memory Management unit).

For U-boot, the most common optimization methods are:

• Delete the function: such as Network load, if not required, then directly remove the code

• Turn off features that you don't need

• Turn off kernel mirroring verification

• Turn off bootstrapper output

• Turn off startup delay

Modify the generic functionality of the bootstrapper to an optimized initial loader (Initial program LOADER,IPL), which can be implemented through SPL (Second program Loader, second stage loader) for U-boot.

Kernel optimization

The Linux kernel is designed to be very flexible and can be configured to optimize for the required functionality. Therefore, optimizing the kernel is critical to the system startup speed.

First of all, remove all not drive, as much as possible to reduce kernel load content, can greatly shorten the system startup time. Second, there are a number of kernel choices that may require further experimentation, such as kernel compression, which is usually a good choice for embedded systems, Lzo compression. Finally, some startup parameters can be customized to speed up the start up. For example, you can use the "lpj=" parameter to preset the value of the number of Beats (loops per JIFFY,LPJ) required for Each loop to avoid the system automatically extrapolating at startup. This can save more than 100ms of time in a ARMv5 based system.

For kernel-initiated optimizations, you can use the bootgraph.pl script (located in kernel source script/bootgraph.pl) to draw a kernel-initiated time-consuming chart to analyze where the boot time is most time-consuming. This script is very simple to generate an SVG diagram by directly using the output of DMESG as its input:

DMESG Perl scripts/bootgraph.pl > Output.svg

The resulting chart is shown below:

Each color segment in the diagram represents the initialization time of a feature. You can simply turn off unwanted features or perform specific optimizations for functionality.

In addition to the kernel itself, the file system in which the kernel resides also has a significant impact on system startup. Ubifs is a good choice for systems that use flash memory chips as storage. It can tolerate accidental power outages and has excellent mounting speed to ensure the system starts quickly.

Application optimization

After the kernel completes the system startup, it is followed by the execution of the application. For application optimization, there are two main parts, one for the application to take over the initiated Init process and the other for optimizing the way the application is linked.

Standard SYSTEMV init program that requires a bunch of startup scripts to execute. For embedded systems, most of them are meaningless. The other part, such as mounting the file system, can be implemented by the application itself. The init process can then be specified directly as an application through the "init=" parameter in the kernel startup parameters.

Dynamic link libraries that apply dependencies are found in the following order:

ld_preload The path specified by the environment variable (general corresponding file/etc/ld.so.preload);

Elf The path specified by the Dt_rpath entry in the dynamic section, if the Dt_runpath entry does not exist;

• The environment variable ld_library_path the specified path, but if the executable has Setuid/setgid permissions, the path is ignored, and the specified –library-path overwrites the path at compile time;

The path specified by the Dt_runpath entry in the elf. Dynamic section;

The path in the ldconfig cache (typically corresponding to the/etc/ld.so.cache file), which is skipped if the link option of-Z nodeflib is used at compile time;

/lib and then/usr/lib the path, and if you use the-Z nodeflib link option, this step is also skipped;

As a result, you can accelerate the link speed by placing the application-dependent dynamic-link libraries on the path of priority lookup. For a cross compilation environment, it is particularly necessary to note that the location of the dynamic link library on the host and the locations on the target system may be inconsistent, which increases the load time of the dynamic link library when the application executes.

Summarize

Based on the three optimization points mentioned above, you can reduce the startup time of the system from the initial 11s to 656ms (data reference the Altenberg of the embedded Linux Conference held in Dublin). From hardware to boot to the kernel and finally to the application, each boot step has its own place to optimize, and with some simple optimizations, it can reduce the startup time of the system.