1. What are Uboot and kernel (from the perspective of system startup)

1.Uboot

The essence of Uboot is a complex bare metal program.

2. Kernel

The operating system kernel itself is also a bare metal program, and there is no essential difference between it and uboot and other bare metal programs.

However, it is different from other bare-metal programs: after the operating system is running, it is divided into a kernel layer and an application layer in terms of software. The two layers have different permissions, and the management of kernel access and device operations is more sophisticated (the kernel can access various hardware at will, while the application can only be restricted to access hardware and memory addresses).

The Uboot image is u-boot.bin, and the Linux system image is zImage. These two files are both bare metal program bin file images.

2. Partitions in SD Card

A complete software + hardware embedded system. When not powered on, the necessary software such as bootloader, kernel, rootfs, etc. are stored in the boot medium (iNand/SD card for x210) in the form of images (.bin). When running, they are all run in DDR memory, regardless of the storage medium. Both states are stable.

Another state is the dynamic process, which is the process from static state to running state, that is, the startup process.

The dynamic boot process is to gradually move from the boot medium (taking the SD card as an example below) to the DDR memory, and run the boot code to perform related hardware initialization and software structure establishment, and finally reach a stable state during runtime.

When the system is at rest, u-boot.bin, zImage, and rootfs are all in the SD card. They cannot be stored anywhere on the SD card. Therefore, the SD card needs to be partitioned, and then various images are stored in their own partitions. In this way, during the startup process, you will know where to find uboot, kernel, etc. (The partition tables in uboot and kernel must be consistent, and must be consistent with the actual partitions used by the SD card).

3. When running, it must be loaded into the link address in DDR first

When Uboot is relocated in the first stage, the second stage (the entire uboot image) is loaded to the 0xc3e00000 address of DDR, which is the link address of uboot.

The kernel has similar requirements. When uboot starts the kernel, it must read the memory from the SD card and put it into the DDR (actually, it is a relocation process). It cannot be placed randomly, but must be placed at the kernel link address, otherwise the kernel cannot be started. If the kernel link address used is 0x30008000, then when uboot copies the kernel code, it must copy the kernel to the DDR at address 0x30008000.

4. Kernel startup requires necessary startup parameters

Uboot is started unconditionally and starts from scratch.

The kernel cannot start up completely from scratch automatically when the computer is turned on. The kernel needs help to start up. Uboot needs to help the kernel to relocate (from SD card to DDR) and provide the kernel with necessary startup parameters, such as the starting address and size of dram, the serial port and baud rate used, the location of the root file system, etc.

When uboot starts the kernel, it calls the kernel's entry function and passes three parameters to the kernel. These three parameters are fixed:

r0: Fixed to 0

r1: machine code

r2: The location of the boot parameters in ddr

5. Start the kernel

Uboot starts the kernel in two steps: the first step is to load the kernel image from the boot medium into DDR, and the second step is to start the kernel image in DDR. (The kernel code does not consider relocation, because the kernel knows that there will be a bootloader to load the kernel code to the DDR link address, so the kernel runs directly from the link address)

1. Load the kernel into DDR

Where to put the static kernel image?

There are two cases:

The first type: SD card/iNand/Nand/Norflash, etc.: raw partition

During normal startup, various images are in the SD card, so uboot only needs to read the kernel image from the kernel partition of the SD card to DDR.

To read, use the uboot command (the iNand version of x210 is the movi command, and the Nand version of x210 is the Nand command)

For example, read the kernel to memory 0x30008000.

movi read kernel 0x30008000

The kernel here refers to the kernel partition in uboot (that is, an area range in the SD card specified in uboot, this area range is designed to store the kernel image, which is the so-called kernel partition)

The second method: tftp, nfs and other network download methods to obtain the image from the remote server

Uboot also supports remote booting, that is, the kernel image is not burned into the SD card of the development board, but placed in the server of the host. Then when it needs to be started, Uboot downloads the image from the server to the DDR of the development board through the network.

First, set up a tftp server on the host, and then copy the file to be downloaded to the transfer directory set by tftp.

