u-boot-xlnx: Xilinx's copy of the boot loader behind every Zynq and Versal board

What a boot loader actually does on a board

The README's summary is the definition. U-Boot is a boot loader for embedded boards based on PowerPC, ARM, MIPS and several other processors, which can be installed in a boot ROM and used to initialize and test the hardware, or to download and run application code. That second role is the one people forget. A boot loader on an embedded board is not only the thing that hands off to an operating system, it is also the environment you boot into to check whether the memory works, whether the flash is readable, whether the network answers, and which board revision you actually have. The development of U-Boot is closely related to Linux, with some parts of the source originating in the Linux tree, some header files in common, and special provision made for booting Linux images. This repository is Xilinx's copy of that tree, the one that ships on the Zynq and Versal families, and it is the place to look when a board will not boot.

The tree structure follows the kernel conventions

The top-level layout is a good orientation for anyone arriving from Linux. There is an arch directory for architecture-specific code, a board directory for board support, a drivers directory, a dts directory for device trees, a configs directory holding the default configuration files, a cmd directory for the monitor commands, a net directory for networking, a fs directory for filesystems, a disk directory, an include directory, a lib directory, common, boot, post, env, tools, scripts, doc, test, examples and Licenses. Alongside them sit the files that make the build work: a Kbuild file, a Kconfig file, a config.mk, a Makefile, a MAINTAINERS file, a COPYING file and a .checkpatch.conf. The presence of MAINTAINERS and the get_maintainer configuration tells you this is a project with a long institutional memory, and the Kconfig plus Kbuild pair shows it has adopted the kernel's configuration model rather than inventing one.

Configuration is a Kconfig menu, not a header file

Selecting a board is one command. For all supported boards there are ready-to-use default configurations, and you just type make with the board name and the defconfig suffix.

	make TQM823L_defconfig

The example in the README uses a TQM823L module, and the procedure given is to change into the u-boot directory and run that target. Once a defconfig has been applied you are in a Kconfig menu where you set the CPU type and board type, exactly one of each, then work through processor-specific options, generic CPU options, the Linux kernel interface and the rest. The README is explicit that some settings are mandatory, for example defining exactly one CPU type such as CONFIG_MPC85XX and exactly one board type such as CONFIG_MPC8540ADS. Other options are erratum workarounds with their own conditions, like the A004510 workaround, which also requires the SVR revision option and the CORENET snoop vector option to be set.

The sandbox target lets you work without the board

The Sandbox Environment section is the most useful thing in the README for a developer without hardware. U-Boot can be built natively to run on a Linux host using the sandbox board, and this allows feature development that is not board or architecture specific to be undertaken on a native platform. The sandbox is also used to run some of U-Boot's tests, with more detail in the sandbox architecture document. The Makefile shows how this is wired: it includes the host architecture header and then works out the target architecture, either from the uname of the host when no cross compiler is set, or by parsing the name out of the CROSS_COMPILE variable, with branches for x86_64, 32-bit x86, aarch64, arm, riscv32 and riscv64. That is a small but thoughtful piece of plumbing, because it lets the same tree build for a workstation and for a cross target without the developer editing anything.

Configurable by design, and extendable with dynamic commands

The README notes that attention has been paid to make the software easily configurable and extendable. Two mechanisms are called out. All monitor commands are implemented with the same call interface, so it is easy to add new commands. And instead of permanently adding rarely used code, for instance hardware test utilities, you can load and run it dynamically. The second point is the interesting one for a boot loader. A boot ROM environment is small and a fixed one, so a command that is only needed during bring-up does not belong permanently in the binary, and being able to load it at runtime keeps the resident image small. The device tree support follows the same kernel-derived line, with CONFIG_OF_LIBFDT used when newer kernel versions expect firmware settings to be passed as flattened device trees based on open firmware concepts.

Where the help comes from, and where the source lives

The project has a defined set of places to look. Questions, problems and contributions go to the U-Boot mailing list, and the README advises searching the archive before asking FAQs, pointing at both the pipermail archive and the marc.info list. The upstream source is maintained in a Git repository at source.denx.de, browsable online at the same host, and official releases are available from the DENX file server over HTTPS or FTP. For a board problem, the README gives a specific tool to use, the get_maintainer.pl script, which takes a path and identifies the people or companies responsible for various boards and subsystems, with the git log offered as the alternative. That is a practical tool for a tree this size, where the number of board configurations is in the hundreds and the person who knows your board may be someone you have never heard of.

A version line that starts at 2026.01, with no GitHub releases

The Makefile header sets the version fields that define the release scheme.

VERSION = 2026
PATCHLEVEL = 01

The extra version and name fields are empty, so this tree identifies itself as the 2026.01 series, a calendar-year scheme rather than the old Linux style numbering. The repository has no GitHub releases, which is normal for this project since official releases are published on the DENX file server instead. The repository is not archived and the last push was on 2026-10-18, so the tree is actively worked on even though the version string looks like a point release. The licence is GPL-2.0-or-later, stated in the SPDX header at the top of the README and the Makefile, with a separate Licenses directory at the root, and the copyright attribution goes back to Wolfgang Denk and DENX Software Engineering for the period 2000 to 2013, which is where the project started.

Editorial conclusion

u-boot-xlnx fits an engineer bringing up a Xilinx board, writing a custom board file, or debugging the gap between the boot ROM and the kernel where nothing else can help. It does not fit a general Linux developer, since the build system and the configuration model are unlike anything in the mainline kernel tree, and the Freescale-era option names still visible in the documentation show how old parts of the tree are. Verify first which U-Boot version your board's boot ROM expects before you build, because a version mismatch shows up as a device that boots nothing, and use the sandbox target to develop features without hardware in the loop.

Frequently asked questions

Official sources

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