Detailed explanation of the bootloader execution process and ARM Linux boot process analysis

This article provides an in-depth analysis of the ARM Linux boot process. The portability of embedded Linux allows it to be implemented across a wide range of electronic devices. However, the boot process varies significantly depending on the architecture of the processor being used.

This paper takes the S3C2410 ARM processor as a case study to examine the execution flow of the bootloader and the startup sequence of ARM Linux after the system is powered on.

1. Introduction

Linux was first developed in 1991 by Linus Torvalds, a student at the University of Helsinki in Sweden. Since then, with the support of the GNU project, Linux has seen rapid growth. While it remains less popular than Microsoft's Windows on desktop PCs, its development and increasing user base are impossible to ignore. In recent years, Linux has gained significant traction in the embedded systems field, bringing new energy and opportunities for expansion.

An embedded Linux system can be divided into four main components from a software perspective: the bootloader, the Linux kernel, the root file system, and the application layer.

The bootloader is the first piece of code executed when the system powers on or resets. Its primary role is to initialize the processor and peripherals before loading the Linux kernel.

Once the Linux kernel completes its initialization, it needs to mount a root file system to continue the booting process. The root file system serves as a critical component, acting as a storage area for system files and libraries necessary for running applications.

Applications are often considered the "soul" of an embedded system, as they define the system’s functionality. Without proper application support, even the most well-designed hardware lacks real-world value.

Understanding the relationship between the bootloader and the Linux kernel is essential for effective embedded system development. While the bootloader performs various tasks such as system initialization and user interaction, its core purpose is to launch the Linux kernel. A significant portion of embedded development focuses on optimizing and porting both the bootloader and the kernel.

By gaining a clear understanding of the bootloader execution process and the Linux boot sequence, developers can streamline their workflow and accelerate the development of embedded systems. This is the main focus of this article.

2. Bootloader

(1) Concept and Role of the Bootloader

The bootloader is the initial program that runs when the system starts. It functions similarly to the BIOS on a PC. After initializing the system, it loads the Linux kernel from non-volatile memory (such as Flash or DOC) into RAM and jumps to the kernel’s entry point to start execution. Thus, the bootloader and the Linux kernel are closely connected. To fully understand the Linux boot process, one must first grasp how the bootloader operates.

(2) Bootloader Execution Process

The address where the first instruction is executed after a processor powers on or resets depends on the architecture. For an ARM processor, this address is typically 0x00000000. In many embedded systems, non-volatile memory like Flash is mapped to this address, and the bootloader is placed at the beginning of the memory. Therefore, the first program to run is the bootloader.

Flash memory is commonly used in embedded systems and comes in two types: NOR Flash and NAND Flash. NOR Flash supports in-chip execution (XIP), allowing code to run directly from Flash without copying to RAM. NAND Flash does not support XIP, so its code must be copied to RAM before execution.

Bootloaders can vary in complexity based on the required functionality. They may handle basic tasks such as initializing the system and loading the kernel, or more advanced features like setting kernel parameters and partitioning Flash. Regardless of design, all bootloaders must perform certain key operations, including:

• Initializing RAM
• Initializing the serial port
• Detecting the processor type
• Setting boot parameters
• Calling the Linux kernel

These steps ensure that the kernel can be properly loaded and executed.

3. Linux Kernel Startup Process

After the bootloader copies the Linux kernel image to RAM, it calls the function call_linux(0, machine_type, kernel_params_base), passing the detected machine type and boot parameters.

Linux kernels come in two forms: the uncompressed Image and the compressed zImage. zImage is smaller but requires decompression before execution, which makes it slower but more suitable for systems with limited storage. Most embedded systems use zImage due to space constraints.

On ARM processors, the zImage entry point is located in arch/arm/boot/compressed/head.S. This code enables the MMU and Cache, decompresses the kernel, and then transfers control to the uncompressed kernel.

(1) Linux Kernel Entry

The entry point for an uncompressed Linux kernel is in the stext section of /arch/arm/kernel/head-armv.S. If the kernel is already in RAM, the bootloader jumps directly to it. Otherwise, it must decompress the kernel first.

The kernel entry code detects the processor type, builds the page table, and then jumps to the start_kernel() function to begin kernel initialization.

(2) start_kernel Function

The start_kernel() function is the central point of kernel initialization. It handles architecture-specific setup, initializes the scheduler, clock, and interrupt handling, and sets up the console for output.

After all initializations are complete, the rest_init() function is called, which creates the first user-space process, init. This process mounts the root file system and executes the command specified by the user, such as /sbin/init.

Finally, the cpu_idle() function is called, putting the system into an idle state until user processes are launched. At this point, the Linux kernel is fully booted.

4. Conclusion

The Linux kernel is a massive project that has evolved over the years. While it is difficult to fully understand every internal process, embedded developers do not need to know everything. Instead, focusing on hardware-related modifications allows Linux to be effectively ported to new platforms. Through the analysis of the boot process, developers can identify hardware dependencies and kernel functionalities, making the porting process more efficient. The modular design of the Linux kernel further simplifies this task.