Raspberry Pi Zero 2 W Boot Process: A Bare Metal Guide

If you have ever built a custom operating system or dug into low-level digital forensics, you know that understanding how a device wakes up is just as important as the OS it runs.

The Raspberry Pi Zero 2 W is a favorite for lightweight cybersecurity tools and headless servers. But unlike a standard desktop PC that relies on a traditional BIOS or UEFI, the Raspberry Pi utilizes a unique, GPU-centric architecture.

In this guide, we are going to break down the exact seven-stage "handshake" protocol that brings the Broadcom System-on-Chip (SoC) to life, from the moment voltage hits the board to the second your custom Linux command prompt appears.

🏗️ The Master and the Peripheral

Before we look at the stages, you have to invert how you think about computer architecture. On a standard x86 motherboard, the CPU is the master. On the Raspberry Pi, the Broadcom VideoCore GPU is the captain of the ship.

When you plug in the power ⚡, the main ARM Cortex-A53 processor is completely inactive. It is up to the GPU to prepare the environment, initialize the memory, and ultimately wake the CPU up. Here is exactly how that relay race happens:

🟥 Stage 1: The Mask ROM (The Root of Trust)

When 5V power is applied, a tiny fragment of hardwired instructions deep inside the silicon wafer wakes up the GPU. This is the Mask ROM.

• 🔒 Immutable Security: Because this code is physically etched into the silicon during manufacturing, it can never be rewritten or modified. This guarantees the device wakes up in a highly predictable state.
• 🎯 The Mission: The Mask ROM has only one job—to scan the microSD card slot for a primary partition formatted as FAT32 and look for a specific file called bootcode.bin.

🟧 Stage 2: Waking the RAM (bootcode.bin)

At this millisecond, the Pi has absolutely no working system memory. The GPU loads bootcode.bin into its own internal cache.

• 🧠 Memory Calibration: The Zero 2 W has 512MB of SDRAM physically stacked on top of the processor. bootcode.bin contains the precise electrical timing instructions required to activate and stabilize this memory.
• ✅ Once the memory controller verifies the RAM is stable and ready to act as a workspace, the GPU discards bootcode.bin and moves to the next phase.

🟨 Stage 3: The GPU Firmware (start.elf)

With the RAM active, the GPU loads start.elf. This is the most complex piece of closed-source, proprietary firmware on the board.

• 👻 The Hidden OS: start.elf actually runs its own lightweight Real-Time Operating System (RTOS) internally.
• 🌡️ Hardware Management: This firmware assumes total control over the physical board. It manages power delivery, initializes hardware interfaces, and monitors thermal limits. If your board gets too hot during a heavy packet-injection attack, it is start.elf that dynamically throttles the processor to prevent it from melting.

🟩 Stage 4: Your Hardware Control Panel (config.txt)

Before the GPU considers waking up the main ARM processor, it reads a plain-text file called config.txt.

Think of this as the equivalent of pressing "Delete" to enter your BIOS settings. By defining parameters here, you dictate how the hardware behaves before the OS even exists 🛠️.

For example, if you are building a headless cybersecurity tool and want to maximize the RAM available for your scripts, you can shrink the GPU's memory allocation and enable the serial console with just two lines:

💻 gpu_mem=16
🔌 enable_uart=1

🟦 Stage 5: The CPU Takeover (kernel8.img)

This is the grand finale of the hardware bootloader. The GPU locates your compiled operating system kernel (typically kernel8.img for a 64-bit environment).

• 🤝 The Handoff: The graphics processor copies the entire kernel image into the main system RAM. It then sends an electrical signal to release the reset line on the ARM CPU.
• 🟢 The OS Begins: The CPU wakes from its slumber, looks at the memory address where the kernel was placed, and immediately begins executing your Linux instructions.

From this millisecond forward, your operating system is officially in charge. The GPU respectfully steps back into a supporting role.

🐧 The Transition: From Bare Metal to Linux

At the end of Stage 5, we officially leave the "hardware firmware" phase and enter the Software Phase. Here is how your custom Linux operating system stands itself up.

🟪 Stage 6: Kernel Initialization and the Device Tree (The Bridge)

The Linux kernel is the engine, but when it first wakes up, it is essentially blind 🦇. It doesn't know what kind of board it is running on.

