BootLoader Design of ARM+Linux Embedded System

The boot loader of an embedded system is composed of the Boot Loader and the Boot code (optional) solidified in the firmware. Its role and function are like a ROM chip program BIOS (basic input output system) solidified on the motherboard of the computer. However, it is generally not configured with a firmware program like BIOS. This is because of economic reasons, so this work must be done by itself. The Boot Loader can initialize the hardware devices and establish a mapping map of the memory space, thereby bringing the system's software and hardware environment to a suitable state, so as to prepare the correct environment for the final call to the operating system kernel. Its implementation is heavily dependent on hardware, especially in embedded systems. Even if the Boot Loader is based on the same CPU, it is very different for different boards.

1 Boot Loader Analysis

After the system is powered on and reset, basically all CPUs get instructions from the reset address. In embedded systems with microprocessors as the core, there is usually some type of solid-state storage device (FLASH, E2PROM, etc.), which is mapped to a pre-set address. After the system is powered on and reset, the processor will start to execute the program stored at the reset address, and the Boot Loader can be located in the storage space at the beginning of the reset address through the development environment. Therefore, the Boot Loader is the first program to be run after the system is powered on, before the operating system kernel or some applications are run. For embedded systems, some use operating systems for more complex or to facilitate the later development of large applications. In many cases, systems with simple functions or only including applications do not use operating systems. However, whether there is an operating system or not, the Boot Loader must be executed at startup in order to prepare the software and hardware operating environment.

Embedded systems with microprocessors as the core generally have some type of solid-state storage device (FLASH, E2PROM, etc.), which is mapped to a pre-set address. After the system is powered on and reset, the processor will start to execute the program stored at the reset address. And through the development environment, the Boot Loader can be located in the storage space at the beginning of the reset address. Therefore, the Boot Loader is the first program to be run after the system is powered on, before the operating system kernel or some applications are run. For the Linux system, its main tasks are the following 7 aspects.

(1) Initialize the hardware resource configuration of the processor and peripherals. After the processor of a general embedded system is powered on and reset, the external I/O pins are in the input state, and the processor's on-chip and off-chip device resources need to be configured.

(2) Create a memory space mapping map to bring the system's hardware and software environment to a suitable environment, thus providing the best conditions for eventually starting the operating system kernel.

(3) Load the operation into the mapped memory. This is also the most important task among all tasks. Only after completing this task can the operating system be loaded into the memory. The Boot Loader generally provides two methods: serial port and network loading.

(4) In order to save the operating system image in FLASH for later startup, the FLASH data can be directly loaded without re-downloading the program, but the FLASH needs to be programmed.

(5) Run the operating system. Set the relevant registers and resources, jump to the space where the operating system is located, and perform relevant guidance. This is the Boot Loader.

(6) When the Linux system starts, the system startup parameters are passed. The command line and other parameters can be passed to the kernel. The command line can be used to select the startup mode of the system.

(7) Command line parsing and input/output control. For the convenience of development, most boot loaders use serial ports as terminal control methods.

The boot process of Boot Loader can be divided into two important stages. The first stage: Since the implementation of Boot Loader depends on the CPU architecture, the initialization of device code and other functions are completed in this stage. Moreover, in order to shorten the code, it is usually written in assembly language. The execution process of this stage can be divided into several aspects.

① Initialization of hardware devices. During the execution of this phase, the hardware devices must first be initialized. The purpose is mainly to prepare the basic hardware environment for the execution of the second phase and the subsequent Kernel call.

② Prepare RAM space for loading the second stage of the Boot Loader. In order to obtain faster execution speed, the second stage is usually loaded into the RAM space for execution. Therefore, a range of available RAM space must be prepared for loading the Boot Loader.

③Set the stack pointer. Setting the stack is to prepare for executing C language code.

④ Jump to the C entry point of the second stage. When the program executes to this position, it can jump to the second stage by modifying the value of the PC register.

