As U-Boot’s support for hardware grows, so does the complexity of managing build configurations. A single board might require several build variations—for example, one with network support and one without, or a standard build versus one tailored for Android booting. Historically, managing these variations often meant duplicating large defconfig files, a maintenance headache waiting to happen.
A recent patch series, with contributions from Heinrich Schuchardt and Simon Glass, introduces a powerful and elegant solution to this problem by formally integrating configuration fragments into buildman, U-Boot’s indispensable build-testing tool.
What are Config Fragments?
A config fragment is a small, targeted file containing just a few Kconfig options. For instance, an acpi.config fragment might contain only one line:
CONFIG_ACPIGEN=y
Instead of creating a whole new qemu-riscv64_smode_acpi_defconfig, you can now apply this small fragment on top of the existing qemu-riscv64_smode_defconfig to generate a new build variant on the fly. This approach is cleaner, reduces duplication, and makes configurations easier to manage.
While the underlying Kconfig system has supported this for a while, buildman was unaware of this mechanism—until now.
Official buildman Support: Two New Approaches
The new series enhances buildman by providing two ways to work with fragments.
The Manual Approach: --fragments
For quick tests or one-off builds, buildman now has a --fragments command-line option. You can pass a comma-separated list of fragment files to apply to your build.
For example, to build qemu-riscv64_smode with ACPI support, you can now run:
tools/buildman/buildman -k qemu-riscv64_smode --fragments acpi.config
buildman handles the rest, correctly merging the fragment with the board’s base defconfig.
The Automated Build Matrix: --extend and .buildman
The real impact of this series lies in its ability to automate the discovery and building of these variations. This is achieved through a new file format and a new command-line flag.
A new file, configs/extended.buildman, now defines the relationships between boards and their valid fragments, creating what are called “extended boards.”
The syntax is simple and powerful. You can define a build variant and specify which boards it applies to using wildcards or by checking for specific CONFIG options in the base defconfig.
Here’s an example from the series that creates ACPI-enabled variants for all RISC-V QEMU boards:
# Build RISC-V QEMU builds with ACPI
name: acpi
fragment: acpi
targets:
qemu-riscv*
To tell buildman to parse this file and build all the resulting extended boards, you simply add the -X (or --extend) flag to your command. buildman will then discover that acpi,qemu-riscv64_smode is a valid new target and add it to its build queue.
Continuous Integration for All Variants
This isn’t just a tool for local development. The final piece of this series integrates the -X flag directly into U-Boot’s GitLab CI. This means that these “extended board” configurations are now built and tested automatically as part of the “world build,” guaranteeing that build variations are treated as first-class citizens and don’t suffer from bit-rot. This last patch is pending, due to some last-minute issues.
By formalizing the concept of config fragments, this series makes the U-Boot build system more robust, easier to maintain, and better equipped to handle the diverse configurations required by the embedded ecosystem.
