Compute Module 5 (BCM2712) — Bootloader & Boot Process: Community Documentation

Target Hardware: Compute Module 5 (CM5) — BCM2712 SoC
Scope: Bootloader architecture, firmware storage, boot modes, serial console, and bare-metal bring-up
Audience: Embedded developers, system integrators, and hobbyists working with CM5 hardware

Note: This document synthesizes community-contributed information from forums, GitHub discussions, and experimental documentation. Where details are unconfirmed or derived from inference, they are marked as community-sourced or unverified. Official Raspberry Pi documentation should be consulted for definitive specifications.

1. Overview of the BCM2712 Boot Sequence

The boot process on BCM2712 (Raspberry Pi 5 and Compute Module 5) differs substantially from earlier generations. Unlike the Pi 4, which relied on bootcode.bin loaded from an SD card or SPI flash, the CM5 implements a multi-stage internal ROM + SPI flash bootloader with no external bootcode.bin requirement on boot media.

Step-by-Step Boot Flow

1. Power-On / Reset - The BCM2712 SoC begins execution from an on-chip boot ROM located on the VideoCore (VPU) processor. - This ROM is mask-programmed and cannot be modified.

2. SPI Flash Loader (Stage 1) - The boot ROM reads a tagged binary blob from the external SPI flash chip (mounted on the Compute Module board). - This blob contains initialization code that brings the LPDDR4 memory controller online.

3. bootmain.elf Execution (Stage 2) - After memory initialization, the blob loads bootmain.elf from SPI flash and transfers control to it. - This stage is analogous to the legacy bootcode.bin on earlier Pi models but resides in SPI flash rather than on removable media.

4. Boot Configuration Reading - bootmain.elf reads bootconf.txt stored in SPI flash. - This configuration file contains the BOOT_ORDER parameter, which defines the boot device priority (e.g., SD → USB → network).

5. Boot Device Selection & Kernel Load - Based on BOOT_ORDER, the bootloader attempts to boot from the selected media (SD card, USB, or network). - The bootloader reads config.txt and the kernel image from the boot media. - Control is handed to the kernel (or bare-metal application) at the configured load address.

Source: "Pi5 Boot Process" — Raspberry Pi Forums (cleverca22, Jul 2024)

2. Boot Firmware & Storage

SPI Flash Organization

The Compute Module 5 includes an SPI flash chip (typically 512KB to 2MB, board-dependent) that stores the bootloader components:

Firmware Equivalents — No External ELF/DAT Files

Unlike earlier Raspberry Pi models:

• CM5 does NOT require bootcode.bin — this file is not used and cannot be executed by the VPU.
• CM5 does NOT require start.elf or fixup.dat — these were used on Pi 0–3.
• CM5 does NOT require start4.elf or fixup4.dat — these were used on Pi 4.
• The functionality previously provided by these files is now stored in SPI flash and loaded by bootmain.elf.

"start.elf and fixup.dat are only valid on the pi0-pi3. start4.elf and fixup4.dat are only valid on the pi4 family. and pi5 just doesnt need any elf or dat, its all in SPI flash." — procount, "Pi5 Boot Process" — Raspberry Pi Forums

Boot Media File Requirements

For bootable SD cards or USB drives, the following minimal file set is required:

• config.txt — Boot configuration (kernel name, device tree, memory settings)
• Kernel image — Typically kernel8.img (64-bit bare-metal or Linux kernel)
• Device Tree Blob (optional in some bare-metal scenarios) — bcm2712-rpi-5-b.dtb

Community observation: "It's true that only bcm2712-rpi-5-b.dtb and config.txt are needed on the SD card." — satyria, "Pi5 Boot Process" — Raspberry Pi Forums

3. Boot Modes Supported

The BCM2712 bootloader supports multiple boot modes, configurable via the BOOT_ORDER setting in SPI flash (bootconf.txt).

BOOT_ORDER Configuration

The BOOT_ORDER parameter in bootconf.txt specifies a sequence of boot attempts. A typical order for general-purpose use is:

BOOT_ORDER=0xf46148d

Which typically translates to: SD → USB → Network → SPI flash (in order of priority).

Network Boot

Community discussion confirms that network boot (PXE) is functional on Pi 5 / CM5:

"PS: btw, I'm booting over the network - easier workflow for me!" — pottendo, Circle GitHub Discussion #413

Network boot requires:

• A DHCP server on the network
• A TFTP server serving config.txt, kernel image, and device tree blob
• Ethernet connectivity on the CM5 (via on-board PHY or USB Ethernet adapter, depending on CM5 variant)

4. UART / Serial Console — Configuration and Quirks

Default Serial Output: ttyS11

On the Compute Module 5 (BCM2712), the default serial console is on the dedicated UART connector (ttyS11), not the legacy GPIO pins 14/15 (ttyS1). This is a departure from earlier Pi models.

"On the RPi 5 the serial console is by default the dedicated UART connector ('ttyS11')." — rsta2, Circle GitHub Discussion #413

