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 – xPL-stack cleanup (4 patches, series)
• I – Convert rockchip to use Binman templates (7 patches, series), kindly taken over and landed by Jonas Karlman
• J – Implementation for RK3399 (25 patches, series)

That’s a total of 163 patches!

The Firefly RK3399 board was chosen, since it has (just) enough SRAM and is fully open source.

The final series has not yet landed in the main tree and it is unclear whether it will. For now I have put it in the Concept tree. You can see a video of it booting below:

I have been thinking about why this took so long to (almost) land. Here is my list, roughly in order from most important to least:

1. Each series had to land before the next could be sent, with it taking at least one release cycle (3 months) to land each one
2. Some of the new features were difficult to implement, particularly the relocating SPL jump and the new Binman features
3. Many of the patches seemed aimless or irrelevant when sent, since they had no useful purpose before VBE could fully land. This created resistance in review
4. On the other hand, sending too many patches at once would cause people to ignore the series

Overall it was a very difficult process, even for someone who knows U-Boot well. It concerns me that it has become considerably harder to introduce major new things in U-Boot, compared to the days of sandbox or driver model. I don’t have much of a comparison with other firmware projects, but I’m interested in hearing other people’s point of view. Please add a comment if you have thoughts on this.

Anyway, I am pleased to be done with it. The only thing missing at present is ‘ABrec’ updates in fwupd. It should be fairly easy to do, but for the signature checking. Since fwupd has its own implementation of libfdt, that might be non-trivial.

More information on VBE:

• Embedded World 2022 program and slides (presented by Alex Graf)
• fwupd plugin
• osfc’22 talk (external link)
• U-Boot documentation

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 two of the seconds were the U-Boot boot delay. Another 800ms was the PXE menu delay. With those removed the time dropped to 210ms, which is not bad.

Using CONFIG_NO_NET dropping CONFIG_VIDEO each shaved off about 50ms. I then tried passing the kernel and initrd through QEMU using the QFW interface. It only saved 15ms but it is something.

I figured that command-line processing would be quite slow. With CONFIG_CMDLINE disabled another 5ms was saved. A final 7ms came from disabling filesystems and EFI loader. Small gains.

In the end, my result is about 83ms (in bold below):

$ ./contrib/qemu-boot-timer.sh
starting perf
building U-Boot
running U-Boot in QEMU
waiting for a bit
qemu-system-x86_64: terminating on signal 15 from pid 2775874 (bash)
parsing perf results
1) pid 2779434
qemu_init_end: 51.924873
u_boot_start: 51.962744 (+0.037871)
u_boot_do_boot: 134.781048 (+82.818304)

One final note: the qemu-x86_64 target actually boots by starting SPL in 16-bit mode and then moving to 64-bit mode to start U-Boot proper. This was partly to avoid calling 16-bit video ROMs from 64-bit code. Now that bochs is used for the display, it should be easy enough to drop SPL for this target. I’m not sure how much time that would save.

Note: Some final hacks are tagged here.

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, maintainers, and users to contribute posts. Have you recently ported U-Boot to a novel board? Do you have a technical deep-dive on a specific subsystem you’d like to share? Or perhaps a case study on how U-Boot solved a unique challenge in your project?

If you have an idea for a post, please email the admin to get a login for this site. We’re excited to build this resource with you.

Happy hacking!