Embedded software engineers have heard of u-boot and bootloader, but many engineers still don’t know what they are.
Today, let’s briefly talk about the content and differences between u-boot and bootloader.
01
What is Bootloader?
Bootloader, as the name suggests, is related to booting and loading. Anyone who has used a computer knows that when Windows starts up, it first loads the BIOS, then the system kernel, and finally completes the boot process. In the context of a smartphone, the bootloader can be compared to the BIOS of a computer. It initializes hardware when the phone is powered on, bootstraps the system kernel, and continues until the system is fully operational.
The bootloader is the first piece of code executed by an embedded system after power is applied. Through this small program, hardware is initialized, memory size information is obtained, and the phone is adjusted to an appropriate state. After it completes the initialization of the CPU and related hardware, it loads the operating system image or embedded application into memory and then jumps to the space where the operating system resides, initiating the operating system’s execution.
For embedded systems, the bootloader is platform-specific. Therefore, it is almost impossible to create a universal bootloader for all embedded systems, as different processor architectures have different bootloaders. The bootloader not only depends on the CPU architecture but also on the configuration of the embedded system’s board-level devices. For two different embedded boards, even if they use the same processor, modifying the bootloader source code is usually necessary to make the bootloader program running on one board also work on another.
However, many bootloaders still share common features, and some can support multiple architecture types of embedded systems. For example, U-Boot supports PowerPC, ARM, MIPS, X86, and more architectures and is compatible with hundreds of different boards. Typically, they can automatically boot from storage media, initiate the operating system boot, and support serial and Ethernet interfaces for communication.
02
What is uBoot?
① Hardware Management
U-Boot must be capable of managing hardware at both the SoC level (internal peripherals of the SoC) and the board level (external peripherals of the SoC). U-Boot contains control logic for certain hardware components because it needs to utilize them for specific tasks. For example, to perform firmware updates, U-Boot must be able to drive in; to display a progress bar on an LCD during firmware updates, it needs to drive the LCD; to provide a user interface via a serial port, it must manage the serial interface, and to enable network functionality, it needs to drive the network card chipset.
② Image Flashing (Firmware Updates)
U-Boot should be capable of facilitating firmware update operations. Here’s an example of how SD card firmware updates work:
a. Write U-Boot to the SD card: There are two methods for writing U-Boot to the SD card. One is using flashing tools in Windows to create a bootable SD card, and the other is using the dd command in Linux. After creating the SD card, insert it into the development board, and when powered on, it should boot into the U-Boot interface.
b. Use U-Boot’s fast boot command, combined with fast boot software on the PC, to flash images including U-Boot, kernel, and roofs: In this process, firmware updates rely on U-Boot’s fast boot command to write images to the corresponding FLASH memory.
③ U-Boot’s “Lifecycle”
U-Boot’s entry point is when it automatically starts during system boot, and its sole exit point is when it initiates the kernel boot process. U-Boot can perform various other tasks (such as firmware updates), but after completing these tasks, it can return to the U-Boot command line for further execution of U-Boot commands. However, once the command to boot the kernel is executed, it cannot return to U-Boot.
④ U-Boot Must Provide a Command-Line Shell Interface
A shell is a user-operated interface. It can be a command-line shell, like Windows’ cmd or a terminal in Linux, or it can be a GUI-based shell, like various interfaces in Windows. A shell is an interface that is wrapped around the underlying system, and U-Boot must provide such an interface. The principle behind a shell involves a continuous loop of message reception, parsing, and execution. I’ve encountered this model in firmware for 3D printers as well. U-Boot’s shell uses a line-buffered mode, where the Enter key (or newline character) signifies the end of a command input. Other buffering modes include unbuffered (each character is treated as a separate command) and fully buffered (input is buffered until the buffer is full, and then processing occurs).
03
Differences Between Bootloader and U-Boot
Bootloader is a program in embedded devices responsible for booting the operating system kernel.
U-Boot (Universal Bootloader) is a type of bootloader program that can be used with various embedded CPUs. In other words, U-Boot is a subset of bootloaders.
The primary function of U-Boot is to initiate the booting process of the operating system kernel. Essentially, U-Boot is a piece of bare-metal software code.
Recommended Reading:
- What is the Firmware of the Hard Drive?
- Debian Point Releases: What’s New in Both Versions?
- Dual Boot Ubuntu and Windows: Boost Your Productivity
- Upgrade to Rufus 4.4: Faster USB Booting with GRUB 2.12
- DIY: From Start to Quit – No Choice in Boot Modes
- Install Win11 on Old PCs – No TPM 2.0 Needed!
Disclaimer: YUNZE maintains a neutral stance on all original and reposted articles, and the views expressed therein. The articles shared are solely intended for reader learning and exchange. Copyright for articles, images, and other content remains with the original authors. If there is any infringement, please contact us for removal.
