Release v2025.01.0 ================== Layerscape ---------- Support for the NXP-specific PPA Secure Monitor has been removed in favor of ARM Trusted Firmware-A as the former has been long unmaintained. I2C Adapter numbering --------------------- ``i2c0`` to ``i2c31`` are now reserved for I2C adapters with device tree aliases. Do not rely on a fixed numbering for other non-aliased adapters. OP-TEE for Rockchip ------------------- The BL32 firmware images are now called ``firmware/rk3XXX-bl32.bin`` instead of ``firmware/rk3XXX-op-tee.bin``. Raw OP-TEE binaries without a header now use the load address the vendor blobs are hardcoded to run at instead of the previous ``0x200000``. To override, use an OP-TEE image with a header specifying the correct load address. TFTP ---- The default TFTP window size has been reverted to 1 as many network drivers couldn't cope with the increased throughput. This can be reverted by setting ``CONFIG_FS_TFTP_MAX_WINDOW_SIZE`` or at runtime via the :ref:`global.tftp.windowsize ` variable. Release v2025.02.0 ================== Environment Auto-Probe ---------------------- A new magic variable ``global.env.autoprobe`` now controls whether barebox will automatically probe known block devices for a GPT barebox environment partition if no environment was specified by other means. The variable defaults to ``0`` (false) if ``CONFIG_INSECURE`` is disabled. The most secure option remains disabling ``CONFIG_ENV_HANDLING`` completely or, starting with v2025.10.0, using the security policy support for runtime access control. Zynq 7000 --------- The MMC controller numbering is now fixed: ``mmc0`` & ``mmc1`` for ``&sdhci0`` and ``&sdhci1`` respectively. Release v2025.03.0 ================== OMAP console fixup ------------------ The option ``CONFIG_DRIVER_SERIAL_NS16550_OMAP_TTYS`` now controls whether barebox fixes up ``ttyS`` or ``ttyO`` into the kernel command line ``console=`` option. fixed-partitions on SD/MMC -------------------------- Linux v6.13-rc1 added ``CONFIG_OF_PARTITION``, which interprets ``fixed-partitions`` nodes in SD/MMC nodes differently to the barebox behavior: It ignores the GPT/MBR if fixed-partitions are specified, instead of allowing them to co-exist like in barebox. To accommodate both the existing barebox and the new kernel functionality, users should replace ``fixed-partitions``-compatible device tree subnodes of SD/eMMC with ``barebox,fixed-partitions``. Similarly, the default for :ref:`global.of_partition_binding ` has been changed to the new ``adaptive`` option, which fixes up ``barebox,fixed-partitions`` except for MTD. Release v2025.05.0 ================== Configuration options --------------------- This can be customized via setting the :ref:`global.linux.rootwait ` variable or by disabling the option. Bootloader Specification ------------------------ Previously only the first partition with the XBOOTLDR partition type was considered. If an XBOOTLDR partition exists, barebox will no longer walk all partitions to find further bootloader spec entries. Board support ------------- Users should migrate to FIP images with barebox as nontrusted firmware (BL33) and the barebox device tree as hardware config. Use of multiple device trees is not supported directly by the FIP format and can be substituted by a barebox image embedding multiple device trees and using the hardware config FIP slot only as dummy. See the lxa-tac board for an example. Shell and magic variables ------------------------- This does not affect users setting ``nv boot.default``, but for others, barebox will look for bootloader spec on the bootsource medium first. Build system ------------ Bisectability ------------- Following regressions had a wider impact and could falsify git bisect results: Release v2025.08.0 ================== W^X on ARM ---------- ``CONFIG_ARM_MMU_PERMISSIONS=y`` is now the default and instructs barebox to map its memory regions with more restricted permissions: Data is no longer executable and code as well as read-only data is no longer writable. This can lead to breakage in code that had invalid assumptions beforehand, e.g. code expecting on-chip SRAMs to be executable or bogus code casting away const. Please report to upstream any issues that are resolved by disabling ``CONFIG_ARM_MMU_PERMISSIONS``, so they can be properly fixed. Bootchooser ----------- Bootchooser now interprets a top-level ``attempts_locked`` variable. For more information, see :ref:`attempts lock feature `. Board support ------------- The hardcoded Vexpress partition layout for barebox, its environment and state has been changed. The first 5M of the NOR flash should now be reserved for barebox use. barebox will, by default, fix up the new partition layout into the kernel device tree. Release v2025.09.0 ================== Removal of CONFIG_BOOTM_FITIMAGE_PUBKEY --------------------------------------- The legacy way of adding FIT keys to the barebox build was having mkimage generate a device tree snippet and including it in the barebox board device tree:: #ifdef CONFIG_BOOTM_FITIMAGE_PUBKEY #include CONFIG_BOOTM_FITIMAGE_PUBKEY #endif This has now been removed in favor of ``CONFIG_CRYPTO_PUBLIC_KEYS``. This option doesn't consume device tree snippets, but file paths to the PEM or PKCS#11 URIs and thus will require a build-time OpenSSL dependency. Build dependencies ------------------ Rename in /dev -------------- EEPROMs that are pointed at by a device tree alias no longer have an extra 0 at the end, e.g., ``/dev/eeprom00`` has become ``/dev/eeprom0``. Release v2025.09.3 ================== FIT Images ---------- The fix for `CVE-2026-33243 `_ has the side effect that barebox after v2025.09.3 will not boot a signed configuration that excludes some images from the signature. Previously, it was possible to generate readily exploitable FIT images by omitting them from ``sign-images`` in the ITS. If a FIT fails to boot with **v2025.09.3**, when it successfully booted v2025.09.2 or earlier, it's likely that it was vulnerable even without knowledge of CVE-2026-33243. Recommendation is to not write FIT ITS manually, but to use higher level tooling that generates the ITS and feeds it to ``mkimage(1)``. For more details, refer to the `security advisory `_. Release v2025.10.0 ================== Rename in /dev -------------- The i.MX SNVS device file is now simply called ``snvs`` instead of the previous unwieldy name derived from device tree, e.g., ``/dev/30370000.snvs@30370000:snvs-lpgpr.of0``. EEPROMs that are pointed at by a device tree alias no longer have an extra 0 at the end, e.g., ``/dev/eeprom00`` has become ``/dev/eeprom0``. AM62L DT Bindings ----------------- The SCMI clock IDs for the AM62L have changed in ARM Trusted Firmware, because the old assignment was not conforming to spec. barebox now requires TF-A to contain commit ("PENDING: feat(ti): add missing scmi pds"). Release v2025.12.0 ================== Shell ----- Configuration options --------------------- Release v2026.01.0 ================== removal for PowerPC ------------------------------ PowerPC was the last remaining user of per-board ```` files. The alternative for out-of-tree boards is now to patch ``arch/powerpc/include/asm/config.h`` to include the board's config.h, like the in-tree boards are already doing. Filesystems ----------- The ``linux.bootargs`` file system device parameter (e.g. ``ext40.linux.bootargs``) has been replaced by the two variables ``${fsdev}.linux.bootargs.root`` and ``${fsdev}.linux.bootargs.rootopts``, splitting the previous bootargs into three parts. For example, the previous:: ext40.linux.bootargs="root=/dev/nfs nfsroot=192.168.1.1:/rootfs" becomes:: ext40.linux.bootargs.root="/dev/nfs" ext40.linux.bootargs.rootopts="nfsroot=192.168.1.1:/rootfs" Scripts that access these parameters will need to be adapted to replace ``{linux.bootargs}`` with ``root={linux.bootargs.root} {linux.bootargs.rootopts}``. :ref:`global.linux.bootargs.* ` is unaffected by this change. Boards ------ ARM i.MX6 RIoTboard ^^^^^^^^^^^^^^^^^^^ The barebox update handler has been changed to write barebox to the eMMC boot partitions rather than the user data area. Release v2026.03.0 ================== ARM NXP i.MX8MP --------------- On NXP i.MX8MP the SoC UID was read out wrong. It really is 128bit from which barebox only read 64bit. barebox now does it correctly, but rolled out devices might depend on the SoC UID being constant. In that case CONFIG_ARCH_IMX8MP_KEEP_COMPATIBLE_SOC_UID should be enabled. FIT Images ---------- The fix for `CVE-2026-33243 `_ has the side effect that barebox after v2026.03.0 will not boot a signed configuration that excludes some images from the signature. Previously, it was possible to generate readily exploitable FIT images by omitting them from ``sign-images`` in the ITS. If a FIT fails to boot with **v2026.03.1**, when it successfully booted v2026.02.0 or earlier, it's likely that it was vulnerable even without knowledge of CVE-2026-33243. Recommendation is to not write FIT ITS manually, but to use higher level tooling that generates the ITS and feeds it to ``mkimage(1)``. For more details, refer to the `security advisory `_. Release v2026.05.0 ================== Removal of global.env.autoprobe ------------------------------- The global.env.autoprobe variable introduced with v2025.02.0 is removed and now replaced with CONFIG_ENV_HANDLING_AUTOPROBE. It has never worked. If you want to load a barebox environment based on its partition UUID enable CONFIG_ENV_HANDLING_AUTOPROBE. CONFIG_CRYPTO_PUBLIC_KEYS ------------------------- The syntax of keytoc keyspecs when fully provided via an environment variable was slightly changed to allow any number of keyspecs to be provided via an environment variable. Such environment variables are now split at spaces to be interpreted as multiple keyspecs. Any literal spaces and backslashes contained in such keyspecs need to be escaped with a backslash. This only applies to the form:: CONFIG_CRYPTO_PUBLIC_KEYS="__ENV__A" While the interpretation of environment variables specifying hint or URI remains unchanged:: CONFIG_CRYPTO_PUBLIC_KEYS="keyring=kr:__ENV__B" Fit hints can no longer be specified by environment variables using the __ENV__ syntax. This functionality was broken since the last change to the keyspec syntax in 2025.12. register_simplefb parameter --------------------------- The ``register_simplefb`` parameter on framebuffer devices has changed from boolean to an enum with values ``disabled``, ``enabled``, and ``stdout-path``. Scripts that **read** the parameter will now receive ``"disabled"`` or ``"enabled"`` instead of ``"0"`` or ``"1"``. Scripts that **write** ``"0"`` or ``"1"`` continue to work. global.linux.bootargs.* appending order --------------------------------------- If barebox was configured to automatically generate any of the ``root``, ``rootwait``, ``earlycon``, ``systemd.machine_id``, ``systemd.hostname`` or ``barebox.security.policy`` kernel command line options, they will be appended onto the final kernel command line :ref:`**after** all other options `. Release v2026.06.0 ================== global.linux.bootargs.* appending order --------------------------------------- If barebox was configured to automatically generate any of the ``root``, ``rootwait``, ``earlycon``, ``systemd.machine_id``, ``systemd.hostname`` or ``barebox.security.policy`` kernel command line options, they will be appended onto the final kernel command line :ref:`after all other options `. Removal of global.env.autoprobe ------------------------------- The global.env.autoprobe variable introduced with v2025.02.0 is removed and now replaced with CONFIG_ENV_HANDLING_AUTOPROBE. It has never worked. If you want to load a barebox environment based on its partition UUID enable CONFIG_ENV_HANDLING_AUTOPROBE. Release v2026.08.0 ================== global.partitions.first_usable_lba removed ------------------------------------------ The ``global.partitions.first_usable_lba`` variable has been removed. Use :ref:`global.partitions.first_partition_offset ` instead. The new variable is a byte offset used by free-space searches for new partitions, for example ``parted mkpart_size``. The default is ``8388608`` bytes (8 MiB). To keep an old configuration, multiply the old ``first_usable_lba`` value by 512. ARCH=arm64 ---------- Use of ``ARCH=arm`` for 64-bit ARM builds is deprecated and now emits a warning. Users should change build scripts to use ``ARCH=arm64`` instead when targetting ARMv8. Release v2026.09.0 ================== Removal of deprecated CONFIG_BOOTM_OPTEE ---------------------------------------- The support for late loading of OP-TEE had been deprecated and ultimately removed as it greatly increased the attack surface and was only supported on 32-bit ARM systems. OP-TEE loading is now only supported :ref:`in the prebootloader `. For i.MX6 boards, this can be enabled by enabling ``CONFIG_FIRMWARE_IMX6_OPTEE``. sha1 no longer accepted for secure boot --------------------------------------- FIT images using sha1 are no longer accepted as secure boot images. sha1 has been proven insecure in 2017. Release v2026.10.0 ================== Removal of bootm -c/-s options ------------------------------ The :ref:`command_bootm` options ``-c`` and ``-s`` used to selectively enable checksum/hash and signature verification, respectively. They have been removed in favor of the global toggle :ref:`global.bootm.verify `. This can be restricted at build-time via setting ``CONFIG_BOOTM_FORCE_SIGNED_IMAGES`` or loosened :ref:`at runtime ` via setting ``SCONFIG_BOOT_UNSIGNED_IMAGES``. The removal is motivated by making it easier to reason about what the active verification level is, especially as there are now other uses for verified images like when :ref:`global.of.overlay.path ` points at a FIT. Existing users, if any, will fail-secure: The command will now exit with a failure:: bootm: invalid option -- s Default environment overlay order --------------------------------- Releases since v2026.01.0 applied board specific default environment overlays added with ``defaultenv_append_directory()`` after the environment given with ``CONFIG_DEFAULT_ENVIRONMENT_PATH`` and thus overwrote its files. The documented order has been restored: ``CONFIG_DEFAULT_ENVIRONMENT_PATH`` is applied after the board specific overlays again and can overwrite their files. Overlays only available at runtime, like an environment passed via QEMU fw_cfg, are still applied last. BSPs that started to rely on the board specific overlay taking precedence need to remove the conflicting files from their external environment. EFI payload reported inverted Secure Boot state ----------------------------------------------- As EFI payload, barebox reported the inverse of the firmware's Secure Boot state in :ref:`efi.secure_boot ` and a wrong :ref:`efi.secure_mode ` derived from it. Both are now ``1`` if Secure Boot is enabled, ``efi.secure_mode`` only if the firmware is additionally not in Setup Mode. In general, this should have no security implications: barebox doesn't evaluate the parameters itself, the firmware enforces Secure Boot according to its enrolled keys and the parameters were undocumented so far. It may however invalidate assumptions made by scripts.