RBoot 26.11 “Iodine” released! With full UEFI support.

Return to index

Article published by: GNU Leah Rowe™

Date of publication: 10 November 2026

• <<
• < Prev
• >>

This is the initial release. RBoot begins as a clean fork of Canoeboot, renamed by the author specifically to avoid confusion with another project; this is part of RBoot’s (formerly Canoeboot’s) proposal to join GNU as a member project. RBoot is a much funnier and simultaneously less offensive project name, named thus as a show of good faith. Same author: I, Leah Rowe. I start Canoeboot fresh under the new name, RBoot.

You can find today’s release in https://rsync.rboot.org/26.11/ or you can use one of the mirrors.

RBoot is free, libre boot firmware replacing proprietary BIOS/UEFI firmware on supported Intel/AMD and ARM64 hardware. It initialises the hardware inside your computer such as the CPU or memory controller, configuring the machine in such a way as to enable use of an operating system at boot. RBoot offers greater security and customisation compared to proprietary firmware; its goal, plainly, is to rid the world of proprietary software and to do that, we therefore try to provide firmware that is extremely easy for non-technical users to understand.

Today’s release changelog is relative to the Canoeboot 26.01 release, and based on the Canoeboot 26.11 changelog, including all revisions up to Canoeboot version 26.11rev12.

First thing’s first. (and yes, you read the previous paragraph correctly)

A strongly anti-AI policy was added to a new file: AGENTS.md in rbmk. This is the most important change in the release - NOTE: rbmk is short for RBoot MaKe. It is the name of RBoot’s build system, derived from the original CanoeBoot MaKe.

Now everything else|

ARM64 is U-Boot and most x86 Intel/AMD machines are EDK2 in this release. Both codebases are provided, for UEFI boot. The GRUB EFI compatibility module was removed.

I repeat, for those considering migrating to this new release:

WARNING: UEFI-only on most boards! The GRUB payload was entirely removed, as was MemTest86plus. SeaBIOS still used on a minority of legacy, 32-bit-only boards, but nearly all 64-bit-capable Intel/AMD boards use EDK2 exclusively. If you previously used SeaBIOS/GRUB payloads, please convert your OS install to UEFI (with EFI System Partition) before switching to RBoot. This is a complete, legacy-free fork of Canoeboot for the most part; extreme levels of modernisation, now and ongoing, are present in this project. This decision is permanent. GRUB presents too much of a maintenance liability due to all the bugs, mostly build system bugs, and buggy kernel too; it’s bad code.

The erstwhile Canoeboot 26.11 release provided GRUB EFI in flash for backward compatibility with older GRUB-payload setups, but it was concluded that many users might use this on new setups as well, which would have forced continued maintenance of GRUB, be it EFI or coreboot-based builds. It was decided thus that the band-aid would be ripped off one year early; removing GRUB was initially planned for late 2027. Nope. Now. The best time is always right now.

Not added in this release - yet.

It’s possible that we can have from Intel SandyBridge, IvyBridge all the way up to Haswell in a future release, as native raminit and video initialisation is available on these boards; the EC firmware could be built from source quite easily.

NOTE: The EDK2 payload was added in this release, for Intel/AMD boards in RBoot that are able to use it. Our very own free distribution of EDK2.

Please note: coreboot (upstream) has patches under review at the time of this release, freeing the Intel FSP on Intel Kabylake hardware. This means that a future release of RBoot will likely contain support for Kabylake Chromebooks as well.

E.g. KGPE-D16. We use the coreboot fork from 15h.org now, on AMD Fam15h mainboards. This uses AMD AGESA source code instead of Timothy’s custom init code. It has much more reliable raminit and CPU initialisation; more RAM also supported. Many bugs are fixed. IOMMU works, I also saw that they mentioned TPM is fixed in their version, now our version also.

Basically, these boards actually work for the first time. NOTE: SeaBIOS only, as the GRUB payload was removed in RBoot. It will also be removed in RBoot’s upstream.

RBoot now provides its own free distribution of EDK2, for UEFI boot on Intel/AMD 64-bit hardware.

The following boards now have an EDK2 UEFI payload available:

• dell_latitude_e4300_4mb
• dell_latitude_e5420_6mb
• dell_latitude_e5520_6mb
• dell_latitude_e5530_12mb
• dell_latitude_e6230_12mb
• dell_latitude_e6330_12mb
• dell_latitude_e6400_gpu_intel_4mb
• dell_latitude_e6430_12mb
• dell_latitude_e6530_12mb
• dell_latitude_e7240_12mb
• dell_optiplex_7010_sff_12mb
• dell_optiplex_780_mt_8mb
• dell_optiplex_780_mt_truncate_8mb
• dell_optiplex_780_usff_8mb
• dell_optiplex_780_usff_truncate_8mb
• dell_optiplex_9020_mt_12mb
• dell_optiplex_9020_sff_12mb
• dell_precision_t1650_12mb
• hp_elite_8300_cmt_16mb
• hp_elite_8300_usdt_16mb
• hp_pro_3500series_8mb
• lenovo_thinkpad_r400_16mb
• lenovo_thinkpad_r400_4mb
• lenovo_thinkpad_r400_8mb
• lenovo_thinkpad_r500_4mb
• lenovo_thinkpad_t400_16mb
• lenovo_thinkpad_t400_4mb
• lenovo_thinkpad_t400_8mb
• lenovo_thinkpad_t430_12mb
• lenovo_thinkpad_t440p_12mb
• lenovo_thinkpad_t500_16mb
• lenovo_thinkpad_t500_4mb
• lenovo_thinkpad_t500_8mb
• lenovo_thinkpad_t530_12mb
• lenovo_thinkpad_w500_16mb
• lenovo_thinkpad_w500_4mb
• lenovo_thinkpad_w500_8mb
• lenovo_thinkpad_w530_12mb
• lenovo_thinkpad_w541_12mb
• lenovo_thinkpad_x200_16mb
• lenovo_thinkpad_x200_4mb
• lenovo_thinkpad_x200_8mb
• lenovo_thinkpad_x230_12mb
• lenovo_thinkpad_x230t_12mb
• lenovo_thinkpad_x301_16mb
• lenovo_thinkpad_x301_4mb
• lenovo_thinkpad_x301_8mb
• hp_elite_8200_sff_8mb
• lenovo_thinkpad_t420_8mb
• lenovo_thinkpad_t420s_8mb
• lenovo_thinkpad_t520_8mb
• lenovo_thinkpad_x220_8mb

