test/py: Correct handling of exceptions

If an Unexpected exception is thrown in a test, an undefined variable
error is reported. Fix this.

Signed-off-by: Simon Glass <sjg@chromium.org>
Fixes: 85d7dae377a ("test: Detect dead connections")
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>

test/py: Use the correct fixture name in exception handler

If a BootFail exception is thrown in a test, it is not handled
correctly. Use the correct fixture variable 'ubman_fix' to resolve this.

Signed-off-by: Simon Glass <sjg@chromium.org>
Fixes: d9ed4b75add ("test/py: Drop u_boot_ prefix on test files")
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>

toradex-smarc-imx8mp: add SPL_STACK size and SPL_HAVE_INIT_STACK

When the toradex-smarc-imx8mp_defconfig file was first added, SPL_STACK
was set to 0x960000, but SPL_HAVE_INIT_STACK wasn't enabled.

This led to SPL_STACK being correctly dropped in commit 25fefa05d732
("configs: Resync with savedefconfig"), since SPL_HAVE_INIT_STACK was
missing, which ended up making the board not boot.

Fix this by adding SPL_STACK back and making sure SPL_HAVE_INIT_STACK is
enabled.

Fixes: dde53eae88d6 ("board: toradex: add Toradex SMARC iMX8MP")
Signed-off-by: Hiago De Franco <hiago.franco@toradex.com>
Acked-by: Francesco Dolcini <francesco.dolcini@toradex.com>

board: var-som-mx8mn: Fix alloc space exhausted in SPL

After enabling some options to support EEPROM read in SPL
(CONFIG_SPL_I2C_EEPROM), the following error appears:

    alloc space exhausted

Increasing SYS_MALLOC_F_LEN from 8kB to 64kB fixes the problem.

