Raspberry Pi 3 (BCM2837) — Bootloader & Boot Process: Community Documentation

Important Note: This document covers the Raspberry Pi 3 family using the BCM2837 SoC: Pi 3 Model B, Pi 3 Model B+, Pi 3 Model A+, and Pi 2 Model B v1.2. It does not cover BCM2835, BCM2836, or later generations (BCM2711, etc.).

1. Overview of the BCM2837 Boot Sequence

The BCM2837 SoC contains an embedded boot ROM that executes immediately on power-on or reset. This ROM is hardcoded into the silicon and cannot be modified. The boot process proceeds through multiple stages, involving both the ARM cores and the VideoCore IV GPU.

Step-by-Step Boot Flow

1. Power-On / Reset - The BCM2837 begins execution from a fixed address in the internal boot ROM (0x00000000). - The boot ROM performs initial hardware initialization (PLLs, SDRAM controller calibration).

2. Boot Mode Selection - The ROM checks boot mode selection pins (or OTP bits) to determine the boot source. - Supported boot sources are tried in a defined order (see Section 3).

3. First Stage: Loading bootcode.bin - On Pi 3 devices, the ROM reads the first FAT-formatted partition on the SD card (or equivalent boot device). - It loads bootcode.bin into the L2 cache (or SRAM on some variants). - Note: On Pi 3B+ and Pi 3A+, bootcode.bin may be replaced by OTP-enabled EEPROM boot behavior (see Section 2).

4. Second Stage: GPU Firmware (start.elf and variants) - bootcode.bin enables the SDRAM and loads the VideoCore firmware (start.elf) from the boot partition. - The GPU begins execution and configures the ARM cores' memory layout. - Additional firmware files are loaded:

   • fixup.dat — memory split configuration
   • config.txt — parsed for hardware configuration
   • cmdline.txt — kernel command line passed to the ARM core

5. Third Stage: Loading the Kernel - The GPU loads the kernel image (typically kernel8.img for 64-bit, kernel7.img for 32-bit) into SDRAM. - Device tree blobs (.dtb) or device tree overlays may also be loaded. - The GPU then releases the ARM cores from reset, passing control to the loaded kernel.

6. Kernel Handoff - The ARM core(s) begin execution at the kernel entry point. - The Linux kernel (or bare-metal payload) takes over all further control.

Source: Raspberry Pi Documentation — "Boot sequence" and "Raspberry Pi boot EEPROM" (Raspberry Pi Ltd.)

2. Boot Firmware & Storage

SD Card — The Primary Boot Medium

On the Raspberry Pi 3 family, the SD card remains the primary and most well-documented boot medium. The boot partition must be:

• FAT32 formatted (typically the first partition, flagged as bootable)
• Located in the first portion of the SD card
• Containing the required firmware files

Required Boot Files

Source: Raspberry Pi Documentation — "boot folder contents" (Raspberry Pi Ltd.)

EEPROM Boot — Pi 3B+ and Pi 3A+

The Pi 3 Model B+ and Pi 3 Model A+ introduced bootloader EEPROM support, though it functions differently than on Pi 4:

• Pi 3B+ has a bootloader stored in OTP (One-Time Programmable) memory that can load bootcode.bin from SD card, or — if boot from network/USB is OTP-enabled — from those sources.
• Pi 3A+ similarly supports EEPROM-based boot modes, but the mechanism is more constrained than on Pi 4.
• Pi 2 Model B v1.2 uses the same BCM2837 SoC as Pi 3 and behaves identically to Pi 3B for boot purposes.

Note: The Raspberry Pi 3 family does not have a user-updateable SPI flash EEPROM like Pi 4. The bootloader is burned into OTP bits during manufacturing or via the raspberrypi-utils tools.

Source: Raspberry Pi Documentation — "Raspberry Pi boot EEPROM" (Raspberry Pi Ltd.)

Firmware Variants

