Raspberry Pi 5 Boot Sequence

I. Architecture Layout of Raspberry Pi 5

On the Raspberry Pi 5 PCB, you will find two core chips: the primary processor, BCM2712 (SoC), and the custom-designed RP1 southbridge:

• BCM2712 SoC (Primary Controller)

  Manufactured using a 16nm process, it features a 2.4GHz quad-core ARM Cortex-A76 and a VideoCore VII GPU. It focuses on high-performance computing, graphics, and high-demand interfaces like LPDDR4X memory and PCIe. It no longer directly handles GPIO or low-speed I/O.

• RP1 (I/O Controller)

  A 40nm chip developed by the Raspberry Pi team over several years at a cost of $15 million. It is dedicated to handling "slow" and diverse peripherals, including USB 3.0, Ethernet, GPIO, and MIPI (Camera/Display).

• Link: PCIe 2.0 x4

  The SoC and RP1 communicate via a dedicated PCIe 2.0 x4 link rather than a traditional bus. This provides up to 20Gbps of bandwidth, allowing USB 3.0 to run at full speed without impacting Ethernet or GPIO performance.

---

II. Boot Sequence

1. BL1 - Primary Bootloader (PBL): SoC Internal Boot ROM

When powered on, the hardware logic inside the BCM2712 SoC awakens first. The VideoCore VII GPU starts up, but at this stage, the ARM CPU remains in a "sleep" (Reset) state. The SoC's internal Boot ROM first checks the root directory of the SD card for recovery.bin. If not found, it proceeds to read pieeprom.bin from the SPI Flash. The pieeprom.bin is loaded into the VideoCore (VPU) internal SRAM. All early hardware initialization is performed by the GPU/VPU.

File Name	Physical Storage	Loading Timing	Embedded Engineering Role
pieeprom.bin	SPI Flash (On-board)	Secondary Bootloader (SBL) stage following PBL execution.	Hardware Init Core
recovery.bin	microSD Card (FAT root)	Emergency Mode. Loaded when SPI corruption is detected or specific pins are triggered.	EEPROM Flasher (Rescue)

2. BL2 - Secondary Program Loader (SPL): EEPROM Bootloader

This core stage is governed by pieeprom.bin, where hardware initialization and file reading occur interleaved:

• Read autoboot.txt (Highest Priority): If find autoboot.txt, it determines the boot partition. If a different partition is specified, the bootloader switches immediately.

• Initialize SDRAM (Core Action): Initializes LPDDR4X memory. This is the most critical action in the process; once complete, the system has the space to load subsequent large firmware files.

• Parse config.txt: Confirms hardware parameters such as overclocking, voltage, and PCIe settings.

• Start RP1: Initializes the PCIe Domain 0002 link and injects the rp1.bin firmware into the RP1. Following this, USB and Ethernet hardware gain basic communication capabilities.

3. BL3 - Tertiary Bootloader (TPL): VideoCore VII GPU

In this stage, the GPU executes start_8.elf accompanied by the dynamic configuration file fixup_8.dat. 

"Note: start_8.elf and fixup_8.dat must have matching versions (paired), otherwise address mapping will fail, resulting in the system hanging at the rainbow screen."

1. Memory Layout & Dynamic Patching (with fixup_8.dat)

This is the primary task of start_8.elf. Since the chip itself does not know if the board has 4GB, 8GB, or 16GB of RAM, it must adjust based on the fixup_8.dat lookup table:

• Memory Splitting: Based on the gpu_mem setting in config.txt, the LPDDR4X is divided into a GPU-dedicated zone and a CPU-available zone.

• Address Mapping Correction: Corrects the physical address offsets for registers and memory buffers to ensure no address conflicts occur between the GPU and ARM CPU.

2. Environment Encapsulation: Preparing the Device Tree

This is the most vital task for bridging to the Linux Kernel. The Kernel relies on this "map" to recognize the hardware:

• Hardware Info Insertion: Writes detected low-level info (RP1 status, PCIe link speed, SoC serial number) into the Device Tree.

• Dynamic Fixups:

  • MAC Address: Calculates and writes the Ethernet MAC address based on the SoC serial number.

  • cmdline.txt Injection: Reads cmdline.txt (e.g., root=/dev/mmcblk0p2) from the boot partition and encapsulates these strings into the chosen node of the Device Tree.

• Storage & Handoff: Places the final .dtb at a specific memory address and prepares to pass this address to the ARM CPU via the x0 register.

3. Hardware Management & Control

• Power & Clock Management (DVFS): Controls dynamic voltage and frequency scaling, determining the BCM2712 clock speed based on load.

• Display & Multimedia Init: Initializes HDMI output and MIPI display interfaces; handles low-level scheduling for H.265 hardware decoding.

• Thermal Management: Monitors SoC temperature and executes throttling strategies for hardware protection.

4. Loading & Formal "Handoff" to ARM CPU

