Fast boot based on arm embedded Linux

by Toradex Hussam

Some applications of the ARM platform embedded Linux have special requirements for system startup time. In many cases, these systems do not need to be immediately seated for all tasks, but must be able to handle certain mission-critical tasks, such as receiving Ethernet commands or displaying the user interface. This blog post will provide some methods and simple steps to optimize startup time based on the Toradex Colibri i.mx6 arm system module.

tip: Some of the methods involved in this article need to recompile the u-boot, kernel, and file systems. Please refer to the relevant articles on the Toradex Developer Center website attached at the end of this article.

Before we start to optimize, we need an appropriate method to measure the start-up time. If you want to measure startup time very accurately, this may even involve hardware (such as GPIO and oscilloscopes). In the vast majority of occasions, through the Monitoring System serial console output is quite accurate. Tim Bird's grabserial is a widely used tool that can be used to view the time information of the serial console output. This tool can add a timestamp for each line of information received, as shown below:

--------------------------------------

[Email protected]:~/software/grabserial-1.8.1$ sudo./grabserial-d/dev/ttyusb0-t

[0.000003 0.000003]

[0.267171 0.267168]

[0.267267 0.000096] U-boot 2015.04 (Dec 15 2015-16:07:42)

[0.271167 0.003900]

[0.271261 0.000094] Cpu:freescale i.mx6dl rev1.1 at 792 MHz

[0.275565 0.004304] Reset Cause:por

[0.277501 0.001936] I2c:ready

[0.278540 0.001039] dram:512 MiB

......

--------------------------------------

The first column number represents the timestamp (from the first character received), and the second line represents the time interval between the receipt of the current row and the previous line of information.

Linux system startup, can be divided into the following 3 stages, the article will be discussed.

-Boot Loader

-Linux Kernel

-User Space (init system)

Boot Loader

In fact, there are two steps before boot loader boot: hardware initialization and boot ROM. The hardware initialization needs to meet the power supply sequencing and the bus and processor chip reset timing requirements. The time spent in this phase is generally fixed, at a level of ten Ms.

Figure 1 Boot ROM boot time

In Figure 1, the yellow signal is the core board VCC, and the blue signal is the serial output TX. The time between the power from the core board and the first character of the serial port output is approximately 102ms. This is the hardware initialization of the Colibri i.mx6d and the boot ROM running time. Since this part of the code is cured on the SOC, it is generally not possible for the user to optimize it.

The ARM processor starts the firmware from the internal ROM. The firmware loads boot loader from the boot media. The time in this phase is generally very short, depending on the boot loader size. In addition to reducing the boot loader volume, it is difficult to do other optimizations. The optimizations and tweaks that can actually be done are still in boot loader (u-boot).

The current release of the V2.5 Beta 3 release, from the first character output to the kernel boot time of about 1.7 seconds. The following processes are mainly involved:

-U-boot initialization (approximately 370 MS, from the first character received)

-autoboot delay (1s)

-read device tree and kernel load (127 ms)

-Load device tree and kernel load (approx. ms)

-Last jump to kernel start address

Uboot boot to kernel boot time: ~1700ms

The most significant optimization is to reduce autoboot delay. This value can be set to 0 using the following command:

--------------------------------------

Setenv BootDelay 0

Saveenv

--------------------------------------

This can also be configured as a default value using Config_bootdelay. In the current release version, if BootDelay is set to 0, there will be no way to go directly to boot loader's command-line mode. U-boot provides an option for Config_zero_bootdelay_check, which is used to detect a character in the case of a bootdelay of 0. We have added it to the default configuration for the next release version.

Uboot boot to kernel boot time: ~700ms

Removing some features helps reduce the time to allocate and initialize these features. For example, removing the USB Client and the DFU feature, please download the relevant patch from here.

