Stay updated with the latest U-Boot development news, features, tutorials, and community highlights.
We’ve just merged a fix in Concept for a particularly tricky memory corruption bug in the U-Boot sandbox environment. This bug was difficult to track down, so we wanted to share the story of the investigation and the solution. The Symptom: Mysterious Heap Corruption The problem first appeared as random and hard-to-reproduce memory corruption in […]
For a while now, U-Boot’s EFI application (efi_app) has been a handy tool, but with one noticeable difference between architectures: x86 could show things on the screen, while ARM was stuck in the dark. If you wanted a splash screen or a graphical boot menu in your ARM EFI app, you were out of luck. […]
Continuous Integration (CI) is the backbone of a large project like U-Boot, ensuring that every change is tested against a huge matrix of boards and configurations. While this comprehensive testing is vital for quality, it can also be time-consuming. When you’re focused on a specific feature, waiting for a full “world build” to complete can […]
The Flattened Image Tree (FIT) is at the heart of modern U-Boot booting, providing a flexible and verifiable way to package kernels, ramdisks, and devicetrees. A new series introduces a significant enhancement to how U-Boot processes FITs, enabling a powerful two-stage boot process. This allows a “load-only” FIT to configure the system (like setting up […]
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 […]
In the world of embedded systems, a Flattened Image Tree (FIT) is the standard way to package a bootable OS, typically bundling the kernel, a ramdisk, and the necessary devicetree (FDT) into a single, verifiable file. While convenient, this approach tightly couples the OS with its hardware description. But what if the OS and the […]
We’re excited to announce a significant new feature in U-Boot: a virtio-scsi driver. While U-Boot has long supported virtio-blk for block device access in virtualized environments, virtio-scsi offers greater flexibility, allowing a single virtio device to host multiple disks (LUNs) and supporting features like hotplug. This comprehensive 27-patch series, does more than just add a […]
The U-Boot boot process relies heavily on the Flattened Image Tree (FIT) format to package kernels, ramdisks, device trees, and other components. At the heart of this lies the fit_image_load() function, which is responsible for parsing the FIT, selecting the right images, and loading them into memory. Over the years, as more features like the […]
The integration of pytest with real boards (test.py) was written by Stephen Warren of Nvidia, some 9 years ago. It has certainly stood the test of time. The original code has been tweaked for various purposes over the years, but considering the number of tests added in that time, the changes are very small. Here […]
U-Boot has a new continuous integration (CI) lab page that provides a real-time look at the status of various development boards. The page, located at https://lab.u-boot.org/, offers a simple and clean interface that allows developers and curious people to quickly check on the health and activity of each board in the lab. When you first […]
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: 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 […]
The Flattened Image Tree (FIT) is at the heart of modern U-Boot booting, providing a flexible and verifiable way to package kernels, ramdisks, and devicetrees. A new series introduces a significant enhancement to how U-Boot processes FITs, enabling a powerful two-stage boot process. This allows a “load-only” FIT to configure the system (like setting up a devicetree) before a second FIT loads the operating system. This capability unlocks more flexible and dynamic boot scenarios, especially for systems where the hardware configuration (devicetree) and the OS have different update cadences or sources. The Concept: Load-Only and Restartable Booting The core of this feature revolves around two new concepts: When combined, these features allow for a sequence like this: Key Changes in the Series Bringing this feature to life required a fair amount of refactoring: This series significantly enhances the flexibility of U-Boot’s FIT handling, paving the way for more sophisticated and […]
Continuous Integration (CI) is the backbone of a large project like U-Boot, ensuring that every change is tested against a huge matrix of boards and configurations. While this comprehensive testing is vital for quality, it can also be time-consuming. When you’re focused on a specific feature, waiting for a full “world build” to complete can slow down your development cycle. A little series of patches introduces several improvements to U-Boot’s GitLab CI, giving developers powerful new tools to get faster, more targeted feedback. ## A New Toolbox for CI Control This series is all about empowering developers to tailor CI runs to their specific needs. Instead of a one-size-fits-all pipeline, you can now easily select which parts you want to run. Stage-Level Control You can now disable entire stages of the CI pipeline using simple variables. If your changes don’t affect the world build, you can just turn it off […]
For a while now, U-Boot’s EFI application (efi_app) has been a handy tool, but with one noticeable difference between architectures: x86 could show things on the screen, while ARM was stuck in the dark. If you wanted a splash screen or a graphical boot menu in your ARM EFI app, you were out of luck. Well, not anymore! A new patch series in Concept closes this gap, bringing full video output capabilities to the ARM EFI application. Let’s dive into how it works. The Challenge: Drawing Pixels on ARM The main hurdle for ARM video support within an EFI environment, especially in virtualized setups, is how graphics are handled. Many ARM systems, like QEMU configured with virtio-gpu, don’t provide a simple, direct-access framebuffer to which you can just write the pixel data. Instead, they rely on the EFI Graphics Output Protocol (GOP) and specifically its Bit Block Transfer function, more […]
We’ve just merged a fix in Concept for a particularly tricky memory corruption bug in the U-Boot sandbox environment. This bug was difficult to track down, so we wanted to share the story of the investigation and the solution. The Symptom: Mysterious Heap Corruption The problem first appeared as random and hard-to-reproduce memory corruption in the malloc() heap. These are often the most frustrating bugs to solve, as the place where the program crashes is rarely the place where the error actually occurred. After many hours of debugging, the root cause was finally identified, and it was quite unexpected. The Culprit: A Memory Map Collision 💥 It turns out that the PCI Enhanced Allocation (EA) driver, a feature used for testing within sandbox, was mapping its simulated device memory at the 1MB physical address. This might seem harmless, but there’s a problem. When using the vbe_abrec_os boot method in sandbox, […]
