U-Boot: the boot loader you build per board, not install

What U-Boot solves, and who actually needs it

U-Boot is a boot loader for embedded boards based on PowerPC, ARM, MIPS and several other processors. The README describes it as software that can be installed in a boot ROM and used to initialize and test hardware or to download and run application code. That sentence covers the whole audience. If you have a board that powers on with no firmware between the reset vector and your operating system, U-Boot is one of the things that fills that gap.

The project's own status section is unusually direct about coverage. All boards for which a default configuration file exists in the configs/ directory have been tested to some extent and can be considered working, and many of them are used in production systems. The qualifier matters. A defconfig in configs/ is the entry ticket, not a guarantee. Boards that lost that entry ticket are listed in doc/README.scrapyard, which is where you look when a configuration you remember has disappeared.

This is not a general purpose boot menu for a laptop. It is board firmware. The people who get value from it are hardware bring-up engineers, SoC vendors shipping reference designs, and product teams who need a boot chain they can patch, because the source tree is the deliverable.

The build system is the architecture

U-Boot's structure is a Kbuild and Kconfig system borrowed from the Linux kernel, and the README says the relationship is deliberate: some parts of the source originate in the Linux source tree, the two share header files, and special provision exists for booting Linux images. The top level Makefile carries VERSION 2026, PATCHLEVEL 10 and EXTRAVERSION -rc5, which tells you releases are cut as kernel-style version numbers and that the tree you are reading is a release candidate line rather than a fixed tag.

Configuration is layered. The README states that for all supported boards there are ready-to-use default configurations, selected with make <board_name>_defconfig, and that exactly one CPU type and exactly one board type must be defined, for example CONFIG_MPC85XX and CONFIG_MPC8540ADS. Everything else is an option on top: DDR controller settings, clock dividers, exception vector placement, and the flattened device tree interface through CONFIG_OF_LIBFDT, which the README notes new kernel versions expect for passing firmware settings.

The practical consequence is that a board port is a directory under board/ plus a defconfig plus a device tree, and the build descends recursively through subdirectories, each of which only modifies files in its own directory. That constraint is stated in the Makefile comments and it shapes where your code can live. You cannot scatter a board's logic across the tree and expect the recursive build to pick it up cleanly.

Building U-Boot for a board, and the sandbox shortcut

The README gives the configuration step directly. Change into the source directory and select a board configuration. The example it uses is a TQM823L module:

cd u-boot
make TQM823L_defconfig

After that, the standard kernel-style build follows. The Makefile notes that make help lists typical targets, so that is where to look for the target that produces your board's image. What you should see is a configuration written into the build tree and, after the build, an image named for your board rather than a generic binary.

If you do not have the target hardware on your desk, the README points at a second path. U-Boot can be built natively to run on a Linux host using the sandbox board, which allows feature development that is not board- or architecture-specific to be undertaken on a native platform, and the sandbox is also used to run some of U-Boot's tests. The details live in doc/arch/sandbox/sandbox.rst. For anyone evaluating the project, this is the cheapest way in: you get a working U-Boot binary without flashing anything.

Before you start, note two conventions from the README that affect patches. The spelling U-Boot is used in all written text, file names use the string u-boot, and variable names and preprocessor constants are based on u_boot or U_BOOT. Reviewers will notice if you get this wrong.

SPL and the limits of a single-stage boot

The README does not describe SPL, so anything beyond the name has to come from the tree itself rather than from the front page. What the material does establish is the constraint that pushes people toward it. U-Boot is installed in a boot ROM and initializes hardware, including DDR memory. On many SoCs the on-chip SRAM available at reset is far too small to hold a full U-Boot with a command monitor, network stack, filesystem drivers and a device tree. Splitting the boot into a small first stage and a larger second stage is the common answer, and the repository layout reflects it: boot/ and common/ hold the code that ends up in the stages, while configs/ holds the defconfigs that decide which options are compiled in.

