U-boot FIT Image Introduction _ Turn from "Snail Nest technology"

Turn from: HTTP://WWW.WOWOTECH.NET/U-BOOT/FIT_IMAGE_OVERVIEW.HTML1. Objective

[1] The Linux kernel introduced device tree in the ARM architecture (full name is flattened device tree, followed by Fdt McCartney), and in fact had a dream of unify kernel----the same image, can support multiple different platforms. With the new ARM64 architecture listing FDT as a required option, and after stripping the architecture-related code, this dream is nearing implementation:

When compiling Linux kernel, you don't have to specifically specify the architecture and the SOC, just tell kernel which board-level platform the compilation needs to support, and eventually generate a kernel image, as well as multiple and specific boards (which schema, Which Soc, which version) about the FDT image (DtB file).

Bootloader at boot time, according to the hardware environment, load different DTB files, can make Linux kernel run on different hardware platform, so as to achieve the goal of unify kernel.

Based on the widely used u-boot in embedded products, this article introduces the steps to achieve this goal in its new uimage format (FIT image,flattened uimage Tree), as well as the thinking and meaning behind it.

2. Legacy Uimage

From a u-boot perspective, it wants to boot a binary file (for example, kernel Image) and needs to know some information about the file, such as:

The type of the file, such as kernel image, DtB file, RAMDisk image, and so on?

Where does the file need to be placed in memory (load address)?

Where does the file need to start executing (execution address) from memory?

Does the file have compression?

Does the file have some information about the integrity check (such as CRC)?

Wait a minute

In conjunction with the "x-010-uboot-using Booti command to start kernel (Bubblegum-96 platform)" In the example of Booti, the above information is implied in our command line, for example:

Through the DFU tool, the specified image file is downloaded to the specified memory address, and the binary file loading address is specified indirectly;

The Booti command itself, stating that the file type being loaded is the image file of the ARM64 platform;

By Booti parameters, you can specify the execution position of kernel Image, RAMDisk, DTB file;

Wait a minute.

However, the disadvantage of this approach is obvious (in summary, it is too verbose):

Need to move different binaries (Kernel, DTB, RAMDisk, etc.) into memory;

The boot command (Booti, etc.) has more complex parameters;

Can not flexibly handle the binary file verification, decompression and other operations;

Wait a minute.

To address these shortcomings, U-boot has customized an image format----uimage. Initially, the uimage format is simple, which is to add a header to the binary file (specifically, refer to the definition in "include/image.h") to indicate the file's characteristics. Then, when you boot the image of that type, read the required information from the header and follow the instructions to do the corresponding action. This primitive image format, called Legacy Uimage, is characterized by:

1) generated using the Mkimage tool (located in the tools/mkimage of U-boot source code).

2) Support OS Kernel Images, RAMDisk Images and many other types of image.

3) Support gzip, bzip2 and other compression algorithms.

4) Support CRC32 checksums.

5) and so on.

Finally, the reason is called legacy, the explanation has the new tricks, this kind of old way, we no longer too much attention, embraces the fresh thing to go.

3. Introduction to FIT uImage3.1

Device tree in the ARM architecture, U-boot also immediately follow up, strong support, after all, the beautiful unify kernel ideal, need to bootloader the consummation. To support device tree-based unify kernel,u-boot requires a new image format, which requires the following capabilities:

1) The image needs to contain multiple DTB files.

2) It is convenient to choose which DTB file boot kernel to use.

In combination with the above requirements, U-boot introduced a new image format----fit Uimage, where fit is the abbreviation for flattened image tree. Do you think fit and FDT (flattened device tree) are a bit like? Yes, it takes advantage of the syntax of device Tree Source files (DTS), and the resulting image file is similar to the DtB file (called ITB), which we'll describe in detail below.

3.2 Ideas

For simplicity, we can directly compare the fit Uimage to the DtB file of device tree, which generates and uses [2]:

Image source file Mkimage + DTC transfer to target
+-----------------------------> image file-----------------------------------> Bootm
Image data file (s)

Where image source file (. Its) is similar to device tree source file (. dts), it is responsible for describing the information to be generated by the image file (the information described in chapter 2nd above). Mkimage and DTC tools, you can package the. its file and the corresponding image data file as an image file. We download this file to memory, which can be executed using the BOOTM command.

