Analysis and Design of Boot Loader for ARM-Linux Embedded System

0 Introduction
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 device and establish a mapping map of the memory space, so as to bring 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 development environment can locate the Boot Loader 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 embedded systems, some use operating systems for more complex or large applications to facilitate the later development. 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.
In embedded systems with microprocessors as the core, there are generally some type of solid-state storage devices (FLASH, E2PROM, etc.), which are 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 development environment can locate the Boot Loader 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 Linux systems, its main tasks are as follows.
(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) Establish a mapping map of the memory space, so as to bring the system's hardware and software environment to a suitable environment, so as to provide the best conditions for the final startup of the operating system kernel.
(3) Load the operation into the mapped memory, which is also the most important of 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 future 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 booting. This is the Boot Loader.
(6) When the Linux system starts, pass the system startup parameters, and pass the command line and other parameters to the kernel. The command line can select the system startup mode.
(7) Command line parsing and input/output control. For the convenience of development, most Boot Loaders use serial ports as the terminal control method.
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 stage, the hardware devices need to be initialized first. Its purpose is mainly to prepare the basic hardware environment for the execution of the second stage and the subsequent Kernel call.
② Prepare RAM space for loading the second stage of Boot Loader. In order to obtain faster execution speed, the second stage is usually loaded into RAM space for execution. Therefore, a range of available RAM space must be prepared for loading Boot Loader.
③ Set the stack pointer. Setting the stack is to prepare for the execution of 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 boot 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 "spring bed" is used here, that is, first write a small program in assembly language, and use this small program as the execution entry point of the second stage executable image, and then use the CPU jump instruction in the assembly program to jump into the main() function to execute. When the main() function returns, the CPU execution path returns to the second stage in the assembly program, including initializing the hardware devices to be used in this stage, detecting the system memory mapping, reading the kernel image and the root file system image from the FLASH to the RAM space, and setting the startup parameters for the kernel to call the kernel.

2 Design of Boot Loader
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:
[page]

2.2 Copy the second stage 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 Setting the stack pointer
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, the stack setting is required and is set by the administrator himself. If IRQ interrupts are required, the IRQ stack setting is also required. The following is the IRQ stack setting:


3 Design of Stage2
3.1 Entry of executable image Stage2
Since the functions supported by the Glibc library cannot be used to compile and link programs written in C language such as Boot Loader, it is the most direct idea to use the starting address of the main() function as the entry point of the second stage. You can use assembly to write a small trampoline program, use the CPU jump instruction to jump to the main() function to execute, 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. [page]

3.2 Memory Mapping
The SDRAM size configured on S3C2410 is usually 64 MB, and the physical address range of the SDRAM is Ox30000000~Ox33FFFFFF (belonging to Bank 6). From the size of the Section, we can see
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 Boot Loader efficiency 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 to effectively improve the running speed of the Boot Loader. The mapping relationship code is as follows:

3.3 Loading the kernel image and the root file system image
Embedded CPUs such as ARM usually address solid-state storage devices such as FLASH in a unified memory address space. Therefore, reading data from the Flash is the same as reading data from the RAM unit. A simple loop can complete the work of copying 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 the kernel startup parameters
The kernel startup can start and run Linux from NAND FLASH (NOR FLASH). The startup command needs to be modified as follows:

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

4 Conclusion
Through the analysis of Boot Loader, it can be seen 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 the next step of system development be carried out until the development of the entire embedded system is completed. Designing 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 passed the debugging smoothly and can load the operating system normally.