All other supported targets are either ARM64 and they use U-Boot, or they are other Intel/AMD, mostly 32-bit-only and using the SeaBIOS payload; the ASUS KGPE-D16 starts in text mode but is 64-bit, so it also uses SeaBIOS because the EDK2 payload requires a linear framebuffer at startup.

TODO: Perhaps strip out the UEFI shell for systems with 2MB flash. Then it will probably fit in 2MB.

EDK2 is Intel’s reference implementation of the UEFI specification, for booting. It’s typically used by vendors, in proprietary forks of Intel’s BSD-licensed code, but Intel’s reference code is Free Software. We use their reference code, and full source code is provided in this RBoot release. EDK is short for: EFI Development Kit.

More specifically:

We use a fork of Intel’s reference code, which specifically offers use of EDK2 as a generic coreboot payload. This is a complete, industry-standard UEFI implementation capable of booting any compliant operating system.

All. Nearly all boards use it in RBoot now, even older ones e.g. ThinkPad X200. Tested on all platforms. Older, 32-bit-only mainboards still use the setup from the previous release, while virtually all 64-bit-compatible hardware now use EDK2.

Modern computers and operating systems are all UEFI, and this new setup can boot basically all of it reliably. More testing will be required, but this is battle-tested code and it has been used extensively in coreboot by many users, for many years. RBoot finally has it as well.

This change alone is part of a much wider effort to modernise RBoot, and I’m only getting started. The next RBoot releases will draw heavily on this, as EDK2 is pretty much the expected payload on a lot of modern coreboot setups these days. Integration of EDK2 removes all limitations in RBoot, allowing us to support much newer hardware and it basically makes RBoot much easier to use; I expect RBoot to become much more popular and useful over time, as a result.

Please look first at extras for notes about use of the onboard GPU e.g. Intel GPU, offloading rendering to a graphics cards. In some cases, this can be used instead, avoiding the need to actually run an option ROM on your graphics card. RBoot generally recommends use of integrated graphics as free initialisation is provided by RBoot, but some users may wish to use graphics cards anyway. It is not the policy of RBoot to break the user’s machine, where it can avoid distributing blobs in the process, but please know for all certainty: graphics cards have option ROMs on them that software like SeaBIOS and EDK2 can scan and execute at boot time, to initialise a framebuffer for the card. This is then used by drivers in operating systems. The purpose of RBoot is to provide the user only free software, and only steer them towards it, but lots of people want to use graphics cards regardless, so RBoot makes a point of ensuring that these also work, while providing warnings such as these.

Finally, some notes about graphics cards that may be of interest to the more demanding users.

EDK2 alongside PCI-E relocatable BAR (rebar) means that you can now use modern graphics cards that require allocations above 4GB. Rebar is not enabled by default, but you can enable it in menuconfig (coreboot). Enabling it causes breakage of Intel GPU video output on libgfxinit in testing, and no fix was found yet, so rebar is disabled by default.

PCI-E Option ROMs are enabled by default where necessary, for EDK2 builds. This means you can use it on desktops with graphics cards. Tested on several desktops (Dell OptiPlex 9020 SFF and 5050 SFF).

On boards with only external GPU, rebar can be left enabled by default. On systems with functioning integrated graphics, accidental enablement of rebar can be remedied by inserting a graphics card; when the video output in the payload does become broken, the Linux-libre i915 video driver still initialises video framebuffer properly in KMS/DRM.

This will be added to general documentation, pending fixes upstream. Note that even with this issue, Linux-libre video output works fine. This will be corrected and rebar enabled by default, on a future RBoot release.

Nearly all major upstream revisions updated:

• Flashprog: updated to 24 September 2026 revision
• EDK2: imported version 26.09.2
• Coreboot (default tree): Updated to 8ce4c91c41da3f042979f92095149a85bc93227d commit ID as of 18 September 2026.
• Coreboot (fam15h): removed (4.11_branch tree) and replaced with:
• Coreboot (fam15h_15h): 57e26bdcd959808c0171164f3c6197d4a347c3b2 commit ID as of 27 May 2026. This is a heavily improved fork of coreboot from version 4.11_branch, for improved initialisation reliability on AMD FAM15H hardware e.g. ASUS KGPE-D16.
• SeaBIOS (coreboot payload): Updated to 81ec9ec0bcf45df11fb7f98339ec9036b546fca0 commit ID as of 28 July 2026.

The 4.11_branch tree of coreboot was removed, because we now use the 15h.org fork of coreboot on AMD Fam15h hardware. This is much improved, with proper AGESA-based initialisation which initialises CPUs and memory controller more reliably. More RAM is supported, and several features were fixed too e.g. IOMMU and TPM.

The use of multiple coreboot upstreams was enabled by a design improvement in rbmk that makes all projects multi-tree, just with some projects ony having one tree in use. We can have N number of upstreams per project now, enabling use of forks.

