The effort to modernise U-Boot’s filesystem support continues with a major update to ext4l—the new ext4 driver ported directly from Linux. A recent series series of 30 patches that brings full write capabilities to the driver.

So far ext4l has only supported reading. With this series, the driver now supports the full lifecycle of file management, including file creation, modification, and deletion, all while using the journal for crash-safety.

What’s New?

The new series adds support for the following operations:

• File Write: You can now write files using the journal for data integrity.
• Deletion: Support for unlink to remove files.
• Directories: Implementation of mkdir to create new directories.
• Symbolic Links: Support for ln to create symlinks.
• Renaming: Full support for renaming and moving files and directories.

Additionally, unlike the legacy ext4 driver, ext4l supports metadata_csum checksums, allowing U-Boot to interact with modern ext4 partitions without disabling features.

Adapting Linux Code for a Bootloader

Porting filesystem code from Linux to U-Boot presents unique challenges regarding resource management.

In the Linux kernel, the filesystem driver doesn’t need to meticulously free every single resource the moment a filesystem is unmounted; it can rely on the kernel’s broader memory management to clean up caches or reuse structures later.

U-Boot, however, operates differently. The bootloader might mount and unmount filesystems multiple times during a single session—for example, when running an extensive test suite or loading kernels and device trees from different partitions. If resources aren’t freed explicitly, memory leaks accumulate, eventually causing allocation failures.

To address this, this series includes significant infrastructure improvements that go beyond the Linux upstream code:

• Aggressive Cleanup: We implemented thorough cleanup of journal references and buffer heads upon unmount to prevent memory leaks.
• Safety Guards: Added safeguards to handle probe calls without explicit close calls from previous sessions.
• Use-After-Free Prevention: Logic was added to prevent freeing buffer heads that still have active journal heads attached.

Testing and Next Steps

This series enables ext4l for sandbox testing, allowing us to validate these features rapidly without hardware. It also includes tweaks to the video console (a new --quiet_vidconsole flag) to speed up verbose test outputs.

While ext4l is now functional and usable for read/write operations, there is still work to be done before it could perhaps replace the existing ‘ext4’ driver: enabling the driver for ARM and x86 targets, fine-tuning Kconfig options to optimise code size, and expanding the documentation.

But for now, this is a significant step toward having a robust, modern, and maintainable ext4 implementation in U-Boot!

Note: This work was brought to you with the assistance of Claude and the city of Wuhan, China.

Developing for U-Boot often involves juggling a variety of tools: buildman for compilation, patman for patch submission, test.py for integration testing, and git for version control. While these tools are powerful individually, orchestrating them—especially when dealing with complex CI pipelines and dependencies—can be tedious.

To bridge these gaps, we are introducing uman (U-Boot Manager), a new command-line tool headed for Concept, designed to streamline the daily workflow of U-Boot developers.

uman unifies build, test, and CI interaction into a single interface, handling the “glue” logic that developers usually script themselves.

1. Taming the CI Pipeline

One of the biggest friction points in development is pushing to GitLab CI. Often, you only need to run a specific set of tests, but the default pipeline runs everything. uman ci gives you fine-grained control over what runs via git push options, without needing to manually edit YAML files.

# Push to CI, but ONLY run the pytest suite (skip world build)
uman ci -p

# Push to CI, but only run tests for the 'sandbox' board
uman ci -p sandbox

# Push and automatically create (or update) a Merge Request
uman ci -m

2. Simplified Local Testing

Running U-Boot’s pytest framework locally requires setting up environment variables, finding the correct build directory, and passing specific flags. uman py automates this. It detects your source tree, sets up paths for hooks, and handles board configuration.

# Run pytests for sandbox (automatically builds u-boot first)
uman py -b sandbox

# Run a specific test, keeping artifacts for inspection
uman py -b sandbox test_vbe -P

