I discovered that the Raspberry Pi doesn’t boot the same way traditional PC’s do. This was interesting and I thought I’d share.

At a high level, Raspberry Pi booting is firmware-driven, not BIOS-driven like a PC. On Raspberry Pi, the GPU (VideoCore) is powered first and is the root of trust for booting. The ARM CPU is not the initial execution environment. This is a deliberate architectural choice dating back to the original Pi.

Boot sequence (simplified):

1. Power applied

• Power management IC brings up rails\
• VideoCore GPU comes up first
• ARM CPU is held in reset

2. VideoCore ROM Executes (GPU Side)

• Immutable GPU boot ROM runs
• This code:
  • Initializes minimal SDRAM
  • Reads boot configuration
  • Locates next-stage bootloader

The ARM cores are still powered down.

3. GPU Loads Firmware

• GPU reads EEPROM bootloader
• EEPROM bootloader then loads firmware from SD / USB / Network

The loaded firmware files are GPU Binaries- not ARM code!

4. GPU Configures the System

The GPU:

• Parses config.txt
• Applies device tree overlays
• Allocates memory split (GPU vs ARM)
• Initializes clocks and peripherals
• Loads the ARM kernel image into RAM

At this point, the system hardware layout is defined by the GPU, not the CPU.

5. GPU Releases the ARM CPU from Reset

Only after:

• Firmware is loaded
• Memory is mapped
• Kernel is staged

…does the GPU release the ARM core(s) and set their entry point.

This is when the CPU first executes instructions.

6. ARM CPU Starts Linux

• CPU jumps directly into:
  • kernel7.img / kernel8.img
• Linux takes over
• GPU becomes a peripheral (mailbox, display, VPU, etc.)

This explains several Raspberry Pi oddities:

• The Raspberry Pi has No BIOS / UEFI
• The config.txt is not a Linux File
• Kernel Replacement Is Trivial
• Boot failures before Linux is loaded are invisible to Linux

Even with the EEPROM bootloader:

• The GPU still executes first
• The EEPROM code is executed by the GPU
• ARM remains gated until kernel handoff

EEPROM just replaces bootcode.bin; it does not change authority.

The trust chain for the pi is:

GPU ROM → GPU firmware → ARM kernel → Linux userspace

The trust chain choices have consequences!

• ARM cannot verify GPU firmware
• Secure boot (where enabled) is GPU-anchored
• This is why Raspberry Pi secure boot is not comparable to PC Secure Boot

The Raspberry Pi Secure boot implementation ensures that:

• Only cryptographically signed boot firmware and kernel images are executed
• The chain of trust starts in the VideoCore GPU, not the ARM CPU
• The system can be locked to a specific vendor or deployment

It does not:

• Provide a hardware-enforced user/kernel trust boundary
• Protect against a malicious or compromised GPU firmware
• Provide measured boot or TPM-style attestation
• Prevent runtime compromise of Linux

Here’s the order of operations for boot up on a traditional PC:

Traditional PC Boot:

  ┌─────────────┐
  │    BIOS     │
  │   (CPU)     │
  └──────┬──────┘
         ↓
  ┌─────────────┐
  │  Bootloader │
  │   (CPU)     │
  └──────┬──────┘
         ↓
  ┌─────────────┐
  │   Kernel    │
  │   (CPU)     │
  └─────────────┘

The firmware embedded in the motherboard powers up the CPU. The CPU loads the bootloader. The bootloader hopefully correctly does cryptographic operations to load an unmodified kernel. From here, the boot process continues with init/systemd and our services are brought online for a running system.

The pi’s totally different. Instead of starting with the CPU, we start with the GPU.

Raspberry Pi Boot:

┌─────────────┐
│  VideoCore  │ ← GPU boots FIRST
│    (GPU)    │
└──────┬──────┘
       ↓
┌─────────────┐
│ Loads ARM   │
│   kernel    │
└──────┬──────┘
       ↓
┌─────────────┐
│  ARM CPU    │ ← CPU starts LAST
│   wakes up  │
└─────────────┘

Why? The Raspberry Pi uses Broadcom BCM2xxx chips where The “main” processor is a VideoCore IV/VI GPU is activated at power-on. It runs proprietary firmware that handles the boot. The BCM2xxx chips are typically used in set-top boxes for video streaming/entertainment. For these types of devices, the goal is to quickly get to a flashy user interface. The Raspberry Pi Foundation chose these inexpensive chips as their base that leave them with an odd boot order.

Related