1. The GPU-First Boot Pipeline: Broadcom VideoCore IV Mechanics

Unlike standard desktop computers and servers that initialize an x86/x64 central processing unit (CPU) via Motherboard UEFI or legacy BIOS firmware, the Raspberry Pi utilizes an inverted architecture where the GPU is the master processor during system power-on:

1. Stage 1 (On-Chip Boot ROM): When electrical power is applied, the ARM CPU is held in hard reset. The Broadcom VideoCore GPU activates first, executing microcode burned permanently into on-chip read-only memory (ROM). The ROM code initializes the SD card controller and searches the primary Master Boot Record (MBR) partition.
2. Stage 2 (FAT32 Boot Partition & bootcode.bin): The on-chip ROM expects the first partition of the storage media to be formatted strictly as FAT16 or FAT32. On early Pis, it reads bootcode.bin into the GPU's L2 cache (on Pi 4 and 5, this stage is stored in onboard SPI EEPROM flash).
3. Stage 3 (GPU Firmware Execution: start.elf): The GPU executes start.elf (the GPU operating system). start.elf parses config.txt (video modes, overclocking parameters, memory split), initializes SDRAM memory controllers, and loads the Device Tree binary (.dtb).
4. Stage 4 (ARM Kernel Initialization: kernel.img): With SDRAM online, the GPU loads the compiled Linux kernel (kernel7.img or kernel8.img for 64-bit) into system memory, passes command-line parameters from cmdline.txt, releases the ARM CPU from reset, and hands over execution.

2. Why PC ISO Installers (UnetBootin) Failed on Single-Board Computers

Software utilities like UnetBootin, Rufus (in ISO mode), or Universal USB Installer were built specifically to create bootable media for x86/x64 PCs. They operate by extracting an ISO 9660 filesystem and installing an MBR bootloader like Syslinux or GRUB designed to execute 16-bit x86 real-mode CPU instructions.

A Raspberry Pi completely ignores PC MBR boot code. It requires an exact raw image containing two distinct partitions pre-baked:

• Partition 1 (/boot): A small (256MB–512MB) FAT32 partition containing bootcode.bin, start.elf, kernel binaries, and device tree overlays.
• Partition 2 (/): An ext4 Linux root filesystem partition containing Debian/Raspbian userland binaries.

To flash this properly, engineers must perform raw block-level disk imaging that writes the raw image byte-for-byte directly across the storage medium:

# Unmount target disk partitions
umount /dev/sdb*

# Write raw image using direct block copy (dd) with 4MB block size
sudo dd if=raspios.img of=/dev/sdb bs=4M status=progress conv=fsync

3. MicroSD Architecture: Wear Leveling & SDXC exFAT Pitfalls

MicroSD cards are built from cheap consumer NAND flash silicon managed by an inexpensive embedded microcontroller. When deploying Raspberry Pis, engineers must navigate two physical limitations:

1. The 64GB+ SDXC exFAT Trap: Memory cards 32GB or smaller (SDHC) are factory formatted as FAT32. Cards 64GB and larger (SDXC) are formatted by manufacturers using Microsoft's proprietary exFAT filesystem. Because the on-chip boot ROM of older Pis only understands FAT16/FAT32, inserting a factory 64GB SDXC card resulted in zero activity (no green LED). The card had to be forcibly re-partitioned to FAT32 before flashing.
2. NAND Flash Wear Leveling: Operating systems designed for rotating magnetic hard drives write frequent temporary logs and swap files to disk. MicroSD flash blocks degrade after roughly 3,000–10,000 program/erase (P/E) cycles. To prevent sudden card death, production systems mount log files in RAM (tmpfs) and disable disk swapping.

4. Automated Headless Provisioning: Zero-Monitor Setup

Modern DevOps engineers rarely connect a physical monitor, keyboard, or mouse to provision a Raspberry Pi. Instead, the bootloader supports automated headless configuration files placed directly into the FAT32 /boot partition:

• Headless SSH Enablement: Creating an empty file named ssh in the root of the boot partition instructs the system to automatically enable the OpenSSH daemon on first boot.
• Headless User Credentials (userconf.txt): Modern Raspberry Pi OS distributions no longer ship with the default insecure pi / raspberry credentials. You can pre-seed credentials by creating userconf.txt containing a username and encrypted SHA-512 password hash:

  # Generate password hash on your workstation:
  echo 'secretpassword' | openssl passwd -6 -stdin
  
  # Write into userconf.txt:
  admin:$6$rounds=4096$salt$abcdef...encrypted_hash...

• Headless Wi-Fi Configuration (wpa_supplicant.conf): Dropping a configured Wi-Fi configuration file into the boot partition automatically joins the local wireless network during initial boot.

5. Upgrading to USB 3.0 NVMe SSD Boot for Enterprise Reliability

For industrial and production server workloads, relying on microSD cards is an operational anti-pattern. Modern boards (Pi 4, Pi 5, Compute Module 4/5) support native PCIe / USB 3.0 NVMe boot.

By updating the onboard EEPROM bootloader order (BOOT_ORDER=0xf416), the Pi boots directly from high-speed NVMe solid-state drives, increasing sequential read/write throughput from ~40 MB/s (Class 10 microSD) to over 850 MB/s while providing true enterprise flash endurance and wear leveling.