For developers working on C-based unit tests, uman introduces a C-Test Direct Runner (-C). If you have already set up the test environment (using -S -P), you can iterate rapidly on the C code without reloading the Python test harness every time:

# Fast iteration on a C test
uman py -C fs_test_ext4l_probe

3. Dependency Management

Testing often requires external firmware blobs (OpenSBI, TF-A, QEMU). Previously, developers had to manually hunt these down. uman setup automates fetching and building these dependencies.

# Download and install QEMU, OpenSBI, and toolchains needed for testing
$ uman setup
Setting up qemu...
All QEMU packages are installed
Setting up opensbi...
Downloading OpenSBI v1.3.1...
OpenSBI rv64: /home/sglass/dev/blobs/opensbi/fw_dynamic.bin
OpenSBI rv32: /home/sglass/dev/blobs/opensbi/fw_dynamic_rv32.bin
Setting up tfa...
Cloning TF-A...
Cloning into '/home/sglass/dev/blobs/tfa/src'...
remote: Counting objects: 6639, done
remote: Finding sources: 100% (6639/6639)
remote: Total 6639 (delta 686), reused 4523 (delta 686)
Receiving objects: 100% (6639/6639), 12.94 MiB | 10.11 MiB/s, done.
Resolving deltas: 100% (686/686), done.
Building TF-A for QEMU SBSA...
TF-A bl1: /home/sglass/dev/blobs/tfa/bl1.bin
TF-A fip: /home/sglass/dev/blobs/tfa/fip.bin
Setting up xtensa...
Downloading Xtensa dc233c toolchain...
Xtensa already configured in ~/.buildman
Xtensa toolchain: /home/sglass/dev/blobs/xtensa/2020.07/xtensa-dc233c-elf
Setup complete

4. Build Management

While buildman is excellent, uman build provides a quick wrapper for common development tasks, such as forcing a fresh build, enabling Link Time Optimization (LTO), or inspecting binary sizes immediately after a build.

# Build sandbox and show the size of the resulting binaries
uman build sandbox --size

# Build with disassembly output for debugging
uman build sandbox -O

Configuration

uman is designed to work out of the box, but it is also configurable via ~/.uman, allowing you to define persistent paths for builds, firmware blobs, and test hooks.

This tool aims to reduce the “context switching” overhead in U-Boot development, letting you focus more on the code and less on the tooling parameters.

Future

uman takes advantage of some of the newer features in Concept but it is compatible with the main tree also.

uman development is in its early stages and will expand over time. For now it is in a separate github repo. If you try it out, please send some feedback on the mailing list. For now, PRs are welcome!

Testing is the backbone of U-Boot development, but as the test suite grows, so does the friction involved in running it. Whether it is the time it takes to regenerate disk images or the difficulty of parsing test output in CI, there is always room for improvement.

A recent series of 9 patches in Concept smooths out several rough edges in the unit-test (ut) infrastructure. These changes focus on speed, directory cleanliness, and better automation support.

Faster Iteration with Persistence

One of the biggest time-sinks when iterating on C-based filesystem / boot tests is the Python-fixture setup. Every time you ran a test, the system generates fresh disk images, which is slow and repetitive if the images haven’t actually changed.

A new --persist (or -P) flag is now available in the Python-test runner. This tells the system to keep test artefacts—like disk images—after the run completes. Combined with updates to the test drivers, you can now re-run specific C tests immediately without waiting for the Python layer to regenerate the world.

A Cleaner Source Tree

Historically, tests tended to dump their temporary disk images (mmc1.img, spi.bin, etc.) directly into the source tree. This cluttered the workspace and requires a git-ignore rule to avoid making git status noisy.

This series moves all test-generated disk images to the persistent-data directory, i.e. inside the build directory. This keeps your source tree clean and groups all transient test-data in one predictable location.

Parallel Execution Support

