For embedded Linux systems, the process from powering on to the operating system startup requires a boot process, which is reflected in the boot program, known as the Bootloader.
Concept and Role of Bootloader
The Bootloader is the boot program for embedded systems, and it is the first program that runs after the system powers on (before the operating system runs). This program can initialize hardware devices, establish a memory mapping table, thereby creating the software and hardware environment for the system, and preparing for the final call to the Linux operating system kernel. After completing the system initialization tasks, it copies the kernel from non-volatile memory (usually Flash) to RAM, then jumps to the first instruction of the kernel to continue execution, thus starting the Linux kernel. Moreover, it is almost impossible to create a universal Bootloader for all embedded systems, as different processor architectures have different Bootloaders. The Bootloader depends not only on the CPU architecture but also on the configuration of the embedded system’s board-level devices.
Types of Bootloaders
There are now various Bootloaders, categorized in multiple ways. Let’s take a look at commonly used boot loaders:
ROLO: Boots Linux from ROM without needing BIOS, supports X86 architecture, does not support ARM and PowerPC;
Etherboot: Firmware that boots the Linux system via Ethernet, supports X86 architecture, does not support ARM and PowerPC;
U-boot: A universal boot loader that supports X86 architecture and also supports ARM and PowerPC;
RedBoot: A boot loader based on eCos, supports X86 architecture and also supports ARM and PowerPC;
It is worth noting Redboot, which can support almost all architectures, including MIPS, SH, M68K, etc. Redboot is based on eCos and is an open-source software project licensed under GPL.
Bootloader Startup Process
The implementation of the Bootloader depends on the CPU architecture; thus, most bootloaders are generally divided into two stages. The first stage is implemented using assembly language, which completes some initialization dependent on the CPU architecture and calls the second stage code; the second stage is usually implemented in C language, allowing for more complex functions, and the code will have better readability and portability.
First Stage of Bootloader
This mainly includes the following steps:
1. Basic hardware initialization: Mainly setting the CPU speed and clock frequency, masking all interrupts, and clearing instruction and data caches.
2. Preparing RAM space: Preparing RAM space means initializing the memory chip to make it usable.
3. Setting up the stack: Setting the stack pointer prepares for executing C language code; the stack setup is very flexible, as long as the sp register points to a segment of unused memory.
4. Jumping to the second stage C entry point: In ARM, this is achieved by modifying the PC register to the corresponding address.
Second Stage of Bootloader
This mainly includes the following steps:
1. Initializing the hardware devices to be used in this stage: The most important is setting the system clock and initializing the serial port.
2. Checking the system memory mapping.
3. Reading the kernel image and root filesystem from Flash into RAM: For the kernel image, it is generally copied to a memory range starting from the base address 0x30008000, about 1MB in size (embedded Linux kernels generally do not exceed 1MB), and the 32KB of memory left empty in this area is for placing some global data structures.
4. Setting boot parameters for the kernel.
5. Calling the kernel: The BootLoader calls the Linux kernel by directly jumping to the first instruction of the kernel. During the jump, the following conditions must be met: CPU register settings: R0=0; R1=machine type ID; R2=base address of the startup parameters list in RAM; CPU mode: interrupts must be disabled; CPU must be in SVC mode; Cache and MMU settings: MMU must be off; instruction Cache can be on or off; data Cache must be off.
Conclusion
The development process of embedded systems involves not only software and hardware but also requires a comprehensive consideration of upper-level applications, with cost constraints being one of the most critical factors. The hardware platform for embedded systems is usually tailored to the application, with various options for the MPU, memory, peripherals, etc., making the design of the boot loader quite complex. If we were to implement it from scratch, it would be very difficult and inefficient. The correct approach should be to find the reference program that is closest to the hardware platform from relevant examples and then modify it according to the hardware platform.
Source:
https://www.toutiao.com/i6846274110515839502/
“IT Experts Say” welcomes submissions from technical personnel. Submission email: [email protected]
IT Experts Say | About Copyright
Articles originally written by “IT Experts Say (ID: itdakashuo)” must be credited to the author, source, and WeChat public account when reproduced.For submissions, commissions, or reprints, please add WeChat: ITDKS10 (note: submission), and Miss Jasmine will contact you promptly!
Thank you for your enthusiastic support of IT Experts Say!
Related Recommendations
Recommended Articles
Is Kunpeng a big hoax? Demonstration of using free Huawei Kunpeng server to install Discuz! forum.
Unveiling the secrets of JAVA JVM (not suitable for beginners).
How to use HTTP Headers to protect your web application.
A comprehensive interpretation of PHP 8.0 version optimizations and improvements.
MXFlutter: A Flutter framework based on JS, enabling Flutter applications to be written in JS.
Billions of user records exposed; Oracle may have triggered the biggest data security breach of the year.