Building U-Boot is only half the job — getting it onto a board so the boot ROM actually finds it is where a lot of first-timers get stuck. This lecture in our free embedded systems course covers the general installation paths available on modern SoCs, then walks through a concrete example on a Raspberry Pi 4.
SD card boot
boot ROM
JTAG recovery
free embedded systems course
What You Will Learn
- The three general paths for getting a bootloader onto silicon: JTAG, boot ROM media, and chainloading
- How a boot ROM decides where to look for a first-stage loader
- How to install U-Boot onto an SD card for a real board and confirm it boots
- How to recover a board that won’t boot after a bad flash
Prerequisites
- A completed U-Boot build from the previous lecture (or a board-specific one)
- A microSD card and reader, and a serial-to-USB adapter for console access
- Comfortable using
sfdisk,mkfs.vfat, and basicddusage on Linux
Three Ways a Bootloader Gets Onto a Board
| Method | When you’d use it | Risk of bricking |
|---|---|---|
| JTAG / debug probe | First bring-up on new hardware, or recovering a bricked board | Low — direct RAM load, doesn’t touch flash until you choose to |
| Boot ROM reads removable media (SD/eMMC/USB) | Most hobbyist and dev-kit boards | Low — swap the card back out if something’s wrong |
| Chainloading from an existing first-stage loader | Boards with closed vendor firmware (e.g. GPU-first boot on some SBCs) | Medium — a bad image can leave the board needing the original firmware restored |
|
v
Boot ROM (fixed in silicon, can’t be changed)
|
v
Checks configured boot media in order:
SD card -> eMMC -> USB -> UART/JTAG fallback
|
v
Loads first stage found at the expected offset
|
v
First stage initializes DRAM, loads U-Boot proper
|
v
U-Boot prompt
Worked Example: Installing U-Boot on a Raspberry Pi 4 via SD Card
The Raspberry Pi 4’s boot ROM reads a small set of GPU firmware files first, then can be told to chainload U-Boot as if it were the Linux kernel. This makes it a good teaching example precisely because it’s a chainload path, not a direct boot-ROM-to-U-Boot path like the QEMU example from the last lecture.
Start by partitioning the card. Double check the device node with lsblk before running anything — writing to the wrong device is the single most common way to lose data at this stage:
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 465.8G 0 disk
sdb 8:16 1 29.7G 0 disk <- our SD card
$ sudo sfdisk /dev/sdb << EOF
label: dos
,256M,c,*
,,L
EOFFormat the boot partition and copy over U-Boot’s binary along with the standard Raspberry Pi firmware files (start4.elf, fixup4.dat — obtained separately from the Raspberry Pi firmware repository, not from U-Boot itself):
$ sudo mkfs.vfat -F 32 -n BOOT /dev/sdb1
$ sudo mount /dev/sdb1 /mnt
$ sudo cp start4.elf fixup4.dat /mnt/
$ sudo cp u-boot.bin /mnt/kernel8.img
$ echo "enable_uart=1" | sudo tee /mnt/config.txt
$ sudo umount /mntInsert the card, connect a serial adapter to the GPIO UART pins, and power on:
$ picocom -b 115200 /dev/ttyUSB0
U-Boot 2024.10 (Nov 01 2024 - 09:14:02 +0000)
DRAM: 3.9 GiB
MMC: mmc@7e202000: 0, mmc@7e300000: 1
In: serial
Out: serial
Err: serial
Net: No ethernet found.
Hit any key to stop autoboot: 0
=>That confirms the boot ROM found the GPU firmware, the GPU firmware chainloaded U-Boot as kernel8.img, and U-Boot initialized DRAM and the MMC controller correctly.
Recovering a Bricked Board
If the board goes silent after a bad flash, don’t panic — on boards with a boot ROM fallback, holding a specific button or shorting a boot-select pin during power-on forces the ROM to wait on JTAG or UART instead of removable media. From there, you can load a known-good U-Boot image directly into RAM over the debug probe and use it to reflash the SD card or eMMC without ever needing to physically reprogram the ROM itself, since the ROM is fixed in silicon and was never touched.
Common Mistakes
- Flashing the wrong device node. Always confirm with
lsblkbefore any destructive command — this is the single biggest cause of accidental data loss in this workflow. - Forgetting board-specific firmware blobs. On chainload boards like the Pi, U-Boot alone isn’t enough; the GPU-side firmware still has to be present.
- No serial console attached. Without UART output, a silent boot failure is nearly undebuggable — always wire up console access before your first boot attempt.
Best Practices
- Keep a known-good SD card image around during bring-up so you can always fall back to a working state.
- Label boot media offsets and partition layouts in your team’s documentation — they’re maddening to reverse-engineer later.
- Test the JTAG/UART recovery path once, deliberately, before you need it in an emergency.
Security Considerations
Removable-media boot paths are convenient for development but are also the easiest attack surface for physical tampering — anyone with SD card access can swap in a malicious bootloader. Production designs typically move to eMMC with secure boot (signed first-stage images verified by the boot ROM) once bring-up is complete.
Summary
Installing U-Boot isn’t one universal recipe — it depends on whether your boot ROM reads U-Boot directly or needs a chainload step through vendor firmware first. Understanding which category your board falls into, and always keeping a serial console and a recovery path available, turns “the board won’t boot” from a crisis into a routine debugging step.
Frequently Asked Questions
Why does the Raspberry Pi need extra firmware files besides U-Boot?
Its GPU boots first and is what actually reads the SD card initially; U-Boot is chainloaded afterward as if it were the kernel, so the GPU-side firmware must still be present.
What happens if I flash a corrupted U-Boot image?
On most boards the boot ROM falls back to a recovery mode (JTAG or UART) after failing to validate the image, letting you reflash without special hardware programmers.
Do I always need a serial console to install U-Boot?
Not strictly, but without one you have no visibility into boot failures, so it’s strongly recommended for any bring-up work.
Is eMMC installation different from SD card installation?
The partitioning and file layout are usually similar, but eMMC often supports boot partitions and hardware write-protection that SD cards don’t.
Can a bad U-Boot flash physically damage my board?
It’s extremely rare — most boot ROMs are read-only and can’t be overwritten, so a bad flash is almost always recoverable through JTAG or UART.
Should I use secure boot during development?
Usually not — it adds signing overhead that slows iteration. It’s typically enabled once the design moves toward production.
Board booting into a U-Boot prompt?
Next up: actually using that shell — environment variables, common commands, and the Hush interpreter.