Dec 10, 2024 · 6 min read · Embedded Systems

Raspberry Pi 5 Boot Sequence and SPI EEPROM Engineering Guide

This technical guide breaks down the multi-stage boot pipeline of the Raspberry Pi 5, analyzes structural parameters of the SPI EEPROM, and demonstrates field techniques for destructive backup verification and firmware recovery.

Prerequisites

Ensure you have the following prerequisites ready before initializing deployment:

A Raspberry Pi 5 single-board computer running clean Raspbian OS.
Sudo administrative privileges enabled on the target user profile.
An external workstation equipped with Raspberry Pi Imager and a spare SD card for bootloader recovery.

Step-by-Step Installation and Configuration

⚠️ Administrative Environment Check

Modifying low-level SPI flash blocks requires hardware interface execution privileges. Ensure your operational profile can invoke sudo commands seamlessly. For system editing tasks, you can view the active configurations via:

sudo rpi-eeprom-config

1. Understand the Multi-Stage Boot Sequence

The Raspberry Pi 5 initializes via a strict cooperative handoff between physical One-Time Programmable (OTP) parameters and localized SPI EEPROM memory blocks.

First Stage Bootloader Architecture

Upon initial System-on-Chip (SoC) power delivery, the boot sequence runs as follows:

Hardware Pin Check: The SoC reads OTP data and checks the nRPIBOOT GPIO state. Note: This pin is currently undocumented on stock Pi 5 units (found on Compute Module 5), meaning its low-state branch cannot be manually simulated.
Local File Search: If nRPIBOOT is high or undefined, the engine polls the SD card or eMMC flash for a valid recovery.bin file.
SPI Handoff vs USB Loop: Finding recovery.bin immediately flashes the SPI EEPROM. If missing, it falls back to execution of the second-stage loader directly from the SPI EEPROM. If that check fails, the SoC drops into a continuous USB Recovery Loop looking for an external source.

Second Stage Bootloader Routing

When execution passes to the secondary loader, clocks and system SDRAM are initialized before executing a conditional halt tree check:

If a HALT status is flagged while POWER_OFF_ON_HALT=1 and WAKE_ON_GPIO=0, the platform executes a hard power-off.
If WAKE_ON_GPIO=1, the board activates GPIO3 system interrupts and places the processor into an ultra-low power sleep cycle.
If no halt is triggered, the loader extracts the BOOT_ORDER parameter and loops systematically through targeted physical states (SD CARD, NETWORK, USB-MSD, NVME, or RPIBOOT) trying to load firmware.

2. Low-Level SPI Interface Verification

To safely interface with the flash hardware components, you must enable the integrated SPI communication bus using the system configuration framework:

sudo raspi-config

Navigate directly through Interface Options → SPI, enable the module, and confirm execution on boot. Next, initialize the low-level flash deployment tool:

sudo apt install flashrom -y

root@linux:~# flashrom --version
flashrom v1.2 on Linux 6.1.0-rpi7-rpi-v8 (aarch64)
flashrom is free software, copyrighted by many authors.
Checking for status of built-in SPI programmer... OK.
Target interface detected at /dev/spidev10.0

Output 1: System flashrom compiler verification showing interface mapping visibility.

3. Execute Destructive EEPROM Testing

To analyze behavior under system failures, you can back up the stable workspace image and intentionally introduce a pseudo-random memory corruptive layer directly onto the chip.

Pull a raw master clone image from the target Linux SPI bus location:

sudo flashrom -p linux_spi:dev=/dev/spidev10.0 -r backup.bin

Generate a 2MB test payload block filled entirely with unstructured kernel random streams:

dd if=/dev/urandom bs=1M count=2 of=random_data.bin

Force write the corrupt random payload into the active hardware block:

sudo flashrom -p linux_spi:dev=/dev/spidev10.0 -w random_data.bin

root@linux:~# sudo flashrom -p linux_spi:dev=/dev/spidev10.0 -w random_data.bin
Writing flash chip... Erasing old blocks... 
Writing new data payload... SUCCESS.
root@linux:~# reboot
Connecting to system bus... System halting immediately. Hardware check state: UNBOOTABLE

Output 2: Chip replacement write sequence confirming unbootable execution state on reboot.

4. Recover and Update the Bootloader via SD Card

When an unbootable state or error pattern is triggered, recovery requires deploying an isolated utility image onto external media.

Mount your external SD card onto your development workstation and open the Raspberry Pi Imager.
Click into the Operating System selection panel and route to Misc utility images.
Select Bootloader (Pi 5 family) → SD Card Boot, select your target media path, and write the structural files.
Power off the bricked Raspberry Pi 5 unit completely and slide the newly written bootloader update media into the SD slot.
Power on the board and leave the recovery loop running for a minimum of 10 seconds.

On completion, the integrated green LED on the Raspberry Pi board will transition into a rapid, continuous blinking pattern to indicate flash success. Disconnect power safely and remove the recovery card.