skip to content

How does a Raspberry Pi's boot sequence differ from a PC that starts at BIOS/UEFI and hands off to a bootloader?

level: middleimportance: nice to knowfreq 38%

answer

  1. no setup screen to press Delete for
  2. the GPU side runs first
  3. two text files on a FAT partition
  4. overlays describe attached hardware
  5. Pi 4 and 5 keep it in EEPROM

basics

~20 s

A Raspberry Pi has no BIOS/UEFI and normally no GRUB. Firmware on the board's VideoCore side starts first, reads config.txt from a FAT partition, loads the kernel and a device tree, then releases the ARM cores. Configuration is text files, not an interactive firmware menu.

solid answer

~50 s

On a PC, firmware in flash initialises hardware, then chain-loads a bootloader such as GRUB, which loads a kernel and initramfs. A Pi inverts the first part: the SoC's VideoCore side runs first while the ARM cores are held in reset. It mounts the first partition — a FAT filesystem, mounted in the running system at `/boot/firmware` on current Raspberry Pi OS — and reads `config.txt`, which is the equivalent of your firmware setup screen: memory split, overclock, enabled interfaces, and `dtoverlay=` lines that patch the device tree for attached hardware. It loads the kernel image, the device tree blob and any overlays, passes the contents of `cmdline.txt` as the kernel command line, then starts the ARM cores. On Pi 4 and 5 the first-stage bootloader lives in an on-board SPI EEPROM, updated with `rpi-eeprom-update`, and its `BOOT_ORDER` setting decides whether to try SD, USB or network.

code

bash · 4 lines
bash
# Firmware-stage configuration on current Raspberry Pi OS
cat /boot/firmware/config.txt
cat /boot/firmware/cmdline.txt
vcgencmd version

go deeper

for a junior

Know there is no BIOS screen: Pi configuration lives in text files on the small FAT partition, and on current releases you edit them under /boot/firmware rather than /boot.

for a middle

Walk the sequence: VideoCore firmware first with the ARM cores held in reset, config.txt parsed, kernel plus device tree and overlays loaded, cmdline.txt passed as the kernel command line, then the ARM cores released. Distinguish the two config files by role.

for a senior

Turn it into recovery and fleet practice: repair an unbootable board by mounting the FAT partition anywhere, use device tree overlays to bring up attached hardware, and use the Pi 4/5 EEPROM BOOT_ORDER to boot from USB or network instead of an SD card.

for a principal

Own boot policy for a fleet: where the trust anchor sits, whether firmware is pinned or auto-updated, whether nodes netboot from a controlled image, and how a failed update is rolled back on a device with no console and no hands nearby.

## The PC model, in one paragraph On a typical x86 server, firmware in flash (BIOS or UEFI) brings up memory and buses, presents an interactive setup screen, then hands control to a bootloader it finds on disk. The bootloader — usually GRUB — presents a menu, loads a kernel and an initramfs into memory, and jumps into the kernel. Configuration lives in two places: NVRAM settings you change in a firmware menu, and bootloader config files on disk. ## The Pi model A Raspberry Pi has no BIOS, no UEFI by default, and no interactive firmware screen at all. It also does not start on the CPU you think of as the CPU. Inside the SoC there is a VideoCore block with its own processor, and on power-up it is that side that runs while the ARM application cores are held in reset. A small immutable boot ROM inside the chip starts the sequence. On models up to the Pi 3 it looks for `bootcode.bin` on the first partition of the SD card; on the Pi 4 and Pi 5 that stage moved into a writable SPI EEPROM on the board itself, which is why those models can boot from USB or the network without an SD card present, and why `rpi-eeprom-update` exists as a maintenance command. The next stage loads the main firmware, which parses `config.txt`. This file *is* the firmware setup screen, expressed as text: how much RAM to reserve for the GPU, whether to enable I²C, SPI or the camera interface, HDMI behaviour, clock and voltage settings, and — most importantly on modern systems — `dtoverlay=` lines. Firmware then loads the kernel image, the base device tree blob for the board, and applies each requested overlay, so the kernel comes up already knowing about the RTC chip or display you bolted on. It reads `cmdline.txt` and passes that single line as the kernel command line, which is where `root=` and console settings live. Finally it releases the ARM cores and Linux starts. On current Raspberry Pi OS this FAT partition is mounted at `/boot/firmware`, not `/boot` — a change that trips up older documentation and any script that edits `/boot/config.txt` by path. ## Why this design keeps showing up in interviews Three practical consequences follow, and they are what the question is really probing. **Recovery is file editing, not a firmware menu.** There is no screen to enter, and often no screen at all. If a Pi will not boot, you pull the card, mount the FAT partition on any machine — including Windows or macOS, since it is FAT — and edit text. Broken overclock, wrong `root=`, headless machine with no network: all fixed by editing two files. That portability is deliberate. **The device tree, not probing, describes the hardware.** An ARM board has no equivalent of PCI enumeration for its on-board and header-attached peripherals. The kernel is told what exists via the device tree, and overlays are how you add to that description without rebuilding anything. "How do I make Linux see this I²C RTC?" is answered with a `dtoverlay=` line, not a module argument. **Boot media selection is firmware policy.** On the Pi 4 and 5, `BOOT_ORDER` in the EEPROM configuration decides the sequence of media to try — SD, USB mass storage, network — and it retries. That is what lets you build an SD-less fleet that boots from USB SSD or netboots, which matters a great deal for reliability. ## What is the same Once the kernel is running, nothing is exotic: it is Linux, with the usual kernel command line, an optional initramfs, and an init process as PID 1. The Pi-specific part ends at the moment the ARM cores start executing the kernel. It is worth saying that explicitly in an interview, because it draws the line between board-specific firmware knowledge and general Linux boot knowledge. ```bash # The two files the firmware reads, on current Raspberry Pi OS ls /boot/firmware/config.txt /boot/firmware/cmdline.txt ``` UEFI firmware for the Pi does exist as a third-party project, which lets the board boot conventional distribution installers, but it runs *on top of* the same first stages rather than replacing them.

  • What is the division of labour between config.txt and cmdline.txt?
    `config.txt` is firmware-facing: it is read before Linux exists and controls memory split, clocks, enabled interfaces and `dtoverlay=` lines that patch the device tree. `cmdline.txt` is a single line handed to the kernel as its command line — `root=`, `rootfstype=`, console settings. Roughly: `config.txt` decides what hardware the kernel is told about, `cmdline.txt` decides how the kernel behaves once it starts.
  • You attach an I²C real-time clock to the header and the kernel does not see it. What is the mechanism you reach for?
    A device tree overlay. An ARM board has no bus enumeration for header-attached parts, so the kernel only binds a driver to hardware the device tree describes. You add the matching `dtoverlay=` line to `config.txt` and reboot; the firmware applies the overlay to the base device tree before the kernel starts, and the driver binds at boot. It is not a module argument or a udev rule.
  • How can a Pi 4 boot with no SD card inserted at all?
    Its first-stage bootloader lives in an SPI EEPROM on the board rather than on the card, so there is no dependency on removable media to start. The EEPROM's `BOOT_ORDER` setting lists media to try in sequence — SD, USB mass storage, network — and it retries. You update that firmware with `rpi-eeprom-update`, which is the closest thing the platform has to a BIOS update.

saying these in an interview costs you the question

  • Enter the Pi's BIOS to change boot order
  • GRUB loads the kernel on a Raspberry Pi
  • config.txt is a kernel configuration file
  • The ARM cores execute first at power-on
  • Editing /boot/config.txt works on every release

context

resolving links…