Running the full unit test suite on a single core takes a while. Just the driver model tests alone (ut dm) take 13 seconds even on a fast machine. As a step towards improving this, we added support for parallel execution to the ut command.

You can now use the -P <n>:<w> flag to shard tests across multiple sandbox instances. For example, if you want to split the work across 4 workers, you can launch 4 separate sandbox processes:

./u-boot -T -c "ut -P4:0 dm"  # Worker 0
./u-boot -T -c "ut -P4:1 dm"  # Worker 1
...

The tests are distributed by index, ensuring a disjoint subset for each worker.

Automation and CLI Improvements

Several changes are included to make the ut command friendlier for both humans and machines:

• Machine-Readable Output: A new -E flag emits explicit Result: PASS: ... or Result: FAIL: ... lines after each test. This eliminates the need for fragile regex parsing in CI scripts to determine exactly which test failed.
• Combined Flags: You can finally combine single-character flags. Instead of typing ut -f -m -E, you can now simply run ut -fmE.
• Manual Test Alias: The -m flag was added as an alias for -f (force), making it more intuitive to run “manual” tests.

These improvements should make the testing experience faster and less intrusive for everyday development.

What’s next?

A new tool is in the works to help productivity when running tests. Watch this space!

In the world of bootloaders, balance is everything. We need enough functionality to load an OS, but we must keep the footprint small and the code maintainable. For years, U-Boot has relied on a custom implementation of the EXT4 filesystem. However, as the EXT4 format evolves with features like metadata checksums and fast commits, keeping a custom implementation in sync with the Linux kernel becomes a monumental task.

Today, we are excited to share a major milestone in U-Boot’s filesystem support: the introduction of ext4l.

What is ext4l?

The ext4l driver (the ‘l’ stands for Linux) is a direct port of the Linux kernel’s EXT4 driver (from v6.18) into U-Boot. Instead of rewriting the logic, we have imported the actual kernel source files—including super.c, inode.c, mballoc.c, and the jbd2 journaling layer—and provided a thin compatibility shim to make them “feel at home” in U-Boot.

Why This Approach?

1. Feature Parity: By using the real kernel code, we gain immediate support for modern EXT4 features like extents, flex_bg, and CRC32C metadata verification.
2. Maintainability: When the Linux kernel community fixes a bug or adds an optimization, we can pull those changes into U-Boot with minimal friction.
3. Reliability: We are leveraging code that has been battle-tested on millions of production servers and devices.

The Engineering Journey: Stubs and Shims

Porting kernel code to a bootloader is no small feat. The Linux kernel assumes a rich environment of threads, complex memory management, and a full VFS (Virtual File System) layer. U-Boot, by comparison, is largely single-threaded and simplified.

To bridge this gap, we developed a sophisticated compatibility layer:

• ext4_uboot.h & stub.c: These files provide the “glue.” They map kernel structures like struct super_block and struct inode to U-Boot’s block I/O layer.
• Dummy Shrinkers & Mutexes: Since U-Boot doesn’t have the same memory pressure or concurrency requirements, we implemented “no-op” or dummy versions of kernel infrastructure like the memory shrinker and various locking primitives.
• Buffer Cache: We added a buffer_head I/O infrastructure to support caching, which significantly improves read performance during the boot process.

Key Milestones in the Patch Series

The journey to a successful mount was achieved through a systematic build-up of the filesystem stack:

Current Status

As of the latest commits, ext4l is capable of:

• Mounting EXT4 filesystems in read-only mode.
• Verifying metadata via CRC32C.
• Using the extent status cache for efficient file lookups.
• Toggling debug output via CONFIG_EXT4L_DEBUG.

While the long-term goal is to support write operations (the mballoc and transaction code is already building), we are prioritizing rock-solid read support for the current release.

How to Try It

You can enable the new driver in your board configuration by selecting:

CONFIG_FS_EXT4L=y

This will replace the legacy EXT4 implementation with the Linux-ported version. We encourage developers to test this on various hardware and provide feedback on the mailing list.