The coreboot update brings in GCC 15.2, MPC 1.4.1, Nasm 3.02, acpica 20251212 and binutils 2.46.1 on crossgcc.

No new hardware was added in this RBoot release, but a lot of interesting features have been added to pre-existing hardware that RBoot supports.

This is very much a features release. A lot of feature changes were made!

• EDK2 payload support on most Intel/AMD boards with at least 4MB flash. This allows to boot operating systems via the UEFI boot specification.
• iPXE boot method added via EDK2 payload (ESC menu) - only EDK2 (not available in the lone SeaBIOS payload on older boards).
• TPM enabled where available, on all targets that use EDK2.
• Added ./mk test command which aggressively builds everything, much more than even ./mk release - it intentionally disables use of caching, so that downloads are aggressively tested as well. Config-related commands are also tested. This is a brutal stress test command used to find build errors.
• Flashprog: always keep the flash IC hot during command loops, rather that doing it in a toggle. The --workaround-mx option is retained, but no longer does anything as its behaviour is always applied. This improves general reliability as a lot of users don’t know about this option anyway. More people can reliably flash their boards now.
• New mkhelper type added: preconfig. This lets you run custom logic prior to configuration on a given project that uses config files. It also works on noconfig projects. This is used for example on coreboot, to build utils.
• Removed used of ccache everywhere in the build system, as it was causing subtle build errors (and possibly code bugs) in several stress test scenarios. We’d rather wait a bit longer for a reliable build. CCache is really only meant for development, not production.
• Removed the -c and x (clean and xgcc-clean) flags in rbmk, as they are largely superfluous; rbmk already auto-cleans everything before build anyway, to remove all build artifacts, and aggressively caches builds out of tree based on config metadata, deleting and re-fetching sources from local cache as required. These options were useless.
• Properly skip builds if makefile checks fail; this allows single-tree projects to build, by preventing error-prone use of copy_elf where no files exist.
• mk: Removed GCC/GNAT version pairing as upstream (coreboot) now does this its its buildgcc script. It’s redundant in rbmk. The coreboot version is better because it simply errs and exits, instead of trying to continue; the latter is what we did, which might actually cause more bugs in some cases. Better to fail hard, than corrupt the build.

A lot of major design changes have been made!

• Short defconfigs now used on coreboot, instead of full configs. This allows for easier maintenance, and rbmk has been modified to accomodate them.
• New safety check: verify that a path prefix is set, when using it in logic. Otherwise, it’s possible that we might have directory escape bugs in rbmk. This is checked relentlessly, throughout the build system.
• No longer export XBMK_CACHE as it’s now hardcoded in config. The new handling is much stricter, and less likely to regress in future revision. This was done to reduce the possibility of a directory escape bug in rbmk.
• Always use --mirror git clones on include/env/get.sh. This makes cloning revisions more reliable on all projects, especially ones where we use revs inside branches other than main.
• When building EDK2, we use coreboot’s build system, but when doing it this way, custom_ prefix is not used in image file names. Proper edk2 prefix is used.
• get.sh: use -L in find command, because some projects now use symlinks to metadata from other projects to ensure rebuilds. For example, edk2 coreboot targets (dummy targets).
• Properly sort submodules by directory name, so that recursive submodules can be handled in projects. This is in the submodule handling on get.sh.
• get.sh: support arbitrary submodule config path, for projects that use multiple versions of a submodule. For instance, EDK2 uses multiple versions of brotli.
• Stronger use of make distclean on projects before building, made feasible due to RBoot’s aggressive out-of-tree caching of project builds based on metadata checks in rbmk.
• Allow noconfig=n on a project, which allows it to be multi-tree and use the same tree on different targets, even when build configs aren’t required; in some cases, configs are done exclusively in mkhelper settings. This is part of RBoot’s decision to make all projects multi-tree, alongside allowing use of N upstreams per project instead of just one upstream.
• Simplify release=n handling in rbmk; don’t execute mkhelpers. Skip source fetches if release=n, so that the corresponding source won’t be downloaded.
• init.sh: Portable date usage; git’s own date handling now used. We no longer rely on GNU-specific extensions to the date command, for git repository initialisation on release builds.
• Allow running mk from outside the main work directory. The build system now changes work directory accordingly.
• Enable 3-way-merge when running git am in get.sh - this enables easier updates on project revisions.

• Set me_state to Disabled by default, tree-wide in coreboot (default tree). We already set the HAP bit in IFD anyway, but this is an extra layer of disablement, to make sure that the Intel ME is deader than dead.
• Added ImageMagick to dependencies (needed for EDK2 boot logo).
• SMMSTORE enabled by default, on all targets that use EDK2 as a payload. This means that RBoot users can now enter a standard setup menu at boot time, configuring their machines (e.g. boot order) in a way that is both persistent and does not require re-building the firmware.
• Added 4MB and 8MB targets for KCMA-D8 and KGPE-D16 mainboards. This, along with use of the 15h.org fork of coreboot on these boards, for improved raminit and various bug fixes. It uses AMD AGESA source code instead of the custom source code written by Raptor Engineering. The modified AGESA code has better CPU and memory initialisation, supporting more hardware combinations and it supports higher amounts of RAM.
• 256KB SMM STORE used on all boards, though some may be able to use more. We do this for simplicity as most boards can only just about fit 256KB in them along with everything else. These EDK2 images are huge.

