Revision as of 06:45, 21 June 2014 by Craig Peacock (Talk | contribs)

Understanding the Raspberry Pi Boot Process

To reduce cost, the Raspberry Pi (Model A & B) omits any on-board non-volatile memory used to store the boot loaders, Linux kernels & file systems as seen in more traditional embedded systems. Rather, a SD card slot is provided for this purpose. (The Raspberry PI Compute Module has 4Gbyte eMMC Flash on-board)

The Raspberry Pi’s Broadcom BCM2835 system on a chip (SoC) powers up with its ARM1176JZF-S 700 MHz processor held in reset. The VideoCore IV GPU core is responsible for booting the system. It loads the first stage bootloader from a ROM embedded within the SoC. The first stage bootloader is designed to load the second stage bootloader (bootcode.bin) from a FAT32 or FAT16 filesystem on the SD Card.

The second stage bootloader is executed on the VideoCore GPU and loads the third stage bootloader start.elf. (Historically, yet another bootloader called loader.bin was loaded at this stage, but has since been phased out)

The third stage bootloader, start.elf is where all the action happens. It starts by reading config.txt, a text file containing configuration parameters for both the VideoCore (Video/HDMI modes, memory, frame buffers etc) and loading of the Linux kernel (load addresses, device tree, uart/console baud rates etc).

Details of parameters contained within this file can be found at

(Prior to the introduction of the 512MB Raspberry Pi, multiple start.elf files were provided (arm128_start.elf, arm192_start.elf, arm224_start.elf & arm240_start.elf). These files would partition the memory used between the ARM processor (Linux) and the VideoCore GPU. This has now been superseded with a gpu_mem parameter in the config.txt file specifying the memory to be allocated to the GPU.)

Once the config.txt file has been loaded and parsed, the third stage bootloader will also load cmdline.txt and kernel.img. cmdline.txt is a file containing the kernel command line parameters to be passed to the kernel at boot. It will load kernel.img into the shared memory allocated to the ARM processor, and release the ARM processor from reset. Your kernel should now start booting.