Embedded Linux systems almost all include a bootloader; technically speaking, it is not part of Linux, but the bootloader is a key part of embedded Linux applications.
While it is theoretically and technically possible to have an embedded system start running the Linux kernel after reset, it is generally not done. Embedded systems typically separate the responsibility for executing the initial boot code and Power On Self Test (POST) from the operating system into a separate bootloader.
When an embedded system is powered on, the CPU runs initialization code, known as the bootloader. The bootloader initializes the necessary hardware, then finds the next program to run, loads that program into memory, and jumps to that program for execution. From this point on, the bootloader code will not run anymore, so it will be removed from memory.
The next program to run can be anything. It's not uncommon for a bootloader to load the next bootloader, which then loads another bootloader. But anyway, in order to get a usable system, it ends up loading the operating system code, most often the Linux kernel. A simple system would run a bootloader after a CPU reset, then load and run the operating system.
Having a separate bootloader, rather than running the kernel directly, provides flexibility; the kernel can then be placed in different places in memory to be found and loaded by the bootloader. In this way, by storing different configurations in the bootloader, the same bootloader can be used from the early development of the embedded system to production. For example, in early development, an embedded platform can boot entirely from the network; in later development, it can boot from an SD card; and a production system can boot from NAND flash.
Various configurations of the hardware can be passed to the kernel in the form of parameters, so that different embedded hardware systems based on the same platform, that is, devices with the same architecture but different hardware configurations, can use the same kernel binary file.
Bootloaders come in all shapes and sizes. What you want in a bootloader is that they are simple, customizable, and have many example configurations for common development boards and devices. The following table shows some commonly used bootloaders:
| Name |
Main architectures supported |
| The submarine |
ARC, ARM, Blackfin, Microblaze, MIPS, Nios2, OpenRiec, PowerPC, SH |
| Barebox |
ARM, Blackfin, MIPS, Nios2, PowerPC |
| GRUB 2 |
X86, X86_64 |
| Little Kernel |
ARM |
| RedBoot |
ARM, MIPS, PowerPC, SH |
| CFE |
Broadcom MIPS |
| BAD |
MIPS |
U-Boot
The most common boot program in embedded Linux systems is U-Boot. The official name of U-Boot is Das U-Boot, but everyone just calls it U-Boot. It supports many processor (CPU) architectures - including 68k, ARM, MicroBlaze, MIPS, Nios, SuperH, PPC, RISC-V, x86, and many more. It also contains a lot of code and supports many existing embedded development boards.
U-Boot is an open source bootloader. For your custom embedded system, U-Boot's code can be modified to support your specific hardware.
U-Boot also has many drivers, which means it can find the kernel from many different places. U-Boot has FTP, NAND flash memory, MMC, i2c and other drivers. It also includes file system drivers such as FAT, ext2/3/4, Cramfs, Squashfs, JFFS2, UBIF, ZFS, btrfs, etc. This means that on different media and in different file systems, U-Boot can find the kernel binary files stored in it.
The startup configuration of U-Boot is stored in the form of environment variables. U-Boot usually stores these environment variables in flash memory, and their values can persist across reboots. When U-Boot runs, it looks for an environment variable called "bootcmd". Then, U-Boot will expand this variable and run any commands in it.
U-Boot includes a Unix-like syntax for the command line. In this command-line environment, you can modify environment variables and store the new values in flash for use on subsequent boots.
In practice, you can use U-Boot for configuration in early development. For example, configure to boot the kernel via TFTP, using NFS as the root filesystem. Then, when you're close to a software release, you can change it to boot from SD card using ext4 via MMC. When you're close to production, you can change U-Boot to use UBIFS to boot from the NAND flash inside the board.
Another important function of U-Boot is the support for device tree. The device tree is a relatively new way of describing hardware in the Linux kernel. Embedded systems rarely have runtime discoverable hardware. The kernel cannot find new hardware available through hardware queries. The kernel must be told which devices or hardware are present. Instead of hardcoding hardware information in code, the kernel can read the device tree that describes the hardware and load the appropriate drivers. This allows the same kernel binary to run on different boards based on the same architecture.
As you know, U-Boot is a general choice for embedded systems due to its extensive support for devices and file systems, coupled with its flexibility. To get more information about U-Boot, you can visit the project website: The U-Boot Documentation — Das U-Boot unknown version documentation
Other Bootloaders
While U-Boot is the most commonly used, other bootloaders are also available for embedded systems. While it would be too space to cover all possible bootloaders, several other common open source bootloaders will be introduced.
Barebox is developed based on U-Boot. It has a lot of the same flexibility as U-Boot, but strives to be more like Linux. It uses a driver architecture similar to the Linux kernel, including using an internal file system and using device nodes in /dev within the file system. URL: Barebox .
RedBoot is a bootloader for Red Hat. It uses eCos RTOS technology internally, and provides debugger, debugger uses serial port or Ethernet.
reference:
1. How to choose a bootloader
Choosing a bootloader - Mastering Embedded Linux Programming - Second Edition [Book]
2. The embedded bootloader provided