3.3 The syntax of the image source file

The syntax of the image source file is exactly the same as the device tree source file (refer to the example in [3][4][5]), except that it customizes some unique nodes, including images, configurations, and so on. The description is as follows:

1) Images node

Specify the binaries you want to include, you can specify multiple types of files, such as multi.its[5] that contain 3 kernel image, 2 ramdisk image, and 2 FDT image. Each file is a child node under images, for example:

[Email protected] {
Description = "2.6.23-denx";
data =/incbin/("./2.6.23-denx.bin.gz");
Type = "Kernel";
Arch = "PPC";
OS = "Linux";
Compression = "gzip";
Load = <00000000>;
Entry = <00000000>;
[Email protected] {
Algo = "SHA1";
};
};

The following keywords can be included:

Description, description, can be casually written;

Data, the path to the binary file, in the format----/incbin/("Path/to/data/file.bin");

Type, binary file types, "kernel", "RAMDisk", "Flat_dt" and so on, can be referred to in [6] of the introduction;

Arch, platform type, "arm", "i386", etc., can refer to [6] in the introduction;

OS, operating system type, Linux, VxWorks, etc., refer to [6] in detail;

compression, the compression format of binary files, U-boot will be extracted according to the format of execution;

Load, the loading location of the binary file, U-boot will copy it to the corresponding address;

Entry, binary file entry address, general kernel image needs to be provided, U-boot will jump to that address to execute;

Hash, using the data validation algorithm.

2) Configurations

can be different types of binary files, according to different scenarios, combined to form a configuration item, U-boot at boot time to configure items for the load, execution, so that can be based on different scenarios, convenient choice of different configurations, to achieve the unify kernel goal. Also take multi.its[5] as an example,

Configurations {
default = "[email protected]";

[Email protected] {
Description = "tqm5200 vanilla-2.6.23 configuration";
kernel = "[email protected]";
RAMDisk = "[email protected]";
FDT = "[email protected]";
};

[Email protected] {
Description = "tqm5200s denx-2.6.23 configuration";
kernel = "[email protected]";
RAMDisk = "[email protected]";
FDT = "[email protected]";
};

[email protected]{
Description = "tqm5200s denx-2.4.25 configuration";
kernel = "[email protected]";
RAMDisk = "[email protected]";
};
};

It contains 3 configurations, each with a different kernel, ramdisk, and FDT, and the default configuration is specified by "default" and, of course, at run time.

Compilation and use of 3.4 image

The compile process for FIT uimage is simple, and after writing the image source file (assuming the name is Kernel_fdt.its), compile with the Mkimage tool at the command line, as appropriate:

$ mkimage-f kernel_fdt.its KERNEL_FDT.ITB

Where-f Specifies the source file that needs to be compiled, and later specifies the image file that needs to be generated (typically with a. ITB suffix, such as KERNEL_FDT.ITB).

After the image file is generated, you can also use the Mkimage command to view its information:

$ mkimage-l KERNEL.ITB

Finally, we can use the DFU tool to generate an. IDB file, an address for the downloaded memory (no special requirements, such as 0x100000), and then use the BOOTM command to start, including the following:

1) Use the Iminfo command to view the images and configurations that exist in the memory.

2) Use the BOOTM command, perform the default configuration, or specify the configuration.

If you start with the default configuration, you can use BOOTM directly:

Bootm 0x100000

If you choose a different configuration, you can specify the configuration name:

BOOTM 0x100000#[email protected]

The above can be referred to "doc/uimage.fit/howto.txt[2", the details of which we will be in the follow-up article in conjunction with the case description.

4. Summary

This article simply introduces U-boot's efforts to achieve unify kernel, but there is a question that you can think about: How does the bootloader unify guarantee?

Soc Manufacturers (curing, providing binary files, etc.)?

Unified format, UEFI?

If there is time in the back, you can follow this question to study.

5. Reference documentation

[1] Device Tree (i): Background introduction

[2] Doc/uimage.fit/howto.txt

[3] Doc/uimage.fit/kernel.its

[4] Doc/uimage.fit/kernel_fdt.its

[5] Doc/uimage.fit/multi.its

[6] Doc/uimage.fit/source_file_format.txt

U-boot FIT Image Introduction _ Turn from "Snail Nest technology"