What You Will Learn

• How to build Barebox’s SPL and main image for a real board
• How to flash both images to an SD card correctly
• How to read and interpret a Barebox boot log
• How to choose between U-Boot and Barebox for a future free embedded linux course project

Prerequisites

You need the Barebox source cloned and checked out to a stable tag from the previous lecture, plus the same cross toolchain you have been using throughout this chapter.

Building For A Raspberry Pi 4 Target

To keep this reproducible on hardware many readers already have, we target the Raspberry Pi 4, the same board used earlier in this course for a U-Boot install. Like most SoCs needing a two-stage boot, Raspberry Pi 4 support in Barebox needs both an SPL build and a main image build.

$ export ARCH=arm
$ export CROSS_COMPILE=arm-linux-gnueabihf-

# Stage 1: build the SPL
$ make rpi4_xload_defconfig
$ make -j$(nproc)

# Stage 2: build the main Barebox image
$ make rpi4_defconfig
$ make -j$(nproc)

The first build produces the secondary program loader image; the second produces barebox-flash-image, the main runtime.

Flashing To An SD Card

$ sudo mkdir -p /media/boot
$ sudo mount /dev/sdX1 /media/boot
$ sudo cp barebox-flash-image /media/boot/barebox.bin
$ sync
$ sudo umount /media/boot

Raspberry Pi’s own GPU-based boot ROM loads barebox.bin directly from the FAT partition, which is simpler than the raw-offset writes we used for U-Boot on EP-Falcon — a good example of how boot conventions genuinely differ across SoC vendors.

Reading The Boot Log

Power on with a serial console attached and you should see a Barebox banner followed by hardware discovery messages:

barebox 2026.07.0 #1 Wed Aug 12 10:14:02 UTC 2026

Board: Raspberry Pi 4 Model B
mci0: registered as mci0
mci0: detected SD card version 3.0
mci0: registered disk0
malloc space: 0x1e000000 -> 0x1fffffff (size 32 MiB)
environment load /boot/barebox.env: No such file or directory
Maybe you have to create the partition.
no valid environment found on /boot/barebox.env. Using default environment
running /env/bin/init...

Hit any key to stop autoboot: 0

barebox@Raspberry Pi 4 Model B:/ 

The missing environment message on a first boot is completely normal — Barebox falls back to compiled-in defaults and still reaches a usable prompt. You can create a persistent environment partition afterward once the board is confirmed working.

Chapter Comparison: U-Boot vs Falcon Mode vs Barebox

Approach	Boot Speed	Interactivity	Best Fit
U-Boot, normal boot	Moderate	Full shell, scripting, network	General development and most production devices
U-Boot, Falcon mode	Fastest	None at runtime	Latency-critical production devices
Barebox	Moderate	Full POSIX-like shell, mountable filesystems	Teams wanting a Linux-like bootloader experience

Common Mistakes And Troubleshooting

• Forgetting the SPL build: some boards need both an xload/SPL defconfig and a main defconfig — skipping the first leaves you with a main image nothing ever loads.
• Wrong filename on the boot partition: the boot ROM or firmware config often expects an exact filename such as barebox.bin; a typo means it silently falls through to any other bootloader present.
• Treating the missing-environment message as an error: it is expected on a first boot and does not indicate a broken build.

Best Practices

• Keep separate SD cards for your U-Boot and Barebox experiments so you can compare boot logs side by side.
• Once a board boots reliably, create a persistent environment partition rather than relying on compiled-in defaults indefinitely.
• Document which boot ROM convention (raw offset vs FAT filename) your SoC uses — it is easy to forget months later.

Performance And Security Considerations

Barebox’s mountable filesystem support is convenient but comes with a larger code footprint than a minimal U-Boot Falcon mode build, so raw boot speed is not its strength. Security-wise, the same rule from earlier in this chapter still applies: any bootloader left with an open, unauthenticated interactive shell in a production image is an attack surface, regardless of which project you choose.

Summary And Key Takeaways

• Every system needs a bootloader to bring hardware to life before a kernel can run.
• U-Boot is the safest default choice thanks to its board support and community size.
• Falcon mode trades interactivity for boot speed on latency-critical devices.
• Barebox offers a genuinely different, Linux-like design for teams who value that workflow.
• The device tree, introduced earlier in this chapter, is what lets one kernel binary support many different boards regardless of which bootloader placed it in memory.

Conclusion

That closes out Chapter 3 of this free embedded linux course. You have now taken a board from nothing through defconfig creation, board bring-up, boot testing, a fast-boot production technique, and a second bootloader entirely — a genuinely complete picture of what happens before Linux ever runs. In the next chapter, we shift focus to the kernel itself: how it starts, how it discovers hardware through the device tree you now understand, and how the driver model ties it all together.

FAQ

Do I need two separate defconfigs for every Barebox board?

Only boards that need a distinct SPL/xload stage require two; simpler platforms that boot Barebox directly from ROM need only one defconfig.

Why is the missing environment message not an error?

Barebox is designed to fall back to compiled-in defaults when no environment partition exists yet, so the board still reaches a working shell.

Which is faster to boot, U-Boot or Barebox?

Neither is inherently faster in normal mode; the real speed advantage in this chapter came from U-Boot’s Falcon mode, which removes an entire stage.

Can Barebox replace U-Boot on every board from this course?

Only where Barebox has equivalent board support; our fictional EP-Falcon board would need its own Barebox port before this would apply.

What comes after this bootloader chapter?

The Linux kernel itself — how it boots, discovers hardware via the device tree, and loads drivers, which is the subject of this course’s kernel and device driver chapters.

---

PREV_LEC | NEXT_LEC