This is the final action of the TPL stage:

• Load Kernel: Moves the Linux Kernel image (kernel_2712.img or vmlinuz) to the designated SDRAM location (typically 0x00080000).

• Stop All Active DMA Transfers: DMA operates independently of the CPU. If not stopped, the background DMA might continue writing stale data to memory while the Kernel is initializing, causing severe memory corruption.

• Flush Data Cache (Clean & Invalidate): Data may still reside in the Cache during image loading or Device Tree modification. If not flushed to physical memory and invalidated, the Kernel will read stale/incorrect data.

• Disable Hardware Interrupts: Ensures the CPU is not disturbed by old timers or peripheral signals during Kernel entry, preventing jumps to obsolete bootloader interrupt vectors.

• Disable MMU (Memory Management Unit): The Kernel begins execution in "Physical Address" mode. The MMU must be disabled to prevent the CPU from attempting to parse addresses using old page tables, which would cause instruction fetch exceptions.

• Set Protocol State: Switches the CPU to EL2 (Hypervisor Mode), ensuring compliance with the ARM64 Boot Protocol (x1-x3 cleared, x0 pointing to DTB).

• Release Reset: Previously, the ARM Cortex-A76 CPU was "locked" (Reset pins or registers held active by the GPU). Once the TPL completes the "cleanup," the GPU writes to a specific register to release the ARM CPU's Reset signal. At this moment, the ARM CPU finally receives power/clock drive and begins fetching instructions from its Reset Vector.

• Software Jump: Just before handoff, the GPU stores the Linux Kernel entry address (e.g., 0x00080000) into a register (e.g., x4). It then executes br x4, forcibly jumping the CPU PC (Program Counter) directly to the first line of the Kernel code.

---

III. Deep Initialization Phase of the Linux Kernel

Once control is transferred to the ARM CPU, the Kernel executes these precision steps:

1. Kernel Self-Decompression & Environment Check (Head.S Stage)

The Linux Kernel (usually vmlinuz) executes a section of assembly code:

• Parse x0 Register: Reads the physical address from x0 to locate the Device Tree (DTB). If this map is unreadable, the Kernel will immediately hang (Panic).

• Build Page Tables: Enables the MMU to map physical addresses to virtual addresses.

• Enable Caches: Improves CPU computing efficiency.

2. Hardware Architecture Initialization (setup_arch)

The Kernel "reads" the Device Tree map and initializes hardware:

• Identify SoC: Confirms the BCM2712 and loads corresponding drivers.

• Initialize Interrupt Controller (GIC): The "heartbeat" of the system, allowing the CPU to process signals from hardware (Southbridge, timers).

• Memory Management: The Kernel takes over all SDRAM, dividing it into zones and executing allocation algorithms like the Buddy System.

3. Southbridge & Peripheral Initialization

Unique to Pi 5, the Kernel must formally "take over" the RP1 initialized by rp1.bin:

• PCIe Rescan: Loads the pcie-brcmstb driver and scans the PCIe Domain 0002 bus to re-confirm the presence of the RP1.

• Load Subsystem Drivers: Once the PCIe link is stable, drivers are loaded sequentially: USB (DWC3), Ethernet (MACB), and GPIO/PWM/I2C controllers.

4. SMP Initialization (Multi-core Startup)

• Wake Core 1, 2, 3: Core 0 uses PSCI or the Spin-table protocol to lead the other three cores to the Kernel entry.

• Interrupt Status: Formally Enabled.

• Start Load Balancing: The Kernel Scheduler begins operation.

5. Mounting the Root File System (Mounting RootFS)

• DMA Status: Fully Operational.

• Parse cmdline.txt: Checks instructions passed by the GPU and injected into the DTB (e.g., root=/dev/mmcblk0p2).

• Mount Disk: Loads Ext4 or Btrfs drivers, mounts the root partition, and switches from the temporary RAM disk (initramfs) to the actual disk partition.

6. Start the First Process: Init

Once all hardware and file systems are ready, the Kernel starts the first program in user space:

• Execute /sbin/init (systemd).

• PID 1: The system begins loading various user services.

---

IV. Evolution of File Access Capabilities by Stage

Stage	Access Mechanism (The Hard Truth)	Consequence / Limitation
EEPROM (SPL)	Hardware Offset Search	It doesn't "read" files; it performs raw block reads at specific offsets. Injecting rp1.bin is a hardwired operation. If the data isn't where the hardware expects it, the boot fails.
VideoCore (TPL)	Minimalist FAT Parser	It is a "dumb" parser, not a driver. It can only "see" kernel_2712.img and config.txt within the FAT partition. It has no concept of mounting, permissions, or symlinks.
Linux Kernel	True VFS (Virtual File System)	This is the first stage that truly "supports" filesystems. It understands complex structures, metadata, and cross-partition mounting. This is where software takes control of the hardware's raw data.

Reference

• The Boot Sequence of Embedded Systems