This reduces the u-boot size to 289 KB and shortens the U-boot read time. In the same way, you can tailor unwanted peripheral support and functionality to the actual peripheral needs of your project. Obviously the kernel size and load time are linearly related, so optimizing the kernel size will further increase the boot time.

Kernel

To measure only the kernel boot time, you can use the Grabserial matching feature to reset the time in the boot loader output message.

--------------------------------------

sudo./grabserial-d/dev/ttyusb0-t-M "^starting kernel*"-Q "^\[*[]0-9. * Freeing unused kernel memory.* "

--------------------------------------

The timing of the start-up is somewhat difficult to determine because the kernel will continue to initialize the hardware, even if the file system is mounted and the first user-space process (init) starts running (delayed initialization). "Freeing unused kernel memory" is the last message issued before the INIT process starts, so it is marked as the end of the kernel linear task (see Kernel_init in INIT/MAIN.C). I will use the timestamp information of this information to compare the startup time. The default kernel on our module has a compression size of 4.8MB and a boot time of 4.6 seconds.

Kernel boot time to init: 4.6 seconds.

Like U-boot, the Linux kernel also synchronously sends information to the serial port. The specific method depends on the serial port used, it will wait until the character is sent over the serial port. The advantage of this is that when the kernel crashes, all the information at that time is visible. If the information is asynchronous output, the last output will not indicate where the kernel crashed.

There is a parameter in the kernel that minimizes the output information: "Quiet". However, this will also block the character information ("Freeing unused kernel memory") of our test startup time. The simplest way to output this information is to use the log level to output specific information. Search for "Freeing%s memory" in ' mm/page_alloc.c '. I will use ' pr_alert ' to output the information. This method is up to 3 seconds high.

--------------------------------------

[0.925608 0.000178] Starting kernel ...

[0.002166 0.002166]

......

[1.432211 0.207636] [1.203216] freeing unused kernel [email protected]:~/software/grabserial-1.8.1$

--------------------------------------

Kernel Boot to init start time increased to 1.4 seconds.

Another easy way to further improve startup time is to remove the feature. The Yocto project provides a handy tool for ksize.py, which needs to be run in the kernel compilation directory. This tool can show the size of each part of the kernel. The first table shows a general overview (to get an accurate overview, use make clean before compiling).

--------------------------------------

[Email protected]:~/toradex/webinar/linux-toradex$./ksize.py

Linux Kernel Total | Text data BSS

--------------------------------------------------------------------------------

Vmlinux 9321389 | 8589061 311188 421140

--------------------------------------------------------------------------------

DRIVERS/BUILT-IN.O 2973586 | 2810983 121247 41356

......

USR/BUILT-IN.O 138 | 138 0 0

--------------------------------------------------------------------------------

Sum 8174774 | 7475382 283956 415436

Delta 1146615 | 1113679 27232 5704

--------------------------------------

The general application-related features that can be safely removed. Browsing through the first-level catalogs helps you quickly determine which objects are most likely to be removed.

The other one can help us to further analysis, the kernel boot when the various functions consumed time is the use of Linux source scripts/bootgraph.pl script, the boot log for graphical analysis. To do this, you need to configure the U-boot in

--------------------------------------

Setenv Defargs ' enable_wait_mode=off galcore.contiguoussize=50331648 initcall_debug printk.time=1 quiet '

--------------------------------------

Export logs in Linux

--------------------------------------

[Email protected]:~# dmesg > Boot.log

--------------------------------------

Run the following command on your computer

--------------------------------------

Cat./boot.log |./scripts/bootgraph.pl > BOOT.SVG

--------------------------------------

Figure 2 Kernel Boot

The unnecessary drivers are removed from the kernel based on the analysis of the tools above, as well as the requirements of the actual project peripherals and functions. For example, we will remove the wireless network driver, CAAM (i.mx6 hardware encryption Accelerator module), File System (EXT4, NFS, CIFS, etc.), SPI and other functions. After recompilation, the new kernel is reduced to 3.6 MB.