• 🗺️ Reading the Map (.dtb): Before the kernel can do anything useful, it reads a file called the Device Tree Blob (for the Zero 2 W, usually bcm2710-rpi-zero-2-w.dtb). This file is a literal map of the motherboard. It tells the kernel exactly which GPIO pins connect to the Wi-Fi chip and where the USB controller is.
• ⚙️ Driver Activation: Armed with the Device Tree, the kernel starts loading its internal drivers. It initializes the virtual memory, sets up the network stack, and probes the USB ports.
• 📂 Mounting the Root Filesystem (RootFS): This is the most critical part of Stage 6. The kernel reaches out to the SD card's second partition (ext4) and mounts it as the Root Directory (/). The "engine" is fully running and has access to its tools, but there is still no user interface.

🟫 Stage 7: PID 1 and "Userland" (The Embedded init Phase)

Now the system has to cross the boundary from "Kernel Space" (privileged, low-level) to "User Space" 🌍 (where your full commands, scripts, and cybersecurity tools actually run).

To do this, the kernel executes the very first program on the system, typically /sbin/init. It is permanently assigned Process ID 1 (PID 1). In a custom, lightweight embedded OS tailored for the Pi Zero, PID 1 is handled by a streamlined init system that follows a strict, sequential script:

1. 🗂️ Mounting the API Filesystems: The init program immediately creates the "virtual" filesystems: /proc, /sys, and /dev. These live in the Pi's RAM and allow your standard commands (like fdisk or ps) to see the hardware and running processes.
2. 📜 The Blueprint (/etc/inittab): The init program reads a single configuration file containing the master instructions for the boot sequence.
3. 🏃 The Master Startup Script (/etc/init.d/rcS): Your custom Pi OS runs a master startup script that executes commands sequentially:
4. It populates your /dev folder with your physical hardware nodes.
5. It brings up the Wi-Fi interface (wlan0) 📡 and requests an IP address.
6. It launches a lightweight SSH daemon 🔑, opening port 22 for remote access.
7. (Note: Because this runs sequentially, you can inject custom packet-sniffing or security scripts right here to execute with root privileges before login).
8. 💻 The Shell (The Prompt): Finally, init spawns a getty process on your active terminal (UART serial or HDMI). This handles the login prompt. Once authenticated, it drops you into your full command-line shell (like Bash), with the vast majority of your RAM completely free.

🏁 Why Custom OS Engineers Care

By understanding this entire pipeline, you can see exactly how a 5-volt power source turns into a functional, hacking-ready embedded Linux machine in just a few seconds.

🎯 The Domino Effect: Your Role as the OS Architect

Think of the boot process like setting up a line of dominoes 🎲. When you plug the Pi into the wall 🔌, gravity (the hardware) knocks all the dominoes down automatically from Stage 1 to 7. The Pi "takes care of everything" during the actual boot-up.

However, as the custom OS engineer, you have to manually design and place dominoes 4, 5, 6, and 7 before you ever plug the power cable in 🧠.

Here is the exact breakdown of who does what before the Pi boots:

🛑 The "Hands-Off" Stages (Broadcom’s Job)

You do not code, alter, or compile anything here. Buildroot simply downloads these pre-made files and puts them on your SD card.

• 🟥 Stage 1 (Mask ROM): You can't touch this; it's physically inside the chip.
• 🟧 Stage 2 (bootcode.bin): You just let it sit on the SD card.
• 🟨 Stage 3 (start.elf): You just let it sit on the SD card.

🛠️ The "Hands-On" Stages (Your Job)

If you do nothing here, the boot process will fail or run poorly. You must "do something" for these stages during your Buildroot setup:

• 🟩 Stage 4 (config.txt): You have to write the text in this file to tell the GPU to shrink its memory (gpu_mem=16) and turn on the serial console. If you don't, the Pi defaults to wasting RAM on graphics you aren't using.
• 🟦 Stage 5 (kernel8.img): You have to configure this. When you run make menuconfig in Buildroot, you are choosing exactly what goes into this kernel.
• 🟪 Stage 6 (Device Tree & RootFS): You choose which packages (like OpenSSH, Python, Nmap) are packed into the RootFS. If you don't add them during the build, they won't be there when the kernel looks for them.
• 🟫 Stage 7 (init and Userland): You have to write or configure the startup scripts (like /etc/init.d/rcS). If you want a Python packet-sniffer to run the second the Pi turns on, you must explicitly type that command into the script before you flash the SD card.

🏁 The Bottom Line

Once the SD card is flashed and inserted, the Pi Zero takes care of the entire 7-stage sequence in less than 5 seconds without you touching a keyboard ⚡. But to get to that point, you are the architect responsible for engineering stages 4 through 7! 🚀