| Age | Commit message (Collapse) | Author |
|---|
|
This reverts:
- commit e49c84f7bb7b ("doc: usage: cmd: reset: specify when the -edl
option is available")
- commit 1076feb8a3f9 ("cmd: boot: fix edl being shown when not
supported")
- commit 63c806ba0e12 ("qcom_defconfig: enable psci based sysreset")
- commit ef06c5d76ff4 ("cmd: boot: Add '-edl' option to reset command
documentation")
- commit 32825eaddc37 ("sysreset: Implement PSCI based reset to EDL mode
for QCOM SoCs")
- commit fcb48b89813b ("drivers: sysreset: Add sysreset op that can take
arguments")
There was a conflict reverting commit 63c806ba0e12 ("qcom_defconfig:
enable psci based sysreset") due to commit 02ef1859b44f ("configs:
Resync with savedefconfig"), but the conflict resolution was trivial.
The args support for the sysreset uclass contains a logic bug. The first
sysreset device implementing the request_arg callback will consume the
args, not support the specified arg and thus return -EPROTONOSUPPORT
which will stop the iteration over all sysreset devices.
This is an issue if one has multiple sysreset devices and each with
support for different (valid) args. If a sysreset device implements a
-dummy argument and another -foo and a user calls reset -dummy from the
U-Boot CLI, it'll depend on which sysreset device will be attempted
first. If it is the one implementing -foo, it'll return it doesn't
support the argument with -EPROTONOSUPPORT in which case the device
implementing -dummy will never be attempted and instead we'll do a cold
reset which is very likely not what's expected from the user.
Casey suggested[1] we revert this and start from scratch again with a
different implementation instead.
[1] https://lore.kernel.org/u-boot/[email protected]/
Acked-by: Casey Connolly <[email protected]>
Signed-off-by: Quentin Schulz <[email protected]>
|
|
Enable USB fastboot support for downloading and flashing images via
the fastboot protocol.
Signed-off-by: Wadim Egorov <[email protected]>
|
|
Bind the DBSC5 DRAM controller driver on boot in board_early_init_r(),
which brings up the DBSC5 DRAM controller and its PHY and which enables
access to DRAM present on this system.
Add default boot command which loads additional bootloader components
from HF and UFS storage into SRAM and DRAM, and starts those components
on SCP and AP core 0. The system is then capable of reaching U-Boot on
the AP core 0. Specifically, the following components are loaded:
- SCP firmware, 384 kiB from HF offset 0x4c0000 to SCP STCM
- TFA BL31, 256 kiB from UFS0 offset 0x5000 * 4 kiB sectors to DRAM 0x8c200000
- TEE, 2 MiB from UFS0 offset 0x5200 * 4 kiB sectors to DRAM 0x8c400000
- U-Boot, 1 MiB from UFS0 offset 0x7200 * 4 kiB sectors to DRAM 0x8c300000
- IPL parameters table is generated at DRAM address 0x8c100000
Enable pstore command support to allow dumping kernel console from
pstore/ramoops, which is convenient for debugging. Use as follows:
=> pstore set 0x80000000 0x10000 0x400 0x8000 0 0 0
=> pstore display console
Signed-off-by: Marek Vasut <[email protected]>
|
|
Currently, the ENETC device on iMX95 is not enumerated before network
initialization because pci_init() is not called. As a result, no
Ethernet device is registered.
Enable CONFIG_PCI_INIT_R so the PCI buses are enumerated early enough
for the Ethernet Controller to be detected and used.
Fixes: 60d8255d8dc0 ("board: toradex: add Toradex Verdin iMX95")
Signed-off-by: Franz Schnyder <[email protected]>
Reviewed-by: Francesco Dolcini <[email protected]>
|
|
Currently, the ENETC device on iMX95 is not enumerated before network
initialization because pci_init() is not called. As a result, no
Ethernet device is registered.
Enable CONFIG_PCI_INIT_R so the PCI buses are enumerated early enough
for the Ethernet Controller to be detected and used.
Fixes: ff0540fcfe49 ("board: toradex: add Toradex SMARC iMX95")
Signed-off-by: Franz Schnyder <[email protected]>
Reviewed-by: Francesco Dolcini <[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
|
|
Enable watchdog autostart for QCS615 and QCS9100 platforms to ensure
the watchdog timer is automatically started during U-Boot
initialization.
Signed-off-by: Balaji Selvanathan <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Casey Connolly <[email protected]>
|
|
Switch rk3229 boards to upstream devicetree.
Signed-off-by: Johan Jonker <[email protected]>
Reviewed-by: Kever Yang <[email protected]>
|
|
Switch rk3128 boards to upstream devicetree.
Signed-off-by: Johan Jonker <[email protected]>
Reviewed-by: Kever Yang <[email protected]>
|
|
NanoPi M5 supports UFS modules to be inserted into its eMMC/UFS slot,
using the on-chip UFS controller inside the RK3576 SoC.
Enable respective drivers in its default config to be able to load
kernels from UFS.
Signed-off-by: Alexey Charkov <[email protected]>
Reviewed-by: Kever Yang <[email protected]>
|
|
The Radxa ROCK 4D has a eMMC 5.1 / UFS 2.0 module connector.
Enable UFS related Kconfig options to support booting from UFS storage
on ROCK 4D.
Signed-off-by: Jonas Karlman <[email protected]>
Signed-off-by: Alexey Charkov <[email protected]>
Reviewed-by: Kever Yang <[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 following failure occurs right before switching to the kernel:
data abort
pc : [<9ff60162>] lr : [<9ff79d13>]
reloc pc : [<8781c162>] lr : [<87835d13>]
sp : 9bf30f78 ip : 9bf4b140 fp : 007963a0
r10: fffffdfb r9 : 9bf3bed0 r8 : 00004600
r7 : 00000000 r6 : 9ffe5a0c r5 : 00004600 r4 : 9bf4acf0
r3 : f5f5f5f5 r2 : f5f5f5f5 r1 : 9ffe0c5c r0 : 9bf7c130
Flags: NzCv IRQs off FIQs off Mode SVC_32 (T)
Code: 9ffe b158 e9d0 2300 (6053) 601a
Resetting CPU ...
This is due to the fact that the board uses a shared MDIO bus for
both ethernet controllers, but FEC_MXC_SHARE_MDIO is not enabled.
This results in a double free in fecmxc_remove(). To fix this
enable CONFIG_DM_MDIO so the shared MDIO is correctly detected
from the devicetree.
Fixes: 048fdda977ab ("imx: kontron-sl-mx6ul: Enable second ethernet interface")
Signed-off-by: Frieder Schrempf <[email protected]>
|
|
https://source.denx.de/u-boot/custodians/u-boot-raspberrypi
Updates for RPi for 2026.07-rc4:
- pci: bcmstb: Support for bcm2712
|
|
A driver for Broadcom rescal reset controllers ported from
linux/drivers/reset/reset-brcmstb-rescal.c to U-Boot.
Signed-off-by: Torsten Duwe <[email protected]>
Co-authored-by: Oleksii Moisieiev <[email protected]>
Tested-by: Pedro Falcato <[email protected]>
|
|
A driver for Broadcom reset controllers ported from
linux/drivers/reset/reset-brcmstb.c to U-Boot.
Signed-off-by: Torsten Duwe <[email protected]>
Co-authored-by: Oleksii Moisieiev <[email protected]>
Tested-by: Pedro Falcato <[email protected]>
|
|
Add support for the Geist board based on the Renesas R8A779MD (M3Le) SoC, a
register-compatible variant of the R8A77965 (M3N) with reduced peripherals.
The Geist board design references the Renesas Salvator-X/XS boards, adapting
their configuration for the R8A779MD SoC.
The board will be switched to OF_UPSTREAM once the DTs land in upstream.
Signed-off-by: Huy Bui <[email protected]>
Signed-off-by: Nguyen Tran <[email protected]>
Signed-off-by: Marek Vasut <[email protected]>
|
|
https://source.denx.de/u-boot/custodians/u-boot-raspberrypi
Updates for RPi for 2026.07-rc4:
- mmc: bcmstb: Fix non-removable check in bcm2712 init
- mmc: bcm2835_sdhci: Parse generic MMC device tree properties
- rpi_arm64: Enable MBEDTLS/LWIP/WGET and WGET_HTTPS
- video: arm: rpi: Add brcm,bcm2712-hdmi0 compatible
|
|
No watchdog was enabled for STM32MP13 platform. Add the required flags to
support it. As done for STM32MP15 (in SCMI config) and STM32MP2x, we use
the Arm SMC watchdog. The required nodes were already present in Linux
imported DT files (stm32mp13.dtsi & stm32mp135f-dk.dts).
To enable this SMC watchdog on other platforms based on STM32MP13, check
that both the following flags are enabled in the dedicated config file:
CONFIG_WDT=y
CONFIG_WDT_ARM_SMC=y
And that there is a node in Linux board DT that enables the feature, as
it is done in stm32mp135f-dk.dts:
&arm_wdt {
timeout-sec = <32>;
status = "okay";
};
Signed-off-by: Patrick Delaunay <[email protected]>
Signed-off-by: Yann Gautier <[email protected]>
Reviewed-by: Patrice Chotard <[email protected]>
|
|
Enable the arm watchdog over SMC driver. This allows using a secure
watchdog, based on IWDG1 peripheral and managed by OP-TEE.
The driver will be probed if a watchdog node with "arm,smc-wdt"
compatible is enabled.
Signed-off-by: Lionel Debieve <[email protected]>
Signed-off-by: Yann Gautier <[email protected]>
Reviewed-by: Patrice Chotard <[email protected]>
|
|
Using stm32mp15_defconfig with stm32mp157c-dk2-scmi.dtsi device tree
with optee-4.10.0, we got:
U-Boot 2026.07-rc2-00052-g215496fec59b (May 18 2026 - 15:05:34 +0200)
CPU: STM32MP157CAC Rev.B
Model: STMicroelectronics STM32MP157C-DK2 SCMI Discovery Board
Board: stm32mp1 in trusted mode (st,stm32mp157c-dk2-scmi)
alloc space exhausted ptr 80060 limit 80000
optee optee: PTA_BSEC invoke failed TEE err: 0, err:fffffff4
alloc space exhausted ptr 80040 limit 80000
alloc space exhausted ptr 80020 limit 80000
DRAM: alloc space exhausted ptr 80040 limit 80000
RAM init failed: -12
initcall_run_f(): initcall dram_init() failed
CONFIG_SYS_MALLOC_F_LEN need to be increased to fix this issue
Reported-by: Yann Gautier <[email protected]>
Signed-off-by: Patrice Chotard <[email protected]>
Reviewed-by: Patrick Delaunay <[email protected]>
|
|
Enable LWIP and HTTPS on the Raspberry Pi arm64 platform to be able to
use it in the boot process.
Signed-off-by: Peter Robinson <[email protected]>
Reviewed-by: Matthias Brugger <[email protected]>
|
|
Resync all defconfig files using qconfig.py
Signed-off-by: Tom Rini <[email protected]>
|
|
Add support for building U-Boot for Cortex-M33 RSIP core in Renesas
R-Car Gen5 R8A78000 X5H SoC. The main goal is to start U-Boot on the
Cortex-M33 RSIP core, which initializes the hardware and then starts
the Cortex-M33 SCP and Cortex-A720 cores which run the SCP firmware
and applications software respectively. The SCP is responsible for
platform resource management, and is used to start other CPU cores.
The Cortex-M33 build contains its own r8a78000_ironhide_cm33_defconfig
which configures the build for aarch32 instruction set compatible with
the ARMv8M core. The build also uses -cm33 DT and -u-boot.dtsi which
are derived from their non-CM33 counterparts, and add CM33 specifics.
The arch/arm/mach-renesas/u-boot-rsip.lds is derived from generic
arch/arm/cpu/u-boot.lds with adjustments to cater to the RSIP core,
those are entrypoint before vectors, __data_start/__data_end symbols
for data-only relocation, and placement of BSS into read-write SRAM
area.
Signed-off-by: Marek Vasut <[email protected]>
|
|
Enable OF_UPSTREAM to use upstream Linux kernel DT source as a base
for U-Boot control DT. Retain currently present parts of the DT which
are not yet part of upstream Linux kernel DT in -u-boot.dtsi files
until they get replaced by upstream equivalents. Add renesas/ prefix
to the DEFAULT_DEVICE_TREE as part of the switch.
Unused i2c2..i2c8 nodes have been removed, and will become available
once upstream Linux kernel DT adds those nodes.
The DRAM_RSV_SIZE has been updated to cover first 518 MiB of DRAM,
which are reserved for firmware and other use.
Note that all DT parts in -u-boot.dtsi are not considered stable DT
bindings and may change before they land in Linux kernel and become
stable DT ABI.
Signed-off-by: Marek Vasut <[email protected]>
|
|
Mikhail Kshevetskiy <[email protected]> says:
This patch series fixes an7581_evb_defconfig.
Link: https://lore.kernel.org/r/[email protected]
|
|
Booting image generated with
make an7581_evb_defconfig
will results in
U-Boot 2026.04-00924-gfb815bd8793b (Apr 27 2026 - 15:08:30 +0300)
CPU: Airoha AN7581
DRAM: 512 MiB
Core: 35 devices, 19 uclasses, devicetree: separate
MMC: mmc@1fa0e000: 0
Loading Environment from MMC... *** Warning - No block device, using default environment
Loading Environment from MTD... *** Warning - get_mtd_device_nm() failed, using default environment
BUG at drivers/mtd/mtdcore.c:898/__put_mtd_device()!
BUG!
resetting ...
This happens because no any mtd partition defined in dts/mtdparts.
Disabling of ENV_IS_IN_MTD fixes an issue.
Signed-off-by: Mikhail Kshevetskiy <[email protected]>
|
|
This enables U-Boot loading from any 4K aligned address.
It makes U-Boot debugging a bit simpler.
Signed-off-by: Mikhail Kshevetskiy <[email protected]>
|
|
The RDB doesn't support NAND boot at all, remove the config for it.
Apparently, it was introduced by commit dd84058d24ff ("kconfig: add
board Kconfig and defconfig files") which ran some scripts. Maybe that
script was wrong or the source boards.cfg was wrong. In any case, there
is no NAND flash on the RDB.
Signed-off-by: Michael Walle <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
The RCW was just supporting SPI boot. Add a second one for the SDcard
boot. While at it, use the same naming scheme as for the other NXP
boards.
Signed-off-by: Michael Walle <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
Switch to the upstream device tree, which already includes the UART
nodes we need for the DM.
We also need to increase malloc area before relocation otherwise you'll
get the following error and the board panics:
DRAM: Initializing....using SPD
alloc space exhausted ptr 414 limit 400
Signed-off-by: Michael Walle <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
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]>
|
|
The main use case for u-boot on Apple silicon based devices is to
provide an EFI based bootloader for operating systems. This uses a
generic u-boot image with DTBs passed from an earlier boot loader
(m1n1). Use the generic board name "mac" for this purpose.
Signed-off-by: Janne Grunau <[email protected]>
|
|
Resync all defconfig files using qconfig.py
Signed-off-by: Tom Rini <[email protected]>
|
|
https://source.denx.de/u-boot/custodians/u-boot-at91
First set of u-boot-at91 fixes for the 2026.07 cycle:
- Cleanup some useless code
|
|
Pull request net-20260506.
net:
- phy: dp83867: default to 2ns delay if unspecified in device-tree
- nfs: fix buffer overflow in nfs_readlink_reply()
- cpsw: Add cpsw-switch DT binding support
- phy: add common PHY polarity properties support
- phy: adin: add support for the ADIN1200 phy
- macb: support for instances with less features
- phy: mscc: add support for the VSC8572
net-lwip:
- wget: correct diagnostic output
|
|
Add sandbox DM unit tests for the PHY common properties library and the
corresponding device tree test nodes to arch/sandbox/dts/test.dts.
Also enable CONFIG_PHY_COMMON_PROPS in configs/sandbox_defconfig so
the tests are built and run in the sandbox environment.
The test file covers rx/tx polarity lookups for all relevant cases:
- missing property (defaults to PHY_POL_NORMAL)
- single value without names array (applies to all modes)
- count mismatch between values and names arrays (-EINVAL)
- name found by exact match
- name not found with no "default" fallback (-EINVAL)
- name not found with a "default" entry (uses fallback value)
- unsupported polarity value (-EOPNOTSUPP)
Ported from Linux KUnit test:
linux/drivers/phy/phy-common-props-test.c
Signed-off-by: Lucien.Jheng <[email protected]>
|
|
There are two reasons why the USB stack needs to be
started before handing to bootflow or other boot
sequences:
1. When a USB hub is present on the board, we need to
do the required sequences to make it usable
2. To make USB storage devices 'visible' to bootflow
without further intervention
Signed-off-by: Mathew McBride <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
Two recent additions to the mainline device tree allow us
to switch away from the local U-Boot copy:
* Board/embedded controller (traverse,ten64-controller)
is now in the mainline device tree.
* USB Hub (USB5744) connections were also added to
the mainline device tree but not in U-Boot.
The LS1088A and Ten64 device trees in U-Boot were actually
'synced' to mainline some time ago, so the content
(except for the changes mentioned above) is identical.
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Mathew McBride <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
Ten64 board revs A through C have a Microchip USB5744
hub on the board, which must be configured over I2C
at boot time to become usable.
This function has not been part of the mainline
U-Boot for this board until now, as a mainline driver
and device-tree binding is now available for the USB5744.
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Mathew McBride <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
We have added board_fix_fdt to remove elements from U-Boot's
internal FDT related to the USB hub, so CONFIG_OF_BOARD_FIXUP
needs to be enabled to utilize it.
Signed-off-by: Mathew McBride <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
CONFIG_SPL_MMC=n and CONFIG_SPL_DM_SPI=n are each listed twice in the
defconfig. Remove the redundant occurrences so each option appears only
once.
Signed-off-by: Aristo Chen <[email protected]>
|
|
CONFIG_SPL_MMC=n is listed twice in the defconfig. Remove the redundant
occurrence so each option appears only once.
Signed-off-by: Aristo Chen <[email protected]>
|
|
CONFIG_SCMI_FIRMWARE=y is listed twice in the defconfig. Remove the
redundant occurrence so each option appears only once.
Signed-off-by: Aristo Chen <[email protected]>
|
|
Francesco Dolcini <[email protected]> says:
Enable standard EFI support for all the arm64 Toradex boards, as
required for booting standard aarch64 Linux distribution, following the
ARM recommendations for SystemReady compliance.
The RTC used on these boards is not currently supported by U-Boot,
therefore it is not enabled at the moment.
Link: https://developer.arm.com/documentation/DUI1101/4-5/Configure-U-Boot-for-SystemReady
Link: https://lore.kernel.org/r/[email protected]
|
|
Enable EFI related options, as suggested for booting standard aarch64
Linux distribution, following the ARM recommendations for SystemReady
compliance [1].
The RTC used on this board is not currently supported by U-Boot,
therefore it is not enabled at the moment.
Link: https://developer.arm.com/documentation/DUI1101/4-5/Configure-U-Boot-for-SystemReady [1]
Signed-off-by: Francesco Dolcini <[email protected]>
|
|
Enable EFI related options, as suggested for booting standard aarch64
Linux distribution, following the ARM recommendations for SystemReady
compliance [1].
The RTC used on this board is not currently supported by U-Boot,
therefore it is not enabled at the moment.
Link: https://developer.arm.com/documentation/DUI1101/4-5/Configure-U-Boot-for-SystemReady [1]
Signed-off-by: Francesco Dolcini <[email protected]>
|
|
Enable EFI related options, as suggested for booting standard aarch64
Linux distribution, following the ARM recommendations for SystemReady
compliance [1].
The RTC used on this board is not currently supported by U-Boot,
therefore it is not enabled at the moment.
Link: https://developer.arm.com/documentation/DUI1101/4-5/Configure-U-Boot-for-SystemReady [1]
Signed-off-by: Francesco Dolcini <[email protected]>
|
|
Enable EFI related options, as suggested for booting standard aarch64
Linux distribution, following the ARM recommendations for SystemReady
compliance [1].
The RTC used on this board is not currently supported by U-Boot,
therefore it is not enabled at the moment.
Link: https://developer.arm.com/documentation/DUI1101/4-5/Configure-U-Boot-for-SystemReady [1]
Signed-off-by: Francesco Dolcini <[email protected]>
|