--------------------------------------

[0.818066 0.000252] Starting kernel ...

......

[0.909013 0.434209] [0.723273] freeing unused kernel [email protected]:~/software/grabserial-1.8.1$

--------------------------------------

Kernel Boot to init start time increased to 0.9 seconds.

User Space

Systemd

In Linux user space, initialization work is done by the INIT system. Toradex BSP Mirror uses the NGSTR standard to start the init system, which is called SYSTEMD. SYSTEMD is now a standard init system for desktop Linux, with rich functionality, especially for dynamic systems. SYSTEMD also affects the startup time. Multiple daemons can be started at the same time (using the current multi-core system); Support for activating the socket and enabling on-demand device activation at a later time delay loading the service. Also, the integrated log daemon Journald saves space due to the use of binary log files and improved log file management.

Depending on the actual application, an embedded system may be quite static. Therefore, SYSTEMD dynamic functionality is not required. Unfortunately, Systemd is not a very modular system, and each module is interdependent. This makes it difficult to streamline SYSTEMD. This section will be a two-part, the first part uses SYSTEMD to start the optimization technology, the second chapter uses System v.

In these two sections, we use "freeing unused kernel memory" as the measuring base time.

sudo./grabserial-d/dev/ttyusb0-t-M "^\[*[]0-9. * Freeing unused kernel memory.* "

In the default BSP

User space starts at login for ~5.3 seconds.

--------------------------------------

[0.447125 0.447125] [FAILED] Failed to start Load Kernel Modules.

[0.463050 0.015925] See "Systemctl status Systemd-modules-load.service" for details.

......

[5.302394 0.016012] colibri-imx6 login:

--------------------------------------

Due to the use of their own compiled kernel, so when loading the module driver prompt error. Just recompile the kernel modules and place them in the/lib/modules/directory on the target board. Of course, if the appropriate driver is required in the application, these module drivers can be completely not loaded.

--------------------------------------

[Email protected]:~# rm/etc/modules-load.d/libcomposite.conf

--------------------------------------

Systemctl tool to view all Startup items

--------------------------------------

[Email protected]:~# systemctl Status

--------------------------------------

SYSTEMD provides the Systemd-analyze tool to print out the various services and their startup time when using "blame". This can find the most consumed start-up time service. However, the values may be confusing because the measured time is the actual elapsed time. The service may be in a sleep state, when the CPU is actually dealing with other tasks. So the service at the top of the list is not necessarily the most time-consuming, especially on a single-core system. The default BSP does not contain systemd-analyze and can be installed online via the following command.

--------------------------------------

[Email protected]:~# opkg Update

[Email protected]:~# opkg Install Systemd-analyze

[email protected]:~# Cat systemd.blame                                                                                                               

          3.188s dev-mmcblk0p2.device                                                                                                                 

          1.080s systemd-journal-flush.service                                                                                                       

......

178ms Systemd-fsck-root.service

--------------------------------------

Systemd-analyze plot can also output the startup item in graphical form.

--------------------------------------

[Email protected]:~# systemd-analyze plot > Systemd.svg

--------------------------------------

?

Figure 3 Systemd Boot

The start service can be closed by using the Disable command. Some services, especially those provided by SYSTEMD itself, may require masks to close them. Others may be needed to run the system. Therefore, you need to be very careful when you close a service, and you can only handle one at a time.

--------------------------------------

[Email protected]:~# systemctl Disable Usbg.service

--------------------------------------

The Toradex BSP, using Connman as the Network management tool, can flexibly manage the wireless network connection. However, the start-up of Connman will consume more time. For cases where the network is not in use or is only wired, the/etc/systemd/network/wired.network configuration can effectively reduce the startup time.

The Toradex BSP, using Connman as the Network management tool, can flexibly manage the wireless network connection. However, the start-up of Connman will consume more time. For cases where the network is not in use or is only wired, the/etc/systemd/network/wired.network configuration can effectively reduce the startup time.