A special thanks to Claude Opus 4.5 for co-developing these patches and assisting with the extensive stubbing required to bring this to life.

A new series just landed, focussed on making one part of U-Boot’s new graphical menus (Expo) considerably better with non-popup menus.

A long-standing and annoying limitation in expo is that couldn’t really type into text fields (like for passwords) if the menu wasn’t a pop-up (i.e. as used by the ‘cedit’ configuration editor). Now, with this work, you can actually use your keyboard!

The Highlights

1. The Series Enables Input! ⌨️

• When a text box is highlighted, key presses are correctly routed to the textline object. This is important for things like password or configuration fields embedded in a menu.
• No More Ghost Text: The series fixes a bug where the displayed text wouldn’t update visually because the text object was pointing at a static empty string instead of the textline’s live buffer. That’s squashed now—what gets typed is what shows up!

2. A Crazy Key Conflict is Resolved 🤯

• It turns out, pressing Up Arrow and hitting the Backspace/Delete Character shortcut (Ctrl-B) were sending the exact same signal to U-Boot. Messy!
• The Fix: This series moves the menu navigation keys to a different number range (0x100). Now, the system knows the difference between “move up” and “delete a character,” so everything works as it should!

3. Debugging is Easier Now (For the Devs) 🔍

• No More Silent-Mode Hassle: The series adds a new test flag (UTF_NO_SILENT) for tests that need the console to be active. This is vital for text-entry tests, as console rendering must be on for the textline state to update correctly.
• Better Names: The series makes the names of all the menu objects clearer (e.g., item0.label instead of a generic label). This hierarchical naming significantly simplifies tracing objects during debugging, particularly when dumping the expo.
• More Docs: New documentation covers how to write tests and debug the Expo system, including which command-line flags to use for watching the video frames in Sandbox.
• Hex Dumping: The series fixes a typo to enable the cedit dump command and switches its output to the standard U-Boot hexadecimal format.

Bottom line: The series makes Expo more flexible, ensures textlines work everywhere, and improves the code base for easier debugging and maintenance.

Expo is U-Boot’s forms and UI subsystem. It supports text, images and menus and a large expo can contain quite a bit of information. How do you debug and understand that? Tracing through large, linked data structures is not fun.

U-Boot Concept now has an expo_dump() function, designed to be called from your code when you are trying to figure out what is happening. It writes a dump of the expo to an abuf, something like the following:

Expo: name 'my menus'
  display lcd
  cons lcd.vidconsole_tt
  mouse (none)
  scene_id 0
  next_id 46
  req_width 0
  req_height 0
  text_mode 0
  popup 0
  show_highlight 0
  mouse_enabled 0
  mouse_ptr 0000000000000000
  mouse_size 0x0
  mouse_pos (0,0)
  damage (0,0)-(0,0)
  done 0
  save 0
  last_key_ms 4526828813
  video: 1366x768 white_on_black 0
  Theme:
    font_size 0
    white_on_black 0
    menu_inset 0
    menuitem_gap_y 0

Scenes:
  Scene 7: name 'main'
    title_id 0 ((none))
    highlight_id 0 ((none))
    Object 9 (logo): type image
      flags dirty
      bbox: (50,20)-(210,180)
      dims: 160x160
      Image: data ff000000
    Object 10 (text): type text
      flags dirty
      bbox: (400,100)-(526,140)
      dims: 126x40
      Text: str_id 20 font_name 'cantoraone_regular' font_size 40
        str 'my string'
    Object 11 (text): type text
      flags dirty
      bbox: (200,600)-(496,660)
      dims: 296x60
      Text: str_id 21 font_name 'nimbus_sans_l_regular' font_size 60
        str 'another string'
    Object 12 (text): type text
      flags size_valid, dirty
      bbox: (500,200)-(1000,350)
      dims: 477x240
      Text: str_id 22 font_name 'nimbus_sans_l_regular' font_size 60
        str 'this is yet
