Raspberry Pi 400 (BCM2711) — Bootloader & Boot Process: Community Documentation

Document Type: Community Technical Report
Target Hardware: Raspberry Pi 400 (BCM2711)
Last Updated: 2025

1. Overview of the BCM2711 Boot Sequence

The Raspberry Pi 400 shares the same BCM2711 system-on-chip (SoC) as the Raspberry Pi 4 Model B, and therefore inherits an identical boot architecture built around a mutable bootloader EEPROM. The boot sequence proceeds from silicon reset through firmware execution to operating system handoff.

Step-by-Step Boot Flow

1. Silicon Reset & ROM Boot (First-Stage) - On power-on, the BCM2711 ARM cores begin execution from an internal Read-Only Memory (ROM) embedded in the SoC silicon. - This ROM contains the primary bootloader — a fixed-purpose firmware blob that cannot be modified. It is responsible for initial hardware initialization (clock, DDR memory training) and for loading the next-stage bootloader from external non-volatile storage. - The ROM bootloader does not support USB or network boot directly; it operates solely from attached SPI flash (EEPROM) or SD card.

2. EEPROM Bootloader Execution (Second-Stage) - The ROM bootloader reads the SPI EEPROM mounted on the board (adjacent to the SoC). If a valid bootloader image is present, it copies it into SRAM and transfers control. - This second-stage bootloader resides in the on-board EEPROM and is field-updatable. It implements the configurable boot order, boot mode selection, and firmware loading logic. - On Raspberry Pi 400, the EEPROM is a 512-Kbit (64 KB) serial flash device (Winbond W25X40CL or equivalent), pre-programmed at the factory with the default Raspberry Pi bootloader. - Source: BCM2711 Boot EEPROM - Official Docs

3. Firmware Loading (Third-Stage) - Once the EEPROM bootloader completes initial setup, it reads the start.elf (or start4.elf for BCM2711) firmware file from the boot partition. - The firmware file is not an operating system kernel — it is a GPU firmware blob that runs on the VideoCore VI GPU. It configures the ARM cores, sets up memory, and prepares the GPU to load the Linux kernel. - The firmware also loads fixup.dat (or fixup4.dat) — a companion file that resolves symbol addresses between the GPU and ARM memory spaces.

4. Device Tree & Kernel Command Line - The firmware reads config.txt to obtain platform configuration (device tree overlays, memory split, boot options). - It then loads the Linux kernel (typically kernel8.img for 64-bit ARM) and the associated Device Tree Blob (*.dtb). - The kernel command line is assembled from cmdline.txt and any built-in defaults.

5. Kernel Handoff - Control transfers to the ARM kernel entry point. From this moment, the boot process follows standard Linux ARM64 boot protocols. - The GPU firmware remains active in the background, handling display output and certain hardware acceleration tasks, but no longer controls boot flow.

Summary Table

2. Boot Firmware & Storage

EEPROM (On-Board SPI Flash)

The Raspberry Pi 400 incorporates a soldered SPI EEPROM chip that holds the primary mutable bootloader. This is a key architectural difference from earlier Raspberry Pi models (BCM2835/BCM2837) that relied entirely on boot files on the SD card.

• Capacity: 512 Kbit (64 KB) serial flash
• Location: On the main PCB, adjacent to the SoC
• Contents: The bootloader binary image, including boot order table, default configuration, and recovery image
• Update mechanism: Can be updated via the rpi-eeprom-update tool under Raspberry Pi OS, or by writing an EEPROM recovery image to an SD card

Source: rpi-eeprom - GitHub

The EEPROM holds two bootloader images:

• Production image: The actively-used bootloader
• Recovery image: A fallback image used during EEPROM updates or when the production image is corrupted

Boot Firmware Files (SD Card / USB)

Once the EEPROM bootloader executes, it searches the boot partition (on SD card or USB mass storage) for:

• start4.elf — The main VideoCore VI firmware blob for BCM2711. This is specific to the Pi 4/Pi 400 generation and differs from the start.elf used on earlier BCM283x devices.
• fixup4.dat — The linker fixup file for the VideoCore firmware.
• config.txt — Configuration file read by the firmware (not by the EEPROM bootloader directly).
• bootcode.bin — Not required on BCM2711. This file was used on earlier models; the Pi 4/400 perform all pre-firmware loading via the EEPROM.

