The RPi Boot Process

The RPi B was the first single board computer I owned. It had been a while since I had played with a SBC. Sure,I had done some messing around with some eval boards and SoC reference boards as part of work, but nothing quite as sophisticated and finished as an RPi.

It might seem amusing to call an RPi sophisticated, but the devices back then were so much more primitive. This was well before the era of U-boot and SD cards. Any tinkering needed an Oscilloscope and flash chip programmer, and getting a 16550 UART console session, with the correct BAUD rate, was the goal. The idea that an SBC would come with an HDMI port was laughable back then.

Well, as I was saying, the RPi boot process is sophisticated and seemingly idiot-proof.

1. On power-on, the ARM processor is still held at reset. Rather, it is the GPU which actually starts executing the boot process. It starts off by running code off the on-chip ROM. This code in the ROM is the first stage boot-loader, which initializes the SD-card, and reads the first FAT partition. It loads the file bootcode.bin from the SD card into the L2 cache. Note, the RAM isn’t up yet. This bootcode.bin is the second stage boot-loader.

2. bootcode.bin enables the SDRAM, and loads the GPU firmware into the RAM. This is typically held in a file called start.elf.

3. start.elf is the third stage boot loader. It has a lot of intelligence. It reads the system configuration parameters, usually stored in a file config.txt. It also loads the configured kernel image, usually kernel.img, into SDRAM. It also reads the kernel command-line parameters, which are usually stored in a different file, cmdline.txt. It also loads the device-tree bitmap (DTB) for the RPi board, if the DTB exists.

4. Once all of this is loaded into RAM, the ARM processor is brought out of reset. Up until this point, the GPU has been doing all the work. From here on, the ARM takes over, and the kernel starts booting, and does what operating system kernels usually do. Drivers, interrupt handlers, network stacks, filesystems, and the like.

There are a few more boot-loader features, related to recovery etc., but I’ll not delve into those.

So here’s the bit that is sophisticated and idiot-proof. Everything that one needs to configure, and get the boot-loader to do exactly what they want are in text files stored on a FAT file system. I can’t describe how cool this is, having myself struggled with multiple boot-loaders on various platforms, even writing one from scratch for a MIPS processor.

The best software is one that works so reliably and seamlessly that it never calls attention to itself. A vast majority of RPi users are probably completely unaware of the above boot process.