The start.elf has several variants controlling GPU memory split:

• start.elf — default split
• start_cd.elf — minimal GPU (for headless/compute use)
• start_x.elf — includes camera and codec support
• start_db.elf — debug variant with verbose output

Source: Raspberry Pi Documentation — "config.txt" (Raspberry Pi Ltd.)

3. Boot Modes Supported

The BCM2837 supports multiple boot modes, though availability varies by model and firmware version.

SD Card Boot

• Supported on: All Pi 3 variants (B, B+, A+, Pi 2 v1.2)
• Mechanism: Boot ROM reads the first FAT partition on the SD card
• Default behavior for all models

USB Boot

• Supported on: Pi 3B, Pi 3B+, Pi 3A+, Pi 2 v1.2
• Requirements:
• OTP bit must be set to enable USB boot (program_usb_boot_mode=1 in config.txt + reboot)
• A suitable USB device (mass storage device) must be present
• Behavior: After the OTP bit is set, the boot ROM will attempt USB mass storage before falling back to SD card
• Limitation: USB boot on Pi 3 relies on the USB 2.0 controller, which must be initialized by the GPU firmware. Early-stage USB boot is slower than SD card boot.
• Compatibility: The raspberrypi/usbboot repository provides a host-side tool (rpiboot) for provisioning. However, note that the mass-storage-gadget firmware in the usbboot repo explicitly supports Pi 3A+, not Pi 3B/3B+ (which use the legacy msd firmware).

Source: Raspberry Pi Documentation — "USB boot modes" and "Raspberry Pi boot modes" (Raspberry Pi Ltd.)
Source: GitHub — raspberrypi/usbboot README (noting compatible device list)

Network Boot (PXE)

• Supported on: Pi 3B, Pi 3B+, Pi 3A+, Pi 2 v1.2
• Requirements:
• OTP bit must be set for network boot
• DHCP server and TFTP server on the network
• Ethernet adapter (built-in on all Pi 3 models)
• Mechanism: The boot ROM broadcasts a DHCP request, receives an IP address and TFTP server details, then downloads bootcode.bin (or equivalent) over HTTP/TFTP
• Implementation: The Pi 3 uses the network boot mode which can operate over IPv4 (more common) or IPv6
• Performance: Network boot is generally slower than SD card boot but useful for diskless deployments

Source: Raspberry Pi Documentation — "Network boot your Raspberry Pi" (Raspberry Pi Ltd.)

Boot Order

The boot ROM attempts sources in a fixed priority order. The exact order on BCM2837:

1. SD card (primary, always attempted first)
2. USB (if OTP bit set)
3. Network (if OTP bit set; may be attempted in parallel or after USB failure)

The OTP bits control whether USB and network modes are even attempted. Once a valid bootable device is found, the process proceeds.

Source: Raspberry Pi Documentation — "Raspberry Pi boot modes" (Raspberry Pi Ltd.)

4. UART / Serial Console — Configuration and Quirks

The Raspberry Pi 3 has specific UART configurations that differ from earlier models due to the integration of Bluetooth.

Hardware UARTs on Pi 3

Critical change on Pi 3: The mini UART became the default for GPIO pins 14/15 (the familiar TXD/RXD pins). The PL011 is now internally routed to Bluetooth. This is a significant difference from Pi 2.

Enabling the Serial Console

1. Add to config.txt: enable_uart=1 - On Pi 3, this enables the mini UART on GPIO 14/15 - Disables Bluetooth if dtoverlay=pi3-disable-bt is also set

2. Add to cmdline.txt (kernel command line): console=serial0,115200

3. (Optional) Disable Bluetooth to free the PL011: dtoverlay=pi3-disable-bt This makes /dev/ttyAMA0 available on the GPIO pins.

Baud Rate and Timing Quirks

