When the Raspberry Pi was launched in February of 2012, it was intended as an inexpensive, small computer for educational purposes. For less than $40, you could take this tiny computer home and deep dive into IT from the roots up. Soon, many projects were using it for all sorts of interesting tasks. Pi models 1, 2, and 3 supported hardware-accelerated processing if you bought a license key; thus, the Pi was often deployed as a fast media server.

There are now countless use cases for the small ARM computer. Today's hardware resources are magnitudes greater than those of the initial models, but one thing has not changed over the years: the initial phases of the boot process. Broadly speaking, the Raspberry Pi boots up in a similar way to a standard PC. After powering on, the motherboard's firmware steps in. It can be controlled to a limited extent via BIOS or UEFI settings. The firmware then hands over control to the bootloader, which in a Linux environment is usually the successor to the Grand Unified Bootloader (GRUB), GRUB 2. Based on either user input or its own configuration, the bootloader finds the operating system kernel and other essential elements such as the initial RAM disk (initrd) or the kernel configuration. After that, control is handed over to the operating system.

With the Raspberry Pi, the process is similar, but somehow different. By default you cannot view or modify the single-board computer's firmware, although some firmware versions can be found in the Raspberry Pi project's GitHub repository [1]. A few newer models let you reprogram the EEPROM [2]; I will return to this subject later. What is effectively the hard-coded firmware loads the bootloader. In the Raspberry Pi world, this is the Universal Bootloader (U-Boot) [3]. Its origins date back a good 20 years and lie outside the ARM world (see box "The PowerPC as a Role Model").

[...]