Uboot Learning Five-----uboot How to start the Linux kernel

What exactly is uboot and the kernel?
Uboot is essentially a complex bare-metal program; Uboot can be configured or ported;

The operating system kernel itself is a bare-metal program, and we learn the uboot and other bare-metal programs are not essential differences, the difference is that our operating system can be divided into the application layer and the kernel layer, after layering, the two tiers of permissions, memory access and the management of device operations more granular ( The kernel can be arbitrarily oriented to various hardware, while applications can only be restricted to access hardware and memory addresses)

Intuitively, the image of Uboot is the mirror of the u-boot.bin,linux system zimage, these two things are actually two bare-metal program images. From the point of view of system startup. Kernel and uboot are bare-metal programs;

Deployed within a specific partition on the SD card
(1) A complete software + hardware embedded system, at rest (not power) bootloader, kernel, rootfs and other necessary software are stored in the form of mirroring in the boot media (x210 is the INAND/SD card), the runtime is running in DDR memory, independent of storage media. The above two states are stable state, the third State is the dynamic process, that is, from the stationary state to the operating state of the process, that is, the start-up process. That's the whole process.
(2) The dynamic START process is to gradually move from the SD card to the DDR memory, and run the startup code for the related hardware initialization and the establishment of the software architecture, and finally achieve a stable state of operation.
(3) Static U-boot.bin Zimage rootfs are in the SD card, they can not be arbitrary location of the SD card, so we need to partition the SD card, and then the various images have their own partitions, so during the boot process, uboot, The kernel will know where to look. (The partition table of the uboot and the kernel must be identical, and the partition of the SD card should be the same as the actual use)

The runtime must first be loaded into the DDR at the link address
Uboot the second stage (the entire uboot mirror) is loaded into the 0xc3e00000 address in the DDR during the first phase of the relocation, this address is the Uboot connection address.
(2) The kernel also has similar requirements, uboot boot kernel from the SD card read into the DDR (in fact, is the relocation process), can not be placed at random, must be placed at the core of the link address, or not start up, for example, we use the kernel connection address is 0x300080000

Kernel boot requires necessary boot parameters
(1) The kernel does not boot automatically completely from zero start, the kernel boot needs to help others. Uboot to help the kernel implement relocation (from SD card to DDR) Uboot also provide boot parameters to the kernel.

Boot the kernel first step: load the kernel into the DDR
Uboot to start the kernel, it is divided into 2 steps: The first step is to load the kernel image from the boot media into the DDR, and the second step is to start the kernel image in the DDR. (Kernel code does not consider repositioning at all, because the kernel knows that bootloader helps to load itself into the DDR link address, and the kernel runs directly from the link address)

