| Age | Commit message (Collapse) | Author |
|---|
|
https://source.denx.de/u-boot/custodians/u-boot-dfu into next
u-boot-dfu-next-20260629:
CI: https://source.denx.de/u-boot/custodians/u-boot-dfu/-/pipelines/30562
Fastboot:
- Add support for CMD_FASTBOOT_ABORT_KEYED
- Enable CMD_FASTBOOT_ABORT_KEYED for qualcomm phones
USB Gadget:
- f_mass_storage: Disable eps during disconnect
- f_sdp: Fix spl load failure error handling
|
|
Add initial U-Boot support for Aquila iMX95 SoM.
Link: https://www.toradex.com/computer-on-modules/aquila-arm-family/nxp-imx95
Link: https://www.toradex.com/products/carrier-board/aquila-development-board-kit
Signed-off-by: Franz Schnyder <[email protected]>
Reviewed-by: Francesco Dolcini <[email protected]>
|
|
Works the same as CONFIG_CMD_UMS_ABORT_KEYED does: any keypress will
abort fastboot mode (rather than only ctrl-c).
Reviewed-by: Mattijs Korpershoek <[email protected]>
Tested-by: Mattijs Korpershoek <[email protected]>
Reviewed-by: Casey Connolly <[email protected]>
Signed-off-by: Sam Day <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Mattijs Korpershoek <[email protected]>
|
|
Since devices that can't DMA above 4GiB will misbehave with this option
enabled add a warning on the documentation.
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
Tested-by: Christophe Leroy (CS GROUP) <[email protected]>
|
|
Prepare v2026.07-rc5
|
|
Signed-off-by: Tom Rini <[email protected]>
|
|
It's possible to interrupt the fastboot command from the U-Boot shell
using the Ctrl-c keybinding.
Document this.
Signed-off-by: Mattijs Korpershoek <[email protected]>
Reviewed-by: Sam Day <[email protected]>
|
|
Document support for Renesas Ironhide development board
based on Renesas R-Car X5H (R8A78000) SoC.
Fixes: cf71963778ee ("arm64: dts: renesas: Add Renesas R-Car X5H R8A78000 Ironhide board code")
Fixes: 9d47a5a4d560 ("arm: renesas: Add Renesas R-Car R8A78000 X5H Cortex-M33 RSIP port")
Signed-off-by: Marek Vasut <[email protected]>
|
|
Document support for Renesas Gray Hawk Single development board
based on Renesas R-Car V4M (R8A779H0) SoC.
Fixes: 53066deccbed ("ARM: renesas: Add Renesas R8A779H0 V4M Gray Hawk board code")
Signed-off-by: Marek Vasut <[email protected]>
|
|
Document support for Renesas Geist development board
based on Renesas R-Car M3Le (R8A779MD) SoC.
Fixes: c8523795d796 ("arm64: dts: renesas: r8a779md: Add support for R-Car M3Le R8A779MD Geist")
Signed-off-by: Marek Vasut <[email protected]>
|
|
The RZ/N1D and RZ/N1S contain Cortex-A7 core, which is 32bit ARM core.
Document the SoC as 32bit ARM instead of aarch64.
Fixes: a5b9f959439b ("doc: renesas: add Renesas board docs")
Signed-off-by: Marek Vasut <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
Rasmus Villemoes <[email protected]> says:
The commit message for patch 1 explains what it is I'd like to be able
to do, but here's some more background:
For a long time, we've embedded the boot script in the U-Boot binary
by building a bootscript.itb, and using a .dtsi like
/ {
config {
bootscript = /incbin/("/path/to/bootscript.itb");
};
};
which in turn is mentioned in CONFIG_DEVICE_TREE_INCLUDES, that
bootscript.itb FIT image has been embedded in U-Boot's control
dtb. Running that was then a matter of doing
fdt addr ${fdtcontroladdr} && fdt get addr bsaddr /config bootscript && source ${bsaddr}
There are a couple of advantage of having the bootscript (and other
script logic) embedded in the U-Boot binary. First, there's no need to
figure out some separate partition to store the script in, and making
sure that gets updated whenever the bootloader itself does. Second,
one doesn't need to worry about verifying the script; whatever steps
one needs to take to implement secure boot for U-Boot itself will by
necessity also cover the control dtb (if nothing else then because
that's where the public key for the kernel verification lives). And
third, the boot script is automatically updated together with U-Boot
itself; and if U-Boot is stored in an eMMC boot partition, that update
is guaranteed to be atomic.
Now with the stricter requirements of libfdt starting from v2026.04,
the above command no longer worked, or only half the time, because the
embedded FIT image may not land on an 8-byte aligned address. So that
line had to be changed a little (line breaks added)
fdt addr ${fdtcontroladdr}
&& fdt get addr bsaddr /config bootscript
&& fdt get size bssize /config bootscript
&& cp.b ${bsaddr} ${loadaddr} ${bssize}
&& source ${loadaddr}
which is getting quite unwieldy.
Then it struck me that one could perhaps simplify all of this quite a
lot: Cut out the intermediate bootscript.itb, just create a .dtsi
which directly puts a /images node inside the control dtb
/ {
images {
default = "bootscript";
bootscript {
description = "Boot script";
data = /incbin/("/path/to/bootscript.sh");
type = "script";
compression = "none";
};
};
};
and treat the control dtb itself as a FIT image; so the command to put
in $bootcmd becomes simply
source ${fdtcontroladdr}:bootscript
and embedding other pieces of callable scripts is quite trivial.
And that almost works out-of-the-box, except for the fit_check_format() sanity check.
Introduce a CONFIG_ knob that allows one to opt out of those sanity
checks, for the special case of the address being checked being
identical to gd->fdt_blob.
Link: https://lore.kernel.org/r/[email protected]
|
|
Add a section that explains how one can embed scripts in the control
DTB and run them from the U-Boot shell, the advantages of doing that
compared to using a separately built FIT image, and the configuration
knob that must be turned on to allow this to work.
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Rasmus Villemoes <[email protected]>
|
|
https://source.denx.de/u-boot/custodians/u-boot-rockchip
CI: https://source.denx.de/u-boot/custodians/u-boot-rockchip/-/pipelines/30398
Please pull the updates for rockchip platform:
- New Board support: rk3588 FriendlyElec NanoPi R76S
- UFS boot from SPL for rk3576 (NanoPi M5, ROCK 4D)
- Clock support for RK3576 GMAC 25MHz output and RK3528/RK3576 USB3 OTG
- Switch rk3128/rk3229 boards to upstream devicetree
- MAINTAINERS update for upstream devicetree references
- rk3588-rock-5b: Remove USB-C controller from u-boot.dtsi
|
|
Add the Allied Telesis x220 board. There are a number of other variants
with the same CPU block that are sold under some different brand names
but the x220 was first.
The x220 uses the AlleyCat3 switch chip with integrated ARMv7 CPU.
Because of this it is reliant on a binary blob for the DDR training. In
upstream u-boot this is replaced by an empty file.
Signed-off-by: Chris Packham <[email protected]>
Reviewed-by: Stefan Roese <[email protected]>
|
|
https://source.denx.de/u-boot/custodians/u-boot-efi
Pull request efi-2026-07-rc5
CI: https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/30365
Documentation:
* Update urllib3 version for building
* usb: typos 'requird', 'current'
UEFI
* Improve PE-COFF relocation data validation
Devicetree-to-C generator:
* dtoc: test: add missing escape in help text
|
|
Neha Malcom Francis <[email protected]> says:
Update all DDR configuration DTSIs to the latest auto-generated output of
the Sysconfig Tool (DDR Configuration for TDA4x, DRA8x, AM67x, AM68x,
AM69x (0.12.00.0000)) [0]
The auto-generated files must not be modified, but effort will be taken to
change the tool output to adhere to the latest checkpatch.pl rules. J722S
and J721E will also be updated in a subsequent series.
All the changes have been kernel boot tested and memtester has passed (same
as v1, as no functional changes made).
[0] https://dev.ti.com/sysconfig/#/start
Link: https://lore.kernel.org/r/[email protected]
|
|
Add a concise section for DDR configuration pointing to the public tool
that can be used to generate the configuration DTSI.
Signed-off-by: Neha Malcom Francis <[email protected]>
Reviewed-by: Romain Naour <[email protected]>
|
|
|
|
Prepare v2026.07-rc4
|
|
Signed-off-by: Tom Rini <[email protected]>
|
|
The NanoPi R76S (as "R76S") is an open-sourced mini IoT gateway
device with two 2.5G, designed and developed by FriendlyElec.
Features tested on a NanoPi R76S 2411:
- SD-card boot
- eMMC boot
- LEDs and button
- PCIe/Ethernet
- USB host
Signed-off-by: Jonas Karlman <[email protected]>
Reviewed-by: Kever Yang <[email protected]>
|
|
The GitHub dependabot tool has reported two "high" priority bug,
CVE-2026-44431 and CVE-2026-44432, with this package. Update to the
patched version.
Reported-by: GitHub dependabot
Signed-off-by: Tom Rini <[email protected]>
|
|
Introduce a sysinfo driver that can be instantiated from the device,
which will provide information from the EEPROM found on all TQ-Systems
SoMs.
Signed-off-by: Nora Schiffer <[email protected]>
Signed-off-by: Max Merchel <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Alexander Feilke <[email protected]>
|
|
The TQMa6UL[L]x is a family of SoMs based on the i.MX6UL[L] SoCs.
They are available either with board connectors or as LGA packages
with solder balls. Add Support for the SoM and its combination with
our MBa6ULx carrier board. For use with the MBa6ULx carrier board,
the LGA variant is soldered onto an adapter board.
Signed-off-by: Nora Schiffer <[email protected]>
Signed-off-by: Max Merchel <[email protected]>
|
|
Caleb Ethridge <[email protected]> says:
This series performs a general cleanup of the default U-boot environment
for sc5xx boards, stemming from the decision to no longer store the
environment in the SPI flash. The environments for each board have been
edited to contain the minimum number of commands needed for all supported
boot modes to avoid confusion, and the default boot command synced to spi
for all boards that support it. The filesystem for the SPI flash has also
been changed from jffs2 to ubifs.
A bug with the Ethernet reset line on the sc594 has been fixed, and the
sc573 has been renamed from the EZKIT to the EZLITE to match the name of the
publically available board. EZKIT was only used internally before release.
Preliminary binman support for sc5xx boards has been removed as it was unused
and full support never added.
Link: https://lore.kernel.org/r/[email protected]
|
|
Rename the SC573 EZKIT board to EZLITE across the device tree,
defconfig, board file, and related Kconfig/Makefile entries to
match with release naming. EZKIT was used internally before the
official product release.
Signed-off-by: Caleb Ethridge <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Wadim Egorov <[email protected]> says:
This is a small updates across all K3 based phytec SoMs.
Update docs, rm-cfg yaml files and drop rauc environment.
Link: https://lore.kernel.org/r/[email protected]
|
|
The phyCORE-AM62x and phyCORE-AM64x R5 SPL detects the populated DDR
size from the SoM EEPROM and falls back to 2 GB if detection fails. For
boards without a populated EEPROM or if no detection needed, the detection
can be bypassed via CONFIG_PHYCORE_AM6{2,4}X_RAM_SIZE_FIX and one of
the CONFIG_PHYCORE_AM6{2,4}X_RAM_SIZE_<size> choices.
Add a "DDR RAM Size" section to both board docs describing this
behaviour and listing the available size options (1/2/4 GB for AM62x,
1/2 GB for AM64x).
Signed-off-by: Wadim Egorov <[email protected]>
|
|
Add two short sections to the common K3 phyCORE docs.
Describe the default boot flow and its deprecated version.
And write down the use of the watchdog.
Signed-off-by: Wadim Egorov <[email protected]>
|
|
A handful of small inaccuracies had crept into the phyCORE-AM6x docs.
Mostly typos and formatting Issues. Fix them. While at it, update the
am62a board to use the correct product link.
Signed-off-by: Wadim Egorov <[email protected]>
|
|
Daniel Golle <[email protected]> says:
This series adds dm-verity support to U-Boot's FIT image infrastructure.
It is the first logical subset of the larger OpenWrt boot method series
posted as an RFC in February 2026 [1], extracted here for independent
review and merging.
OpenWrt's firmware model embeds a read-only squashfs or erofs root
filesystem directly inside a uImage.FIT container as a FILESYSTEM-type
loadable FIT image. At boot the kernel maps this sub-image directly from
the underlying block device via the fitblk driver (/dev/fit0, /dev/fit1,
...), the goal is that the bootloader never even copies it to RAM.
dm-verity enables the kernel to verify the integrity of those mapped
filesystems at read time, with a Merkle hash tree stored contiguously in
the same sub-image just after the data. Two kernel command-line
parameters are required:
dm-mod.create= -- the device-mapper target table for the verity device
dm-mod.waitfor= -- a comma-separated list of block devices to wait for
before dm-init sets up the targets (needed when fitblk
probes late, e.g. because it depends on NVMEM
calibration data)
The FIT dm-verity node schema was upstreamed into the flat-image-tree
specification [2], which this implementation tries to follow exactly.
The runtime feature is guarded behind CONFIG_FIT_VERITY. If not
enabled the resulting binary size remains unchanged. If enabled the
binary size increases by about 3kB.
[1] previous submissions:
RFC: https://www.mail-archive.com/[email protected]/msg565945.html
v1: https://www.mail-archive.com/[email protected]/msg569472.html
v2: https://www.mail-archive.com/[email protected]/msg570599.html
v3: https://www.mail-archive.com/[email protected]/msg573223.html
v4: https://www.mail-archive.com/[email protected]/msg574000.html
[2] flat-image-tree dm-verity node spec:
https://github.com/open-source-firmware/flat-image-tree/commit/795fd5fd7f0121d0cb03efb1900aafc61c704771
Link: https://lore.kernel.org/r/[email protected]
|
|
Add documentation for CONFIG_FIT_VERITY which allows U-Boot to
construct dm-mod.create= and dm-mod.waitfor= kernel command-line
parameters from dm-verity metadata embedded in FIT filesystem
sub-images.
The new document covers the relationship between FIT loadable indices
and the /dev/fitN block devices that the Linux uImage.FIT block driver
creates, provides a complete .its example with a dm-verity-protected
SquashFS root filesystem, describes all required and optional dm-verity
subnode properties and explains how mkimage generates the verity
metadata automatically.
dm-verity is only supported for external-data FIT images (mkimage -E);
mkimage aborts with an error if the flag is omitted.
Signed-off-by: Daniel Golle <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
This series from James Hilliard <[email protected]> converts the
static flags list for the environment to be configured via Kconfig and
updates the documentation.
Link: https://lore.kernel.org/r/[email protected]
|
|
Environment callbacks can already be configured from Kconfig with
CONFIG_ENV_CALLBACK_LIST_STATIC, but static environment flags still
require board headers to define CFG_ENV_FLAGS_LIST_STATIC.
Add CONFIG_ENV_FLAGS_LIST_STATIC and use it as the only board-provided
static environment flags list. Convert the remaining default-config users
from CFG_ENV_FLAGS_LIST_STATIC to defconfig settings and drop the legacy
header macro from ENV_FLAGS_LIST_STATIC.
Move the environment flags format documentation out of README and into
the developer environment documentation. Include the format in the
Kconfig help as well.
This lets boards configure writeable-list policy and type validation
from defconfig without adding a config header solely for env flags.
This preserves the behavior of default configs. Header-only cases that
were inactive in upstream defconfigs are not converted into defconfig
entries: iot2050 can add its list when enabling ENV_WRITEABLE_LIST, and
smegw01 can add mmcdev:dw support if the unlocked SYS_BOOT_LOCKED=n
configuration is needed.
Signed-off-by: James Hilliard <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Reviewed-by: Alexander Sverdlin <[email protected]>
Reviewed-by: Walter Schweizer <[email protected]>
|
|
Prepare v2026.07-rc3
|
|
Signed-off-by: Tom Rini <[email protected]>
|
|
Our official domain is now u-boot-project.org, so update all in-tree
references to use the correct domain.
Reviewed-by: Tony Dinh <[email protected]>
Reviewed-by: Peter Robinson <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
|
|
The option is only available when CONFIG_SYSRESET_QCOM_PSCI is enabled,
so let's make that explicit in the boot cmd documentation.
Due to the implementation in drivers/sysreset/sysreset-uclass.c
do_reset() function, all options to the reset command are passed to all
sysreset drivers' sysreset_ops.request_arg callback (including -w) which
is only available when CONFIG_SYSRESET_CMD_RESET_ARGS=y. -w, however,
works also without this option.
Fixes: ef06c5d76ff4 ("cmd: boot: Add '-edl' option to reset command documentation")
Signed-off-by: Quentin Schulz <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
"Do warm WARM" doesn't mean anything, I'm assuming the intent was to say
"Do WARM reset" so reword.
Fixes: 34e452dd0252 ("doc: usage: Group all shell command docs into cmd/ sub-directory")
Signed-off-by: Quentin Schulz <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Add instructions on how to use U-Boot to save
DDR training data to NVM and explain the saving
process.
Signed-off-by: Simona Toaca <[email protected]>
|
|
https://source.denx.de/u-boot/custodians/u-boot-stm
CI: https://source.denx.de/u-boot/custodians/u-boot-stm/-/pipelines/30081
- reset: stm32: Fix compilation error
- Remove remaining non-existant STM32_RESET flag
- configs: stm32mp13: Add SPI-NAND UBI boot support
- Support metadata-driven A/B boot for STM32MP25
|
|
Janne Grunau <[email protected]> says:
The Linux device trees for Apple silicon devices cover now most of the
hardware as u-boot's internal device trees for M1 devices. Linux has in
addition device trees M2 and M1 and M2 Pro/Max/Ultra devices which were
never added in u-boot.
The most common use case for u-boot on Apple silicon devices does not
use DTBs from u-boot but passes runtime modified device trees from an
earlier boot loader (m1n1).
This change regresses support for the SPI on M1 and M1 Pro/Max notebooks
as SPI keyboard support is not in upstream Linux. This regression is in
my opinion acceptable due to the limited use of u-boot's DTBs for these
targets.
Link: https://lore.kernel.org/r/[email protected]
|
|
The device tree on Apple silicon devices is passed from a previous
bootloader stage. The bootloader fills in dynamic information so
u-boot can not use its own device tree.
As documented in doc/board/apple/m1.rst it is possible to build boot
bundles (bootloader + device tree + gzipped u-boot binary). These are
useful for testing.
Instead of using u-boot's own device trees for M1 (t8103) devices use
upstream device trees from dts/upstream/src/arm64/apple. The u-boot
device trees have not seen updates since 2022. The upstream linux device
trees have feature parity for the M1 devices. In addition linux has
device trees for M1 Pro/Max/Ultra, M2 and M2 Pro/Max/Ultra devices.
Keep t8103-j274 as default device tree to avoid further updates.
Signed-off-by: Janne Grunau <[email protected]>
Acked-by: Mark Kettenis <[email protected]>
|
|
Remove outdated apple,pinctrl.yaml. The dts/upstream contains the
current version of this binding.
Signed-off-by: Janne Grunau <[email protected]>
Acked-by: Mark Kettenis <[email protected]>
|
|
These SoCs are supported since 2022/2023 but were never added to the
documentation. The devices very similar to the equivalent M1 devices.
The biggest difference is that the M2 and M2 Pro/Max based laptops no
longer use SPI for the keyboard.
Signed-off-by: Janne Grunau <[email protected]>
Acked-by: Mark Kettenis <[email protected]>
|
|
The 'part' command currently allows looking up a partition only by its
number or name.
Extend the 'number', 'start', and 'size' subcommands to support looking
up the partition via its UUID. Unlike names, UUIDs guarantee unique
partition identification, avoiding ambiguity.
The logic is updated to check if the provided string is a valid UUID
before falling back to a name-based search. The help strings for these
subcommands are updated accordingly.
Signed-off-by: Dario Binacchi <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
The Extended Boot Loader Partition (XBOOTLDR) is a standard defined by
the Discoverable Partitions Specification (DPS) to host boot loader
resources outside of the EFI System Partition ([1], [2]).
Defining this GUID (bc13c2ff-59e6-4262-a352-b275fd6f7172) allows U-Boot
to correctly identify and label these partitions using the "xbootldr"
shorthand.
[1] https://uapi-group.org/specifications/specs/discoverable_partitions_specification/#extended-boot-loader-partition:~:text=UEFI%20Specification.-,Extended%20Boot%20Loader%20Partition,-bc13c2ff%2D59e6%2D4262
[2] https://uapi-group.org/specifications/specs/boot_loader_specification/
Signed-off-by: Dario Binacchi <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Signed-off-by: Tom Rini <[email protected]>
|
|
NET=y
In the past, we only had one network stack which was called NET. The
network features were enabled for the legacy (and then only) networking
stack since commit 22353fa6b585 ("bootstd: Add some default filesystems
and commands"). Then instead on relying on NET legacy stack for enabling
networking features, the dependencies were (mostly) changed to depend on
CMD_NET in commit a0c739c184ca ("boot: Create a common BOOT_DEFAULTS for
distro and bootstd"). Then a new stack (lwIP) appeared, then CMD_NET was
made available with this new stack in commit 98ad145db61a ("net: lwip:
add DHCP support and dhcp commmand") making the networking features
possible to enable and finally commit f1e978fd54d9 ("boot: Update tests
around network symbols in BOOT_DEFAULTS_CMDS") made it explicit that we
need *a* network stack to enable some networking features.
Align the bootstd documentation with what's actually implemented as
Kconfig dependencies. Note that BOOTSTD_DEFAULTS selects BOOT_DEFAULTS
which selects BOOT_DEFAULTS_CMDS which then selects network features.
The CMDLINE symbol needs to be enabled as well for BOOT_DEFAULTS to
select BOOT_DEFAULTS_CMDS, but I don't think we need to go that far into
explaining what's required to enable some commands.
Reported-by: Simon Glass <[email protected]>
Closes: https://lore.kernel.org/u-boot/CAFLszTgZC1FGy8965pHiG-u=FhrguftRv41ghQ_Qb_RRXx6tyg@mail.gmail.com/
Signed-off-by: Quentin Schulz <[email protected]>
|