In the uboot of the development board, use the tftp command to download the remote file through the network.

tftp command format

tftp DDR address Remote download file name

Regardless of the method, the final result is to have the kernel image in a specific address in DDR, regardless of how the kernel image is in DDR. The above two methods have their own advantages and disadvantages. The product is set to boot from the SD card when it leaves the factory; tftp download remote boot is generally used for development.

Where should the image be placed in DDR?

The kernel must be placed at the link address. The link address should be found in the link script or makefile of the kernel source code. In X210, it is 0x30008000.

2. Execute the kernel

After uboot copies the kernel to the kernel's link address in DDR, it directly calls the kernel's entry function to start the kernel.

Uboot uses the command bootm to start the kernel.

6. The difference between zImage and uImage

1. The bootm command corresponds to the do_bootm function (common/cmd_bootm.c)

The CONFIG_SECURE_BOOT macro indicates secure boot, which performs a more secure check on the program. For general applications, this is not necessary.

The CONFIG_ZIMAGE_BOOT macro is very important. This macro controls the conditional compilation of a section of code that supports kernel startup in zImage format.

2.vmlinuz and zImage and uImage

The executable program in elf format generated directly by uboot after compilation is u-boot. This program is executable, similar to the exe format under windows, and can be directly executed under linux. However, this format cannot be used for burning and downloading. The one used for burning and downloading is u-boot.bin. This is converted by u-boot using the arm-linux-objcopy tool (mainly to remove useless information). This u-boot.bin is called an image, and the image is used to burn into the boot medium for the CPU to fetch instructions and execute.

After the Linux kernel is compiled, it will also generate an executable program in elf format, called vmlinux or vmlinuz. This is the original kernel elf file without any processing. When the embedded system is deployed, it is generally not burned in this vmlinux/vmlinuz, but it is made into a burning image format (such as u-boot.bin, but the kernel does not have a .bin suffix) using the objcopy tool. The produced image file is called Image (this image is much smaller than the elf format file).

In principle, the image can be burned directly into the boot medium, but in fact, the Linux developers think that the image size is still too large, so the image is compressed and a part of the decompression code is added to the front of the compressed image file. The image in the compressed format is called zImage.

In order to start the Linux kernel, Uboot has invented a kernel format called uImage. UImage is processed by zImag. There is a tool in uboot that can convert zImage into uImage. Note: uImage has nothing to do with the Linux kernel. The Linux kernel only generates zImage, and then the mkimage tool in uboot converts zImage into uImage to start uboot. This conversion process is actually to add 64 bytes of uImage header information in front of zImage.

In principle, uboot should give it a kernel image in uImage format when it is started, but in fact, uboot can also support zImage startup. Whether it is supported depends on whether the CONFIG_ZIMAGE_BOOT macro is defined in x210_sd.h.

That is, some uboots support zImage booting, while others do not. But all uboots definitely support uImage booting.

For the mkimage tool, in the tools directory under uboot, mkimage is generated by

The above code is to provide the zImage startup of uboot. When the image is determined to be a zImage, it is verified. After the verification, it jumps directly to the after_header_check symbol, and the other subsequent images are not verified.

LINUX_ZIMAGE_MAGIC is a defined magic number, which is equal to 0x016f2818, indicating that the image is a zImage. That is, in the image of zImage format, this number is stored in a fixed position in the head as a format mark. If there is an image, read 4 bytes of data from this position to determine whether it is 0x016f2818. If it is, it means it is a zImage, otherwise it is not.

The address of the command bootm is (0x30008000), so do_bootm's argc=2, argv[0]=bootm, argv[1]=0x30008000. However, there is a case where argc is less than 2. At this time, the boot address is the default address. This address is the base address of the memory 0x30000000. Therefore, the bootm command can be executed without parameters. Without parameters, the default boot address is 0x30000000.

Read the 4 bytes starting from byte 37 of the image and check whether it is 0x016f2818, so as to determine whether this image is a zImage.

image_header_t (include/image.h) is a standard boot data structure used by the uboot boot kernel. The zImage header information is also an image_header_t, but some modifications are required before actual booting.