Updating Firmware

Firmware updates are delivered through the rpi-eeprom package in Raspberry Pi OS:

sudo apt update
sudo apt install rpi-eeprom
sudo rpi-eeprom-update
sudo reboot

The update process writes a new bootloader image to the SPI EEPROM. The Raspberry Pi 400 uses the same EEPROM layout and update mechanism as the Raspberry Pi 4 Model B.

Source: rpi-eeprom - GitHub

3. Boot Modes Supported

The BCM2711 bootloader in the EEPROM supports multiple boot modes, configurable via the BOOT_ORDER field in the EEPROM configuration. The default boot order on Raspberry Pi 400 prioritizes SD card, then USB.

Supported Boot Modes

Boot Order Configuration

The BOOT_ORDER EEPROM parameter defines a prioritized sequence of boot attempts. The default value is 0xf461 (SD → USB → Network), meaning:

• Try SD card first
• Fall back to USB mass storage
• Fall back to network boot

Users can modify the boot order using the rpi-eeprom-config tool or by editing /boot/firmware/config.txt with the BOOT_ORDER directive (on EEPROM versions that support it).

USB Boot Requirements

Booting from USB on the Raspberry Pi 400 requires:

• USB mass storage device with a valid boot partition (FAT32 or ext4)
• Firmware files (start4.elf, fixup4.dat, kernel8.img, boot.scr, config.txt, cmdline.txt) on the USB device
• EEPROM bootloader configured to attempt USB boot (default enables this)
• For USB 3.0 devices, ensure the device provides sufficient power or use a powered hub

Network Boot (PXE)

Network boot is supported but requires:

• A DHCP server on the local network to provide IP address and TFTP server details
• A TFTP server hosting the boot files (start4.elf, fixup4.dat, kernel8.img, *.dtb, config.txt, cmdline.txt)
• Ethernet connectivity — the Pi 400 has a built-in Gigabit Ethernet port (via the USB hub chip)

The bootloader broadcasts a DHCP request; upon receipt of a DHCP offer containing the tftp-server option, it downloads the boot files via TFTP.

Source: BCM2711 Boot EEPROM - Official Docs

4. UART / Serial Console

The Raspberry Pi 400 provides access to a serial console via the 40-pin GPIO header (pins 8, 10, and 14/Ground). However, there are hardware and configuration quirks specific to the Pi 400 that users should be aware of.

Pinout

• Baud rate: Default 115200 baud, 8N1
• Voltage level: 3.3V TTL (not RS-232). Do not connect directly to a PC's DB-9 RS-232 port without a level shifter.

Enabling Serial Console

The serial console is controlled via two mechanisms:

1. config.txt — Add or modify the following: enable_uart=1 dtoverlay=disable-bt # Optional: disables Bluetooth to free up UART0
2. cmdline.txt — Must contain the console directive: console=serial0,115200 console=tty1 root=/dev/mmcblk0p2 fsckfix=true

With these settings, the Linux kernel logs boot messages to the serial port and presents a login shell on /dev/serial0 (which maps to UART0).

Quirk: UART on Raspberry Pi 400

On the Raspberry Pi 400, the primary UART (UART0) is routed to the Bluetooth module by default, not to the GPIO header. This is a key difference from the Raspberry Pi 4 Model B.

• To use the GPIO header for serial console, Bluetooth must be disabled using dtoverlay=disable-bt in config.txt.
• When Bluetooth is disabled, UART0 is remapped to GPIO pins 14 and 15.
• Alternatively, the mini UART (UART1) can be used on GPIO 14/15, but it has limited baud rate accuracy and lacks flow control — not recommended for reliable serial console.

Serial Console via USB-C (Console Cable)

The Raspberry Pi 400 has a USB-C power port. Some community reports (not officially documented) suggest that certain USB-C debug cables may present a serial adapter, but this is not a standard feature. The canonical method for serial console remains the GPIO header.

Bootloader Serial Output

The EEPROM bootloader itself does not output debug messages to the serial port by default. Serial console output begins after the Linux kernel takes control. To observe the earlier boot phases (EEPROM → firmware),JTAG debugging would be required, which is not documented for community use.

