Embedded System BootLoader

Article Title: Embedded System BootLoader technology insider. Linux is a technology channel of the IT lab in China. Includes basic categories such as desktop applications, Linux system management, kernel research, embedded systems, and open source.
　　 1. Introduction
Running GNU/Linux systems on dedicated embedded boards has become increasingly popular. An embedded Linux system can be divided into four levels from the software perspective:
　　
1. boot the loader. Includes the boot Code (optional) in the firmware and the Boot Loader.
　　
2. Linux kernel. Customized kernel and kernel startup parameters specific to embedded boards.
　　
3. file system. Including the root file system and the file system built on the Flash memory device. Ram disk is usually used as root fs.
　　
4. user applications. User-specific applications. Sometimes an embedded graphical user interface may be included between the user application and the kernel layer. Common embedded guis are MicroWindows and MiniGUI.
　　
The pilot loader is the first piece of software code that runs after the system is powered on. Recall the architecture of the PC. We can know that the Boot Loader in the PC is defined by the BIOS (which is essentially a firmware program) and the OS Boot Loader in the hard disk MBR (for example, LILO and GRUB. After the BIOS completes hardware detection and resource allocation, it reads the Boot Loader in the hard disk MBR into the system RAM, and then gives the control to the OS Boot Loader. The main task of running Boot Loader is to read the kernel image from the hard disk to RAM, and 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 (NOTE: Some embedded CPUs also embed short boot programs ), therefore, the Boot Loader is used to load and start the entire system. For example, in an embedded system based on arm7TDMI core, the system usually starts from 0x00000000 when powered on or reset, in this address, the Boot Loader program of the system is usually arranged.
　　
This article will discuss the Boot Loader of the embedded system from four aspects: the concept of Boot Loader, the main task of Boot Loader, the Framework Structure of Boot Loader, and the installation of Boot Loader.
　　
　　 2. Concepts of Boot Loader
Simply put, Boot Loader is a small program that runs before the operating system kernel runs. Through this small program, we can initialize hardware devices and build a map of memory space to bring the system's hardware and software environment to a suitable state, in order to prepare the correct environment for the final call to the operating system kernel.
　　
Generally, Boot Loader relies heavily on hardware, especially in the embedded world. Therefore, it is almost impossible to build a general Boot Loader in the embedded world. However, we can still summarize some general concepts of Boot Loader to guide the user's specific design and implementation of Boot Loader.
　　
1. CPU and insert Board supported by Boot Loader
　　
Different CPU architectures have different Boot loaders. Some Boot loaders also support CPUs with Multiple Architectures. For example, U-Boot supports both the arm architecture and MIPS architecture. In addition to the CPU-dependent architecture, Boot Loader actually depends on the configuration of embedded board-level devices. That is to say, for two different insert boards, even if they are built based on the same CPU, to enable the Boot Loader program running on a board to run on another board, you usually need to modify the source program of the Boot Loader.
　　
2. Installation Medium)
　　
After the system is powered on or reset, all CPUs usually take instructions from a pre-arranged address by the CPU manufacturer. For example, the CPU Based on arm7TDMI core usually obtains its first command from address 0x00000000 during reset. CPU-based embedded systems usually have some kind of solid-state storage devices (such as ROM, EEPROM, or FLASH) mapped to this preset address. Therefore, after the system is powered on, the CPU will first execute the Boot Loader program.
　　
1 is a typical space allocation structure of a solid-state storage device with both Boot Loader, kernel startup parameters, kernel image, and root file system image.
　　
Typical space allocation structure of solid state storage devices
　　
3. the device or mechanism used to control the Boot Loader
　　
Generally, a connection is established between the host and the target host through a serial port. During execution, the Boot Loader software usually uses a serial port to perform I/O, for example, outputting information to the serial port, reads user control characters from the serial port.
　　
4. Whether the Boot Loader is started in Single Stage or Multi-Stage)
　　
Generally, multi-stage Boot Loader provides more complex functions and better portability. Most Boot loaders started from solid state storage devices are two-phase Boot processes, namely, the Boot process can be divided into two parts: stage 1 and stage 2. The specific tasks completed in stage 1 and stage 2 will be discussed below.
　　
5. Operation Mode)
　　
Most Boot loaders have two different operating modes: "Start loading" mode and "Download" mode. This difference is only meaningful to developers. However, from the end user's perspective, the function of Boot Loader is to load the operating system, but there is no difference between the so-called start loading mode and the download working mode.
　　
Boot loading Mode: This mode is also called the Autonomous mode. That is, Boot Loader loads the operating system to RAM from a solid-state storage device on the target machine, and does not involve user intervention throughout the process. This mode is the normal working mode of Boot Loader. Therefore, when embedded products are released, Boot Loader obviously must work in this mode.
　　
Downloading mode: In this mode, the Boot Loader on the target machine downloads files from the Host through serial port connection or network connection. For example: download kernel images and root file system images. Files downloaded from the host are usually first saved to the RAM of the target machine by Boot Loader, and then written to the FLASH solid-state storage device on the target machine. This mode of Boot Loader is usually used when the kernel and root file system are installed for the first time. In addition, Boot Loader will be used for later system updates. In this mode, Boot Loader usually provides a simple command line interface to its end users.
　　
A powerful Boot Loader such as Blob or U-Boot usually supports both working modes and allows users to switch between them. For example, Blob is in normal start loading mode at startup, but it will be delayed for 10 seconds until the end user presses any key and switches blob to download mode. If you do not press the button within 10 seconds, blob continues to start the Linux kernel.
　　
6. Communication devices and protocols used for file transmission between the BootLoader and the host
　　
The most common situation is that the Boot Loader on the target machine transmits files to the host through the serial port. The transmission protocol is usually one of xmodem/ymodem/zmodem protocols. However, the speed of serial transmission is limited. Therefore, it is better to use Ethernet connection and TFTP protocol to download files.
　　
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.
　　
After discussing the above concepts of BootLoader, let's take a look at what tasks should be completed by BootLoader.
　　
　　 3. Main Tasks and typical structure framework of Boot Loader
Before continuing the discussion in this section, let's make a assumption that the kernel image and the root file system image are loaded into RAM for running. The premise is that kernel images and root file system images in embedded systems can also run directly on solid-state storage devices such as ROM and Flash. However, this practice is undoubtedly at the expense of running speed.
　　
From the operating system perspective, the general goal of Boot Loader is to correctly call the kernel for execution.
　　
In addition, because the implementation of Boot Loader depends on the CPU architecture, most Boot loaders are divided into two parts: stage1 and stage2. Code dependent on the CPU architecture, such as the device initialization code, is usually stored in stage1, and is usually implemented in assembly language to achieve the goal of being short and concise. While stage2 is implemented through common C language, which can provide complex functions and better code readability and portability.
　　
Stage1 of Boot Loader generally includes the following steps (in the order of execution ):
　　
Hardware Device initialization.
　　
Prepare the RAM space for loading the stage2 of the Boot Loader.
　　
Copy the stage2 of the Boot Loader to the RAM space.
　　
Set the stack.
　　
Jump to the C entry point of stage2.
　　
The stage2 of Boot Loader usually includes the following steps (in the order of execution ):
　　
Initialize the hardware devices to be used in this phase.
　　
Checks the memory ing of the system ).
　　
Read the kernel image and the root file system image from the flash to the RAM space.
　　
Set startup parameters for the kernel.
　　
Call the kernel.
3.1 stage1 of Boot Loader
　　
3.1.1 basic hardware initialization
　　
This is an operation performed by the Boot Loader at the beginning. It aims to prepare some basic hardware environments for the execution of stage2 and subsequent kernel operations. It usually includes the following steps (in the order of execution ):
　　
1. Block all interruptions. It is usually the responsibility of the OS device driver to provide services for interruptions. Therefore, you do not have to respond to any interruptions during the execution of the Boot Loader. Interrupt shielding can be completed by writing the interrupt shielding register or Status Register (such as the CPSR register of arm) of the CPU.
　　
2. Set the CPU speed and clock frequency.
　　
3. RAM initialization. Including Correctly Setting the system's memory controller function registers and various memory library control registers.
　　
4. initialize the LED. Typically, GPIO is used to drive the LED. The purpose is to indicate whether the system status is OK or Error. If no LED exists on the board, you can initialize UART to print the Logo character information of Boot Loader to the serial port.
　　
5. Disable CPU Internal commands/data cache.
　　
3.1.2 prepare RAM space for loading stage2
　　
To get faster execution speed, stage2 is usually loaded into the RAM space for execution. Therefore