| Age | Commit message (Collapse) | Author |
|---|
|
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]>
|
|
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]>
|
|
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 standard EFI support, as required 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 standard EFI support, as required 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]>
|
|
- stmark2 / mcf5441x updates
|
|
Enable bdinfo command.
Signed-off-by: Angelo Dureghello <[email protected]>
---
Changes in v2:
- recreated by make menuconfig
|
|
Add support for mmc.
Signed-off-by: Angelo Dureghello <[email protected]>
---
Changes in v2:
- recreated by make menuconfig
|
|
With correct POSIX handling, unquoted empty variables can turn the
expression like
test -n ${fdtfile}
into
test -n
The POSIX handling for single argument `test` evaluates it as true,
so the fallback initialization will be skipped unexpectedly.
Quoting variable expansions in `test` expressions will always result in
correct behavior for empty and non-empty values.
This change was triggered by
commit 8b0619579b22 ("cmd: test: fix handling of single-argument form of test")
The aim is to have a less fragile codebase that is not dependent on a
quirk of the shell implementation.
Use quoted variable expansions in `test` expressions throughout.
Signed-off-by: Franz Schnyder <[email protected]>
Acked-by: Francesco Dolcini <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
All of these platforms enable CONFIG_BOARD_EARLY_INIT_F and then have a
do-nothing board_early_init_f function. Change to not enabling the
option and so not needing an empty function.
Signed-off-by: Tom Rini <[email protected]>
|
|
CONFIG_DRAM_SUNXI_TPR6 is the only DRAM config parameter that has a
non-zero default value. Since we need to provide a value for all the
other parameters anyway, avoiding TPR6 makes no real difference.
To make matters worse, TPR6 is a compound value covering multiple DRAM
types, but also spans over three SoCs, which makes it hard to find one
good default value.
Drop the default from Kconfig, and put some explicit values in the
defconfigs for the few boards that were relying on the default so far.
The value is taken from one BSP, only the lower byte matters anyway for
those boards, all using DDR3 DRAM.
Signed-off-by: Andre Przywara <[email protected]>
Reviewed-by: Jernej Skrabec <[email protected]>
Reviewed-by: Paul Kocialkowski <[email protected]>
|
|
We recently gained a simple way to enable a power LED very early in the
SPL boot, through simple Kconfig variables.
Add those symbols to those boards' defconfigs where the DT indicates a
default-on power LED. The number used is <port bank> * 32 + <pin no>,
an active low setup means CONFIG_SPL_SUNXI_LED_STATUS_ACTIVE_HIGH must be
undefined.
This will light up the power LED very early in the (SPL) boot phase on
those 64-bit boards.
Signed-off-by: Andre Przywara <[email protected]>
Reviewed-by: Paul Kocialkowski <[email protected]>
|
|
We recently gained a simple way to enable a power LED very early in the
SPL boot, through simple Kconfig variables.
Add those symbols to those boards' defconfigs where the DT indicates a
default-on power LED. The number used is <port bank> * 32 + <pin no>,
an active low setup means CONFIG_SPL_SUNXI_LED_STATUS_ACTIVE_HIGH must be
undefined. Since its default is "high", we can skip the symbol in the
defconfig in this case.
This will light up the power LED very early in the (SPL) boot phase on
those 32-bit boards.
Signed-off-by: Andre Przywara <[email protected]>
Reviewed-by: Paul Kocialkowski <[email protected]>
|
|
The newly introduced Allwinner SPL LED "framework" defined a
SPL_SUNXI_LED_STATUS_STATE Kconfig symbol, that was supposed to denote
the active-low vs. active-high polarity of the LED. However this is
a bool symbol, so it will simply vanish if not defined, and we cannot use
it directly inside a C statement.
Filter the symbol through the IS_ENABLED() macro, which will return 0 if
the symbol is not defined, which is the intended value here.
Since the STATUS_STATE name is a bit confusing, rename it to ACTIVE_HIGH
on the way, because that is its real meaning. Also the LED_STATUS_BIT
name for the GPIO number is similarly a remnant of the old status LED
code, so rename it to LED_STATUS_GPIO as well.
This fixes configuring LEDs with active-low polarity.
Fixes: 256557dd9aae ("sunxi: remove usage of legacy LED API")
Signed-off-by: Andre Przywara <[email protected]>
Reviewed-by: Paul Kocialkowski <[email protected]>
Closes: https://lore.kernel.org/u-boot/adfMQBPdntWy1KIq@shepard/
Acked-by: Quentin Schulz <[email protected]>
|
|
https://source.denx.de/u-boot/custodians/u-boot-stm
- arm; stm32mp2: Factorize TAMP_FWU_BOOT_IDX_MASK/OFFSET definition
- arm: stm32mp: Drop unnecessary BOARD_EARLY_INIT_F usage
- board: stm32mp25: support dynamic A/B bank bootup
- board: stm32pm1: Fix board_check_usb_power()
- clk: stm32: Add STM32MP23 support
- video: stm32: dsi: fix unchecked return values
- video: support Rocktech RK050HR345-CT106A panel
- Remove non-existent STM32_RESET flag
|
|
All of these platforms enable CONFIG_BOARD_EARLY_INIT_F and then have a
do-nothing board_early_init_f function. Change to not enabling the
option and so not needing an empty function.
Signed-off-by: Tom Rini <[email protected]>
Reviewed-by: Patrice Chotard <[email protected]>
|
|
https://source.denx.de/u-boot/custodians/u-boot-mediatek
* MMC fixes for Genio 520/720 (mt8189)
* SPI NOR Flash controller fixes
* SPI NOR Flash support for Genio 520/720
* PMIC controller fixes
* PMIC support for Genio 1200 (mt8195)
* Drop CONFIG_IDENT_STRING to be consistent across the platform
* Remove empty header on mt7622
|
|
This platform is often close to the binary size limit and minor changes
lead to exceeding image size. Enable LTO for this platform.
Signed-off-by: Tom Rini <[email protected]>
---
Cc: Marek Vasut <[email protected]>
Cc: Tien Fong Chee <[email protected]>
|