The design trade-off is real. A first-stage build that only trains memory and loads the next image is small and fast, but it is also a place where a mistake is expensive, because there is no monitor to fall back to and no network to recover over. The README's own remedy for board problems is procedural rather than technical: use scripts/get_maintainer.pl <path> to identify the people or companies responsible for various boards and subsystems, or read the git log. That is sound advice and it is also an admission that board-specific knowledge is distributed across maintainers rather than centralized in documentation.

Where U-Boot is the wrong choice

If you want a boot loader for a normal x86 desktop or server, U-Boot is the wrong tool. The README's processor list is PowerPC, ARM, MIPS and several others, and the configuration model assumes a board type defined at build time. There is no story here about detecting whatever hardware you happen to be running on.

A second wrong case is a team that wants a binary artifact rather than a build. U-Boot is distributed as source. The README points at the Git repository at git.u-boot-project.org, at tarballs for tagged versions, and at the DENX file server over HTTPS and FTP for official releases. Nothing in that list is a package manager. You are expected to have a cross toolchain and to run the build yourself, and you are expected to keep running it, because your board's configuration is your responsibility.

The third case is subtler. If your board has no defconfig in configs/, the README's status claim does not apply to you. You are not using a tested configuration; you are porting. That is a legitimate thing to do, and the README's history section is essentially a record of people doing it, from 8xxrom through PPCBoot and ARMBoot to U-Boot. But it is a project, not an installation.

U-Boot against GRUB and Barebox

The comparison people reach for is GRUB, and the difference is where the configuration lives. GRUB is designed around a boot-time configuration file and a menu, and its target is the PC and server world. U-Boot's configuration is compiled in. The README's statement that exactly one CPU type and one board type must be defined is the clearest expression of this: the boot loader knows what board it is because you told it at build time. That makes U-Boot smaller and more predictable on fixed hardware, and it makes it useless as a general purpose loader.

Barebox is the closer relative. It is also embedded board firmware built from source with a per-board configuration, and the two projects overlap heavily in the boards they support and the problems they solve. Choosing between them is mostly about which one already has a port for your SoC and which maintainer community you can get answers from, not about a capability gap you can read off a feature list. The README's own help channel is the U-Boot mailing list at [email protected], with an archive at lists.u-boot-project.org and marc.info, and it asks you to search the archive before asking questions. That archive is the practical thing to check when comparing the two.

Licence and the cost of staying current

The repository's licence field reads NOASSERTION, and there is a Licenses/ directory at the top level alongside COPYING. The README and the Makefile both carry SPDX-License-Identifier: GPL-2.0+ headers, and the README notes that some source originates in the Linux source tree. The honest reading is that U-Boot is a large tree with per-file licensing rather than one uniform declaration, and that the NOASSERTION field reflects that. If you are shipping a product, the file headers are what you check, and a lawyer is who checks them, not a review article.

The upgrade cost follows from the same structure. Board configuration is expressed as Kconfig symbols, and the README devotes a long section to individual options such as CONFIG_SYS_FSL_ERRATUM_A004510, which enables a workaround for a specific silicon erratum and requires CONFIG_SYS_FSL_ERRATUM_A004510_SVR_REV and CFG_SYS_FSL_CORENET_SNOOPVEC_COREONLY to be set alongside it. Options like that are tied to silicon revisions, not to your application. When you move to a newer U-Boot, you re-validate the board, and the effort scales with how much board-specific code you added.

The last push to the default branch was on 2026-09-22, and the tree is at a 2026.10 release candidate. That is a moving target by design. A product team pinning a release will still need a plan for pulling in fixes, because the fixes arrive as source changes to files you may have modified.

Editorial conclusion

Adopt U-Boot if you are bringing up an embedded board with a supported defconfig in configs/ or porting one, and you can maintain a board directory and a config fragment across releases. Do not adopt it as a desktop boot loader or if you need a binary you can install without a toolchain. Verify first that your board still has a defconfig, that the maintainer listed by scripts/get_maintainer.pl is reachable, and which licence applies to the files you modify, since the repository carries a NOASSERTION licence field and a Licenses/ directory rather than a single declared identifier.

Frequently asked questions

Official sources

1. Issues
2. README
3. u-boot/u-boot on GitHub