This paper introduces the concept of the OS boot loader based on the embedded system, the concept of Boot Loader, the main task of software design, and the structure framework. 1. Introduction In the dedicated embedded board, the GNU / Linux system has become more and more popular. A embedded Linux system can usually be divided into four levels from the perspective of software: 1. Boot loader. Includes Boot code (optional) cured in firmware, and two parts of Boot Loader. 2. Linux kernel. The custom kernel of the embedded plate and the startup parameters of the kernel. 3. File system. Includes root file system and file system based on Flash memory devices. Usually used as RAM Disk as root fs. 4. User application. User-specific applications. Sometimes there may be an embedded graphical user interface between the user application and the kernel layer. Common embedded GUIs are: MicroWindows and Minigui understand. The boot loader is the first software code running after the system is powered up. Recalling the architecture of the PC We can know that the boot loader in the PC consists of BIOS (its essence is a firmware program) and OS boot loader located in the hard disk MBR (such as Lilo, and Grub, etc.). After completing hardware detection and resource allocation, Boot Loader in the hard disk MBR is read in the system's RAM, and then the control is handed over to OS Boot Loader. Boot Loader's main running task is to read the kernel image from the hard disk to the RAM, then jump to the entry point of the kernel to run, which will start the operating system. In the embedded system, there is usually no firmware program like the BIOS (note, some embedded CPUs also embed a short start program), so the load start tasks of the entire system are completely completed by the boot loader. For example, in an embedded system based on ARM7TDMI Core, the system is usually started from the address 0x00000000 when power-on or reset, and it is usually the Boot Loader program of the system at this address. This article discusses the Boot Loader of the embedded system from the four aspects of the Boot Loader's concept, Boot Loader's main task, Boot Loader's framework and Boot Loader installation. Second, Boot Loader's conceptually said that Boot Loader is a small program that runs before the operating system kernel runs. Through this small program, we can initialize the hardware device to create a mapping map of memory space, bringing the software hardware and software environment to a suitable state to prepare the correct environment for the final call operating system kernel. Typically, Boot Loader is severely relying on hardware, especially in embedded world. Therefore, it is almost impossible to establish a general Boot Loader in the embedded world. Despite this, we can still summarize some general concepts to Boot Loader to guide users specific Boot Loader design and implementation. 1. The CPU and embedded boards supported by Boot Loader have different CPU architectures with different Boot Loader. Some boot loaders also support a variety of architectural CPUs, such as U-Boot, support the ARM architecture and MIPS architecture. In addition to the architecture that relies on the CPU, Boot Loader actually depends on the configuration of the specific embedded plate-based device. That is to say, for two different embedded panels, even if they are constructed based on the same CPU, if they want to run the Boot loader program running on a plate on another board, usually also Need to modify the source program of Boot Loader.
2. The installation medium of the Boot Loader is powered or reset, all CPUs usually take instructions from a certain address pre-scheduled by the CPU manufacturer. For example, the CPU based on ARM7TDMI CORE is typically taken from the address 0x00000000 from the address 0x00000000 when reset. CPU-based embedded systems typically have some type of solid state storage device (such as ROM, EEPROM or FLASH, etc.) being mapped to this pre-arranged address. Therefore, after the system is powered up, the CPU will first execute the Boot Loader program. The following is a typical spatial allocation structural diagram of a Solid Storage Device that simultaneously contains a boot loader, a kernel's startup parameter, a kernel image, and a root file system image. Figure 1 Typical spatial distribution structure of solid state storage equipment
3. Equipment or mechanism host and target machine to control Boot Loader is generally connected to the serial port, and the Boot Loader software is usually performed by serial port when executed, such as: Output print information to the serial port, read from serial port Take the user control character, etc. 4. The boot loader startup process is a single stage or multi-stage usually multi-stage Boot Loader provides more complex features, as well as better portability. Most boot loaders starting from solid state storage devices are 2-stage startup process, i.e., the startup process can be divided into two parts and STAGE 2. As for the specific completion of Stage 1 and STAGE 2, it will be discussed below. 5. Operation Mode Mode Most Boot Loader contains two different operating modes: "Launch Load" mode and "Download" mode, this difference is only for developers. However, from the perspective of end users, the role of Boot Loader is to load the operating system, and there is no distinction between the so-called start-load mode and the download mode. Boot loading mode: This mode is also called "autonomous) mode. That is, Boot Loader loads the operating system into the RAM from a certain solid storage device on the target, and the entire process does not intervene. This mode is the normal working mode of Boot Loader, so the boot loader must work in this mode when the embedded product is released. Download (Downloading) Mode: In this mode, Boot Loader on the target will download files from the host (Host) through communication means such as serial connections or network connectivity, such as downloading kernel images and root file system images. The files downloaded from the host typically be saved in the RAM of the target machine by Boot Loader, and then written by Boot Loader to the Flash Category Solid Storage Device on the Tall. This mode of Boot Loader is usually used when the first installation kernel is used when the root file system is installed; in addition, the future system update will use the work mode of Boot Loader. Boot Loader working in this mode usually provides a simple command line interface to its end users. Strong Boot Loader like blob or u-boot usually supports both working modes simultaneously, and allows users to switch between the two working modes. For example, Blob is in normal startup mode at startup, but it will delay 10 seconds waiting for the end user to press any key to switch BLOB to download mode. If there is no user button in 10 seconds, the blob continues to start the Linux kernel. 6. The most common case of communication devices and protocols used between BootLoader and the host is that Boot Loader on the target machine is transmitted through the serial port and the host, the transfer protocol is usually one of the XMODEM / YMODEM / ZMODEM protocol. . However, the speed of serial port transmission is limited, so it is a better selection through the Ethernet connection and downloading the file with the TFTP protocol. In addition, the software used by the host is also considered in the theory and this topic. For example, when downloading the file by an Ethernet connection and a TFTP protocol, the host must have a software to provide TFTP services.
After discussing the above concept of Bootloader, let's take a look at what tasks should be done by Bootloader. ----------------------------------
This article is reproduced in IBM DW, Author: Zhan Rong open research interests include: embedded Linux, Linux kernel, drivers, file systems. You can connect him through ZHANRK@sohu.com.
Figure 1 Typical spatial distribution structure of solid state storage equipment
3. Equipment or mechanism host and target machine to control Boot Loader is generally connected to the serial port, and the Boot Loader software is usually performed by serial port when executed, such as: Output print information to the serial port, read from serial port Take the user control character, etc. 4. The boot loader startup process is a single stage or multi-stage usually multi-stage Boot Loader provides more complex features, as well as better portability. Most boot loaders starting from solid state storage devices are 2-stage startup process, i.e., the startup process can be divided into two parts and STAGE 2. As for the specific completion of Stage 1 and STAGE 2, it will be discussed below. 5. Operation Mode Mode Most Boot Loader contains two different operating modes: "Launch Load" mode and "Download" mode, this difference is only for developers. However, from the perspective of end users, the role of Boot Loader is to load the operating system, and there is no distinction between the so-called start-load mode and the download mode. Boot loading mode: This mode is also called "autonomous) mode. That is, Boot Loader loads the operating system into the RAM from a certain solid storage device on the target, and the entire process does not intervene. This mode is the normal working mode of Boot Loader, so the boot loader must work in this mode when the embedded product is released. Download (Downloading) Mode: In this mode, Boot Loader on the target will download files from the host (Host) through communication means such as serial connections or network connectivity, such as downloading kernel images and root file system images. The files downloaded from the host typically be saved in the RAM of the target machine by Boot Loader, and then written by Boot Loader to the Flash Category Solid Storage Device on the Tall. This mode of Boot Loader is usually used when the first installation kernel is used when the root file system is installed; in addition, the future system update will use the work mode of Boot Loader. Boot Loader working in this mode usually provides a simple command line interface to its end users. Strong Boot Loader like blob or u-boot usually supports both working modes simultaneously, and allows users to switch between the two working modes. For example, Blob is in normal startup mode at startup, but it will delay 10 seconds waiting for the end user to press any key to switch BLOB to download mode. If there is no user button in 10 seconds, the blob continues to start the Linux kernel. 6. The most common case of communication devices and protocols used between BootLoader and the host is that Boot Loader on the target machine is transmitted through the serial port and the host, the transfer protocol is usually one of the XMODEM / YMODEM / ZMODEM protocol. . However, the speed of serial port transmission is limited, so it is a better selection through the Ethernet connection and downloading the file with the TFTP protocol. In addition, the software used by the host is also considered in the theory and this topic. For example, when downloading the file by an Ethernet connection and a TFTP protocol, the host must have a software to provide TFTP services.
After discussing the above concept of Bootloader, let's take a look at what tasks should be done by Bootloader. ----------------------------------
This article is reproduced in IBM DW, Author: Zhan Rong open research interests include: embedded Linux, Linux kernel, drivers, file systems. You can connect him through ZHANRK@sohu.com.
