Bootloaders for Embedded Linux Systems
The Linux Foundation sponsored this post.
Embedded Linux systems almost always include a bootloader. Technically it’s not a part of Linux, but bootloaders are an essential part of the embedded Linux experience.
While it is technically possible to make an embedded system start running the Linux kernel right out of reset, this is generally not done. Embedded systems generally separate out the responsibility for performing initial start-up code and Power On Self Test (POST) from the operating system and into a separate bootloader.
When embedded systems are powered on, the CPU runs the initial code — which is a bootloader. The bootloader will initialize necessary hardware, then find the next program to run, load that program into memory, and jump into that program, executing it. At this point, the bootloader code will not be run again, so it is discarded from memory.
That next program to run can be anything. It is not uncommon to have bootloaders load a next bootloader, which loads yet another bootloader. Eventually, for the system to be useful, it finally loads the operating system code — which in this case is the Linux kernel. A simple system will run the bootloader after CPU reset, and then load and run the operating system.
Having a separate bootloader, rather than just running the kernel straight away, provides flexibility; now the kernel can reside in various locations, to be found and loaded by the bootloader. This makes it so the same bootloader can be used from early development to production of the embedded system, just by storing different configurations in the bootloader. For example, in early development, the embedded platform can boot entirely from the network; while in later development it may boot from an SD card and production systems can boot from NAND flash.
Parameters can also be passed to the kernel, based on the hardware configuration, and we can now have the same kernel binary run on different embedded hardware systems based on the same platform.
U-Boot
The most common bootloader for embedded Linux systems is U-Boot. U-Boot is officially named Das U-Boot, but everyone just calls it U-Boot. It has support for many CPU architectures — including 68k, ARM, MicroBlaze, MIPS, Nios, SuperH, PPC, RISC-V, x86, and more. It also contains code to support many existing embedded development boards.
U-Boot is an open-source bootloader. For your custom embedded systems, the U-Boot code can be modified to support your specific hardware.
U-Boot also has a lot of drivers, which means it can find the kernel from many different locations. U-Boot has drivers for FTP, NAND flash, MMC, i2c, and more. It also contains filesystem drivers for FAT, ext2/3/4, Cramfs, Squashfs, JFFS2, UBIF, ZFS, btrfs, and more. This means that the kernel binary can reside in one of many locations — including inside one of these filesystems on media somewhere — and U-Boot will find it.
U-Boot’s boot configuration is stored in the form of environment variables. U-Boot usually stores these environment variables in flash memory, where their values can persist across reboots. When U-Boot runs, it looks for the environment variable named ‘bootcmd’. U-Boot then expands this variable and runs whatever commands are in it.
U-Boot contains a command line with a Unix-like syntax. In this command line environment, you can modify the environment variables and store the new values in flash — to be used on subsequent boots.
In practice, you can use U-Boot in early development; for example, configured to boot the kernel over TFTP using NFS for the root filesystem. Then as you get closer to release, you can change it to boot from an SD card over MMC using ext4. And as you get even closer to production, you can change U-Boot to boot from NAND flash inside the board using UBIFS.
Another important feature in U-Boot is the support for device trees. Device trees are a newer way to describe hardware to the kernel. Embedded systems rarely have run-time discoverable hardware. The kernel can’t just query the hardware to find out what is available. The kernel has to be told what devices are present. Rather than hardware information being hardcoded, the kernel can read the device tree which describes the hardware and load appropriate drivers. This allows the same kernel binary to run on different boards based on the same architecture.
As you can see with the large support for devices and filesystems, coupled with its flexibility, U-Boot is an easy choice to use for embedded systems. To get more information on U-Boot, you can go to the project’s website: https://www.denx.de/wiki/U-Boot
Other Bootloaders
While U-Boot is pretty common, other bootloaders are possible for embedded systems. While it is too much information to cover all possible ones, I will mention a couple of other common open source bootloaders.
Barebox is a derivative of U-Boot. It has a lot of the same flexibility as U-Boot but strives to be more Linux-like. It uses a driver architecture similar to the Linux kernel and includes the use of an internal filesystem including device nodes in /dev.
RedBoot is a bootloader from Red Hat. It uses eCos RTOS technology internally and provides support for debugging applications over a serial cable or ethernet.
These are some of the more common options for bootloaders on embedded Linux systems. While they’re technically part of Linux itself, it’s not uncommon to have to build and configure the bootloader. This should give at least an introduction to the world of embedded bootloaders.
Feature image via Pixabay.