5. Bare-Metal and Custom Firmware Bring-Up

The Raspberry Pi 400, with its BCM2711 SoC, is a popular platform for bare-metal development. However, there are specific considerations for writing custom firmware or bootloaders without relying on the VideoCore firmware stack.

Using Custom Firmware Without start.elf

It is possible to bypass the VideoCore firmware entirely and boot custom code directly on the ARM cores. This is commonly done in bare-metal tutorials and in projects such as U-Boot, Circle, and bare-metal ARM64 code.

Requirements for Bare-Metal Boot

1. Custom boot stub or bootloader: Must be stored in a location the EEPROM bootloader can find. The supported locations are: - A file named kernel8.img on the SD card/USB boot partition - The file must be a valid ARM64 ELF or raw binary, loaded at the address specified in config.txt (default: 0x100000)

2. config.txt directives for bare-metal: kernel_address=0x100000 arm_64bit=1 enable_uart=1 - Setting kernel8.img as the boot target bypasses the VideoCore firmware loading entirely. - However, the VideoCore is still powered on and manages certain hardware (e.g., clocks, power management). Some peripherals (e.g., USB, Ethernet) may require interaction with the VideoCore or the secondary firmware start4.elf.

3. Disabling the VideoCore: It is possible to power down the VideoCore to reduce power consumption in pure bare-metal applications, but this disables hardware that depends on it (USB controller, network adapter, hardware video codecs).

U-Boot on Raspberry Pi 400

U-Boot (Das U-Boot) supports the BCM2711 and can be used as a second-stage bootloader to load operating systems from network, USB, or SD card. The typical workflow:

1. Flash a recent U-Boot binary (u-boot.bin or u-boot.elf) to the boot partition as kernel8.img.
2. Configure config.txt to point to the U-Boot image.
3. U-Boot then loads the target OS (Linux, bare-metal application) from storage or network.

Community documentation for U-Boot on Pi 4/Pi 400 is extensive; the Raspberry Pi GitHub organization maintains a fork of U-Boot with Pi 4/400 support.

Circle — A C++ Bare-Metal Framework

Circle is a C++ bare-metal framework for Raspberry Pi (including BCM2711). It provides a lightweight alternative to the VideoCore firmware stack, handling ARM core initialization, memory management, and basic peripheral access without relying on start.elf.

• Circle runs entirely on the ARM cores.
• It does not require the VideoCore, making it suitable for low-power or educational bare-metal projects.
• Supported peripherals include USB host, Ethernet, SD card, and GPIO.

Custom Firmware via USB Boot

For custom firmware deployment, the USB boot mode can be used:

1. Configure the Pi 400 to boot from USB in the EEPROM (BOOT_ORDER set to prioritize USB).
2. Place the custom firmware binary as kernel8.img on a USB mass storage device.
3. On power-on, the EEPROM bootloader reads the USB device and loads the custom firmware.

This approach is commonly used in embedded development workflows where firmware is tested on removable media.

JTAG Debugging

The BCM2711 supports ARM CoreSight JTAG debugging. However, the Raspberry Pi 400 does not expose a standard JTAG header on the board. Users interested in JTAG debugging must solder a connection to the SoC's JTAG pins — a non-trivial modification not covered in official documentation.

Source: BCM2711 Boot EEPROM - Official Docs; community bare-metal forums

6. Key Differences from Neighbouring Pi Generations

The Raspberry Pi 400 uses the BCM2711 SoC, placing it between the Raspberry Pi 4 Model B (identical SoC) and the Raspberry Pi 5 (BCM2712). Below are the key boot-related differences compared to other models.

vs. Raspberry Pi 4 Model B

• No functional differences. The Pi 400 and Pi 4 Model B share the identical BCM2711 SoC and boot architecture. The only difference is form factor and integrated keyboard.
• Both support the same EEPROM bootloader, boot modes, and firmware files.

vs. Raspberry Pi 3B+ / 3B (BCM2837B0)

• The Pi 3B+ does not have on-board EEPROM for the bootloader; it relies entirely on bootcode.bin on the SD card as the second-stage bootloader.
• The Pi 400's EEPROM bootloader allows boot order configuration without modifying the SD card.

vs. Raspberry Pi 5 (BCM2712)

-