another string, with word-wrap and it goes on for quite a while'
    Object 13 (main): type menu
      flags size_valid, dirty
      bbox: (50,400)-(210,560)
      dims: 160x160
      Menu: pointer_id 45 title_id 14 manual 0
        Item 35: name 'item1' label_id 36 desc_id 37
        Item 40: name 'item2' label_id 41 desc_id 42
    Object 14 (title): type text
      flags dirty
      bbox: (50,400)-(122,418)
      dims: 72x18
      Text: str_id 24 font_name '(default)' font_size 0
        str 'Main Menu'
    Object 45 (cur_item): type text
      flags dirty
      bbox: (147,436)-(156,454)
      dims: 9x18
      Text: str_id 25 font_name '(default)' font_size 0
        str '>'
    Object 36 (label1): type text
      flags dirty
      bbox: (50,436)-(79,454)
      dims: 28x18
      Text: str_id 26 font_name '(default)' font_size 0
        str 'Play'
    Object 37 (item1-txt): type text
      flags dirty
      bbox: (227,436)-(316,454)
      dims: 89x18
      Text: str_id 27 font_name '(default)' font_size 0
        str 'Lord Melchett'
    Object 38 (item1-key): type text
      flags dirty
      bbox: (177,436)-(186,454)
      dims: 9x18
      Text: str_id 28 font_name '(default)' font_size 0
        str '1'
    Object 41 (label2): type text
      flags dirty
      bbox: (50,454)-(79,472)
      dims: 29x18
      Text: str_id 30 font_name '(default)' font_size 0
        str 'Now'
    Object 42 (item2-txt): type text
      flags dirty
      bbox: (227,454)-(316,472)
      dims: 70x18
      Text: str_id 31 font_name '(default)' font_size 0
        str 'Lord Percy'
    Object 43 (item2-key): type text
      flags dirty
      bbox: (177,454)-(186,472)
      dims: 9x18
      Text: str_id 32 font_name '(default)' font_size 0
        str '2'
    Object 15 (box): type box
      flags size_valid, dirty
      bbox: (500,200)-(1000,350)
      dims: 160x0
      Box: fill 0 width 3
    Object 16 (box2): type box
      flags 
      bbox: (0,0)-(0,0)
      dims: 160x0
      Box: fill 0 width 1
    Object 17 (editor): type textedit
      flags size_valid, dirty
      bbox: (100,200)-(400,650)
      dims: 289x54
      Textedit: str_id 23 font_name '(default)' font_size 0
    Object 18 (overlap): type text
      flags dirty
      bbox: (405,105)-(480,123)
      dims: 75x18
      Text: str_id 34 font_name '(default)' font_size 0
        str 'overlap text'

To print it, use puts() which has no line limits and will just dump the entire block to the console.

One nice thing about this dump is that you can compare it with a desired expo state.

What’s next? It would be nice to be able to move the mouse around and get information about the objects underneath the mouse. Another useful feature would be to write the dump to a file.

For now, it’s a start. Give it a try!

Testing boot scenarios in very important but there are quite a lot of them! Concept currently has about 13 images containing various partitions and files used by the bootstd tests. These are listed in test.dts, for example:

	aliases {
...
		mmc7 = "/mmc7";
		mmc8 = "/mmc8";
...
	};

	/* This is used for Android boot image v4 tests */
	mmc7 {
		status = "disabled";
		compatible = "sandbox,mmc";
		filename = "mmc7.img";
	};

	/* This is used for Android boot image v2 tests. */
	mmc8 {
		status = "disabled";
		compatible = "sandbox,mmc";
		filename = "mmc8.img";
	};

All images are built by test_ut_dm_init_bootstd(), but most of these are disabled by default, to avoid making sandbox unwieldy and confusing. It also means that a test only has to worry about its particular disk image (plus a few common ones) and doesn’t have to be be updated every time a new test case is added in the code base.

