U-Boot Blog

Stay updated with the latest U-Boot development news, features, tutorials, and community highlights.

Fixing a Devious Memory Corruption Bug in Sandbox
26Aug

Fixing a Devious Memory Corruption Bug in Sandbox

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 […]

Seeing is Believing: Video Support Lands for the ARM EFI App! 🎨
22Aug

Seeing is Believing: Video Support Lands for the ARM EFI App! 🎨

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. […]

Making CI Work for You: New Controls for U-Boot’s GitLab Pipeline
19Aug

Making CI Work for You: New Controls for U-Boot’s GitLab Pipeline

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 […]

Supercharging FITs: U-Boot’s New Two-Stage Boot Capability
15Aug

Supercharging FITs: U-Boot’s New Two-Stage Boot Capability

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 […]

Taming Build Complexity: Introducing Config Fragments in Buildman
12Aug

Taming Build Complexity: Introducing Config Fragments in Buildman

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 […]

New VBE Boot Method: Decoupling Your OS and Devicetrees
08Aug

New VBE Boot Method: Decoupling Your OS and Devicetrees

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 […]

Virtio-SCSI Arrives, Backed by a Major SCSI Overhaul
05Aug

Virtio-SCSI Arrives, Backed by a Major SCSI Overhaul

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 […]

Giving FIT-loading a Much-Needed Tune-Up
01Aug

Giving FIT-loading a Much-Needed Tune-Up

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 pytest / board Integration
29Jul

The pytest / board Integration

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 […]

New U-Boot CI Lab Page
25Jul

New U-Boot CI Lab Page

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 […]

Booting Up the U-Boot Blog!

Welcome to the new official blog for Das U-Boot! For over two decades, the U-Boot mailing list has been the vibrant hub of our development discussions. While the mailing list remains our primary channel for patches and technical conversations, this blog will serve as a new platform to share deeper insights, project news, and community stories in a more accessible format. As of mid-2025, U-Boot is more critical to the embedded ecosystem than ever. Our development is thriving, with robust support spanning a vast array of architectures from ARM and x86 to the rapidly expanding world of RISC-V. U-Boot provides a flexible, powerful foundation for countless products in the industrial, automotive and consumer-electronics spaces, incorporating modern standards like FIT, EFI and Firmware Handoff to meet today’s demanding security and interoperability requirements. This blog is a community platform, and we need your voice to make it a success. We invite developers, […]

...

Booting into Linux in 100ms

A few weeks ago I took a look at Qboot, a minimal x86 firmware for QEMU which can boot in milliseconds. Qboot was written by Paolo Bonzini and dates from 2015 and there is an LWN article with the original announcement. I tried it on my machine and it booted in QEMU (with kvm) in about 20ms, from entering Qboot to entering Linux. Very impressive! I was intrigued as to what makes it so fast. There is another repo, qemu-boot-time by Stefan Garzarella, which provides an easy means to benchmark the boot. It uses perf events in Linux to detect the start and end of Qboot. Using x86 post codes, I added the same to U-Boot. Initially the boot time was 2.9 seconds! Terrible. Here is a script which works on my machine and measures the time taken for U-Boot boot, using the qemu-x86_64 target: It turned out that almost […]

...

Verified Boot for Embedded on RK3399

VBE has been a long-running project to create a smaller and faster alternative to EFI. It was originally introduced as a concept in 2022, along with a sandbox implementation and a simple firmware updater for fwupd. In the intervening period an enormous about of effort has gone into getting this landed in U-Boot for a real board. This has resulted in 10 additional series, on top of the sandbox work: A – Various MMC and SPL tweaks (14 patches, series) B – binman: Enhance FIT support for firmware (20 patches, series) C – binman: More patches to support VBE (15 patches, series) D – A collection of minor tweaks in MMC and elsewhere (18 patches, series) E – SPL improvements and other tweaks (19 patches, series) F – VBE implementation itself, with SPL ‘relocating jump’ (22 patches, series) G – VBE ‘ABrec’ implementation in TPL/SPL/VPL (19 patches, series) H – […]

...

Filesystems in U-Boot

U-Boot supports a fairly wide variety of filesystems, including ext4, ubifs, fat, exfat, zfs, btrfs. These are an important part of bootloader functionality, since reading files from bare partitions or disk offsets is neither scalable nor convenient. The filesystem API is functional but could use an overhaul. The main interface is in fs/fs.c, which looks like this: At first glance this seems like a reasonable API. But where is the filesystem specified? The API seems to assume that this is already present somehow. In fact there is a pair of separate functions responsible for selecting which filesystem the API acts on: When you want to access a file, call either of these functions. It sets three ‘global’ variables, fs_dev_desc, fs_dev_part and fs_type . After each operation, a call to fs_close() resets things. This means you must select the block device before each operation. For example, see this code in bootmeth-uclass.c: […]

...

Streamlining Emulation in U-Boot: A Kconfig Cleanup 🧹

In the world of software development, consistency is key. A recent update to U-Boot Concept takes a solid step in that direction by restructuring how it handles emulation targets. This change makes life easier for developers working across different processor architectures. Previously there were inconsistencies in the configuration system (Kconfig). For example, enabling QEMU emulation for ARM systems used the ARCH_QEMU symbol, while x86 systems used VENDOR_EMULATION for a similar purpose. This could create confusion and added complexity when managing board configurations. To resolve this, a new, architecture-neutral symbol, MACH_QEMU, has been introduced. This single, unified option replaces the separate symbols for both ARM and x86 emulation targets. This small but important merge tidies up the codebase, creating a more consistent and intuitive developer experience. It also sets the stage for future work, with the potential to extend this unified approach to other architectures. It’s a great example of the […]

...