The relationship between BootLoader and kernel image

Last night, I heard my roommate talking about compiling the Linux kernel. As a computer science graduate, I have no idea about this thing. It was so depressing. After learning from many sources, I finally got a vague idea. In Linux, the kernel image is usually placed in boot/grub or boot/lilo. After my roommate's explanation, I roughly understood the image, but who reads this grub.conf? My roommate didn't know either. Lying in bed, I thought about it, BootLoader! This thing must be earlier than image loading! In connection with some development processes at work, I was more certain about this thing, and I was excited. . I came here this morning and checked BootLoader. The following is a more introductory explanation I found, which is roughly the same as what I thought. Continue to learn, as a kind of embedded system, the switch also needs BootLoader to load the image and run.
BootLoader is the first code that runs after the system is powered on. Generally, it only runs for a very short time when the system starts. For embedded systems composed of DaVinci, this is a crucial step.
In PC, the entire BootLoader consists of BIOS (a program fixed on the motherboard) and OS
Loader located in the MBR area of ​​the hard disk. BIOS completes the first-level boot loading, and OS
Loader completes the second-level boot loading (some systems may have more than two levels of loading). After power-on, the system starts to execute the code in BIOS, which is responsible for hardware detection and resource allocation. After completing this step, it will search the hard disk in the order set in CMOS. BIOS reads the content in the MBR of the first hard disk retrieved into the system RAM, and then hands over the system control to the corresponding OS
Loader. Finally, OS
Loader is responsible for reading the kernel image of the operating system to be booted from the hard disk into the system RAM, and then jumps to the entry point of the kernel.
In embedded systems composed of DaVinci platforms, there is usually no fixed program with fixed content like BIOS. The reason is that although PC platforms have different brands, they usually have similar or even identical architectures and follow a common industrial standard, so they can use the same BIOS code to boot. Usually for embedded systems, even if they use the same architecture, or even the same CPU such as DM6446, they cannot follow a common industrial standard. Therefore, unless the two aspects of the boot process are designed to be consistent, the same BootLoader cannot be used on embedded systems built on the DaVinci platform.
It can be said that BootLoader is the key to an embedded system composed of the DaVinci platform. Without this key, you cannot enter the door of the system. That is to say, after completing your own hardware research and development, the first task is to transplant the BootLoader.
The concept of BootLoader
BootLoader is the first piece of software code that the system starts running after powering on. Recalling the PC architecture, we can know that the boot loader in the PC consists of BIOS (which is essentially a firmware program) and the boot program located in the hard disk MBR. After completing hardware detection and resource allocation, the BIOS reads the boot program in the hard disk MBR into the system's RAM, and then hands over control to the boot program. The main running task of the boot program is to read the kernel image from the hard disk into the RAM
and then jump to the kernel entry point to run, that is, start the operating system.
In embedded systems, there is usually no firmware program like BIOS (some embedded systems also have a short startup program embedded), so the loading and startup task of the entire system is completely completed by BootLoader. For example, in an embedded system based on ARM7TDMI core, the system starts execution
from address 0x00000000 when it is powered on or reset . And the system's BootLoader program is usually arranged at this address. Simply put, BootLoader is a small program that runs before the operating system kernel or user application runs. Through this small program, we can initialize hardware devices and establish a mapping map of memory space (some CPUs do not have memory mapping functions such as S3C44B0), thereby bringing the system's hardware and software environment to a suitable state, so as to prepare the correct environment for the final call to the operating system kernel or user application. For an embedded system, some may include an operating system, and some small systems may only include applications, but before this, BootLoader is required to prepare a correct environment for it. Usually, BootLoader is implemented based on hardware, especially in the embedded field, it is very difficult to establish a general BootLoader for embedded systems. Of course, we can summarize some general concepts so that we can understand the design and implementation of a specific BootLoader. u BootLoader porting and modification Each different CPU architecture has a different BootLoader. In addition to relying on the CPU architecture, the BootLoader actually also depends on the configuration of specific embedded board-level devices, such as the hardware address allocation of the board, the type of RAM chip, the type of other peripherals, etc. This means that for two different embedded boards, even if they are built based on the same CPU, if their hardware resources and configurations are inconsistent, if you want the BootLoader program running on one board to run on another board, you still need to make some necessary modifications. u BootLoader installation After the system is powered on or reset, all CPUs usually take instructions from the address pre-arranged by the CPU manufacturer. For example, S3C44B0 takes its first instruction from address 0x00000000 when it is reset. Embedded systems usually have some type of solid-state storage device (such as ROM, EEPROM or FLASH, etc.) arranged at this starting address, so after the system is powered on, the CPU will first execute the BootLoader program. That is to say, for this system based on S3C44B0, our BootLoader is stored from address 0, and this starting address needs to use a bootable solid-state storage device such as FLASH. u Device or mechanism used to control the BootLoader Serial communication is the simplest and cheapest dual-machine communication device, so the host and target machines are often connected through the serial port in the BootLoader. When the BootLoader program is executed, it usually performs I/O through the serial port, such as outputting print information to the serial port, reading user control characters from the serial port, etc. Of course, if you think the export communication speed is not enough, you can also use network or USB communication, then you need to write your own driver in the BootLoader accordingly. u BootLoader startup process Multi-stage BootLoader can provide more complex functions and better portability. Most of the BootLoaders started from solid-state storage devices are two-stage boot processes, that is, the boot process can be divided into two parts: stage 1 and stage 2. The specific functions will be introduced in the next section.














u Boot Loader Operation Modes
Most Boot Loaders contain two different operation modes. "Boot Loading" mode and "Download" mode. This distinction is only meaningful to developers. But from the end user's point of view, the role of Boot Loader is to load the operating system, and there is no difference between the so-called boot loading mode and download working mode.
Boot loading
mode: This mode is also called "autonomous" mode, that is, the Boot Loader loads the operating system from a solid-state storage device on the target machine into the RAM for operation, and the whole process does not involve the user. This mode is the normal working mode of the Boot Loader. Therefore, when the embedded product is released, the Boot Loader must obviously work in this mode.
Download mode: In this mode
The Boot Loader on the target machine will download files from the host through communication means such as serial port connection or network connection, such as: downloading applications, data files, kernel images, etc. The files downloaded from the host are usually first saved by the Boot Loader to the RAM of the target machine and then written to the solid-state storage device on the target machine by the Boot Loader. This mode of Boot Loader is usually used when the system is updated. The BootLoader working in this mode usually provides a simple command line interface to its end user.
The autonomous mode is not implemented in the BootLoader provided in the teaching system. This function can be implemented by modifying the code.
u Communication equipment and protocol used for file transfer between the BootLoader and the host
The most common situation is that the BootLoader on the target machine transfers files to the host through the serial port. The transmission can simply use direct data transmission and reception. Of course, the xmode/ymode/zmode protocol can also be used on the serial port and the TPTP protocol can be used on the Ethernet.
In addition, when discussing this topic, the software used by the host side must also be considered. For example, when downloading files through an Ethernet connection and the TFTP protocol, the host side must have a software to provide TFTP services.