But sometimes it is useful to enable a particular image. Tests do this individually, by enabling a devicetree node and then binding a device to it. But there is no way to do this from the command line. The only way is to edit test.dts to remove the status = "disabled" line for a node.

Until now. A very simple addition to sandbox allows an image to be enabled from the command line: the sb devon command. Simply specify the device name (e.g. mmc11) and it will set up a device. From then on the device appears as normal, so it can be used with the bootflow command, ls, etc.

When you have finished with the device sb devoff disables it again, putting things back to normal. Here is an example:

=> mmc list
mmc2: 2 (SD)
mmc1: 1 (SD)
mmc0: 0 (SD)
=> ls mmc b:1
** Bad device specification mmc b **
Couldn't find partition mmc b:1
=>
=> sb devon mmc11
Device 'mmc11' enabled
=> mmc list
mmc2: 2 (SD)
mmc1: 1 (SD)
mmc0: 0 (SD)
mmc11: 11 (SD)
=> ls mmc b:1    
            extlinux/
        7   initrd.img-6.8.0-53-generic
     1620   vmlinuz-6.8.0-53-generic

2 file(s), 1 dir(s)

=> sb devoff mmc11
Device 'mmc11' disabled
=> mmc list       
mmc2: 2 (SD)
mmc1: 1 (SD)
mmc0: 0 (SD)
=> 

Give it a try!

U-Boot’s ‘expo’ toolkit is used for creating user interfaces, such as the configuration editor (cedit) and graphical boot menus (bootflow menu). Previously, user interaction with expo scenes was limited to the keyboard.

A recent 23-patch series introduces support for mouse and touchpad interaction.

New Input Handling

For devices where a mouse or touchpad is available, keyboard-only navigation can be inefficient. This update is intended to improve user interaction, particularly within complex screens like the configuration editor.

The core of this update is a new expo_send_click() function, which is designed to work similarly to the existing expo_send_key() function for processing user input.

The expo framework separates the processing of an event (like a click or keypress) from the handling of the resulting action. This series maintains that design, which allows expo to be integrated into different event loops. If a mouse is detected, expo will enable it by default.

Implementation Details

To enable mouse clicks, the framework required a method to determine which UI element exists at a specific (x, y) coordinate. This was implemented in several stages:

1. Coordinate Checking: New functions, such as scene_menu_within() and scene_textline_within(), have been added. These check if a given coordinate is within the bounding box of a menu item or an editable text field.
2. Scene-Level Clicks: The logic was then extended to the scene level, allowing a click to be routed to the correct object within the current scene. This includes handling for popup menus.
3. Input Polling: The main expo_poll() function was updated to check for both keyboard and mouse events.

Additional Changes

The series also includes a few other updates:

• Filled Boxes: The video API now supports drawing filled rectangles in addition to outlines.
• New Fonts: The Ubuntu Light and Bold fonts have been added.
• Testing: New tests for the mouse functionality have been added, including helpers to simulate clicks and verify the resulting actions.

This series expands U-Boot’s user interface capabilities by adding a new method for user input.

The U-Boot EFI application is a powerful tool, allowing U-Boot to run on top of existing UEFI firmware. This is increasingly important as we see new platforms, especially in the ARM64 world, shipping with complex, ACPI-based firmware. A prime example is the recent wave of laptops powered by the Qualcomm X-Elite, which rely on this boot model.

However, booting a traditional, device-tree-based OS like ARM Linux from this environment presents a unique set of challenges. A recent comprehensive patch series lands with a host of fixes and new features designed to bridge the gap between the EFI world and the device tree world, dramatically improving the experience and reliability of the U-Boot EFI app.

Let’s dive into what’s new.

The Core Challenge: Memory Map Misalignment