• The mini UART baud rate is derived from the core clock and can vary with overclocking settings, potentially causing baud rate mismatch.
• The PL011 (when available) is a more reliable full-featured UART with proper FIFO and baud rate control.
• Flow control (CTS/RTS) is not available on the GPIO header UARTs — only TX/RX (and ground) are exposed on pins.

Boot Serial Output

The firmware (bootcode.bin, start.elf) outputs early boot messages to the primary UART (the one mapped to GPIO 14/15 at boot time). This output is useful for debugging boot failures:

• Pi 3 default: mini UART outputs at 115200 baud
• Messages include: firmware version, SDRAM initialization, partition detection, kernel load progress

Known Issues

• Bluetooth interference: By default, Bluetooth uses the PL011, which shares the same pins as the GPIO UART. Without configuration, serial console on the header may not work or may output garbage if Bluetooth is active.
• Pi 3B+ UART mapping: Some community reports indicate that the UART mapping changed slightly between Pi 3B and Pi 3B+ firmware versions; always verify with vcgencmd get_config str .
• Mini UART instability: Under heavy system load or with certain config.txt settings (e.g., core_freq changes), the mini UART baud rate can drift.

Source: Raspberry Pi Documentation — "Configure UARTs" (Raspberry Pi Ltd.)
Source: Community reports — Raspberry Pi Forums

5. Bare-Metal and OS Bring-up Notes

Bare-Metal Development on BCM2837

Developing bare-metal code for the Pi 3 requires understanding the split between ARM and GPU responsibilities.

Option 1: Bypassing the GPU (ARM-only Boot)

• The Pi 3 can boot directly into ARM-only code by placing a specially crafted kernel8.img (64-bit) or kernel7.img (32-bit) in the boot partition, but the GPU still executes start.elf to initialize SDRAM.
• It is not possible to completely bypass the GPU firmware — the SDRAM initialization is only performed by the VideoCore.
• Bare-metal tutorials typically use a minimal bootcode.bin + start.elf + kernel8.img flow.

Option 2: Using Existing Frameworks

• Circle — A C++ bare-metal framework for Raspberry Pi (supports Pi 3 / BCM2837). Provides a clean API for GPIO, UART, USB, and other peripherals.
• U-Boot — The Universal Boot Loader can be compiled for Pi 3, providing a flexible second-stage bootloader. U-Boot supports network boot, SATA, USB, and can load kernels from various sources.
• Build with: make CROSS_COMPILE=aarch64-raspberrypi-linux-gnu- rpi_3_defconfig
• U-Boot can be loaded as boot.img by the Pi 3 firmware
• Bare-metal examples — The raspberrypi/firmware GitHub repository contains minimal example code.

Boot Configuration via config.txt

Key config.txt options for bare-metal development:

Source: Raspberry Pi Documentation — "config.txt" (Raspberry Pi Ltd.)

Device Tree and Overlays

• The Pi 3 uses device tree to describe hardware.
• Custom hardware can be described using device tree overlays (.dtbo files compiled from .dts).
• Overlays are loaded from /boot/overlays/ and referenced in config.txt using dtoverlay=
• The device tree blob (.dtb) is typically bcm2837-rpi-3-b.dtb or bcm2837-rpi-3-b-plus.dtb

Source: Raspberry Pi Documentation — "Device Trees, overlays, and parameters" (Raspberry Pi Ltd.)

Boot Debugging Tips

• Boot delay: Add boot_delay=1 to config.txt to give time for UART connection
• Boot log level: Not directly controllable from firmware, but Linux kernel earlyprintk can be enabled
• LED codes: The Pi 3 has a single green Activity LED (ACT). Patterns indicate boot failures (e.g., 3 flashes = bootcode.bin not found, 4 flashes = start.elf not found, 7 flashes = kernel not found)

Source: Raspberry Pi Documentation — "LED warning flash codes" (Raspberry Pi Ltd.)

6. Key Differences from Neighbouring Pi Generations