Bootloaders
Fundamentals
What runs before an operating system exists to run anything at all — and why that job is usually split across multiple stages instead of being one program.
- What it is
- The staged sequence (ROM code → SPL → full bootloader → OS) that brings a chip from power-on to running Linux.
- Mental model
- Each stage is just barely enough to load the next, bigger stage — like lighting a match to light a candle to light a room.
- Key numbers
- ROM code is fixed at manufacture and cannot be overwritten; boot-mode pins/eFuses select the first boot source.
- Reach for it when
- Bringing up new hardware, debugging a board that won't boot at all, or setting up secure/verified boot.
Why boot in stages?
At power-on, RAM is typically not yet initialized (DDR training takes real configuration work) and the only memory guaranteed to be usable is a small amount of on-chip SRAM or boot ROM. A full bootloader like U-Boot is too large to fit in that small space. So boot is split:
| Stage | Runs from | Job |
|---|---|---|
| ROM code (BootROM) | On-chip mask ROM, fixed at manufacture | Minimal — read a boot device (eMMC, SD, SPI flash) per boot-mode pins, load the next stage into on-chip SRAM, jump to it. |
| SPL / TPL (Secondary/Tertiary Program Loader) | On-chip SRAM | Initialize DRAM controller and minimal clocking, then load the next stage into DRAM. |
| Full bootloader (e.g. U-Boot proper) | DRAM | Full driver set, storage/network access, environment variables, boot menu logic, final load of the OS kernel. |
| OS kernel | DRAM | Takes over entirely — see Linux → Boot. |
Not every platform has all of these stages — a simple microcontroller typically jumps straight from a tiny ROM bootloader (or none at all) into the application. The staged model above is most visible on application-class SoCs that run Linux.
What a boot ROM actually decides
Boot-mode selection is usually determined by hardware strap pins or eFuses read very early — which storage device to read the next stage from (SD card, eMMC, SPI NOR/NAND, UART/USB recovery mode). This is why "hold this pin, it boots from USB instead" exists on many dev boards — it's a boot ROM feature, before any user code has run.
Secure/verified boot, briefly
On SoCs with a hardware root of trust, the boot ROM (or SPL) can verify a cryptographic signature on the next stage before jumping to it, forming a chain of trust — each stage verifies the next before handing off control. Skipping or misconfiguring any link in that chain breaks the guarantee for every stage after it.
Real-world applications
- Secure/locked-down IoT devices — a hardware root of trust and signature verification at every stage is what stops a stolen or compromised device from running unauthorized firmware.
- Field-recoverable devices — a USB/UART recovery boot mode built into ROM code is what lets a device be reflashed even after a completely bad firmware update.
- Multi-boot-source designs — industrial devices that boot from SD card during development and eMMC in production rely on boot-mode strap pins to switch sources without code changes.
- Product certification — many regulatory/security certifications for connected devices specifically require a documented, verified chain of trust starting at the ROM stage.
"Bricked" after a bad bootloader flash usually still isn't unrecoverable — the boot ROM stage is typically burned in mask ROM and can't be overwritten, and often supports a recovery/download mode specifically for this situation. Knowing your SoC's recovery boot mode before you need it saves a lot of stress later.