When Linux boots using a device tree, it trusts the /reserved-memory nodes in the FDT to know which memory regions to avoid. But when running as an EFI application, the underlying UEFI firmware has its own, separate memory map with regions reserved for runtime services, ACPI data, and other critical functions.

If U-Boot doesn’t transfer this information into the device tree, Linux has no idea these regions are off-limits. It might try to use them, leading to mysterious crashes and instability.

The Solution: Automatic Memory Map Synchronization

Enter a new mechanism to synchronize these two views of memory. A new command, efi memsync, has been introduced.

This command:

1. Reads the memory map provided by the EFI boot services.
2. Parses the existing /reserved-memory nodes in U-Boot’s working device tree.
3. Compares the two, identifying any reserved regions from EFI that are missing in the device tree.
4. Automatically creates new no-map reserved-memory nodes in the device tree for these missing regions.

This process is now automatically run during the boot flow when using the EFI app, ensuring that the device tree passed to Linux is a complete and accurate representation of the hardware’s memory layout.

=> efi memsync -v
Comparing EFI memory-map with reserved-memory
EFI Memory Map Analysis:
ID   Type                  Start              End                In DT?
------------------------------------------------------------------------
0    EFI_RUNTIME_SERVICES_CODE 0x001f9ef000       0x001faef000       no -> adding
1    EFI_ACPI_RECLAIM_MEMORY   0x001fb6f000       0x001fb7f000       no -> adding
2    EFI_ACPI_MEMORY_NVS       0x001fb7f000       0x001fbff000       yes
Regions added: 2

New command: fdt reserved

To complement efi memsync, you can now easily inspect the result with the fdt reserved command. It provides a clean, readable list of all regions in the /reserved-memory node.

=> fdt reserved
ID   Name                 Start            Size
----------------------------------------------------------------
0    secmon@1f000000      0x1f000000         0x1000000
1    efi-runtime@1f9ef000 0x1f9ef000         0x100000

Stability and Polish

Beyond the major new features, this series includes critical fixes that make the EFI app more robust and stable:

• Correct Device Naming: A subtle bug was fixed where block devices were being named based on a temporary placeholder, leading to confusing device names. Names are now set correctly before the device is bound.
• ARM64 Exception Level Handling: The app now correctly avoids trying to change CPU exception levels, which it is not permitted to do, preventing crashes on ARM platforms.
• Graceful Exit: The app no longer tries to free its own memory right before exiting, which could cause a crash. It now relies on the underlying UEFI firmware to clean up resources.
• Simple Framebuffer: For a better user experience, the app now automatically adds a simple-framebuffer node to the device tree, ensuring Linux has an early graphics console.

Conclusion

This is a small step forward for U-Boot’s capabilities as an EFI application. These changes are already proving essential for bringing up Linux on platforms like the Qualcomm X-Elite, showcasing U-Boot’s adaptability and continued importance in a complex and evolving boot ecosystem.

If you are interested in watching the development of U-Boot Concept, consider joining the mailing list. You can do this in your web browser here, or send an email with ‘subscribe’ in the subject to concept-join@u-boot.org. If you are able to review patches or contribute your own, please do!

Also the patchwork server is up and running so future patches will be visible there. This also helps to collect reviews, etc.

You may also find it interesting to look at the merge requests.

Development goals

With U-Boot Concept, the goal is to continue the transformation of the code base so that it remains relevant in future, even if only as fodder for new developments. Keys goals remaining for 2025 are:

• Continue evolution of standard boot
• Get the EFI app fully functional on x86 and ARM
• Broaden the expo feature set a little, e.g. a text editor
• Keep up with the development of the Flat Image Tree (FIT) specification
• Create packages for QEMU and EFI (including versions more focussed on secure boot)
• Take a look at what it would take to support Rust code
• Build out the new filesystem and file uclasses (better Linux compatibility?)

Not all of these will get done, but we’ll see what happens!