I have never thought of any good way to pass parameters to the kernel through registers until now the implementation of uboot reading.
In uboot, the most common method to boot the kernel is the bootm command. The bootm command can boot the "uboot format" kernel. Let's take a moment to know what the kernel is in uboot format: Use
UbootThe kernel generated by the built-in mkimage command is called the kernel in the uboot format. The following command is used as an example:
Mkimage-n "kernel 2.4.18"-A arm-O Linux-T kernel-C none-A 30007fc0-e 30008000-D 401_bin vmlinux-2.4.18.img
-E 30008000 is the most closely related to kernel boot, that is, the kernel entry address. For other parameters, see help. The kernel in other uboot formats is only compressed (optional) compared with the original one, and a 0x40 header is added in front. This header contains the kernel location (0x30007fc0), entry address (0x30008000), and other information.
During bootm command execution, the header information is verified first and then put in a structure. Finally, call the corresponding startup function based on the kernel type. For Linux, It is do_bootm_linux. In the startup function, there is such an operation: Thekernel = (void (*) (INT, Int, uint) ntohl (HDR-> ih_ep );, this is the most critical operation. The kernel entry address 0x30008000 is assigned to Thekernel. At the end of the function startup, Thekernel is used.
(0, BD-> bi_arch_number, BD-> bi_boot_params); start the kernel.
According to the parameter passing specification, the three variables are transmitted to the kernel using r0, R1, and R2 respectively. This cleverly uses the function pointer for parameter passing, which is really subtle!
After kernel boot and parameter passing, note that when the mkimage command is used to generate the kernel, the address after-E is 0x40 different from the address after-, the reason is very simple, so I will not elaborate on it.
For how to use mkimage, refer to the previous article: How to Use the uboot tool mkimage. As mentioned above, bootloader cleverly uses function pointers and parameter passing specifications to convert R0: 0x0, R1: machine number, R2: The parameter address is passed to the kernel. since R0 and R1 are relatively simple, no further instructions are required. it takes some time to understand the R2 register.
The R2 register transmits a pointer pointing to a tag area. uboot and Linux kernel use this Extended Tag area to transmit complex parameters, such as command line and file system information, you can also extend this tag to transfer more parameters. the address in the tag area, that is, the R2 value, is in/board/yourboard/youboard. the board_init function in C is initialized, for example, Gd-> BD-> bi_boot_params in ub4020.
= 0x30000100; this is an absolute address.
The structure of the tag area is relatively simple and can be considered as the arrangement of tags (array ?), Each tag transmits a specific type of parameter. For definitions of various system tags, see./include/ASM-arm/setup. h.
The following is an example of a tag area:
0x30000100 00000005 54410001 00000000
0x30000110 00000000 0000000f 54410009 746f6f72
0x30000120 65642f3d 61722f76 7220306d 6f632077
0x30000130 6c6f736e 74743d65 2c305379 30303639
0x30000140 696e6920 6c2f3d74 78756e69 ea006372
0x30000150 00000004 54420005 30300040
0x30000160 00000000 00000000
We can see that there are three tags in total:
The length of the first tag is five characters and the type is atag_core (54410001). There are three elements, all of which are zero. The tag must start with this tag.
The second tag is f characters in length and the type is atag_cmdline (54410009). This is a string and is the kernel command line passed to the kernel.
The third tag is 4 characters in length and belongs to the atag_initrd2 (54410005) type. It has two elements: Start: 30300040 (30300000 + 40) and size: 200000 (2 m)
If there is still the fourth tag, it is the end of the two completely Zero, this is the tag end sign.
These tags are in. do_bootm_linux function in/lib_arm/arm_linux.c. the specific tag is determined by the corresponding control macro. for details, refer to the relevant code. in this example, the first tag is the starting tag. If the environment variable contains bootargs, the second tag is created. If bootm has two parameters (boot file system ), the System reads the necessary information in the file system header and creates the third tag.
After the kernel is started, the tags are found based on the value of the R2 register, and corresponding processing functions are called Based on the tag type to obtain the necessary information for Kernel running.
