Linux-uboot- study notes (8): uboot boot the kernel
When uboot started when performing theKernel pointer to jump to the kernel execution, it marks the end of uboot. Uboot kernel final preparations to start before this: from the deployment location of the kernel image kernel move to DDR, the kernel check format, ready kernel parameters pass, jump to theKernel to perform kernel.
First, what is the kernel uboot
Kernel is essentially a large, complex "bare metal program", and uboot, and other bare metal program and no essential difference.
Difference is that the operating system running on the software into the core layer and application layer , the stratified layers of different permissions , access to more sophisticated memory management and operation of equipment (kernel can easily access a variety of hardware, and application only can access hardware and memory address limit).
Intuitively: the uboot mirror isu-boot.bin, Linux mirroring system iszImageThese two things are actually two bare metal program mirrors. Start from the perspective of the system is concerned, the kernel is actually a big point of bare metal complex procedures.
uboot is unconditional start, start from scratch. The kernel can not boot automatically start completely from scratch, the kernel boot to others for help. To help achieve uboot kernel relocation, uboot also provide start-up parameters to the kernel (from the SD card to the DDR).
Second, a specific partition deployment
A complete software + hardware of embedded systems, stationary (when not powered) bootloader, kernel, rootfs and other necessary software are stored in the form mirrored in the starting medium (X210 is iNand / SD card); Runtime It is run in DDR memory , regardless of the storage medium. The above two states are steady state, the third state is a dynamic process, i.e.,During operation from a quiescent state to state, that is, the boot process.
Dynamic start-up process is a gradual move from an SD card to DDR memory, and run the startup code to initialize the establishment of related hardware and software architecture, and ultimately achieve steady state operation.
U-boot.bin zImage rootfs in the SD card, they can not exist any random rest position of the SD card, it is necessary to partition a SD card, and each present a respective image various partitions, so start process uboot, the kernel and other who know where to look. (Uboot kernel and the partition table must be the same, while the actual partition, and use the SD card to be consistent)
When uboot relocation in a first stage, the second stage (uboot whole image) is loaded into DDR 0xc3e00000 address, the address is a link address uboot.
The kernel also has a similar requirement when uboot boot the kernel memory read from an SD card into the DDR (actually a relocation process), can not be left unattended, it must be placed at the core of the link address, or do not start up. For example kernel link address we use is 0x30008000.
Three, uboot kernel boot process
Step 1. Start the kernel: the kernel is loaded into the DDR
To start uboot kernel is divided into two steps: The first step is to load the kernel image from the medium to start the DDR DDR second step is to start the kernel image . (Kernel code did not even consider relocation, because the kernel knows there will be uboot like to load their own links to the DDR address, so the kernel is a direct link from the address at the start of the run )
Initially kernel image in the SD card kernel partition , it is necessary to read from the SD card kernel partition and a mirror (zImage-qt) and loaded into a DDR before kernel.
Uboot instruction fetch by:movi read kernel 30008000
Load by tftp:tftp 0x30008000 zImage-qt(To zImage-qt before loading into tftpboot folder)
loading is complete, the kernel starts by a command:bootm 0x30008000
The end result is that the kernel image to be the DDR to a specific address, regardless of how the kernel image to the DDR. Two or more ways have advantages and disadvantages. When the factory is set to start (the customer does not have to set up tftp server in order to use ???) from the SD card; tftp download Remote Start This approach is generally used to develop .
2. Start the kernel Step two: check the kernel format
First, the kernel image is probably available in three versions: Image, and zImage uImage .
After compiling linux kernel will generate an executable program that elf format, called vmlinux or vmlinuz , this is the original without any treatment and processing of the original kernel elf file; burn when deploying embedded systems are generally not the vmlinuz / vmlinux , but to use tools to objcopy made into a burning image format (that is, u-boot.bin this, but not the kernel .bin suffix), through the production process into a burning image file calledImage(78M making the large streamline became 7.5M, so the main purpose is to make burning mirrors to reduce the size and save disk).
In fact the authors think linux is still too big so the Image Image is compressed, and the compressed image file of the front end portion of the decompression code that is added (this part of the uncompressed) . Constitute a compressed image format calledzImage.
To start uboot linux kernel, the kernel also invented a format calleduImage. zImage uImage is obtained by machining, uboot with a tool, can be generated zImage uImage processing. Note: uImage something to do with the linux kernel, linux kernel zImage can simply generate, uboot in mkimage generated by the tool to go zImage uImage to start the process to uboot . This process is actually in front of the header information to add zImage uImage 64 bytes.
do_bootm function up to 397 linesafter_header_checkAt this symbol, it is performed header information checking mirror . It will be different depending on the type of verification when verifying image type. Therefore do_bootm core function is passed in to distinguish what type of image in the end, and in this type of header information to verify the format. Verification by the kernel is ready to start the next step; if the check fails believes that there is a problem mirrored, so you can not start.
(1) zImage start
For zImage magic number, and if the check is successful, the initiated by zImage format. Therefore, we can view the contents zImage to see the location where the magic number and the time of detection methods correspond.
image_header_tThis data structure is that we start uboot a standard data structure used by the kernel to start, zImage header information is a image_header_t, but prior to the actual start needs some renovation.hdr-> ih_os = IH_OS_LINUX; hdr-> ih_ep = ntohl (addr); these two is reinventing.
images global variable is used in the function do_bootm, used to complete the boot process. zImage validation process is not in fact make sure zImage, confirm and then modify header information zImage to the right, with a modified header information to initialize the global variable images, and then complete the verification.
(2) uImage start
Conventionally uboot supports three kinds of situations:
IMAGE_FORMAT_INVALID: image format is not legitimate.
IMAGE_FORMAT_LEGACY: uImage format.
IMAGE_FORMAT_FIT: device tree format.
uImage start in the main checkboot_get_kernelFunction, the main task is to check uImage header information, and get the real kernel of the starting position to start.
Where parameter passing zImage same manner, supports both cases, the default address parameter of less than 2; 2 greater than or equal parameters, the argv [1] pass in.
This is determined by magic uImage digital image format, and the print information.
This is after the determination is completed, some of the information inside the print image.
Here is a way to decompress the uImage.
By analysis of the code can be obtained, and zImage uImage substantially the same, are first determined by magic digital image format, and then after the parameter stored by constructing images down . images included in the image header information, the header information can be obtained through these basic elements of the image (the magic number, the length of the mirror, the mirror type, and so address entry). After the mass participation also need to use this information inside.
3. Start the kernel Step Three: Prepare the kernel parameter passing
(. 1) Introduction entrypoint
Abbreviation ep is the entrypoint, that is the program entry. Performing a start portion of the image file are not mirrored at the beginning (the beginning of the image has n bytes of header information), the real implementation of an image file byte code on a central mirror, is equivalent to the head there is a certain offset . This offset is recorded in the header information.
A mirror is typically performed: the first step, the read header information, and then look at a particular address MAGIC_NUM header information, thereby determining the type of image; a second step of the image for verification; a third step again reads the header information , known by the particular address information of the various mirror (length mirror, mirror type, an entry address); a fourth step begins execution go entrypoint mirror.
(2) Comparative machine code
uboot kernel at boot time, the machine code to be passed to the kernel. uboot passed to the kernel of the machine code is how determined? The first alternative is to order the environment variable machid, a second alternative is to order gd-> bd-> bi_arch_num (x210_sd.h arranged in hardcoded).
(3) tag parameter passing
uboot kernel parameter passing through tostruct tag, Tag is a data structure , and in uboot linux kernel is defined for the tag data means, and is the same definition.
Because uboot kernel and can not run at the same time , uboot after the kernel started by thekernel pointer. Therefore, in a specific format uboot (tag) in a particular position, then position corresponding to the kernel starts to take a corresponding method. Parameter passed is a future of a tag.
tag_header 和 tag_xxx. tag_header have the tag type code and the size (0x54410001), the first analysis obtained tag_header tag type (Core) and get a kernel size of the tag, and the tag part remaining as a tag_xxx (tag_core) treated.
tag_start 与 tag_end. kernel parameters received transmission tag is composed of a number, which is initiated by TAG_STARTback tag, to the end tag_end.
Starting tag is ATAG_CORE, the end tag is ATAG_NONE, other ATAG_XXX are valid information tag.
CONFIG_SETUP_MEMORY_TAGS, tag_mem , mass participation is the content memory configuration information .
CONFIG_CMDLINE_TAG, tag_cmdline , mass participation is content to start the command-line parameters , that is, uboot bootargs. Environment variables
CONFIG_INITRD_TAG, linux is INITRD mechanism.
CONFIG_MTDPARTITION, parameter passing content is the partition table iNand / SD card.
(4) theKernel function
tag can pass parameters through the above we know that when the kernel starts, various information parameters can be passed through a corresponding tag, then the kernel how we can get these kind of tag it?
The final call is passed uboot theKernel function to perform linux kernel, uboot call this function (actually a linux kernel) when: a.3 parameters. Uboot three parameters is passed directly to the linux kernel three parameters, parameter passing is achieved through the register. (The first parameter will be placed in r0, r1 on the second parameter, the third parameter in the r2) of the first parameter is fixed to 0, the second parameter is the machine code, the third transmission parameters the first address is the large mass of the reference tag.
theKernel = (void (*) ( int, int, uint)) ep; assigned to the ep theKernel, theThis function entry points to points to the real memory address loaded OS image(Code execution is the first sentence of the operating system). Thekernel last sentence uboot by parameters passed into the function pointer.