But instead of manually increasing the value, adopt method used in
commit ce3f23404c19 ("board: bsh: imx8mn_bsh_smm_s2/s2pro: enlarge
CONFIG_SPL_SYS_MALLOC_F_LEN"):

Dropping CONFIG_SPL_SYS_MALLOC_F_LEN option allows it to be set to the
default value of CONFIG_SYS_MALLOC_F_LEN, which is set by default to 64kB
(0x10000) on i.MX8M platforms.

Suggested-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>

imx91: Drop OF_UPSTREAM

i.MX91 device tree still not landed in linux kernel, so drop OF_UPSTREAM
and move the device tree files to arch/arm/dts

Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>

mmc: Kconfig: Really correct dependencies SDHCI ADMA options

When doing the investigation for commit 53bb8fdea12a ("mmc: Kconfig:
Correct dependencies SDHCI ADMA options") I missed the implications of
MMC_SDHCI_ADMA_HELPERS. The problem is that FSL_ESDHC via the
FSL_ESDHC_SUPPORT_ADMA2 option will also enable these helper functions.
This in turn means the correct dependency here is
MMC_SDHCI_ADMA_HELPERS and not *MMC_SDHCI_ADMA.

Reported-by: Heiko Thiery <heiko.thiery@gmail.com>
Signed-off-by: Tom Rini <trini@konsulko.com>

Merge branch 'master' of https://source.denx.de/u-boot/custodians/u-boot-sh

One more board to support, this time Retronix Sparrow Hawk based on
Renesas R-Car V4H SoC . This is board support, so master branch should
be fine. The DT in dts/upstream/ is a backport from Linux, and will
disappear on next DT sync.

arm64: dts: renesas: r8a779g3: Add Retronix R-Car V4H Sparrow Hawk board support

Add Retronix R-Car V4H Sparrow Hawk board based on Renesas R-Car V4H ES3.0
(R8A779G3) SoC. This is a single-board computer with single gigabit ethernet,
DSI-to-eDP bridge, DSI and two CSI2 interfaces, audio codec, two CANFD ports,
micro SD card slot, USB PD supply, USB 3.0 ports, M.2 Key-M slot for NVMe SSD,
debug UART and JTAG.

DT is imported from Linux next commit:
a719915e76f2 ("arm64: dts: renesas: r8a779g3: Add Retronix R-Car V4H Sparrow Hawk board support")

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>

arm64: renesas: Introduce renesas_dram_init_banksize()

Introduce weak renesas_dram_init_banksize() function which is meant
to be used to adjust DRAM bank sizes after the common Renesas board
DRAM bank handling code finished. This is mainly meant for boards
which ship with multiple DRAM size options, which can be detected
at runtime. This allows such boards to ship with single U-Boot
binary on all boards.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>

Prepare v2025.07-rc4

Signed-off-by: Tom Rini <trini@konsulko.com>

pylibfdt: correct license information

Setuptools 78.1.1 shows warnings:

* Pattern 'GPL' did not match any files.
* Pattern 'BSD-2-Clause' did not match any files.
* SetuptoolsDeprecationWarning: License classifiers are deprecated.

Cf. https://packaging.python.org/en/latest/guides/writing-pyproject-toml/#license

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

Revert "caam: Fix CAAM error on startup"

This reverts commit 159b6f0e119962ce5da645f548cefe9196c8778e.

Since commit 159b6f0e1199 ("caam: Fix CAAM error on startup") the following
regression was reported by Tim Harvey:

"I've found that this patch causes a regression on an imx8mm board
(imx8mm_venice_defconfig) where the first call to caam_rng_read fails
here in jr_dequeue but if you call it again it works. With some
debugging added:
SEC0:  RNG instantiated
...
Hit any key to stop autoboot:  0
u-boot=> rng list
RNG #0 - caam-rng
u-boot=> rng 0 10
caam_rng_read caam-rng len=16
run_descriptor_jr_idx idx=0
Error in SEC deq: -1
caam_rng_read_one run_descriptor_jr failed: -1
caam_rng_read caam-rng caam_rng_read_one failed: -5
Reading RNG failed
u-boot=> rng 0 10
caam_rng_read caam-rng len=16
run_descriptor_jr_idx idx=0
00000000: ad 2e ad c0 2a 12 27 c4 65 82 66 19 be ef f6 07  ....*.'.e.f.....

If I revert your patch caam_rng_read works initially and on subsequent
calls."

" I ran into this when I was testing
lwIP HTTPS as it causes anything that uses dm_rng to fail the first
time (such as HTTPS)."

Revert it for now to avoid the regression.

Reported-by: Tim Harvey <tharvey@gateworks.com>
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Acked-by: Peng Fan <peng.fan@nxp.com>

configs: Resync with savedefconfig

Resync all defconfig files using qconfig.py

Signed-off-by: Tom Rini <trini@konsulko.com>

Merge patch series "arm: armv7: fix a bug that prevents CONFIG_BLOBLIST and CONFIG_POSITION_INDEPENDENT to be enabled together"

Yang Xiwen <forbidden405@outlook.com> says:

This patchset also enables CONFIG_POSITION_INDEPENDENT for qemu boards
to avoid similar issues to happen again in the future.

Link: https://lore.kernel.org/r/20250531-pie_blob_fix-v1-0-7b4a37987dbc@outlook.com

arm: qemu: Add imply CONFIG_POSITION_INDEPENDENT

Add 'imply CONFIG_POSITION_INDEPENTDENT' for QEMU arm arch. This allows
qemu arm boards to load u-boot.bin at any address. It is skipped by
default when u-boot is loaded by either --bios or --kernel.

To load u-boot.bin at a different address, one can use u-boot
chain-loading or qemu loader device[1].

[1] https://www.qemu.org/docs/master/system/generic-loader.html

Signed-off-by: Yang Xiwen <forbidden405@outlook.com>

arm: armv7: restore section to .text after saved_args

when CONFIG_BLOBLIST is enabled, the section is switched to .data but is
not switched back to .text. It makes all the code below placed in .data
section, also breaks CONFIG_POSITION_INDEPENDENT.

Fix it by adding `.section .text` to switch the section back to .text.

Fixes: 5103e69344d6 ("arm: armv7: save boot arguments")
Signed-off-by: Yang Xiwen <forbidden405@outlook.com>

Merge tag 'u-boot-rockchip-20250606' of https://source.denx.de/u-boot/custodians/u-boot-rockchip

CI: https://source.denx.de/u-boot/custodians/u-boot-rockchip/-/pipelines/26117

- Allow to silent TPL/SPL debug console;
- enable exFAT support for Theobroma boards;
- Fix SD power initialization in SPL for rk3399-nanopi4

Merge tag 'doc-2025-07-rc4' of https://source.denx.de/u-boot/custodians/u-boot-efi

Pull request doc-2025-07-rc4

Documentation:

* fix typo in gcc.rst
* correct EFI_TCG2_PROTOCOL_MEASURE_DTB description
* Add missing reference to firmware for BB-AI64
* Tidy up the bootefi-command docs

doc: build: fix typo in gcc.rst

Fix a typo error in gcc.rst, changing "out-out-tree" to
"out-of-tree" in the Out-of-tree section.

Signed-off-by: BehradElmi <behradelmi1@gmail.com>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

doc: efi_loader: Tidy up the bootefi-command docs

There are backslashes in some of the tags which seems to be unnecessary.
Remove then.

Change the word 'either' to 'any' since there are three options.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

doc: board: ti: Add missing firmware for BB-AI64

The details of the sysfw.itb from the R5 build that
also needs to be copied as part of the target images
is missing, but is included in the image formats a
little further down, so add it to the instructions.

Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Acked-by: Nishanth Menon <nm@ti.com>

efi_loader: correct EFI_TCG2_PROTOCOL_MEASURE_DTB description

%s/data that change/data that changes/
%s/cannot be used has/cannot be used for/
%s/Otherwise/Otherwise,/
%s/allows better measurement/allows for better measurement/

Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

power: rk8xx: fix swapped mask and value in init registers for RK806

The val (the bits to set) is the second member of the reg_data structure
and mask the third one. We obviously want to clear bits 6 and 7 in order
to only set bit 7 in there instead of only clearing bit 7 in order to
write bits 6 and 7 (which makes no sense).

Fortunately, according to the datasheet, bit 6 value doesn't matter when
bit 7 is set so this is essentially just a cosmetic change, no intended
change in behavior.

Fixes: f172575d92cd ("power: rk8xx: add support for RK806")
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

rockchip: rk3399-nanopi-4: Enable IO-domain driver in SPL

The NanoPi RK3399 boards support UHS-I (up to SDR104) SD cards, however
using any of these 1.8v modes results in a boot failure in SPL upon soft
reboot.

The issue is that the "vcc_sdio" regulator is left at 1.8v on reboot
and the corresponding GPIO defaults to 3.3v. This prevents the SD card
from being reinitialized and read successfully.

This change enables the RK8XX regulators and Rockchip IO-domain drivers
in SPL, which initializes "vcc_sdio" regulator to 3.0v and configures
the GPIO for the correct level on boot.

Signed-off-by: Justin Klaassen <justin@tidylabs.net>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

rockchip: rk3399-nanopi-4: Allow MMC driver to control SD regulators

This change removes the "regulator-always-on" property from the
"vcc3v0_sd" (vmmc-supply) and "vcc_sdio" (vqmmc-supply) regulators,
which otherwise prevents the MMC driver from being able to power cycle
the SD card as part of the initialization procedure.

It also removes the "regulator-boot-on" from the "vcc_sdio" regulator,
which could theoretically damage a SD card that is already initialized
in a low voltage mode.

Signed-off-by: Justin Klaassen <justin@tidylabs.net>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

regulator: rk8xx: Add CONFIG_SPL_REGULATOR_RK8XX

Allows use of the regulator functions of the RK8XX PMIC in SPL, which is
necessary to support the functionality of the Rockchip IO-domain driver
on relevant platforms.

Signed-off-by: Justin Klaassen <justin@tidylabs.net>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

rockchip: io-domain: Add CONFIG_SPL_ROCKCHIP_IODOMAIN

Allows use of the Rockchip IO-domain driver in SPL to configure
the GPIO to match the voltage supplied by specific regulators
(e.g. "vcc_sdio").

Signed-off-by: Justin Klaassen <justin@tidylabs.net>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

rockchip: io-domain: Add debug logging for regulators during probe

Log the value of the regulators during initialization of the IO-domain
driver to aid in debugging GPIO voltage configuration problems.

Signed-off-by: Justin Klaassen <justin@tidylabs.net>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

configs: puma-rk3399: enable exFAT support

Our upcoming Mass Flasher solution will be storing boot artifacts on an
exFAT partition so enable its support.

Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

configs: tiger-rk3588: enable exFAT support

Our upcoming Mass Flasher solution will be storing boot artifacts on an
exFAT partition so enable its support.

Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

configs: jaguar-rk3588: enable exFAT support

Our upcoming Mass Flasher solution will be storing boot artifacts on an
exFAT partition so enable its support.

Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

configs: ringneck-px30: enable exFAT support

Our upcoming Mass Flasher solution will be storing boot artifacts on an
exFAT partition so enable its support.

Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

rockchip: px30: Fix hard dependency to DEBUG_UART_BOARD_INIT

Because DEBUG_UART_BOARD_INIT depends on DEBUG_UART, hard dependency
to DEBUG_UART_BOARD_INIT in ROCKCHIP_PX30 can cause warnings if
DEBUG_UART is disabled.
The DEBUG_UART_BOARD_INIT is already implied by ARCH_ROCKCHIP entry.
Remove hard dependency from ROCKCHIP_PX30, so that it will be
consistent with other rockchip boards.

Signed-off-by: Lukasz Czechowski <lukasz.czechowski@thaumatec.com>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

rockchip: px30: Weaken dependency TPL/SPL serial

Allow to disable serial console in TPL and SPL. Weak dependency
to SPL_SERIAL and TPL_SERIAL is also used in other Rockchip boards.

Signed-off-by: Lukasz Czechowski <lukasz.czechowski@thaumatec.com>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

debug_uart: Replace debug functions with dummies if CONFIG_DEBUG_UART is not set

In case DEBUG UART is not used, define dummy macros replacing
the actual function implementations that will not be available.
This allows to compile code and avoid linker errors.
Redefine the DEBUG_UART_FUNCS macro if DEBUG UART is not available,
to avoid compilation errors.

Signed-off-by: Lukasz Czechowski <lukasz.czechowski@thaumatec.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

ram: rockchip: Fix dependency of RAM_ROCKCHIP_DEBUG

The RAM_ROCKCHIP_DEBUG can be used only if DEBUG_UART is
available.
The next commit introduces changes in definition of debug
uart functions, so that DEBUG_UART is required to be defined
in order to initialize uart and use print functions.

Signed-off-by: Lukasz Czechowski <lukasz.czechowski@thaumatec.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>

efi: stub: Change _debug_uart_putc function to inline

Update definition of _debug_uart_putc to static inline.
This will allow to avoid compilation warnings about unused code
after introduction of patch changing debug uart functions to
dummies if CONFIG_DEBUG_UART is not set.
This also matches the instructions in include/debug_uart.h and
provides consistency with implementations for other platforms.

Signed-off-by: Lukasz Czechowski <lukasz.czechowski@thaumatec.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

arm: uniphier: Change _debug_uart_putc function to inline

Update the definition of _debug_uart_putc to static inline.
This matches the instructions in include/debug_uart.h and
provides consistency with implementations for other platforms.

Signed-off-by: Lukasz Czechowski <lukasz.czechowski@thaumatec.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

Merge tag 'xilinx-for-v2025.07-rc4' of https://source.denx.de/u-boot/custodians/u-boot-microblaze

AMD/Xilinx/FPGA changes for v2025.07-rc4

usb:
- Fix regulator handling

net:
- Fix MII clock handling

phy:
- Fix GTR line logic for sgmii

pci:
- Fix pcireg_base logic

fpga:
- Fix change handling in intel_sdm_mb driver

mach-k3: am62ax: enable caches for the SPL stage

board_init_f for the am62a is missing the call to spl_enable_cache which
exists for all other am62 platforms (check am625_init.c &
am62p5_init.c).

This allows the usage of caches while loading and parsing the u-boot.img
FIT resulting in ~2x speedup in the A53 SPL stage.

Signed-off-by: Anshul Dalal <anshuld@ti.com>

board: ti: am62ax: env: Use default MMC related args

There are common MMC args for TI plats in include/environment/ti/mmc.env.
Since we already include this, there is no need to redefine these
MMC vars. Use the defaults.

This seems like something that could have been done while refactoring
these vars in the first place as it happened after this AM62A file
was available hence the fixes tag.

Reported-by: Chirag Shilwant <c-shilwant@ti.com>
Fixes: 3709b529156e ("env: ti: mmc.env: Move mmc related args to common place")
Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
Acked-by: Chirag Shilwant <c-shilwant@ti.com>
Reviewed-by: Judith Mendez <jm@ti.com>

mmc: am654_sdhci: Clear UHS_MODE_SELECT when <= MMC_HS_52

This clears UHS_MODE_SELECT for timing modes <= MMC_HS_52.

When initializing to HS400 mode, the host controller downgrades to non-uhs
modes so clear UHS_MODE_SELECT at modes <= MMC_HS_52.

This fixes eMMC writes on j7200 EVM.

Fixes: 6067aa66b3bb ("mmc: am654_sdhci: Add am654_sdhci_set_control_reg")
Signed-off-by: Judith Mendez <jm@ti.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>

x86: Correct condition for init_cache_f_r()

The condition here is reversed, which makes link and coral very slow,
leading to lab failures.

Fixes 6c171f7a184 ("common: board: make initcalls static")

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>

usb: onboard-hub: Fix return type for regulator APIs

Apart from ENOENT observing return value as ENOSYS when
!DM_REGULATOR that's why cover both configurations.
Changed code is not working as operation should be "&&"
not "||" (ret != -ENOENT && ret != -ENOSYS).

Also fix the remove function where the regulator_set_enable_if_allowed()
function is returning an error.

Signed-off-by: Padmarao Begari <padmarao.begari@amd.com>
Reviewed-by: Marek Vasut <marex@denx.de>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/a2d520f14efc30fc28ec59881205e156dabbfcd9.1744350937.git.michal.simek@amd.com

Merge tag 'qcom-more-for-2025.07' of https://source.denx.de/u-boot/custodians/u-boot-snapdragon

More Qualcomm fixes for 2025.07

* Adjust fdtfile logic to support more boards
* Support linux,code variable in qcom-pmic button driver
* Minor CLK API adjustments and apq8096/msm8916 fixes
* vbus regulator register fixes
* dragonboard410c KASLR support and other fixes

arm/dts/qemu-sbsa: Fix interrupt

Change the vcpumntirq in the GICv3 node from SPI to PPI.

Prevents Linux from complaining:
'[Firmware Bug]: CPU interface incapable of MMIO access'

Fixes: 6d722894fd48 "board: emulation: Add QEMU sbsa support"

Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>

scripts/spelling.txt: Sync script with kernel v6.15

Keep spelling.txt in sync with the version from kernel v6.15.

Reported-by: Yao Zi <ziyao@disroot.org>
Reviewed-by: Yao Zi <ziyao@disroot.org>
Signed-off-by: Tom Rini <trini@konsulko.com>

mach-snapdragon: Update fdtfile logic to work for RB1 and RB2

RB1 and RB2 have three root compatibles where the last one can't be used
to decode fdtfile name (qcm* vs qrb*). So rather just rely on the first
compatible to retrieve the SoC name.

Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250505124333.12344-1-sumit.garg@kernel.org
Signed-off-by: Casey Connolly <casey.connolly@linaro.org>

button: qcom-pmic: allow to specify code in devicetree

Most device vendors put "Volume Down" button onto PMIC RESIN.
But Sony is special: see
dts/upstream/src/arm64/qcom/sdm630-sony-xperia-nile.dtsi or [1].
They put "Volume Down" on PMIC GPIO 7 where others usually put
"Volume Up", and KEY_VOLUMEUP is inside &pon_resin.

Currently if you boot U-Boot on such Sony device, you end up
with 2 "Volume Down" buttons, and no "Volume Up", which makes
navigating menu problematic.

Support reading devicetree "linux,code" property and override
statically defined button code & label based on that.

[1] https://elixir.bootlin.com/linux/v6.15-rc3/source/arch/
arm64/boot/dts/qcom/sdm630-sony-xperia-nile.dtsi#L263

Signed-off-by: Alexey Minnekhanov <alexeymin@postmarketos.org>
Signed-off-by: Alexey Minnekhanov <alexeymin@minlexx.ru>
Reviewed-by: Casey Connolly <casey.connolly@linaro.org>
Link: https://lore.kernel.org/r/20250424014811.3809818-1-alexeymin@minlexx.ru
Signed-off-by: Casey Connolly <casey.connolly@linaro.org>

clk: qcom: apq8016: Fix SDCC clock warnings

As of commit dc8754e8e408 ("clk/qcom: apq8016: improve clk_enable logging")
there are now warnings in the U-Boot console on DragonBoard 410c:

  apq8016_clk_enable: unknown clk id 122
  apq8016_clk_enable: unknown clk id 123
  apq8016_clk_enable: unknown clk id 124
  apq8016_clk_enable: unknown clk id 125

This is because we don't implement enable() properly for the SDCC clocks.
Currently they are being enabled as part of set_rate().

Fix this by moving the enable calls out of the apq8016_clk_init_sdc()
function and convert them to the equivalent GATE_CLK_POLLED() definitions.

Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Reviewed-by: Casey Connolly <casey.connolly@linaro.org>
Link: https://lore.kernel.org/r/20250424-apq8016-clock-fixes2-v2-6-fcc371c9e45f@linaro.org
Signed-off-by: Casey Connolly <casey.connolly@linaro.org>

clk: qcom: apq8016: Convert GATE_CLK() to GATE_CLK_POLLED()

Convert the usages of GATE_CLK() in clock-apq8016 to GATE_CLK_POLLED() to
make sure that we poll the status when enabling clocks:

 - PRNG_AHB_CLK is a vote clock, so we poll a different register address.
 - The USB clocks are simple branches, so enable/poll is the same register.

Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Reviewed-by: Casey Connolly <casey.connolly@linaro.org>
Link: https://lore.kernel.org/r/20250424-apq8016-clock-fixes2-v2-5-fcc371c9e45f@linaro.org
Signed-off-by: Casey Connolly <casey.connolly@linaro.org>

clk: qcom: Allow polling for clock status in qcom_gate_clk_en()

GATE_CLK() in its current state is unsafe: A simple write to the clock
enable register does not guarantee that the clock is immediately running.
Without polling the clock status, we may issue writes to registers before
the necessary clocks start running. This doesn't seem to cause issues in
U-Boot at the moment, but for example removing the CLK_OFF polling in TF-A
for the SMMU clocks on DB410c reliably triggers an exception during boot.

Make it possible to poll the branch clock status register, by adding a new
GATE_CLK_POLLED() macro that takes the extra register address. Existing
usages work just as before, without polling the clock status. Ideally all
usages should be updated to specify the correct poll address in the future.

The Qualcomm naming for these clocks is "branch" and not "gate", but let's
keep the existing naming for now to avoid confusion until all others
drivers have been converted.

Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Reviewed-by: Casey Connolly <casey.connolly@linaro.org>
Link: https://lore.kernel.org/r/20250424-apq8016-clock-fixes2-v2-4-fcc371c9e45f@linaro.org
Signed-off-by: Casey Connolly <casey.connolly@linaro.org>

clk: qcom: Use setbits_le32() for qcom_gate_clk_en()

The other clock enable functions in clock-qcom.c use setbits_le32() to
read/modify/write the enable registers. Use the same for qcom_gate_clk_en()
to simplify the code a bit.

Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Reviewed-by: Casey Connolly <casey.connolly@linaro.org>
Link: https://lore.kernel.org/r/20250424-apq8016-clock-fixes2-v2-3-fcc371c9e45f@linaro.org
Signed-off-by: Casey Connolly <casey.connolly@linaro.org>

clk: qcom: Move qcom_gate_clk_en() to C file

This avoids having to inline it separately into every single clock driver,
when U-Boot is built with support for multiple SoCs.

Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Reviewed-by: Casey Connolly <casey.connolly@linaro.org>
Link: https://lore.kernel.org/r/20250424-apq8016-clock-fixes2-v2-2-fcc371c9e45f@linaro.org
Signed-off-by: Casey Connolly <casey.connolly@linaro.org>

clk: qcom: apq8016: Fix SDCC clock addresses

The SDCC_...(n) macros in clock-apq8016.c result in the wrong addresses:

 - SDCC1: SDCC_APPS_CBCR(0) = ((0 * 0x1000) + 0x41018) = 0x41018
   Should be 0x42018, this is an invalid register close to the USB clocks.
 - SDCC2: SDCC_APPS_CBCR(1) = ((1 * 0x1000) + 0x41018) = 0x42018
   Should be 0x43018, this is the SDCC1 clock.

When we try to enable SDCC2, we actually end up enabling SDCC1. When we try
to enable SDCC1, we just issue some broken register writes.

This hasn't caused any trouble so far, because the boot firmware is keeping
both SDCC clocks running. However, if these clocks are disabled when
entering U-Boot, MMC initialization is failing.

Fix this by using the proper offset for the macros. The SDCC_CMD_RCGR() was
already correct, but change it the same way for consistency.

Fixes: 085921368b7d ("arm: Add support for Qualcomm Snapdragon family")
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Reviewed-by: Casey Connolly <casey.connolly@linaro.org>
Link: https://lore.kernel.org/r/20250424-apq8016-clock-fixes2-v2-1-fcc371c9e45f@linaro.org
Signed-off-by: Casey Connolly <casey.connolly@linaro.org>

power: qcom_vbus_regulator: add and fix support for pmic variants

Fix and add support for different pmic variants pm8x50b to handle
the vbus regulator.

Signed-off-by: Rui Miguel Silva <rui.silva@linaro.org>
Link: https://lore.kernel.org/r/20250412174157.104419-1-rui.silva@linaro.org
Signed-off-by: Casey Connolly <casey.connolly@linaro.org>

board: dragonboard410c: Enable support for KASLR in Linux

When booting Linux, there is currently the following warning in the console
when using the default dragonboard410c_defconfig:

  [    0.000000] KASLR disabled due to lack of seed

Fix this by enabling DM_RNG and RNG_MSM in the defconfig to generate the
KASLR seed:

  [    0.000000] KASLR enabled

Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
Reviewed-by:
Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250417-db410c-fixes2-v1-3-76ad994da152@linaro.org
Signed-off-by: Casey Connolly <casey.connolly@linaro.org>

board: dragonboard410c: Drop custom reduced malloc size

At the moment, the dragonboard410c_defconfig specifies a custom
SYS_MALLOC_LEN, lower than the default for Qualcomm boards defined in
arch/arm/mach-snapdragon/Kconfig. It looks like it's too low, since
flashing larger sparse partition images using Fastboot fails with:

  FAILED (remote: 'Malloc failed for: CHUNK_TYPE_RAW')

We are not really that memory-constrained for U-Boot on DB410c, so fix
this by just dropping the custom malloc size and using the default.

Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
Reviewed-by:
Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250417-db410c-fixes2-v1-2-76ad994da152@linaro.org
Signed-off-by: Casey Connolly <casey.connolly@linaro.org>

board: dragonboard410c: Fix button cmd name

Commit 359e1d4a57e0 ("board: dragonboard410c: Use button_cmd instead of
custom code") was made in parallel with commit 8f5685d5d32f ("button:
qcom-pmic: prettify and standardise button labels"), which changed the
default button label from "vol_down" to "Volume Down". This is causing
errors in the console during boot now:

  No button labelled 'vol_down'

Fix this by using the new label.

Fixes: 359e1d4a57e0 ("board: dragonboard410c: Use button_cmd instead of custom code")
Fixes: 8f5685d5d32f ("button: qcom-pmic: prettify and standardise button labels")
Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
Reviewed-by:
Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250417-db410c-fixes2-v1-1-76ad994da152@linaro.org
Signed-off-by: Casey Connolly <casey.connolly@linaro.org>

Merge tag 'i2cfixes-for-2025.07-rc4' of https://source.denx.de/u-boot/custodians/u-boot-i2c

i2c bugfixes for v2025.07-rc4
- designware_i2c: fix globally wrong return value -1 into -ETIMEDOUT
  in driver, which leaded in silent errors as a timeout resulted in
  an uninitialized value being returned, potentially causing
  unexpected behavior.

Merge branch 'master' of https://source.denx.de/u-boot/custodians/u-boot-riscv

CI: https://source.denx.de/u-boot/custodians/u-boot-riscv/-/pipelines/26455

Thanks Conor and Yao for catching this issue.

- Revert "RISC-V 32/64 images support" to fix compatibility issue

i2c: designware_i2c Return -ETIMEDOUT for timeout errors

Change the return value for timeout errors in i2c-designware from 1 to
-ETIMEDOUT. Returning errors as negative values is standard practice in the
u-boot, which enhances error handling consistency across the codebase.

The current behavior can lead to silent errors when functions check for
negative return values to identify errors. For example, in
`dm_i2c_reg_read` from i2c-uclass.c, a timeout results in an uninitialized
value being returned, potentially causing unexpected behavior.

Cc: Heiko Schocher <hs@denx.de>
Cc: Tom Rini <trini@konsulko.com>
Cc: Wojciech Szamocki <wojciech.szamocki@nokia.com>
Signed-off-by: Wojciech Szamocki <wojciech.szamocki@nokia.com>
Reviewed-by: Heiko Schocher <hs@denx.de>

Revert "riscv: image: Add new image type for RV64"

This reverts commit 14a4792a71db3561bea065415ac1f2ac69ef32b5 as
discussed in [1].

[1] https://lists.denx.de/pipermail/u-boot/2025-May/590841.html

Signed-off-by: Mayuresh Chitale <mchitale@ventanamicro.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>

Revert "riscv: Select appropriate image type"

This reverts commit 027a316828528da95a77d20632370b1bc2823f0b as
discussed in [1].

[1] https://lists.denx.de/pipermail/u-boot/2025-May/590841.html

Signed-off-by: Mayuresh Chitale <mchitale@ventanamicro.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>

Revert "booti/bootm: riscv: Verify image arch type"

This reverts commit 37b0b22d8b7bbed6aa95b6daed06dcbf4a66f211 as
discussed in [1].

[1] https://lists.denx.de/pipermail/u-boot/2025-May/590841.html

Signed-off-by: Mayuresh Chitale <mchitale@ventanamicro.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>

net: gem: ignore tx_clk if MII is used

If the MII interface is used, the PHY is the clock master, thus don't
set the clock rate. On Zynq-7000, this will prevent the following
error:
  zynq_gem ethernet@e000b000: failed to set tx clock rate 25000000

Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de>
Link: https://lore.kernel.org/r/20250415150400.136723-1-martin.kaistra@linutronix.de
Signed-off-by: Michal Simek <michal.simek@amd.com>

phy: zynqmp: Fix sgmii clk ctrl GTR lane bit shift

The bitshift in GEM_CLK_CTRL register is five bits, not two. There are
four bits for each GEM, and one bit reserved in between.

This has caused that using more than one GEM is impossible,
additionally corrupting the GEM0's configuration, leaving GEM0
unusable as well (ie. if GEM0 and GEM1 are used, GEM1 configuration is
going to write to GEM0's registers wrong value, leaving GEM0 unusable)

Signed-off-by: Frantisek Bohacek <rutherther@ditigal.xyz>
Link: https://lore.kernel.org/r/20250522060703.4863-1-rutherther@ditigal.xyz
Signed-off-by: Michal Simek <michal.simek@amd.com>

drivers: fpga: intel_sdm_mb: Flush cache before FPGA configuration

FPGA configuration encounters failure when the cache is not flushed.
Add cache flushing to the memory region that holds the FPGA
configuration bitstream.

Signed-off-by: Naresh Kumar Ravulapalli <nareshkumar.ravulapalli@altera.com>
Link: https://lore.kernel.org/r/20250506012851.30039-1-nareshkumar.ravulapalli@altera.com
Signed-off-by: Michal Simek <michal.simek@amd.com>

pci: zynqmp: Fix the pcireg base

The pcireg base is not assigned to any address, reading the
pcireg base with PS_LINKUP_OFFSET which is incorrect and
giving random values. So update the pcireg base from
devicetree so that we can read the valid PCIE link status
and PHY ready status.

Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Link: https://lore.kernel.org/r/20250516092314.939424-1-venkatesh.abbarapu@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>

image: android: fix ramdisk default address

Commit 21e7fa0e3ac5 ("image: android: handle ramdisk default address")
changed the default behavior for header versions less than or equal to 2.

The ramdisk address (img_data.ramdisk_ptr) is only assigned to *rd_data
if the physical load address (img_data.ramdisk_addr) is equal to 0 or
the Android default ramdisk address.

    /* Ramdisk can be used in-place, use current ptr */
    if (img_data.ramdisk_addr == 0 ||
            img_data.ramdisk_addr == ANDROID_IMAGE_DEFAULT_RAMDISK_ADDR) {
        *rd_data = img_data.ramdisk_ptr;
    } else {
        ramdisk_ptr = img_data.ramdisk_addr;
        *rd_data = ramdisk_ptr;
        memcpy((void *)(ramdisk_ptr), (void *)img_data.ramdisk_ptr,
                img_data.ramdisk_size);
    }

When the img_data.ramdisk_addr and the img_data.kernel_addr are the same
*rd_data needs to be assigned to the ramdisk address (ramdisk_ptr), not
the physical address (ramdisk_addr).

As a result of the current behavior, we can no longer boot a kernel on
the Renesas R-Car S4 board.

Add an additional check to the if clause so that the ramdisk address is
assigned when the kernel address and the ramdisk address are the same,
restoring the previous default behavior.

Fixes: 21e7fa0e3ac5 ("image: android: handle ramdisk default address")
Signed-off-by: Eddie Kovsky <ekovsky@redhat.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Tested-by: Mattijs Korpershoek <mkorpershoek@kernel.org> # khadas vim3

bootm: Fix bmi->images pointer not initialized in some cases

When building with only bootz command, without bootm, images pointer
inside bootm_info structure is not initialized. And since this structure
is stored in stack, the generated error is kind of random, but most of
the time this will generate: "ramdisk - allocation error".

Also, after analysis, this problem could occur with the command booti,
if the command bootm is disabled.

Currently bootm_init() is called by: do_bootz(), do_bootm(), do_booti()
and by do_stm32prog(). And all of these commands execute bootm_run_states()
which access the images pointer stored into bootm_info structure.

So, to fix this issue, just do the assignment unconditionally.

Fixes: c2211ff65136 ("bootm: Add more fields to bootm_info")
Signed-off-by: Benjamin ROBIN <dev@benjarobin.fr>
Reviewed-by: Tom Rini <trini@konsulko.com>

env: Fix network support when CONFIG_NET_LWIP is set

When lwIP (CONFIG_NET_LWIP) is used instead of legacy stack (CONFIG_NET),
environment flags support associated with network was not built: restore
support of "i" and "m" environment flags.

Signed-off-by: Benjamin ROBIN <dev@benjarobin.fr>
Acked-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

scripts/setlocalversion: Reinstate .scmversion support

The .scmversion is used by oe-core to append U-Boot version string.

LOCALVERSION is not fully compatible replacement as it adds trailing
"-dirty" string at the end of version string in case the U-Boot git
tree contains uncommitted changes. This behavior itself is correct.
However, OE builds do clone U-Boot sources from git and may apply
additional patches on top, which are not tracked in U-Boot git tree,
but rather in the OE metalayer git tree, which leads to the addition
of "-dirty" string as well.

The .scmversion used by oe-core used to replace the version string
suffix fully, including the "-dirty" string. Reinstate support for
the .scmversion to let OE core do exactly that as it used to do it.

Fixes: 5c02350fa03d ("scripts/setlocalversion: sync with linux v6.9")
Signed-off-by: Marek Vasut <marex@denx.de>

Merge branch 'master' of https://source.denx.de/u-boot/custodians/u-boot-sh

board: rzg2l: Update MAINTAINERS file

Un-orphan the RZ/G2L , keep the RZ/G2L maintained.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Paul Barker <paul@pbarker.dev>

board: rzg2l: Drop myself to reviewer for RZ/G2L boards

I still intend to review patches, and will be using my own email address
going forward.

Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com>

ARM: renesas: Enable serial RX buffer on Renesas R-Car

Enable CONFIG_SERIAL_RX_BUFFER on all Renesas R-Car devices which
use the SCIF serial port. This allows receiving large strings at
bulk even if the RX FIFO is small and would otherwise overflow.

The usual trigger for the problem addressed here is a paste of a
very long command into U-Boot command line, somewhere between 400
and 500 characters long. The trailing end of the string is usually
not received and the command line input stops responding due to RX
overflow errors. The CONFIG_SERIAL_RX_BUFFER allows efficient read
of data from the RX FIFO, which prevents the overflow, and allows
safe reception of long pasted strings.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>

Revert "ext4fs: Fix: Read outside partition error"

The issue here is that the function read_allocated_block() will report
problems via a negative return value. If we say the return value is
stored in an lbaint_t that can no longer happen (and Coverity discovered
this by reporting a no effect comparison and then dead code). The
problem being fixed by allowing for storing a larger block number will
have to be solved in some other manner.

This reverts commit df2ed552f0b05591090369a7fe7ddc92439dea5c.

Addresses-Coverity-ID: 131183
Signed-off-by: Tom Rini <trini@konsulko.com>

Prepare v2025.07-rc3

Signed-off-by: Tom Rini <trini@konsulko.com>

Merge branch 'master' of git://source.denx.de/u-boot-usb

Merge tag 'efi-2025-07-rc3-3' of https://source.denx.de/u-boot/custodians/u-boot-efi

Pull request efi-2025-07-rc3-3

CI:

* https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/26313

UEFI:

* run dhcp if an http boot option is selected
* separate device path into its own header and add it to the API docs
* rename END to EFI_DP_END
* make x86 SMBIOS tables usable in the EFI context

usb: ulpi: Clean up how we enable support

The way we enable ULPI support today isn't something that should work.
The "optional" keyword in a choice statement is not a documented
feature. To make this work in a supported way, make USB_ULPI something
we ask about if USB_HOST is set. Next, we move the choice of what
viewer to use to be after the framework portion and to depend on that.
We then borrow a few words from the top-level README to make the help
text here clearer. Finally we make the Qualcomm driver select ULPI as
it's required and we make the tegra driver not duplicate a check that
Kconfig now handles for us.

Signed-off-by: Tom Rini <trini@konsulko.com>

usb: ulpi: Remove unused omap-ulpi-viewport driver

The last platform to enable this driver was removed in 2019. Remove this
unused code and documentation now.

Signed-off-by: Tom Rini <trini@konsulko.com>

usb: dwc3: core: Fix timeout check

dwc3_core_init loops 'timeout' times to check if the IP block is out
of reset using 'while (timeout--)'. If there is some issue and
the block doesn't come out of reset, the loop will run till
'timeout' becomes zero and the post decrement operator would set
timeout to 0xffffffff. Though the IP block is not out reset, the
subsequent if check 'if !timeout' would fail as timeout is not
equal to zero and the function proceeds with the initialization.

Use poll API instead to resolve this.

Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org>

efi_loader: Run dhcp if an http boot option is selected

The EFI boot manager relies on having an IP address before trying to
boot an EFI HTTP(s) boot entry. However, defining it as a boot or
pre-boot command is not always the right answer since it will
unconditionally add delay to the board boot, even if we don't boot
over the network.

So let's do a DHCP request from the boot manager, if 'ipaddr' is
empty and fail early if we don't have an address.

Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Tested-by: Michal Simek <michal.simek@amd.com>

x86: efi_loader: Ensure the SMBIOS tables are sent via EFI

The EFI-loader code has not been fully converted to use bloblist, so
relies on the SMBIOS-table address being set in global_data.

Set this up in write_tables() so that the SMBIOS tables are actually
available.

Enable the command for x86 QEMU so that the SMBIOS tests actually run.

Signed-off-by: Simon Glass <sjg@chromium.org>
Fixes: 83ce35d6ebb ("emulation: Use bloblist to hold tables")
Reported-by: Niklas Sombert <niklas.sombert@uni-duesseldorf.de>
Tested-by: Niklas Sombert <niklas.sombert@uni-duesseldorf.de>
Tested-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

efi: Rename END to EFI_DP_END

This exported symbol has a very generic name. Rename it to indicate that
it relates to EFI and device-paths.

Fix checkpatch warnings related to use of multiple assignments.

Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

efi: Include device-path functions in the EFI API docs

Include these function so they can be browsed in the API docs. Exclude
END since it causes a warning, which becomes an error:

   ./include/efi_device_path.h:22: warning: cannot understand function
      prototype: 'const struct efi_device_path END; '

Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

efi_loader: Separate device path into its own header

These functions are useful for the EFI app. As a first step towards
making these available outside lib/efi_loader, create a separate header
file and include it where needed. Add proper comments to the functions,
since many are missing at present.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

ext4fs: Fix: Read outside partition error

Use lbaint_t for blknr to avoid overflow in ext4fs_read_file().

Background:

blknr (block number) used in ext4fs_read_file() could be increased to a
very large value and causes a wrap around at 32 bit signed integer max,
thus becomes negative. This results in an out-of-normal range for sector
number (during the assignment delayed_start = blknr) where delayed_start
sector is typed uint64 lbaint_t. This causes the "Read outside partition"
error.

This patch was tested on the Synology DS116 (Armada 385) board, and a
4TB Seagate HDD.

Signed-off-by: Tony Dinh <mibodhi@gmail.com>

fs: fs_devread should log error when read outside partition

Log the error if fs_devread() fails when trying to reading outside
partition. This will make bug reporting easier.

Signed-off-by: Tony Dinh <mibodhi@gmail.com>

board: total_Compute: enable bloblist for SPL handoff

Add bloblist support to total_comput platform for passing data
from TF-A using the firmware handoff framework.

Signed-off-by: Jayanth Dodderi Chidanand <jayanthdodderi.chidanand@arm.com>

EXT4: add CRC16 dependency

CRC16 is used in ext4_common.c. Build fails without it.

PS:
This is my first patch sent to a mailing list.
If there is anything wrong with it (email format, whitespace, etc.)
please let me know.

Signed-off-by: Marius Dinu <m95d+git@psihoexpert.ro>

env: mtd: fix usability with NAND flashes

1. As this is for MTD-based devices, the Kconfig dependency should be MTD
   instead of only spi-nor flashes
2. Initialize saved_buf to avoid crash on free()
3. Remaining size should be set correctly to write_size

Fixes: 03fb08d4aef (env: Introduce support for MTD)
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
Reviewed-by: Christian Marangi <ansuelsmth@gmail.com>

Merge tag 'u-boot-imx-master-20250522' of https://gitlab.denx.de/u-boot/custodians/u-boot-imx

CI: https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/26275

- Fix boot regression on imx8mn_bsh_smm_s2/s2pro.
- Fix reset on imx6ulz_smm_m2.
- Adjust DDR initialization on imx6ulz_smm_m2.
- Fix CAAM startup error.

caam: Fix CAAM error on startup

In rare cases U-Boot returns an error message when intantiating the RNG
of the CAAM device:
“SEC0:  RNG4 SH0 instantiation failed with error 0xffffffff”
This  means, that even when the CAAM device reports a finished
descriptor, none is found in the output ring.
This might be caused by a missing cache invalidation before
reading the memory of the output ring
This patch moves the cache invalidation of the output ring from start of
the job to immediately after the notification from hardware where the
output ring will be read.

Signed-off-by: Olaf Baehring <olaf.baehring@draeger.com>
Signed-off-by: Fabio Estevam <festevam@gmail.com>

Merge branch 'master' of https://source.denx.de/u-boot/custodians/u-boot-riscv

CI: https://source.denx.de/u-boot/custodians/u-boot-riscv/-/pipelines/26259

- Initial SPL support for T-Head TH1520 SoC
- Improve usability of TH1520 with mainline SPL
- Support building RV32 & RV64 images
- riscv: Improve jh7110 support

Merge tag 'net-20250520' of https://source.denx.de/u-boot/custodians/u-boot-net

Pull request net-20250520.

CI: https://source.denx.de/u-boot/custodians/u-boot-net/-/pipelines/26247

net, net-lwip:
- Remove wget console output when called by EFI

net-lwip:
- Add 10 s timeout to TFTP
- Add LMB buffer checks

board: bsh: imx6ulz_smm_m2: Add delay between DRAM read access

A small delay between DRAM read access with wrong parameters and
reconfiguration is necessary.
Without a delay between DRAM read access and a following reconfiguration
this reconfiguration fails for certain DRAM chips (Nanya).

Signed-off-by: Michael Bode <michael.bode@bshg.com>
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>

board: bsh: imx6ulz_smm_m2: Add support for 512 MiB DRAM

Calibration values were calculated using the NXP tool
I.MX6ULL_DDR3_Script_Aid_V0.01.xlsx

Signed-off-by: Michael Bode <michael.bode@bshg.com>
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>