Where is the static kernel image?
(1) SD card, Inand, NAND, Norflash, etc.: Raw zone
The various mirrors are on the SD card during normal boot, so the uboot only needs to read the kernel image to the link address of the DDR from the kernel partition of the boot media SD card, read to use the Uboot command to read (for example, the Inand version is the Movi command, and the NAND version of X210 is the NAND command)
(2) This boot mode to load DDR, using command: movi read kernel 30008000. Where kernel refers to the kernel partition in the Uboot (that is, the Uboot specifies an area range in the SD card, this area is designed to store the kernel image, which is called the kernel partition, sometimes called the original partition, After the operating system starts, you can use the file system to manage partitions. ）
(3) TFTP, NFS and other network download mode from the remote server to obtain the mirror
Uboot also supports remote boot, that is, the kernel image is not burned to the board's SD card, but is placed on the host's server, and then needs to be started when the uboot from the server to download the image to the Development Board of the DDR.

Analysis Summary: The end result is that the kernel is mirrored to a specific address in the DDR. Each of the above two ways have advantages and disadvantages, the product will be set from the factory SD card startup, customers will not have to build a TFTP server to use, TFTP download remote start, suitable for development.


What address is the image to be placed on the DDR?
The kernel must be placed at the link address, the link address to the kernel source code connection script or makefile to find. The x210 is 0x300080000.

The difference between Zimage and uimage
BOOTM command corresponds to Do_boot function
(1) before the command name plus DO_,DO_BOOTM in CMD_BOOTM.C
(2) Do_bootm has just started to define a variable, and then use the macro to conditionally compile some of the Secureboot code is mainly security authentication. Then to the Config_zimage_boot, use this macro to control the conditional compilation of a piece of code, this code is used to support the zimage format of the kernel boot.

Vmlinuz and Zimage and Uimage
(1) Uboot compiled into an elf-formatted executable program u-boot, which resembles the EXE format under Windows, can be executed under the operating system, but cannot be used to burn the download, What we use to burn downloads is u-boot.bin, which is obtained by U-boot using arm-linux-objcopy (the main purpose is to get rid of some useless). U-boot.bin is called mirror, image is used to burn, burn to inand execution, or is placed in the SD card execution, or dnw download execution,
(2) Linux kernel compiled will also generate an elf-formatted executable program, called Vmlinuz or Vmlinux, this is the original without any processing of raw original kernel elf files, embedded deployment burning is not generally this vmlinuz, Instead, use the objcpy tool to create a burn-in image format (which is u-boot.bin, but the kernel does not have a. bin suffix). This burning image is image, and the main purpose of making the image is to reduce the size of the disk.
(3) In principle, the image can be burned directly to flash, but in fact it is not so simple, in fact, the authors of Linux think the image is too large, compression, and in the compression of the previous section, the addition of a decomposition compression code, constitutes a compression but the image is zimage (because the image size is just bigger than a floppy disk, (floppy disk has 2, 1.2M and 1.4m,image than 1.4M a little), in order to save a floppy disk money, so, The technique of compressing image into Zimage is designed.
(4) Uboot in order to start the Linux kernel, also invented a kernel format called Uimage. Uimage is produced by zimage processing, Uboot has a tool that can be zimage processing production uimage. Note: Uimage regardless of the Linux kernel, the Linux kernel just generates zimage, and then uboot mkimage tool to zimage processing to generate uimage to boot uboot. This process is done by adding 64 bytes of Uimage header information to the front of the zimage.
(5) In principle, uboot boot should give him the uimage format of the kernel image, but in fact Uboot can also support zimage, whether the support is to see whether x210_sd.h is defined in LINUX_ZIMAG_MAGIC this macro. So some uboot support zimage boot, others do not support it. But all uboot are sure to support Uimage startup.

Compile kernel get uimage to start
(1) The first step: if directly under the kernel to make uimage will prompt Mkimage did not find, the solution is/uboot/tool down to the copy to/usr/local/bin. Go down, copy it to the system directory, and then do Uimage can do it.

Zimage Boot Details
#ifdef Config_zimage_boot
#define Linux_zimage_magic 0x016f2818
/* Find out kernel image address */
if (ARGC < 2) {
addr = load_addr;
Debug ("* Kernel:default image load address = 0x%08lx\n",
LOAD_ADDR);
} else {
Addr = Simple_strtoul (argv[1], NULL, 16);
Debug ("* kernel:cmdline image address = 0x%08lx\n", img_addr);
}


if (* (ULONG *) (addr + 9*4) = = Linux_zimage_magic) {
printf ("Boot with zimage\n");
addr = Virt_to_phys (addr);
HDR = (image_header_t *) addr;
Hdr->ih_os = Ih_os_linux;
Hdr->ih_ep = Ntohl (addr);

Memmove (&images.legacy_hdr_os_copy, HDR, sizeof (image_header_t));

/* Save Pointer to image header */
Images.legacy_hdr_os = HDR;

Images.legacy_hdr_valid = 1;

Goto After_header_check;
}
#endif
The DO_BOOTM function always checks the header of the zimage mirror until it is 397 rows long. The checksum is based on different kinds of image types. So the core of the DO_BOOTM function is to discern what type of image is coming in, and then to verify it in this type of header information format. The validation passes to the next step to prepare the kernel, and if the checksum fails the mirror is considered to be a problem, so it cannot be started.

#define Linux_zimage_magic 0x016f2818
(1) This is a magic number, 0x016f2818 means that the image is zimage, that is, in the zimage format of the image, in a fixed position in the head to store this number, as a format tag, if we get an image, go to his location to fetch 4 bytes, Determine if it equals this magic number linux_zimage_magic. You can tell if this image is zimage or not.
(2) command Bootm 0x30008000, so Do_bootm Argc=2,argv[0]=bootm argv[1]=0x30008000 but the actual BOOTM command can also be executed without parameters, if the direct BOOTM without parameters will be from, CFG_LOAD_ADDR address to execute (defined in x210_sd.h)
(3) Zimage from the beginning of the 37th to 40th Byte, the zimage is stored in the symbol of the magic number, from this position to take out the contrast linux_zimage_magic, we can use the Binary View tool to view the image of Zimage, found that it is really stored this magic number.

image_header_t
(1) This data structure is a standard boot data structure used by our Uboot boot kernel, and Zimage header information is also a image_header_t, but some modifications are needed before actually booting.
if (* (ULONG *) (addr + 9*4) = = Linux_zimage_magic) {
printf ("Boot with zimage\n");
addr = Virt_to_phys (addr);
HDR = (image_header_t *) addr;
Hdr->ih_os = Ih_os_linux;
Hdr->ih_ep = Ntohl (addr);

Memmove (&images.legacy_hdr_os_copy, HDR, sizeof (image_header_t));

/* Save Pointer to image header */
Images.legacy_hdr_os = HDR;

Images.legacy_hdr_valid = 1;

This is where the transformation is.
(2) The image global variable is used in the BOOTM function, the purpose is to point to OS/INITRD/FDT images, which is used to complete the boot, the Zimage verification process first determine is not zimage, and then modify the Zimage header information, to the appropriate, That is, the above transformation, and finally use this header information to initialize the image, and then complete the verification.
Zimage start Mode is added later, and with a goto way to jump part of the code, itself on the structure of Uboot added.

Uimage start
(1) in the Uboot start do_boot There is a legacy method, refers to uimage such a way, why is legacy (left), is because Uimage itself is uboot invented a way to start, and later this way is not good, abandoned, And then replaced by a new way, the new way is the device tree, here is called fit, this is the way the device tree.
(2) uimage start check function is in Boot_get_kernel This function, the main task is to verify our Uimage header information, and get the real kernel starting position to start.

Summary: Uboot itself only support the Uimage way to start, and then after the device tree, the Uimage method named Legacy mode, FDT Way is named fit mode, so many of the # if #endif添加代码. Later the transplant of the people to add a zimage way, and for the sake of convenience, add the # if #endif.

The second phase of the verification header information is completed, the third stage, the Linux kernel, call do_bootm_linux this function


Do_bootm_linux
(1) Find Do_bootm_linux, this function in LIB_ARM/BOOTM.C, Sourceinsight cannot find, to search for find,

(2) EntryPoint of the Mirror
EP is the program entrance, the beginning of an image is not at the beginning of the image (the beginning of the image has a lot of bytes of header information), the code really started in the middle of a part, relative to the head has a certain offset, the offset is placed in the header information.
Generally perform an image is: The first step to read the header information, and then at the specific address of the header to find Magic_num, to determine the type, the second step to verify the image, the third step to read the header information, the specific address of the headers know the image of the various information, including length, type, entry address, etc. The fourth step is to go to entrypoint and start mirroring,

Thekernel = (void (*) (int, int, uint)) EP; Assigning a true entry address to Thekernel is the first code of the operating system


Re-determination of machine code
Uboot when booting the kernel, the machine code is passed to the kernel. How is the machine code passed to the kernel uboot determined? The first order alternative is the environment variable Machid, the second order alternative is gd->bd->bi_arch_number (x210_sd.h configured)


To pass the parameter and start
Send a parameter to the kernel (do_bootm_linux 110-144 lines here)

Starting kernel ... Here printing is the last print information of Uboot, if after this sentence, the serial port does not output information, indicating that the kernel was not successfully executed, because of the parameter error (80%), the kernel in the DDR load address ...

A tag way to pass the parameter
(1) struct Tag,tag is a data structure that defines the tag data mechanism in both Uboot and Linux kernel, and the definition is the same.
(2) Tag_header and tag_xxx. Tag_header has this tag size and type code, kernel get a tag first analysis Tag_header get the type and size of tag, and then the rest of the tag as a tag_xxx to deal with.
(3) Tag_start and Tag_end. The kernel received is composed of several tags, which are tag_start from the beginning to the end of the tag_end.
(4) The way of the tag is invented by the Linux kernel, kernel defines the way to me, Uboot just realizes the way of this kind of communication and can support to the kernel.

Configuring a parameter macro in X210_sd.h
(1) CONFIG_SETUP_MEMORY_TAGS,TAG_MEM, the parameter content is memory configuration information.
(2) Config_cmdline_tag,tag_cmdline, the content of the argument is the start command line parameter, that is, the UBOOT environment variable Bootargs.
(3) Config_initrd_tag
(4) Config_mtdpartition, the reference content is the partition table of the INAND/SD card.
(5) The starting tag is atag_core, the end tag is Atag_none, the other atag_xxx are valid information tag.
Think: How does the kernel get these tags?
Uboot finally calls the Thekernel function to execute the Linux kernel, and Uboot calls this function (which is actually the Linux kernel) and passes 3 parameters. These 3 parameters are the Uboot directly passed to the Linux kernel 3 parameters, through the register to achieve the parameter. (the 1th parameter is placed in the R0, the second parameter is placed in the R1, the 3rd parameter is placed in the R2) the 1th parameter is fixed to 0, the 2nd parameter is the machine code, and the 3rd parameter is the first address of the large-size pass tag.

2.7.7.3 and Transplant considerations
(1) When uboot transplant, it is generally necessary to configure the corresponding macro to
(2) kernel boot is unsuccessful, note the success of the transfer. The argument is not successful first look at the Uboot Bootargs set is correct, and then see if Uboot open the corresponding macro to support the parameter.

Uboot Learning Five-----uboot How to start the Linux kernel