Analysis of the startup process of the second stage: In order to facilitate the implementation of complex functions and obtain better code readability and portability, the second stage code is usually implemented in C language. However, the difference from ordinary C language is that the concept of "trampoline" is used here, that is, a small program is written in assembly language first, and this small program is used as the execution entry point of the second stage executable image, and then the CPU jump instruction is used in the assembly program to jump into the main() function for execution. When the main() function returns, the CPU execution path returns to the second stage in the assembly program again, including initializing the hardware devices to be used in this stage, detecting the system memory map, reading the kernel image and the root file system image from FLASH to the RAM space, and setting the startup parameters for the kernel to call the kernel.

2 Boot Loader Design

2.1 Design and establishment of interrupt vector table (secondary)

If an interrupt or exception occurs, the processor will force the PC pointer to point to the corresponding interrupt type address value in the vector table. In order to improve the interrupt response speed, the 0x0 address of FLASH stores the jump instruction that can jump to the interrupt vector at the address 0x33FFFF00, that is, a secondary interrupt vector table will be established in RAM, with the starting address of 0x33FFFF00. Except for reset, all exception entry addresses are obtained by FLASH jump, the code is as follows:

2.2 The second stage is copied to RAM

Copy the second stage Stage2 to the top of the RAM address with a size of 1 MB. The starting address of RAM is 0x30000000. The code is as follows:

2.3 Stack Pointer Setting

The interrupts used by the user determine the initialization of the system stack and the types of errors that the system needs to handle. In general, stack settings are required and are set by the administrator. If IRQ interrupts are required, the IRQ stack settings are also required. The following are the IRQ stack settings:

3. Stage 2 Design

3.1 Entry of Executable Image Stage 2

Since the functions supported by the Glibc library cannot be used to compile and link programs written in C language such as Boot Loader, the most direct idea is to use the starting address of the main() function as the entry point of the second stage. You can write a small Trampoline program in assembly language, use the CPU jump instruction to jump to the main() function for execution, and when the function returns, it will return to the Trampoline program again. The code is as follows:

If the program goes smoothly, it will not return to the starting Trampoline program, otherwise it will return to the last statement and the system will restart.

3.2 Memory Mapping

Generally, the size of SDR SAM configured on S3C2410 is 64 MB, and the physical address range of the SDRAM is Ox30000000~Ox33FFFFFF (belonging to Bank 6). From the size of the Section, it can be seen that the physical space can be divided into 64 physical segments. Because the data buffer in the ARM architecture must be enabled through the MMU, the efficiency of the Boot Loader is not very high, but the MMU can be enabled through flat mapping (the virtual address and the physical address are the same), so that the memory space Dcache is used, thereby effectively improving the running speed of the Boot Loader. The mapping relationship code is as follows:

3.3 Loading the kernel image and root file system image

Embedded CPUs like ARM usually address solid-state storage devices such as FLASH in a unified memory address space. Therefore, reading data from Flash is the same as reading data from RAM units. A simple loop can be used to copy the image from the FLASH device: where count is the size of the root file system image or the size of the kernel image.

3.4 Setting kernel startup parameters

Kernel boot can start and run Linux from NAND FLASH (NOR FLASH). The boot command needs to be modified as follows:

LCD startup parameters generally include root, init and console. noinitrd does not use ramdisk. The root file system is in the MTD partition. Init kernel runs the entry command file. console kernel information console, ttys0 represents serial port 0; tty0 represents virtual terminal.

4 Conclusion

Through the analysis of Boot Loader, we can see that designing a Boot Loader with excellent performance can improve the stability and real-time performance of the system. It is an indispensable part of embedded development. Only by designing a stable Boot Loader can we proceed to the next step of system development until the development of the entire embedded system is completed. Designing a Boot Loader is a very complex task, which requires a deep understanding of hardware resources and the operating system used. In actual development, the design can be simplified as needed, and unnecessary system functions can be removed, which can greatly improve the efficiency and stability of program execution. The Boot Loader given here has successfully passed the debugging and can load the operating system normally.