Relationship between Bootloader and kernel Image

Last night, I heard from my roommates about how to compile the Linux kernel. As a computer graduate, I don't know much about it. It's so depressing. After much understanding, we finally have a vague concept. In Linux, the kernel image is usually stored in Boot/grub or boot/Lilo. After a roommate's explanation, I have a rough idea about this image. But who will read this grub. conf? You do not know. Come and think about it in bed, bootloader! This must have been loaded earlier than the image! I was excited to contact some development procedures at work to determine this thing .. I checked the bootloader this morning. Below is a more advanced explanation, which is similar to what I think. As a type of embedded system, a vswitch requires bootloader to load and run the image.
Bootloader is the first code to run after the system is powered on. Generally, it only runs in a very short period of time when the system is started. This is a crucial step for embedded systems consisting of DaVinci.
In a PC, the entire bootloader is composed of BIOS (a program solidified on the motherboard) and OS located in the hard disk MBR area.
Loader. BiOS completes the first-level boot loading, OS
Loader completes the second-level boot loading (some systems may load more than two levels ). After power-on, the system starts to execute the code in the bios, which is responsible for hardware detection and resource allocation. After completing this step, the hard disk will be retrieved in the order set in CMOS. The BIOS reads the content in MBR from the first retrieved hard disk to the system ram, and then gives the system control to the corresponding OS.
Loader. Finally
Loader reads the kernel image of the operating system to be guided from the hard disk to the system ram, and then jumps to the kernel entry point.
In an embedded system composed of the DaVinci platform, there is usually no fixed program such as BIOS. The reason is that although there are differences in the PC platform brand, there are usually similar or even the same architecture, following a common industrial standard, so you can use the same BIOS code for guidance. For embedded systems, even if the same architecture or even the same CPU is built on dm6446, it cannot comply with a common industrial standard. Therefore, the same bootloader cannot be used in an embedded system built on the DaVinci platform unless all aspects of the two are consistent with the design of the boot process.
Bootloader is the key of an embedded system composed of the DaVinci platform. Without this key, you cannot access the system. That is to say, after completing hardware R & D, the first task is to port bootloader.
Concepts of bootloader
Bootloader is the first software code for the system to power up and run. recall the architecture of the PC. We can know that the boot loader in the PC is composed of the BIOS (which is essentially a firmware program) and the boot program in the hard disk MBR. After completing hardware detection and resource allocation, the BIOS reads the boot program in the hard disk MBR to the system Ram and gives control to the boot program. The main running task of the boot program is to read the kernel image from the hard disk to ram.
Then jump to the kernel entry point to run, that is, start the operating system.
In embedded systems, there are usually no firmware programs like bios (some embedded systems also embed short boot programs ), therefore, the boot task of the entire system is completely completed by bootloader. for example
In the embedded system of ARM7TDMI core, when the system is powered on or reset from the address
0x00000000 is started, and the system bootloader program is usually arranged at this address.
In short, bootloader is a small program that runs before the operating system kernel or user applications run. Through this applet, We can initialize hardware devices and create a memory space ing diagram (some CPUs do not have the memory ing function, as shown in figure
To bring the system's hardware and software environment to a suitable State, so as to prepare the correct environment for the final call of the operating system kernel or user applications. For an embedded system, some may include the operating system, and some small systems may only include applications. However, before that, bootloader needs to prepare a correct environment for it. Generally, bootloader is implemented by hardware, especially in the embedded field. It is very difficult to establish a general bootloader for the embedded system. Of course, we can summarize some general concepts so that we can understand the design and implementation of a specific bootloader.
Port and modify U bootloader
Each CPU architecture has a different bootloader. In addition to the CPU architecture, bootloader actually depends on the configuration of embedded board-level devices, such as card hardware address allocation, RAM chip type, and other peripheral types. That is to say, 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 a 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, the First Command of the B0 reset is obtained from the address 0x00000000. Embedded systems usually have some type of solid-state storage devices (such as Rom, EEPROM, or flash) arranged on this starting address. Therefore, after the system is powered on, the CPU will first execute the bootloader program. That is to say, for this system based on B0, our bootloader is stored from the 0 address, and this starting address needs to adopt a bootable solid-state storage device such as flash.
U is the device or mechanism used to control bootloader.
Serial Communication is the simplest and cheapest type of Dual-host communication device. Therefore, in bootloader, the host and the target are connected through the serial port, the bootloader program is usually executed through the serial port.
I/O, for example, outputs printed information to the serial port, and reads user control characters from the serial port. Of course, if you think that the egress communication speed is not enough, you can also use network or USB communication, then you need to write their respective drivers in the bootloader.
U bootloader Startup Process
Multi-Stage bootloader provides more complex functions and better portability. Started from a solid-state storage device
Most of the bootloader is a two-phase START process, that is, the START process can be divided into stase1 and stase.
2. The specific functions are described in the next section.
Operating mode of u boot loader
Most bootloaders have two different operating modes. The "Start loading" mode and "Download" mode are only meaningful to developers. However, from the end user's perspective, bootloader is used to load the operating system, and there is no difference between the so-called start loading mode and download working mode.
Boot
Loading Mode: This mode is also called the autonomous mode, that is, the bootloader loads the operating system to ram from a solid-state storage device on the target machine for running, no user intervention is involved in the entire process. This mode is the normal working mode of bootloader. Therefore, during the release of embedded products, bootloader obviously must work in this mode.
Download (down loading) mode: In this mode
The bootloader on the target machine downloads files from the host through serial port connection or network connection, such as downloading applications, data files, and kernel images. files downloaded from the host are usually saved to the ram of the target host by Bootloader and then written to the solid state storage device of the target host. This mode of bootloader is usually used when the system is updated. In this mode, the bootloader usually provides a simple command line interface to its end users.
The bootloader provided in the teaching system does not implement the autonomous mode. You can modify the code to implement this function.
Communication device and protocol used for File Transfer Between U Bootloader and host
The most common situation is that the bootloader on the target machine transfers files to the host through the serial port, and the transmission can simply adopt direct data sending and receiving, of course, xmode/ymode/zmode protocol and tptp protocol can also be used on the serial port.
In addition, the software used by the host should also be considered when talking about this topic. For example, when downloading files through Ethernet connections and the TFTP protocol, the host must have a software to provide the TFTP service.