Using Legacy GPIO UART (ttyS1)

To redirect the serial console to GPIO pins 14/15 (the traditional UART pins), the following configuration is required:

For bare-metal Circle framework:

DEFINE += -DSERIAL_DEVICE_DEFAULT=0

Source: Circle GitHub Discussion #413 (rsta2, Feb 2024)

Bare-Metal Serial Configuration Notes

For bare-metal development:

• The default console on GPIO 14/15 is ttyS1 (baud rate 115200, 8N1).
• If using the dedicated mini-UART connector on the CM5 IO board, it appears as ttyS11.
• Ensure your config.txt specifies the correct kernel_address to avoid loading issues.

UART Availability on Compute Module 5

The CM5 has two UARTs available:

• Mini UART (ttyS1) — mapped to GPIO 14/15; requires configuration
• PL011 UART (ttyS11) — dedicated UART connector on CM5 IO board; default console

5. Bare-Metal and OS Bring-Up Notes

Minimal config.txt for Bare-Metal

The following is the minimum viable config.txt for bare-metal bring-up on CM5:

kernel_address=0x80000
kernel=kernel_2712.img
os_check=0

• kernel_address=0x80000: Loads the kernel at the standard ARM64 load address. Without this, the firmware may load the image at 0x200000 and attempt Linux-specific behavior.
• os_check=0: Disables OS validation checks. Without this, the firmware assumes a Linux kernel and may load at the wrong address or attempt to load a device tree automatically.
• kernel=kernel_2712.img: Specifies the kernel filename (default is kernel8.img).

"Actually you only need config.txt to boot a Pi 5, in addition to your kernel / bare metal application which should be named kernel8.img by default, but you'll have to add os_check=0 to config.txt, as otherwise it assumes that you're booting Linux, so it will run your code from 0x200000 instead of 0x80000, and will try loading the device tree blob." — Fridux, "Pi5 Boot Process" — Raspberry Pi Forums

Device Tree Blob (DTB)

For bare-metal use, the device tree blob (bcm2712-rpi-5-b.dtb) may or may not be required:

• If using os_check=0, the bootloader does not mandate DTB loading.
• For full hardware initialization (e.g., to access board-specific peripherals), the DTB is recommended.
• Community testing shows bare-metal images can boot with only config.txt and the kernel image.

Bare-Metal Framework Support

Circle (a popular bare-metal C++ framework for Raspberry Pi) supports CM5 on the rpi5 branch:

• Requires kernel_address=0x80000 in config.txt
• For headless operation, add DEFINE += -DSCREEN_HEADLESS in Config.mk
• Network boot is confirmed working with Circle on CM5

"Serial works also again - on pins 14/15. I managed to merge this into circle-stdlib and even my app starts doing something..." — pottendo, Circle GitHub Discussion #413

Known Bare-Metal Quirks

• HDMI/Display output: Many configuration options available on earlier Pis are not honored by the CM5 firmware. The Linux kernel now handles display output; bare-metal frameworks relying on firmware-provided graphics may have limited display compatibility.
• USB/Ethernet: Some bare-metal frameworks (including Circle) require code adoption for CM5's USB and Ethernet drivers (#if RASPPI <= 4 guards may need removal).
• Dynamic frequency scaling: The CM5 may change ARM core frequency dynamically; bare-metal code should account for variable clock speeds or disable DVFS if timing-critical.

6. Key Differences from Neighbouring Pi Generations

Summary of Key Changes

1. No external bootloader files on boot media — All firmware resides in SPI flash; no bootcode.bin or start*.elf needed.
2. SPI flash is mandatory — Even for SD boot, the primary firmware chain runs from SPI flash first.
3. Default kernel address changed — Without kernel_address=0x80000, bare-metal images may be loaded incorrectly.
4. Serial console moved — Default is now ttyS11, not the legacy GPIO UART.
5. Network boot functional — Unlike early Pi 4 revisions, network boot works reliably on CM5.

7. Open Questions / Areas Without Official Documentation

The following topics remain unconfirmed or poorly documented in official Raspberry Pi materials. Community experimentation has provided partial answers, but definitive specifications are not available.

Recommendations for Developers

• Experiment cautiously: Many bootloader behaviors are discovered through community trial-and-error.
• Use official Raspberry Pi imager for flashing CM5 bootloader EEPROM updates when available.
• Monitor the Raspberry Pi forums for new discoveries; the community is the primary source of CM5 bootloader insight.
• Reference Pi 5 documentation — While not identical, Pi 5 (standard form factor) shares the same BCM2712 SoC and bootloader architecture; many findings apply to CM5.

Appendix: Minimal config.txt Example for Bare-Metal CM5

# Minimal config.txt for bare-metal on Compute Module 5 (BCM2712)
kernel_address=0x80000
kernel=kernel_2712.img
os_check=0
# Optional: specify device tree explicitly
# device_tree=bcm2712-rpi-5-b.dtb

This document is community-maintained. Last updated: based on source material collected November 2025.