--------------------------------------

[Match]

Name=eth0

[Network]

Dhcp=ipv4

--------------------------------------

In applications that do not require logging of the system log, the log storage feature is disabled, and the startup time can be reduced to some extent.

--------------------------------------

/etc/systemd/journald.conf

[Journal]

Storage=none

#Compress =yes

--------------------------------------

The quiet in kernel parameters also applies to Systemd. This helps to Systemd the startup time.

In accordance with the above optimization, User space starts to login for ~3.8 seconds.

--------------------------------------

[1.748022 0.493043] [0.783547] Freeing unused kernel memory:280k (805f6000-8063c000)

[0.609885 0.609885] [1.390393] systemd-fsck[117]: Rootfs:clean, 21509/876392 files, 446716/3543040 blocks

......

[3.799609 0.016926] colibri-imx6 login:

--------------------------------------

System V Init

For a long time, Linux also used SysV as the standard init system. Because of the script-based system, this is modular and can be relatively easy to streamline the system. Especially for relatively static systems, SYSTEMD device activation and socket activation are not required. At this point, sysv can be a good choice.

Toradex's Linux BSP is based on the openembedded framework, and users can easily configure the SysV. Please download the required patch files from here.

Recompile a mirror using SysV

--------------------------------------

[Email protected]:~/toradex/oe-core/v2.5/oe-core/build$ bitbake console-trdx-image

--------------------------------------

After the target board is updated with the above image, the Linux execution

--------------------------------------

[Email protected]:~#/usr/sbin/resize.sh

--------------------------------------

If you are using Colibri i.mx6d 512MB, perform in U-boot

--------------------------------------

Colibri IMX6 # Patch_ddr_size

--------------------------------------

On systems that use SysV, you can also delete some unwanted startup items.

--------------------------------------

[Email protected]:~ #update-rc.d-f bootlogd Remove

[Email protected]:~ #update-rc.d-f mountall.sh Remove

[Email protected]:~ #update-rc.d-f Networking Remove

--------------------------------------

In accordance with the above optimization, User space starts to login for ~1.1 seconds.

--------------------------------------

[1.594064 0.371247] [0.661430] Freeing unused kernel memory:280k (805f6000-8063c000)

[0.057864 0.057864] Init:version 2.88 booting

......

[1.098062 0.000060] colibri-imx6 login:

--------------------------------------

Build a startup script to load the app in/ETC/INIT.D

--------------------------------------

[Email protected]:vi/etc/init.d/drawing.sh

# # # BEGIN INIT INFO

# Provides:toradex

# Default-start:3 5

# default-stop:0 1 2 6

# Description:draw rectangles on fb0

# # # END INIT INFO

/home/root/rectangles &

[Email protected]:chmod a+x drawing.sh

[Email protected]:update-rc.d drawing.sh Defaults

--------------------------------------

In this way, the application can be started within 2.55 seconds using the above method.

--------------------------------------

[Email protected]:~/software/grabserial-1.8.1$ sudo./grabserial-d/dev/ttyusb0-t

[0.000002 0.000002]

[0.162820 0.162818]

[0.162917 0.000097] U-boot 2015.04 (Apr 14 2016-10:09:25)

......

[0.690563 0.001000] Starting kernel ...

......

[2.633291 0.000076] colibri-imx6 login:

--------------------------------------

Reference:

Flashing Embedded Linux to iMX6 Modules

Http://developer.toradex.com/knowledge-base/flashing-linux-on-imx6-modules

Build U-boot and Linux Kernel from Source Code

Http://developer.toradex.com/knowledge-base/build-u-boot-and-linux-kernel-from-source-code

OpenEmbedded (CORE)

Http://developer.toradex.com/knowledge-base/board-support-package/openembedded-%28core%29

Fast boot based on arm embedded Linux