uboot kernel and in the end is what?
uboot essence is a complicated bare-metal program; uboot can be configured can do transplants;
the operating system kernel itself is a bare metal program, and uboot and other bare metal program we learn not essentially different; difference is that after our operating system up and running can be back into the application layer and kernel layer, stratification, different layers of authority, more sophisticated memory management and device access operations (kernel can easily position a variety of hardware, applications can only be limited access to hardware and memory address )
intuitively: uboot image is a mirror image of u-boot.bin, Linux system is zImage, these two things are actually two bare metal program mirrors. From the point of view in terms of system startup. Kernel and uboot is bare metal program;
deploy special partition on the SD card
(1) a complete software + hardware of embedded systems, stationary (not powered) bootloader, kernel, rootfs and other necessary software in the form of a mirror stored in the boot medium (x210 is inand / SD card); runtime is running in DDR memory, regardless of the storage medium. The above two states are steady state, the third state is a dynamic process, i.e. from the stationary state to the running state of the process, the process is started. It is this whole process.
(2) dynamic start-up process is gradually moving from the SD card to DDR memory, and run the startup code to initialize the establishment of related hardware and software architecture, and ultimately achieve stable operation state.
(3) u-boot.bin zImage rootfs in SD card, they can not exist stationary random anywhere in the SD card, SD card so we need to be a partition, and then all kinds of mirror each present their own partition so during the boot process, uboot, the kernel and other who know where to look. (Uboot kernel partition table must be the same, while the actual partition, and use the SD card to be consistent)
runtime must be loaded into the DDR link address
When uboot relocation in a first stage, the second stage (the entire image uboot) 0xc3e00000 DDR loaded into the address, this address is the address uboot connection.
(2) The kernel also have similar requirements, uboot boot the kernel when the kernel is read from the SD card to the DDR (actually the relocation process) and can not put, must be placed at the core of the link address, or do not start up, for example, core connection address we use 0x300080000
kernel boot parameters required to start the necessary
(1) the kernel can not boot automatically start completely from scratch, and need someone to help start the kernel. To help achieve the core uboot uboot also provide relocation to the kernel boot parameters (from the SD card to the DDR).
Step Start kernel: load the kernel into a DDR
uboot to launch 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 know bootloader to load itself to help address the link DDR, the kernel will run directly from the link at the address)
static kernel image Where?
(1) SD card, inand, nand, norflash such as: raw area
when routine start various mirrored in SD card, so just from uboot kernel partition boot media SD card to read the kernel image to address the DDR link read command to read uboot to use (e.g. inand version movi command, nand nand command version is x210)
(2) this start-up mode to load DDR, use the command: movi read kernel 30008000. kernel refers wherein uboot in the kernel partition (that is, a region-wide regulations uboot SD card, this region range is designed to store kernel images, the so-called kernel partition, sometimes also called the original partition, boot the operating system can use the file system to manage partition.)
(3) tftp, nfs-peer networks to download from the remote server to obtain a mirror
when uboot also supports remote boot, which is the kernel image does not burn to the development board SD card, but on the host server, then you need to start uboot image downloaded through the network from the server to the DDR developed plate.
Analysis Summary: The end result is a specific address to the kernel image to the DDR. Above two methods have advantages and disadvantages, the product at the factory will be set up to boot from the SD card, the customer will not be there to set up tftp server to use, tftp download remote boot, suitable for development.
Mirroring what address to put the DDR?
The kernel must be placed at the address link, the link address to the kernel source code in connection script or makefile to find. x210 is 0x300080000.
zImage uImage difference and contact
bootm command corresponds do_boot function
(1) before the command name plus do_, do_bootm in cmd_bootm.c in
(2) do_bootm the beginning of the definition of a variable, and then use conditional compilation macros to execute some code secureboot mainly safety certificate. Then to the CONFIG_ZIMAGE_BOOT, be a piece of code conditional compilation use this macro to control, this code is used to support the kernel boot zImage format.
and vmlinuz and zImage uImage
(1) uboot compile epigenetic became an ELF format executable program uboot, this EXE format under similar windows, can be executed in the operating system, but can not be used to burn downloaded, we to burn downloaded u-boot.bin, which is used by the u-boot arm-linux-objcopy ( main purpose is to remove useless) obtained. u-boot.bin called mirroring, mirroring is used to burn and burn to inand performed, or performed on the SD card, or download execution dnw,
(2) Linux kernel after compiling a program will generate an executable ELF format, called vmlinuz or vmlinux, this is the original without any treatment and processing of the original kernel ELF file, the embedded generally not deployed burn this vmlinuz, but the use of tools to objcpy made into a burning image format (that is, u-boot.bin this, but not the kernel .bin suffix) is produced by the burning mirror Image, mirrored main purpose is to reduce the size, thrift disk.
(3) Image In principle, it can be burned directly to Flash, but in reality is not so simple, in fact, the authors feel that Linux Image is too big, it is compressed, and the compressed portion of the previous paragraph, additional part decompress the code, but constitutes a mirror image compression is zImage (the year when the Image size just larger than a floppy disk (floppy disk is in 2, 1.2M and 1.4M, 1.4M larger than the Image), in order to save a floppy disk money, and thus, the design of this Image compression technology into zImage)
(4) uboot order to start the Linux kernel, the kernel also invented a format called uImage. zImage uImage is obtained by machining, the uboot with a tool, can be zImage uImage processing. Note: uImage thing regardless of the Linux kernel, the Linux kernel can just generate zImage, then uboot in mkimage tool to go there zImage uImage to start the process to generate uboot. This processing procedure is in front zImage uImage to add header information of 64 bytes.
(5) In principle uboot boot should give him the kernel image uImage format, but in fact uboot can also support zImage, whether to support x210_sd.h to see whether this macro is defined LINUX_ZIMAG_MAGIC. So some uboot support zImage start, some do not. But all uboot certainly support uImage start.
Compile the kernel uImage to get started
(1) Step 1: If you go to make uImage directly under the kernel prompt mkimage not find the solution is to go to copy / usr / local / bin in / uboot / tool go below, copy it to the system directory, and then performed to make uImage it
zImage details of startup
#ifdef CONFIG_ZIMAGE_BOOT
#define LINUX_ZIMAGE_MAGIC 0x016f2818
/ OUT * Find Kernel Image address * /
IF (argc <2) {
addr = load_addr;
Debug ( "* Kernel: Image Load default address = 0x% 08lx \ n-",
load_addr);
} the else {
addr = simple_strtoul (the argv [. 1], NULL, 16);
Debug (" * Kernel: cmdline Image address = 0x% 08lx \ n-", img_addr);
}
IF (* ( * ulong) (* addr +. 4. 9) == LINUX_ZIMAGE_MAGIC) {
the printf ( "the 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, the sizeof (image_header_t));
/ * pointer to Save Image header * /
Images. HDR = legacy_hdr_os;
images.legacy_hdr_valid =. 1;
GOTO after_header_check;
}
#endif
are carried out header information checking function zImage mirrors before do_bootm up to 397 rows. 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. By then check the next step is ready to start the kernel; Ruoguo check fails it believes that there is a problem mirrored, so you can not start.
LINUX_ZIMAGE_MAGIC 0x016f2818 #define
(. 1) which is a magic number, 0x016f2818 this image is expressed zImage, that is to say the mirror zImage format, this number is stored in a fixed position of the head, as the format marks, if we got a Image, to that position to pick up his four bytes determines whether it is equal to the number of the magic LINUX_ZIMAGE_MAGIC. Then you know that this image is not zImage
(2) command bootm 0x30008000, so do_bootm the argc = 2, argv [0] = bootm argv [1] = 0x30008000 bootm but the actual command without parameters may also be performed, if no parameters will directly from bootm, CFG_LOAD_ADDR to address perform (defined in the x210_sd.h)
(. 3) from the head zImage of 37 to 40 bytes, the magic number is stored in the flag zImage removed from this position LINUX_ZIMAGE_MAGIC contrast, we can view the binary tool View zImage the mirror and found that this really is the magic number is stored.
image_header_t
(1) This data structure is our uboot a standard startup data structure to start used by the kernel, zImage header information is a image_header_t, but prior to the actual start needs some renovation,
IF (* (ulong *) (addr + 9 * 4 ) == LINUX_ZIMAGE_MAGIC) {
the printf ( "the 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, the sizeof (image_header_t));
/ * pointer to Save Image header * /
HDR = images.legacy_hdr_os;
images.legacy_hdr_valid = 1;
this is during the transformation.
(2) image bootm global variable is used in the function, the object is used to point os / initrd / fdt images, which is used to complete the startup, zImage verify process to determine if zImage, and then modify the header information zImage, to the right, which is above the transformation, the last and then the header information to initialize the image, and then complete the verification.
zImage startup mode is added later, but with the way the jump goto a part of the code, add itself to the structure of the uboot.
uImage Start
(1) a method in legacy do_boot uboot started in such a manner refers uImage, why legacy (legacy), because uImage itself is a way to start uboot invention, this later way is bad, abandoned, they were to replace a new way, a new way is the way the device tree, is referred to herein fit, this is the way the device tree.
(2) uImage start check function in boot_get_kernel this function, the main task is to check our uImage header information, and get the real kernel of the starting position to start.
Summary: uboot itself only supports uImage way to start, and later Once you have the device tree, put uImage manner was named legacy mode, fdt way is named fit manner, and thus be more #if #endif Add code. Later transplant in order to save the people and added zImage way, and in order to save, adding #if #endif.
End of the second stage of verification header information, the third stage, start the Linux kernel, calling this function do_bootm_linux
do_bootm_linux
(1) find do_bootm_linux, this function lib_arm / bootm.c in, sourceinsight not find, to search to find,
(2) mirror EntryPoint
EP is the program entry, an initial portion of the image is not mirrored in the beginning (Mirror there are many beginning byte header information), the code actually started in a middle part, with respect to the head has a certain offset, this offset is placed 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, the second step verify the mirror, the third step again reads the header information, the head address information of the specific kinds of information to know this mirror, including the length, type, and so address entry, the fourth step is to begin at the mirror entrypoint,
theKernel = (void (*) (int, int, uint)) EP ; the actual entrance address assigned to thekernel, is the operating system of the first sentence of the code
machine code again to determine
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? Alternatively the first sequence environment variable machid, a second alternative is to order gd-> bd-> bi_arch_number (x210_sd.h configured)
transmission parameters and start
the kernel parameter passing (do_bootm_linux 110-144 lines here)
Starting Kernel ... here is the final print uboot printing of information, if the phrase, serial no output, indicating the kernel is not successfully performed because the mass participation error (80%), the kernel load address in the DDR. . .
A tag mode of mass participation
(1) struct tag, tag is a data structure, and in the linux kernel uboot tag data defined in both bodies, but the definition is the same.
(2) tag_header and tag_xxx. tag_header this tag has the size and type of coding, kernel got a tag tag_header obtained after the first analysis of the tag type and size, then the remaining portion of the tag as a tag_xxx processed.
(3) tag_start and tag_end. kernel parameters received transmission tag is composed of a number, which is initiated by TAG_STARTback tag, to the end tag_end.
(4) transfer parameter tag by way of the invention linux kernel, kernel to define such a parameter passing mode I, uboot only way to achieve this transmission parameters so as to support the kernel parameter passing.
x210_sd.h configuration parameter passing macro
(1) CONFIG_SETUP_MEMORY_TAGS, tag_mem, parameter passing are memory configuration information content.
(2) CONFIG_CMDLINE_TAG, tag_cmdline, the content is to start mass participation command line parameters, that is, bootargs uboot environment variable.
(3) CONFIG_INITRD_TAG
(4) CONFIG_MTDPARTITION, mass participation content is the partition table iNand / SD card.
(5) is the start tag ATAG_CORE, the end tag is ATAG_NONE, ATAG_XXX other information are valid tag.
Thinking: How to get the kernel tag?
uboot ultimately call theKernel function to perform linux kernel, uboot call this function (actually a linux kernel) passed three 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.
2.7.7.3, when migrating Notes
(1) When uboot transplant generally only need to configure the macro to
(2) kernel unsuccessful start, pay attention to mass participation was successful. Parameter passing unsuccessful first look bootargs settings are correct in uboot, uboot second look at whether to open the appropriate macros to support mass participation.
https://www.cnblogs.com/yr-linux/p/5495734.html