• Preventative build fixes: removed used of -Werror on all projects, where feasible.
• Fixed a hanging bug on ThinkPad X230 targets, caused by an optimisation - now reverted for this fix - that optimised the CAR setup in coreboot. This fix reverses coreboot revision 97dbfd3098ae12ef3f51e5f95cd6d66c25214205.
• Added fake menuconfig Make options to several projects, so that the related mk options don’t cause build errors (instead, a harmless no-op now occurs).
• Backported several build fixes to our early 2025 revision of U-Boot, so that it builds on modern distros e.g. latest Parabola updates. (needed so that GRU Kevin/Bob chromebooks can continue to build).
• Removed src/gpio-scripts due to unclear licensing on the version used. (no license given on the changes to it, forked to standalone from coreboot where it fell back to coreboot’s COPYING file, but the fork repo did not have any licensing in it whatsoever - what changes were made was also unclear as a result).
• Safer handling of defconfigs; stricter error checks, including on noconfig projects.
• Fixed missing infinite loop detection in mk when resolving trees/revisions in projects. Trees that refer to other trees infinitely are now detected.
• Fixed pico-serprog build errors on GCC 16 (tested on the latest Parabola)
• Use std=gnu2x on coreboot/default instead of std=gnu23; gnu2x is code compatible with gnu23 on newer GCC versions, but older versions used in e.g. 2024 distros.
• ONLY skip make when if_skip_build is set in the main mk script, for more thorough mkhelper execution on all projects.
• Added missing error handling on command -v usage in a few places when setting up rbmk.
• Preventative fix: call x_ in mk, wrapping xbmk_init. The latter never returns non-zero status, so this fix is purely preventative in case the function is ever redesigned at some point to do that.
• mk: Fix globbing issue in multi-tree command args. We previously populated a string with arguments, but now we use dollar-ampersand and cycle through arguments using shift which allows for proper double-quoting to be handled.
• Fully export git author/commit date when re-initialising rbmk on release builds. This is done on every related git command, for deterministic operation.
• Fam15h coreboot: patch out __unused variables and cast them to (void) instead, where unused, to prevent build errors in GCC 16.

A lot of changes were made to util/nvmutil/ to the extent that it deserves its own release log:

• Generally safer use of macros (use brackets).
• Removed errno-based error handling. Just return zero or one, based on logical errors, but do not rely on the status of errno for error exits. Only use return values as appropriate to POSIX in libc functions. However, errno reset is handled more reliably accordingly, after return from libc functions; not required but also not counterindicated by POSIX. - dell-flash-unlock errno handling also fixed in the same way. We previously relied heavily on errno for exit, in ways that were not portable. Not all libc will properly reset it, and may set it randomly even when a given function logically returns with success. Any number of things could set it, so it’s not a reliable mechanism for general error handling.
• Don’t use -pedantic flag - also remove this on spkmodem-recv. Reduces the chance of pedantic build errors based on warnings.
• General correctness fixes; bound checks, proper handling of word alignment, use of uintptr when converting pointers, etc. The code is generally much safer, in terms of memory management, as a result of extensive auditing.
• EINTR-safe wrappers for various functions; loop until EINTR clears, where error occurs, otherwise err-exist on non-EINTR errors. Properly ignore EINTR on close() if function returns with error (EINTR on close is not an error condition in POSIX, and the descriptor should be disregarded in such scenario).
• Generalised I/O functions for libc functions like read, write,preadandpwrite` - EINTR-safe, with stricter (than libc) checks against incomplete writes and such.

NOTE: This applies to the standalone version of nvmutil. There was an attempt to rewrite it in a much larger utility, mentioned in the following section about canceled changes for this release.

Roughly one thousand lines of dead code were cleaned out of the build system, but several hundred more were added due to new feature changes. Overall, the amount of code in rbmk has been reduced, in spite of its advances in this release.

Specific cleanup includes:

• Projects under config/ centralised better, e.g. config/module/coreboot/ instead of config/coreboot. The directory config/ifd/ is moved to config/data/coreboot/ifd/ as it’s only ever used from coreboot.
• The config/ directory is generally better organised now, with more unified placement of files per-project.
• Systematically removed unused variables in the build system.
• mk: new forx function allows macro-like shorthand for loops, greatly simplifying much of the code.
• Removed several redundant checks in the build system, and generally tightened up all error handling.
• Various random and minor code cleanups; minor dead code removal in the build system.
• Generalised several macro’d mkhelper checks in rbmk, refactoring and reducing overall code complexity.
• lib.sh: Made build_sbase function a macro instead, so that it can be changed all in one place. It’s literally just one command (make -C util/sbase).
• Simplified add_uboot logic as it is only needed now for ARM64. The conditional logic for x86 was removed as we no longer use U-Boot on x86 at all; EDK2 is now the preferred payload on x86, for UEFI.
• Removed ccache from dependencies as we no longer use ccache, for reliability reasons.
• release.sh: Removed the -m option as it’s useless. There is no context in which we want to generate a source archive without also building binaries. What’s the point in doing half a release? This is dead code. Knobs are for nobs.
• Unrolled several loops in rbmk, generalising them into macro-like functions. This allowed for a decent code size reduction while also increasing code readability. Macro-like programming is quite feasible in sh when you do it right.
• Removed u-boot-specific make-clean handling in mk; mk is more generalised now anyway. U-Boot was making use of git-clean but only on rbmk Git, not releases; so what’s the point? We want the behaviour on either to be in as much parity as possible, and doing unnecessary work is, well, unnecessary.
• Greatly simplified the findpath function in mk. It’s now one line of code, using forx. (wrapper function for readlink -f and realpath.
• Added error check (stricter one) on xbmkpwd initialisation in mk.
• Simplified xbmkpwd initialisation in mk; we now find the path to mk and cd to its base directory, which thus becomes xbmkpwd.
• mk: run xbmk_init from main script, not init.sh. This makes it clearer on first reading, where xbmk initialisation is called from. We do it just below the include of init.sh.
• Moved tree.sh into mk (merger). Everything centralised there, with custom functions now shimmed.
• All includes now done in bulk, and everything called from the main script. We previously included tree.sh (later merged into mk) conditionally. Now absolutely all state is global, which enabled further code simplication and variable cleanup.
• Simplified get.sh considerably. A lot of logic, especially submodule handling, was aggressively generalised.

Just two canceled works:

• Updated U-Boot to a late 2026 revision on ARM64 chromebooks, but the bootflow menu looks ugly now and barely works. Upstream completely broke it. Therefore, we still use the early 2025 revision of U-Boot that was there in the Canoeboot 26.01 (January 2026) release.

The ARM64 payload is still present, but EDK2 has replaced U-Boot on x86.

This deserves its own section, in this release, as it is a major design change. EDK2 was not merely added as an option; it has replaced U-Boot on x86. I could make this its own article. It deserves one. It deserves my judgement, publicly as I’m now about to articulate in no uncertain terms:

U-Boot was used for lightweight UEFI implementation on Intel/AMD boards, but the person chiefly in charge of the x86 coreboot payload for U-Boot has largely forked U-Boot into a newly vibe-coded project; RBoot opposes heavily the use of AI, as per new policy. AI is no good, and upstream x86 U-Boot support has largely bitrotted although several interesting patches were merged.

U-Boot is thus a liability on x86. EDK2 is more fully functional already, so this is used instead. Think AI makes you a super hacker? Think again:

• https://arxiv.org/abs/2507.09089

U-Boot was always buggy on x86 anyway. It’s really just not ready at all. It is better used on RISCV and ARM64(where we continue to use it).

U-Boot upstream itself is staunchly anti-AI, at least at the time of this release, and much discussion of the above was had on their mailing list. It would not be productive to re-ligitate that on this release page, but it should suffice to say that the RBoot project considers U-Boot to be effectively dead on x86. The ARM-based development is still ongoing strongly, upstream, and we will continue to use U-Boot for UEFI on ARM64 (chromebooks for example).

I will not say his name, or the name of his fork, because I don’t want to promote him or his U-Boot fork. If you know his name or his project, you should not say it or promote it either. AI is bad, very bad, for reasons here:

• https://blog.codeberg.org/protecting-our-floss-commons-from-llms.html

The fork in question, of U-Boot, is heavily AI vibe-coded and thus useless to RBoot. This is not mere conjecture; in said aforementioned U-Boot mailing list thread, the author stated thus. We will not, in any way, encourage or facilitate use of AI. It has been made clear that several projects RBoot uses also have some AI-assisted commits; GCC, etc. This is not our fault, but it is my intention that I and others will audit these projects in the future, de-slopping them and possibly even forking them entirely for that very reason. The author of the fork basically went insane with it, proposing to the U-Boot upstream that his work be “custodian”, and merged slowly into the upstream U-Boot tree. He was basically pressuring them to accept AI code against their wills. I say in my capacity as leader of the RBoot project that U-Boot should never allow AI to taint its project. When you accept AI, you become deskilled and you erode the trust that exists between you and your users. You remove the human connection between maintainers and users, and your project will start to become dependent on what is - yes - proprietary technology, paid for in blood. AI is one of the single biggest consumers of electricity and water on the planet, leading to resource shortages all over the world and its increasing control over what information people see in the news is even a threat to democracy worldwide. This is before even arguing about unclear licensing, copyright violations and so on. It was decided that RBoot would join the crusade against all artificial intelligence. The countries chiefly in charge of AI training and infrastructure are the United States (led by several companies currently attacking democracy worldwide) and the People’s Republic of China; even if all the other problems with AI didn’t exist, it would be a very bad idea to give these countries even more power over our computing.

NO. RBoot says no to AI. Thus, we will continue using upstream U-Boot as they say no also, and we will not use any vibecoded forks of it. Even if that causes me to have to spend weeks integrating a totally new system to replace it. That is precisely, exactly and indubitably how far I will go to prove my point.

That is why I went to such extreme effort integrating EDK2. Rather than replace U-Boot with yet another incomplete UEFI implementation, I simply added EDK2 which is already feature-complete as it is the reference, industry-standard implementation of the UEFI spec.

It was originally intended that U-Boot would become RBoot’s primary payload on x86, but alas. I bit the Intel-flavoured bullet and went with EDK2.

Say no to AI. AI makes you stupid. AI is the reason we can’t have nice things.

Renamed more boards, for more consistent naming across all mainboards and platforms. Old target names are still compatible, in current revisions of 26.11, via backward compatibility features implemented in those revisions.

Renamed chromebook_ (rk3399) to cros_ in coreboot chromebook boards, for more consistent naming across different google products.

The new naming scheme is also more friendly to scripts (build systems).

Renamed cros rk3399 targets to match u-boot and coreboot target names. This affects gru bob/kevin chromebooks.

None of the changes from this rev were included (they were all for boards that RBoot does not support in this release).

Minor fixes and usability improvements:

• mk: Errors now properly printed to stderr, where an error occurs in rbmk.
• inject function: the name of the tarball is now printed, making it more clear to the user that a tarball was modified. (the inject script only does MAC address injection in RBoot’s version of that script)
• Dummy EDK2 builds not generated in bin/ as they are not intended for general use. Only the UEFIPAYLOAD.fd files from elf/ are used anyway, so to avoid confusing users, only the final real board build is provided in bin e.g. ThinkPad T480 build.
• EFI- and non-EFI targets on x86, where EDK2 is supported, both now have SMMSTORE in exactly the same configuration. This ensures that users swapping between the two can do so interchangeably, while preserving SMMSTORE.
• Backwards compatibility introduced in ./mk inject commands, such that it works on tarballs from older RBoot releases. This is to mitigate the fact that the image names were changed heavily in this and other 26.11 revisions. Note once more: RBoot’s version of the inject script only does MAC address injection, so it’s only useful on IFD-based images with Intel GbE region for Intel gigabit ethernet configuration.

Of note, this revision backports a major coreboot patchset from upstream:

Nicholas Chin has done extensive rework on battery handling for Dell Latitude models. It is no longer done in SMM. It is now done in a generalised ACPI framework, and existing S3 fixes are done there (patching to prevent DRAM from powering down in S3).

This patchset also adds support for battery status in EC, via the new ACPI patching. This means you can now monitor battery usage / charge level in ACPI-enabled operating systems.

The following features are still broken (and previously broken too), on Dell Latitudes:

• Brightness controls via hotkey(software-based controls work except on the Latitude E4300)
• Physical wireless switch (soft enable/disable works fine)
• Battery charge thresholds (vendor firmware seems to have it on E6430, but coreboot and RBoot do not).
• Wake (S3 resume) on lid open; must press power button to wake from suspend, but this was already true.

The new EC handler code is more efficient, on Dell Latitudes. Doing it all in SMM violates one of coreboot’s main design criteria… putting everything in SMM is bloat. Doing it all in ACPI is just more performance-efficient, and easier to maintain. Note that these patches are still under review on the coreboot project, but they were deemed stable enough for a RBoot release.

Minor tweaks to RK3399 coreboot chromebooks (fix payload setup). Switching to defconfigs nuked CONFIG_PAYLOAD_NONE for some reason - more investigation needed, but rk3399 configs were switched back to full configs for now. This bug does not affect Intel/AMD boards, so they are still defconfig. Without this setting, rbmk’s payload insertion is skipped. This is a bug upstream that needs to be fixed, mitigated for now in this revision release.

Moved RK3399 chromebooks in coreboot to their own tree, for coreboot and u-boot, both trees named cros_arm.

Fixed a critical remote code execution bug in EDK2, as reported by Intel’s Tianocore Security Advisory here:

https://github.com/tianocore/edk2/security/advisories/GHSA-99cj-7hg9-mp4m

NOTE: Not actually ever used when booting iPXE, so this bug never actually affected users, but the fix was merged anyway. We don’t want to ship with a known security bug.

An unchecked bound on incoming ICMP packets allowed attackers to send large packets during the PXE boot window, which could allow the ICMP buffer in EDK2 to overflow and, hence, the attacker could run unsigned code in an unprivileged context.

Tianocore released this patch to fix the CVE:

https://github.com/tianocore/edk2/pull/13302 - fixes CVE-2026-97631; users who did not boot with PXE were unaffected by this issue.

Fixed a hanging bug in EDK2 when booting operating systems via SD card on affected hardware. The fix is done by reverting a previous patch that forced eMMC probing as some soldered-down mmc flash may report itself as removeable; see notes in the patch, linked above. This patch was backported into RBoot EDK2, for the 26.11 release series.

Sources only cleaned before doing a build, to save on build time.

Simplified building of PCSX-Redux Open BIOS, by making use of the cpbin variable recently added to the RBoot build system.

Simplified building of serprog images by using cpbin instead of custom copy logic.

In get.sh, more thorough hash checks are done based on build_depend and fetch_depend, which makes adding symlinks to config directories unnecessary.

Added EDK2 build with just iPXE, nothing else, for images with 3MB of CBFS space.

The next section will cover post-release revisions, which were then provided as amended tarballs, re-built based off of the original one.

Minor build system cleanup.

The rev2 changes were not imported (relevant feature never present in RBoot)

Added missing SMMSTORE config on ThinkPad T420, T420s and T520.

Also enabled SMMSTORE config on HP Elite 8200 SFF

Documentation cleanup

Removed some missed blobs, after more thorough scan; a few microcode updates, and one VGA blob. All unused in RBoot, but they were present in the rev4 source archive. This new revision removed the following files:

• src/mainboard/gigabyte/mz33-ar1/early_vga.bin in coreboot/default and coreboot/cros_arm

And the following blobs were removed from coreboot/fam15h_15h:

• src/vendorcode/amd/agesa/f15/Proc/CPU/Family/0x15/OR/F15OrMicrocodePatch0600050D_Enc.c
• src/vendorcode/amd/agesa/f15/Proc/CPU/Family/0x15/OR/F15OrMicrocodePatch0600063E_Enc.c
• src/vendorcode/amd/agesa/f15/Proc/CPU/Family/0x15/OR/F15OrMicrocodePatch06000852_Enc.c
• src/vendorcode/amd/agesa/f15/Proc/CPU/Family/0x15/OR/F15OrMicrocodePatch06000425.c
• src/vendorcode/amd/agesa/f15/Proc/CPU/Family/0x15/OR/F15OrMicrocodePatch06000624_Enc.c
• src/vendorcode/amd/agesa/f15/Proc/CPU/Family/0x10/RevD/F10MicrocodePatch010000d9.c
• src/vendorcode/amd/agesa/f15/Proc/CPU/Family/0x10/RevD/F10MicrocodePatch010000c5.c

Notably, the microcode blobs are in a different location in this new 15h.org tree, compared to the old 4.11 tree. Please know: these blobs were unused. RBoot patches coreboot so as to never add blobs, even when told to. This means that microcode updates are never applied to images, nor downloaded. In this case however, they were included directly in the tree. The coreboot upstream is much better about splitting these into their own repository, but it seems that the 15h.org fork is a bit more cavelier about keeping them in the main repository - as such, RBoot releases will be more vigilant from now on.

Removed one more blob: src/vendorcode/amd/cimx/rd890/HotplugFirmware.h - it was missed during the last scan. I saw it but accidentally did not include it in the nuke list. Now this blob is removed. Note that coreboot/default and cros were already checked thoroughly. The new 15h.org tree needed more handling.

The nuke function is now applied in Git, when fetching sources. It was previously only applied when preparing sources for release archives, as those are what actually get released. This new redesign brings parity with Git-based builds in line with release builds.

Coreboot 15h (15h.org fork) was heavily modified, so as to force-disable loading AMD microcode. Even when you turn on microcode, it no longer adds microcode. It would fail with a build error if you did anyway, because we remove the microcode files.

This should now be very freedom-friendly indeed. Note that I also patched 15h coreboot to always turn on CONFIG_REMOVE_MICROCODE.

General cleanup of docs, aggressively removing references to proprietary software, or projects that promote it. General cleanup to the EDK2 documentation.

RBoot will be submitted for evaluation by the GNU project. It is very much the intention of the RBoot project that RBoot become a part of the GNU project.

The flashing instructions, for external flashers, have removed references to flash programmers that are hard to set up with free systems; e.g. BBB/RPi. We now standardise on just the RP2040-based programmers.

Both the code and the docs should now be a ready state for the gnueval team. I don’t know whether they would accept RBoot, but I’ve made as many changes as I can think of within what I believe would be their own criteria, anticipating what sort of things they would have flagged regardless. The docs and the code should hopefully already be in a state such that they could accept this as-is.

Restored previous behaviour of scrubbing files at release time instead of during every download in rbmk; otherwise, you end up with a lot of junk in diffs during development, which makes working on upstreams harder. This means then that files are scrubbed during release, but not during ordinary development. The files in question are always ones that are carefully never used when building from rbmk(Git repository) anyway, so this is fine. The restored behaviour is more reliable at scrubbing tarballs, actually intended for release to the public.

No other changes were made, in rev9. This was done when it was realised that the rev6, 7 and 8 tarballs didn’t have files scrubbed in release tarballs at at all; they only get scrubbed when using the rbmk Git repository. Rather than fixing it so that it happens in both places, the old behaviour of only scrubbing release archives was restored. This is a much more conservative implementation, and reduces friction during normal development as it means that development more or less mirrors the same workflow as RBoot’s main upstream project.

Added patch disabling the loading of previously removed SMU firmware for AMD CIMX RD890 northbridge - also disabled (by code patching) PCIe hotplug. This fixes build errors when blobs are removing, which makes this the first revision of RBoot that reliably builds on these ASUS KCMA-D8/KGPE-D16 boards.

Blobs were removed from 15h.org in previous revs, but this broke the build. This patch fixes the build. NOTE: SMU firmware not used on ASUS KGPE-D16 and KCMA-D8, so this breaks nothing. PCIe hotplug basically optional - shouldn’t affect most users. Really the only thing here is CPU microcode being removed, affecting users - beware errata, e.g. VM escape bugs on 62xx/42xx opterons. 63xx and 43xx recommended when excluding microcode updates, as always.

The SMU disable patch keeps the SMU loader code in place; it still carries on like the SMU firmware was loaded, but it’s operating from the default blanked out state (blanked SMU memory). The SMU code is actually unused on ASUS KGPE-D16 and KCMA-D8 so it’s just dead code at that point. This would have to be properly split up and tidied up, upstream.

Essentially, these changes are done because there isn’t much separation in the AGESA code so a bunch of dead code gets included, even if unused. Proper splitting up of the code is needed, removing parts that aren’t used on given boards. The AGESA code is basically bolted onto coreboot, in 15h.org’s coreboot as also when it was originally in the upstream coreboot tree. The 15h.org project did add a bunch of configuration options themselves to the code, e.g. disabling AMD microcode, which RBoot actually doesn’t use - because RBoot just removes all microcode handling entirely, thus the microcode is permanently removed in RBoot on these machines. This is how it was always done.

Testing was done on ASUS KGPE-D16 and it boots, with this RBoot revision. Tested with help from the 15h.org Matrix chatroom. Thank you! ASUS KCMA-D8 is nearly identical in code, and should work just fine as well.

I also fixed some minor issues in the docs, e.g. the about page was still in the pandoc template, even though I removed it (the about page was basically just a meaningless stub that summarised what’s on the homepage).

Please note that the ASUS KGPE-D16 and KCMA-D8 still don’t have EDK2 enabled. This is because it won’t work in text mode startup on the AST2050, even if it could be used on a graphics card, and there’s no SMMSTORE driver in the 15h.org tree; lots of polishing is needed first, before EDK2 can be used on these boards, but you can easily enable it in the corresponding target.cfg file for your board and re-compile if you want to try it, adding e.g. these to the target.cfg file, e.g. config/module/coreboot/asus_kgpe_d16_4mb/target.cfg:

build_depend="coreboot/edk2_chromebook"
payload_edk2="edk2_chromebook"

YMMV but these AMD boards should be rock-solid now. 15h.org makes a lot of fixes; for example, I was told that you can use half a terabyte of RAM on these machines. That is to say, 15h.org supports more RAM than the vendor firmware officially does, on these machines.

Heavily modified all RBoot documentation to remove all references to projects that either are proprietary, or which openly link to or promote or otherwise facilitate the use of proprietary software. The entire RBoot documentation and website is now much more friendly to GNU ideology, though it already was quite friendly as it already implemented that ideology. Now it implements it even more.

Further promoted libre distros, from a curated list of just two: Parabola and Guix. These are the operating systems that RBoot recommends to its users, especially since RBoot is build-tested on Parabola; Guix could be used to create an environment to build it more robustly, in the future, though rbmk likely won’t make use of Guix itself; use of rbmk inside Guix is quite possible.

Made the binary blob extermination policy clearer, in docs.

A thorough re-scan was conducted since the last revisions, to find the last remaining binary blobs from upstream projects. Several were found, and deleted. They are:

• Broadcom (bnx2) firmware removed from iPXE, and the driver patched out entirely. Broadcom hardware is generally hostile to free software.
• mpc8xx microcode removed from U-Boot (ppc)
• F12PcieAlibSsdt.h file removed from coreboot/fam15h_15h (missed in a previous audit)
• Removed r8152 nic firmware from U-boot, but the driver is retained; it was modified to not use the firmware. This is similar to how a deblobbed version of the kernel Linux, namely Linux-libre, handles those nics. Most of them should still work fine without this firmware.
• Various linda NICs disabled, and their firmware removed, in iPXE.

Specifically, these blob files were removed:

in coreboot cros_arm and default trees, these files were removed:

• payloads/external/iPXE/ipxe_src/src/drivers/infiniband/linda_fw.c
• payloads/external/iPXE/ipxe_src/src/drivers/net/bnx2_fw.h

Removed these in u-boot/cros_arm:

• drivers/usb/eth/r8152_fw.c
• board/cssi/mcr3000/fpga_code.h
• arch/powerpc/cpu/mpc8xx/micropatch_smc.c

Removed these in coreboot/fam15h_15h:

• src/vendorcode/amd/agesa/f12/Proc/GNB/PCIe/Family/LN/F12PcieAlibSsdt.h

Corresponding source trees were patched to fix build errors, where necessary, after removing these firmware blobs.

Blob deletion now occurs when fetching sources in rbmk.git, in addition to release archives. This brings parity with local rbmk development in line with release engineering, so that the build is identical in both cases; we previously had to be very careful that files tagged for removal in releases would not be used in local rbmk builds. The previous issue identified can be mitigated by temporarily committing deletions in hot copies of source trees, for quick patching, when testing a patch in a given project.

RBoot 26.11 was submitted for evaluation by the GNU project, pending possible accession; Import from Canoeboot 26.11rev11 will now be built, and this version submitted to GNU with the following notes. This was done ahead of any auditing on their part, to make sure that all blobs have been cleaned.

No blobs found in EDK2 thus far; scans are ongoing, and further amendments will be made to this release if offending files are found.

Fixed the r8152 firmware removal in U-Boot; I removed the firmware files, and the corresponding rule in the Makefile. However, I’d not removed the actual calls to the functions that updates the firmware. I had done so, but did not commit it.

It has now been committed, such that rev12 is now what rev11 should have been. Otherwise, U-Boot won’t compile without this fix in rev12.

The firmware for realtek nics is provided in U-Boot as headers, with functions in those files that are called by the driver, updating the firmware which is contained in byte arrays inside those headers. RBoot patches this out entirely, such that the drivers still operate but without firmware; most of the r8252 nics should still work without it, but some may be buggy.

This patched behaviour in U-Boot is identical to how deblobbed versions of Linux behave such as Linux-libre, in their driver for these NICs.

On boards that can use EDK2, they only use EDK2.

All GRUB trees have been removed, even the EFI build. EFI-only, where EFI is available; that’s the policy.

Legacy boards still have SeaBIOS, where EDK2 is not possible yet. Most boards have EDK2. You’ll know when flashing, because the ROM image file names are named accordingly.

Removal of GRUB removes a lot of legacy bloat from the build system, compared to previously named iterations of this project. It modernises the project as everything revolves around EDK2 now. This makes project maintenance much easier. Nearly all boards have EDK2. The few that don’t have SeaBIOS, and SeaBIOS is such a simple codebase that the maintenance burden is non-existent.

Boards that were set release="n" have been removed. In short: this is a mostly legacy-free fork of Canoeboot. Very minimal amount of legacy cruft remains; SeaBIOS is relatively easy to maintain, and the machines that use it all still work fairly well.

Removing GRUB removes a lot of future bugs from RBoot. A whole range of bugs were present in GRUB, especially the build system; it lacks good error handling in most cases, especially pertaining to tmpfile usage. All of the code that remains in RBoot is relatively modern, or otherwise clean.

Everything is EDK2 now. Libre UEFI is the future.

The memtest86plus payload was also removed in RBoot. More generally, it is the intention of this project that the maintenance burden be kept as low as possible; users can just run memtest from a USB stick in EDK2 if they want.

Basically:

You might regard RBoot 26.11 as Canoeboot 26.11rev13. That is a good way to think of it, though more accurately it reflects what would have been the future ambition of that project; the plan was to slowly remove GRUB and SeaBIOS as much as possible, but in a phased manner. It was decided that since the project was rebooting anyway, we may as well just start from a clean slate. Thus, this extreme level of modernisation has been brought forward roughly one year ahead of schedule! RBoot does not provide GRUB at all.

PS: All Canoeboot binaries have been removed from the server; source code archives remain hosted, and will always be. Only RBoot binaries are provided now, where binaries are provided; RBoot source code also provided. This is essentially a complete revolution, implementing what Canoeboot should have always been. I actually did integrate EDK2 into another boot distro of mine a few years ago, but removed it for some reason. Oh well. We have it in 2026.

SPDX-License-Identifier: GFDL-1.3-or-later

Markdown file for this page: https://rboot.org/news/rboot2611.md

Site map

This HTML page was generated by the Rboot Static Site Generator.