adi: Stop disabling device tree relocation

Remove setting of fdt_high to ~0, which disables device tree relocation,
from the default environment. Doing so prevents U-Boot from correcting
problems such as having an unaligned device tree and leads to various
failure modes in the OS.

Tested-by: Greg Malysa <malysagreg@gmail.com>
Signed-off-by: Tom Rini <trini@konsulko.com>

boot/image-fit.c: Use aligned_alloc(...) not memalign(...)

With the changes in commit 8fbcc0e0e839 ("boot: Assure FDT is always at
8-byte aligned address") to call memalign(...) we now always call
memalign(...) rather than malloc(...) when allocating a buffer that may
contain a device tree. However, memalign(...) is not portable among all
of the host OSes we support. The C11 standard does require that
aligned_alloc(...) exist and it takes the same parameters as
memalign(...) does. Change this file to call aligned_alloc rather than
memalign, and for the non-USE_HOSTCC case define that function back to
memalign.

Fixes: 8fbcc0e0e839 ("boot: Assure FDT is always at 8-byte aligned address")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Tom Rini <trini@konsulko.com>

clk: Only enable the parent clock if the clock was enabled before reparenting

The current implementation of clk_set_parent() unconditionally enables
the new parent clock, even if the target clock was not previously enabled.

To avoid this implicit behavior, this patch adds a check for whether
the target clock has been enabled before parent enabling..

Fixes: ac30d90f336 ("clk: Ensure the parent clocks are enabled while reparenting")
Signed-off-by: Maksim Kiselev <bigunclemax@gmail.com>
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>

Merge patch series "Add support for SM3 secure hash"

Heiko Schocher <hs@nabladev.com> says:

Add SM3 secure hash, as specified by OSCCA GM/T 0004-2012 SM3 and described
at https://datatracker.ietf.org/doc/html/draft-sca-cfrg-sm3-02

TPMv2 defines hash algo sm3_256, which is currently
not supported and prevented TPMv2 chip with newer
firmware to work with U-Boot. Seen this on a ST33TPHF2XI2C

    u-boot=> tpm2 init
    u-boot=> tpm2 autostart
    tpm2_get_pcr_info: too many pcrs: 5
    Error: -90
    u-boot=>

Implement sm3 hash, so we can fix this problem.

Link: https://lore.kernel.org/r/20251118043042.27726-1-hs@nabladev.com

test: cmd: fix a typo in md5 test

In dm_test_cmd_hash_md5 accidentially sha256 hash
ist used. Use the correct md5 hash instead.

Signed-off-by: Heiko Schocher <hs@nabladev.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

tpm2: add sm3 256 hash support

add sm3 256 hash support, so TPM2 chips which report
5 pcrs with sm3 hash do not fail with:

  u-boot=> tpm2 autostart
  tpm2_get_pcr_info: too many pcrs: 5
  Error: -90

Signed-off-by: Heiko Schocher <hs@nabladev.com>

test: cmd: hash: add unit test for sm3_256

add simple test for sm3 256 hash

Signed-off-by: Heiko Schocher <hs@nabladev.com>

lib: sm3: implement U-Boot parts

add the U-Boot specific parts for the SM3 hash
implementation:

Signed-off-by: Heiko Schocher <hs@nabladev.com>

lib: import sm3 256 hash parts from linux

Implement SM3_256 Hash algorithm, based on
linux commit f83a4f2a4d8c: ("Merge tag 'erofs-for-6.17-rc6-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs")

Therefore add the needed parts from linux.

Signed-off-by: Heiko Schocher <hs@nabladev.com>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

lib: Import rol32 function from Linux

sm3 crypto algorithm uses rol32 function from linux, so
import it. Linux base was:

commit ca91b9500108:("Merge tag 'v6.15-rc4-ksmbd-server-fixes' of git://git.samba.org/ksmbd")

Signed-off-by: Heiko Schocher <hs@nabladev.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

Merge patch series "clk: Fix some error detection"

Andrew Goodbody <andrew.goodbody@linaro.org> says:

The function clk_get_rate() returns a ulong with 0 meaning an invalid
clock rate and also negative error codes being returned for other
errors. But being an unsigned return value this cannot simply be tested
for with a < 0 test. Instead use the IS_ERR_VALUE() macro to check for
negative errors appearing as very large positive values. Fix those
places that test for <= 0. Also fix some places checking the return of
clk_register() that incorrectly used ERR_PTR().

Link: https://lore.kernel.org/r/20251021-clk_funcs-v1-0-acf51a40eea7@linaro.org

timer: imx-gpt: Fix error detection

Testing an unisgned ivariable to be <= 0 will only detect the
case when it is 0. So correct this error test to a working version that
will behave as expected.

Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>

i2c: imx_lpi2c: Fix error detection

Testing an unisgned ivariable to be <= 0 will only detect the
case when it is 0. So correct this error test to a working version that
will behave as expected.

Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Reviewed-by: Heiko Schocher <hs@nabladev.com>

i2c: npcm: Fix error detection

Testing an unisgned member of a struct to be <= 0 will only detect the
case when it is 0. So correct this error test to a working version that
will behave as expected.

Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Reviewed-by: Heiko Schocher <hs@nabladev.com>

clk: microchip: mpfs: Fix error detection

clk_register() will return standard error codes so the use of ERR_PTR()
is incorrect. Furthermore the code was ineffective as it lacked a return
statement that would have actually made use of the result. Add the
return statement and remove the use of ERR_PTR to correct this.

Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Acked-by: Conor Dooley <conor.dooley@microchip.com>

mmc: fsl_esdhc_imx: Cannot test unsigned to be < 0

Testing an unisgned member of a struct to be <= 0 will only detect the
case when it is 0. So correct this error test to a working version that
will behave as expected.

Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>

mmc: hi6220_dw_mmc: Fix error detection for clk_get_rate

clk_get_rate() returns a ulong and that return value is assigned to a
member of a struct that is an unsigned int. So testing this value to <=
0 will only detect a return of 0. Also the code in the if block assumes
ret holds the return value when it does not. So update the test to one
that will work as intended and update the if block to actually refer to
the return value.

Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>

Merge tag 'u-boot-dfu-next-20251203' of https://source.denx.de/u-boot/custodians/u-boot-dfu into next

u-boot-dfu-next-20251203:

CI: https://source.denx.de/u-boot/custodians/u-boot-dfu/-/pipelines/28617

Fastboot:
- Add generic flashing support using BLK

Merge patch series "led: remove u-boot,boot-led and u-boot,error-led + add cmd doc"

Quentin Schulz <foss+uboot@0leil.net> says:

u-boot,boot-led and u-boot,error-led aren't actually handled by some
generic code but rather by board or architecture specific code. They
also aren't properties that are part of the official dt-binding so they
cannot be upstreamed. For u-boot,boot-led, there's actually a proper
replacement which is /options/u-boot/boot-led[1] (+ CONFIG_LED_BOOT=y).

For Rockchip boards, either nothing (for RK3066, PX30 and RK3399) was
using that property or (for RK3188) the code handling it was guarded by
symbols that were not enabled in the defconfig. For those, the property
and guarded code are removed.

For the Sam9x60 Curiosity, it seems that even though the LED is
controlled whenever CONFIG_LED is enabled, it isn't enabled by default
in the defconfig (but the code was added without modifying the
defconfig, explicitly leaving a choice to the user). I decided to keep
that feature by simply migrating it to the new API, though I cannot test
it as I do not own the device.

The STM32 boards will be migrated in the near future once their upstream
(kernel) Device Trees gain the new way to specify this (via
/options/u-boot/boot-led). I'll let Patrice handle this, see
https://lore.kernel.org/u-boot/94ed1988-13e8-4fe3-bdff-ba2c9973c556@foss.st.com/
and
https://lore.kernel.org/u-boot/2a3aa43a-ce19-41e1-ab56-556629ce5cf9@foss.st.com/

After this, only one user of u-boot,boot-led will be left, based on
STM32: board/dhelectronics/dh_stm32mp1/board.c. @Patrice, maybe that's
something you want to have a look at as well, this seems to be some
evaluation kit?

The only users of u-boot,error-led are STM32 boards, so I'll leave this
to Patrice as well, I do not know what's the way to go for that one.

In any case, I would like to not encourage people to use out-of-spec DT
properties when there is another option (u-boot,boot-led), so I remove
the properties from the dt-binding document from U-Boot.

The help text for the blink subcommand of the led command was misleading
so this is now fixed.

This also moves the content of doc/README.LED into the doc/api/led.rst,
while clearly stating one shouldn't be using this anymore.

This also gets rid of dt-binding that we already have in dts/upstream.

Finally, this adds documentation for the led shell command.

[1] https://github.com/devicetree-org/dt-schema/blob/v2025.08/dtschema/schemas/options/u-boot.yaml#L113-L116

Link: https://lore.kernel.org/r/20251112-led-old-dt-v1-0-2892d49517db@cherry.de

doc: remove u-boot,boot-led and u-boot,error-led from "binding"

We're aiming to reduce the amount of U-Boot-specific and out-of-spec
Device Tree additions.

Those two properties haven't been doing anything for a long time
already, except when read by board files manually. This is still the
case for STM32 boards but those will be migrated in the near future
according to their maintainer. In any case, let's not encourage people
to add either of these properties to new or existing Device Trees and
remove it from the bindings.

Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>

sam9x60-curiosity: migrate Boot LED setup to use /options/u-boot/boot-led

This board is one of the last users of /config/u-boot,boot-led property
which is a U-Boot property out of the DT spec.

Let's migrate it to use the in-spec /options/u-boot/boot-led property.
When enabling LED_BOOT, U-Boot proper will lit the LED right before
entering the main loop, so nothing needs to be done in board files.

As explained in the commit adding support for this u-boot,boot-led
property, let's keep backward compatibility in case LED_BOOT isn't
selected.

Note that this is not tested as I do not own this device.

Cc: Alexander Dahl <ada@thorsis.com>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Tested-by: Alexander Dahl <ada@thorsis.com>

arm: dts: rockchip: rk3066a-mk808: remove unused u-boot,boot-led

There's no code to make use of it.

Additionally, if we ever want to enable this LED as Boot LED, we should
instead be using boot-led phandle property in /options/u-boot[1] Device
Tree node with the "new" LED UCLASS devices.

So let's simply remove this unused property to not mislead users.

[1] https://github.com/devicetree-org/dt-schema/blob/v2025.08/dtschema/schemas/options/u-boot.yaml#L113-L116

Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>

arm: dts: rockchip: px30-ringneck: remove u-boot,boot-led

There's no code to make use of it.

Further more, the HW default state of that LED is on and migrating this
to the LED_BOOT implem brings no benefit as it'll stay on if U-Boot
reaches its main-loop. Blinking the LED_BOOT also doesn't help because
it doesn't blink for long enough to be noticeable before it's kept on.

This is by design, c.f.
https://source.denx.de/u-boot/u-boot/-/blob/v2025.10/include/led.h#L32-34

If we want this LED to be doing something different, it'll need to be
handled by a board file anyway.

Considering it hasn't worked in many years (if ever), let's just remove
it.

Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>

arm: dts: rockchip: rk3399-puma: remove u-boot,boot-led

There's no code to make use of it.

Further more, the HW default state of that LED is on and migrating this
to the LED_BOOT implem brings no benefit as it'll stay on if U-Boot
reaches its main-loop. Blinking the LED_BOOT also doesn't help because
it doesn't blink for long enough to be noticeable before it's kept on.

This is by design, c.f.
https://source.denx.de/u-boot/u-boot/-/blob/v2025.10/include/led.h#L32-34

If we want this LED to be doing something different, it'll need to be
handled by a board file anyway.

Considering it hasn't worked in many years, let's just remove it.

Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>

rockchip: rk3188: remove setup_led from xPL

There's not a single device making use of that code and it anyway
shouldn't be using the old deprecated u-boot,boot-led /config property
anymore but rather boot-led from /options/u-boot[1] Device Tree node.

Because spl_board_init() is only present to call this now removed
function, we can remove it as well as SPL_BOARD_INIT which is the symbol
guarding calls to spl_board_init() (which is now also removed).

[1] https://github.com/devicetree-org/dt-schema/blob/v2025.08/dtschema/schemas/options/u-boot.yaml#L113-L116

Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>

arm: dts: rockchip: rk3188-radxarock: remove unused u-boot,boot-led

This property is only read in arch/arm/mach-rockchip/rk3188/rk3188.c
when CONFIG_SPL_LED is enabled, which isn't the case for this board, so
let's remove dead code.

Additionally, if we ever want to enable this LED as Boot LED, we should
instead be using boot-led phandle property in /options/u-boot[1] Device
Tree node with the "new" LED UCLASS devices.

[1] https://github.com/devicetree-org/dt-schema/blob/v2025.08/dtschema/schemas/options/u-boot.yaml#L113-L116

Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>

doc: dt-bindings: remove duplicates with dts/upstream

doc/device-tree-bindings/leds/leds-bcm6328.txt can be found at
dts/upstream/Bindings/leds/leds-bcm6328.yaml.

doc/device-tree-bindings/leds/leds-bcm6358.txt can be found at
dts/upstream/Bindings/leds/leds-bcm6358.txt.

doc/device-tree-bindings/leds/leds-gpio.txt can be found at
dts/upstream/Bindings/leds/leds-gpio.yaml.

doc/device-tree-bindings/leds/leds-lp5562.txt can be found at
dts/upstream/Bindings/leds/leds-lp55xx.yaml.

Only two LED dt-bindings are left in U-Boot: leds-bcm6858.txt and
leds-pwm.txt. The former is partially supported by
dts/upstream/Bindings/leds/leds-bcm63138.yaml but is lacking all
optional properties we have listed in "downstream" dt-binding in U-Boot.
However, there doesn't seem to exist any user of that compatible.
The latter is partially supported by
dts/upstream/Bindings/leds/leds-pwm.yaml but is missing the
u-boot,default-brightness property, which is used by
arch/arm/dts/rk3326-odroid-go2-u-boot.dtsi at the moment. The
default-brightness property is probably not what we want here as it
defaults to max-brightness if missing. I'm assuming we want a different
value for U-Boot (127) and the kernel (255 via max-brightness as a
default), which would prevent us from upstreaming this property, which
doesn't change the status quo, so let it be for now.

Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>

doc: cmd: document the led shell command

This adds documentation on how to use the led shell command.

Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>

doc: move legacy API documented in README.LED to doc/api/led.rst

This moves the content of the legacy LED API from doc/READ.LED to
doc/api/led.rst, applying minimal cosmetic changes to "nicely" integrate
it with the current docs and adding a small introduction to the legacy
API section.

Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>

cmd: led: fix help text for blink subcommand

The blink subcommand actually requires an additional parameter
(blink-freq) but not the others.

In order to simplify the help text, split the blink subcommand help text
from the off|on|toggle subcommands.

Then, fix the help text so that it is clear that the frequency is
required.

While at it, specify the duty cycle.

Fixes: ffe2052d6e8a ("dm: led: Add a new 'led' command")
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>

Merge tag 'u-boot-ufs-20251202' of https://source.denx.de/u-boot/custodians/u-boot-ufs into next

- Second batch of UFS config renames for Cadence/Qcom/Rockchip/TI

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

Pull request net-next-20251201

net:
- phy: Add the Airoha EN8811H PHY driver
- airoha: bind MDIO controller on Ethernet load
- phy: Disallow PHY_MSCC and PHY_VITESSE under COMPILE_TEST
- phy: aquantia: refactor firmware upload helpers
- phy: aquantia: use generic firmware loader

net-legacy:
- tftp: Remove tftp_init_load_addr error path

Azure: Rework jobs for disk space and 29 jobs

The problem we face currently with Azure jobs is that we're running out
of disk space on the runners as we build. There's not a good way to
split approximately 1500 configurations across 10 jobs and not be close
to or exceeding that limit. Split this in to 29 jobs instead with a goal
of averaging an hour per job. This split gets us close, but there are
still some challenging jobs to try and break up further. The list is
mostly alphabetized but with some intentional changes (catch-all are
last, mx/imx are together, SoC family splits are just grouped together).

The average build time should be close to the same, but outliers can and
will happen.

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

CI: Update to latest container images

- Bump to noble-20251013
- Include tools for sage lab, build TF-A for platforms there.
- Switch to distro provided trace-cmd, add libengine-pkcs11-openssl
- Use mirrors for GNU projects
- Switch to QEMU 10.1.x

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

Merge patch series "CI: use mirrors for GNU tools"

Quentin Schulz <foss+uboot@0leil.net> says:

I have to add one (1) package to the Dockerfile as a new dependency and
wanted to build the image to verify it works. I wasn't able to because
GNU servers are just not reliable at all.

The git server URL we're using doesn't seem to be a mirrored one, and
switching to mirror URLs seem to make fetching possible again.

Unfortunately, we don't have the option to do that for coreboot's
dependencies, though we can ask coreboot to download the dependencies
through its own mirror, which we do in this series.

Link: https://lore.kernel.org/r/20251127-gnu-mirror-v2-0-c86fa2e8d464@cherry.de

CI: add libengine-pkcs11-openssl package for pkcs11

In the future, we'll need proper pkcs11 support so that we can validate
mkimage/binman works well with pkcs11 OpenSSL engine/provider via
softhsm2-util (already installed).

Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Tom Rini <trini@konsulko.com>

Dockerfile: Switch to distro-provided trace-cmd

Now that we have moved to Ubuntu 24.04 the distribution provided
trace-cmd is new enough for our needs. Switch to installing that and
stop building it from source.

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

Docker: Update QEMU to 10.1.x

The current release of QEMU is 10.1.2 and we should be tracking at least
that new currently, to help find and fix emulation problems. This will
make it smaller of a change when we move to 10.1.3 which will re-enable
sifive_unleashed_sdcard testing again.

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

Merge patch series "Gitlab: Add a "sage-lab" stage to access a board farm"

This series adds support for Gitlab pipelines to run our pytest suite on
a limited number of hardware platforms. While better documentation and
some further enhancements will be coming soon, this can be triggered by
passing '-o ci.variable="SAGE_LAB=1"' to git push, or adding
'pushOption = ci.variable="SAGE_LAB=1"' to the .git/config file for the
project. It can also be invoked manually from the pipeline webpage on a
an existing pipeline.

Link: https://lore.kernel.org/r/20251118210015.624758-1-trini@konsulko.com

Gitlab sage, Docker: Add snmp and rsync

Add snmp and rsync to the normal docker image. While these tools are
only required for the lab on sage, I think it's a small enough addition
to be worth always including at this point. A higher level TODO I think
may be to see if we can / should split the resulting container up, or
if there's host tooling we can remove at a later step, after building
all the software we require.

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

Gitlab: sage: Add Pine64+ platform

This adds the Pine64+ platform to the sage lab, for both legacy and lwIP
networking stacks. In order to build this platform we need to copy
certain files that were built in the container to /tmp and then set
BINMAN_INDIRS to /tmp in order to find them when building.

For now, we disable the test_net_pxe_boot_config test on lwIP as it
leads to a crash that needs to be investigated.

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

Docker: Add building TF-A for pine64_plus

In order to add pine64_plus to the sage lab we will need to have a build
of TF-A available for it as bl31.bin. Add this to the existing build
loop of TF-A targets.

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

Gitlab: Add a "sage-lab" stage to access a board farm

This is the Gitlab side of adding support for the board lab connected to
the "konsulko-sage" runner. On the software side, this lab uses only
upstream labgrid. On the hardware side, each device under test is
connected to its own exporter (typically a Raspberry Pi 4) that must be
turned on (and cleanly turned off) as part of a given test cycle.

Add support for testing on a SolidRun Hummingboard 2 (imx6), Raspberry
Pi 3 and Raspberry Pi 4. In all cases, we enable additional options to
run more tests on the board. As we have some networking tests, we test
both the legacy network stack and lwIP. In the case of Pi platforms, we
test all of 32bit configuration, plain configuration and rpi_arm64, and
again with and without lwIP.

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

net: tftp: Remove tftp_init_load_addr error path

tftp_init_load_addr() always returns 0 since commit af45c84871e4 ("tftp:
rework the logic to validate the load address"), so we don't need to
check if it failed and can remove the error handling.
Also change tftp_init_load_addr() to static void since the return value
is now unused.

Signed-off-by: Leonard Anderweit <l.anderweit@phytec.de>
Reviewed-by: Yannic Moog <y.moog@phytec.de>

net: phy: aquantia: use generic firmware loader

Aquantia PHYs are being used w/o SPI flash in some routers recently.
Current firmware loader only attempts to load from FS on top of MMC,
limiting the use on many devices.

Removed the old firmware loader, migrate to generic script based firmware
loader to allow a wider range and runtime override of firmware source.
(e.g., MMC, USB, UBIFS).

Tested on Buffalo WXR18000BE10P with UBIFS.

Signed-off-by: Beiyan Yun <root@infi.wang>

net: phy: aquantia: refactor firmware upload helpers

Split `aquantia_upload_firmware` into `aquantia_upload_firmware`
and `aquantia_do_upload_firmware` to prepare for fwloader change.

Signed-off-by: Beiyan Yun <root@infi.wang>

net: phy: Disallow PHY_MSCC and PHY_VITESSE under COMPILE_TEST

These two PHY drivers have some overlap of supported PHYs. A longer term
effort is needed to both remove duplication and enhance support by
dealing with some issues that downstream vendor drivers address. For
now, make both of these depend on !COMPILE_TEST so that we can enable
"allyesconfig".

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

net: airoha: bind MDIO controller on Ethernet load

Bind MDIO controller on Ethernet Controller load. The Airoha AN7581 SoC
have an integrated Switch based on MT7531 (or more saying MT7988).

Attach it to the mdio node in the switch node to support scanning for
MDIO devices on the BUS with DM API.

Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>

net: phy: Add the Airoha EN8811H PHY driver

Add the driver for the Airoha EN8811H 2.5 Gigabit PHY. The PHY supports
100/1000/2500 Mbps with auto negotiation only.

The driver uses two firmware files, for which updated versions are added to
linux-firmware already.

Locating the AIROHA FW within the filesystem at the designated partition
and path will trigger its automatic loading and writing to the PHY via MDIO.
If need board specific loading override,
please override the en8811h_read_fw function on board or architecture level.

Based on the Linux upstream AIROHA EN8811H driver code(air_en8811h.c),
I have modified the relevant process to align with the U-Boot boot sequence.
and have validated this on Banana Pi BPI-R3 Mini.

Signed-off-by: Lucien.Jheng <lucienzx159@gmail.com>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>

CI: use coreboot mirror for GNU dependencies of coreboot

coreboot buildgcc script downloads GNU dependencies from GNU FTP server.
For some reason, this is also as unreliable as their git main server.
There's no option to use a GNU mirror (and I'm not even sure if there's
one for FTP), so we simply pass --mirror to the buildgcc script via the
BUILDGCC_OPTIONS variable so that it makes use of coreboot's mirror.
Hopefully, this proves more reliable than GNU original FTP server.

Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>

CI: use mirror for gnulib dependency of grub

grub bootstrap script downloads gnulib from a non-mirror URL and thus is
unreliable.

One can specify the URL to fetch from with GNULIB_URL environment
variable, so let's make this variable point at a mirror URL.

Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>

CI: use GNU mirror for grub (and switch to HTTPS)

GNU announced they activated mirrors for git servers[1] in May this
year.

The main git server keeps being very unreliable and switching to those
mirrors seems to improve reliability (albeit somewhat slow).

Yes, the URL in this patch has nothing in common with the URL in the
linked mail, it was extracted from the Clone section in the mirrored
cgit page[2].

While at it, switch to the HTTPS clone which is "more secure" than git
protocol.

[1] https://lists.gnu.org/archive/html/savannah-users/2025-05/msg00002.html
[2] https://cgit.git.savannah.gnu.org/cgit/grub.git/

Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>

Merge tag 'u-boot-imx-next-20251129' of https://gitlab.denx.de/u-boot/custodians/u-boot-imx into next

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

- Stop disabling device tree relocation on i.MX boards.
- Add support for imx6ulz_smm_m2d.
- Add support for Kontron i.MX93 OSM-S SoM and BL carrier board
- Fix probe of i.MX FEC MDIO bus for DM_MDIO.
- Cleanup for tqma6 boards.
- Initialize the ELE RNG context on imx95_evk
- Disable EFI partition, MP, sysboot, bind commands on tbs2910.

phytec: sort .env files alphabetically for imx8 boards

Sort all .env files alphabetically like it is already done for
phycore_imx8mp.

Signed-off-by: Benjamin Hahn <B.Hahn@phytec.de>

phytec: use fdtoverlay_addr_r

fdtoverlay_addr_r is the correct variable name according to standardboot
documentation and already used for phycore_imx8mp.

Signed-off-by: Benjamin Hahn <B.Hahn@phytec.de>

phytec: change preferred bootdevice dynamically

We want to change the bootdevice dynamically, so that when booting
U-Boot from sdcard, kernel is also preferably booted from sdcard by
default. If the user decides to set their own bootorder, this should not
be overwritten. This was already implemented for imx8mp-libra-fpsc
board, but as we set the default value for boot_targets in devicetree
now, the env_get_default will return NULL. Also env_get might return
NULL when boot_targets is not set. A string compare with NULL is unsafe
and should be avoided. To fix this we only change the env value if the
variable was not set before (NULL), as this is the new default value.
In any other case the user has changed the value so it will not be
overwritten.
Also let standardboot set bootcmd automatically. For this
CONFIG_USE_BOOTCOMMAND needs to be activated.

Signed-off-by: Benjamin Hahn <B.Hahn@phytec.de>

phytec: set bootdevices and bootmeths in devicetree for imx8 boards

Standardboot allows setting bootdevices and bootmeths in devicetree.
This is already implemented for imx8mp-libra board.

Signed-off-by: Benjamin Hahn <B.Hahn@phytec.de>

phytec: add emmc_dev and sd_dev env vars for imx8 boards

Add emmc_dev and sd_dev env variables with comment that they are needed
for builtin uuu flash scripts. This is already done for imx8mp-libra
board.

Signed-off-by: Benjamin Hahn <B.Hahn@phytec.de>

phytec: adapt env to ampliphy-boot bootscripts for imx8 boards

Netboot script is named net_boot_fit.scr.uimg with ampliphy-boot.
fit_fdtconf is not longer needed. The default config is automatically
fetched from the fitImage. mmcroot is also not longer used, the
bootscript has a builtin default. bootenv_addr_r is no longer used, as
the bootenv is loaded into loadaddr.

Signed-off-by: Benjamin Hahn <B.Hahn@phytec.de>

board: tqma6: update MAINTAINERS

- change maintainer e-Mail address
  (old is not suitable for plain text mail)
- add TQ mailing list

Signed-off-by: Max Merchel <Max.Merchel@ew.tq-group.com>

board: [cosmetic] tqma6: adjust SPDX tag

While at it, adjust the TQ-Systems copyright info to include
consistent company information, the mail address to reach all
developers at TQ-Systems for questions regarding U-Boot support
for our SOM and remove author's company mail address not suitable
for plain text mail.

Signed-off-by: Markus Niebel <Markus.Niebel@ew.tq-group.com>
Signed-off-by: Max Merchel <Max.Merchel@ew.tq-group.com>

board: tqma6: style fixes

fix checkpatch warnings

- WARNING: break is not useful after a return
- WARNING: Comparisons should place the constant
  on the right side of the test
- WARNING: please write a help paragraph that fully describes
  the config symbol with at least 2 lines

Signed-off-by: Paul Gerber <Paul.Gerber@tq-group.com>
Signed-off-by: Max Merchel <Max.Merchel@ew.tq-group.com>

tqma6: Remove empty function tqma6_iomuxc_spi()

The function `tqma6_iomuxc_spi()` was removed in the commit
"tqma6: Remove non-DM board code".
The original function was overwritten with an empty function in the
WRU4 baseboard and should also have been removed.
Therefore, the function and its call are being removed.

Fixes: 93552cc442de ("tqma6: Remove non-DM board code")
Signed-off-by: Max Merchel <Max.Merchel@ew.tq-group.com>

net: fec_mxc.c: improve readability of dm_fec_bind_mdio

The last parameter to device_bind_driver_to_node is optional.
Since the returned information is not used and overwritten by
uclass_get_device_by_ofnode just provide NULL as parameter.

Signed-off-by: Markus Niebel <Markus.Niebel@ew.tq-group.com>
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Signed-off-by: Alexander Feilke <alexander.feilke@ew.tq-group.com>

net: fec_mxc: add unique bus and device names for DM_MDIO

When using DM_MDIO on SOC with more than one FEC and not sharing the MDIO
bus the name of the driver and the bus needs to be unique. Since name
used in device_bind_driver_to_node needs to be a static string, add the
string to the fec_priv struct and reuse fec_set_dev_name to generate the
name with the device sequence number.

Fixes: 3b8f99a3e762 ("net: fec: add support for DM_MDIO")
Signed-off-by: Markus Niebel <Markus.Niebel@ew.tq-group.com>
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Signed-off-by: Alexander Feilke <alexander.feilke@ew.tq-group.com>

net: fec_mxc: fix usage of DM_MDIO and DM_ETH_PHY

If DM_ETH_PHY is used and the FEC instance owns the shared MDIO bus,
eth_phy_get_mdio_bus returns NULL. If DM_MDIO bus is used, the
mdio_register API is called from dm_mdio_post_probe. Therefore the
bus should must be queried by name in this case.

For DM_MDIO case fec_mii_setspeed has already being called in
dm_fec_mdio_probe(), so skip setting this again.

Fixes: 3b8f99a3e762 ("net: fec: add support for DM_MDIO")
Fixes: e75d08821574 ("net: fec-mxc: prevent crash if no MAC address is set")
Signed-off-by: Markus Niebel <Markus.Niebel@ew.tq-group.com>
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Signed-off-by: Alexander Feilke <alexander.feilke@ew.tq-group.com>

net: fec_mxc: rewrite fallback MDIO Bus allocation

The code should only be executed if MDIO bus is not assigned.
Otherwise the already assigned / allocated bus will be overwritten.
Add condition check and simplify the code to make it more readable.

Signed-off-by: Markus Niebel <Markus.Niebel@ew.tq-group.com>
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Signed-off-by: Alexander Feilke <alexander.feilke@ew.tq-group.com>

net: fec_mxc: fix remove with DM_MDIO

If DM_MDIO is used and the FEC device is removed the mdio API
must not be used to remove the bus structure. Store pointer the
the udevice for MDIO bus created by dm_fec_bind_mdio and use DM
functions to cleanup the device in fecmxc_remove.

Fixes: 3b8f99a3e762 ("net: fec: add support for DM_MDIO")
Signed-off-by: Markus Niebel <Markus.Niebel@ew.tq-group.com>
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Signed-off-by: Alexander Feilke <alexander.feilke@ew.tq-group.com>

net: fec_mxc: fix probe of MDIO bus for DM_MDIO

When initializing the MDIO bus the MDC signal needs to be configured.
Otherwise the communication over the bus may fail. Add the call to
fec_mii_setspeed to the DM_MDIO probe handler.

Fixes: 3b8f99a3e762 ("net: fec: add support for DM_MDIO")
Signed-off-by: Markus Niebel <Markus.Niebel@ew.tq-group.com>
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Signed-off-by: Alexander Feilke <alexander.feilke@ew.tq-group.com>

net: fec-mxc: prevent crash if no MAC address is set

If no MAC address can be found (either in ROM, device tree or env),
the post_probe of an ethernet device will fail and therefore
the device cannot be instantiated.

The DM_ETH_PHY (eth-phy-uclass) use case must not be mixed with
using CONFIG_FEC_MXC_MDIO_BASE.

This prevents following error for MAC not fused, no eth[1]addr
env is present and providing a random MAC is disabled:

Net:
Error: ethernet@5b040000 address not set.

Error: ethernet@5b040000 address not set.
FEC: can't find phy-handle
"Error" handler, esr 0xbf000002
elr: 000000008004e4b8 lr : 000000008004e4b4 (reloc)
elr: 00000000bfe984b8 lr : 00000000bfe984b4
x0 : 0000000000000000 x1 : 0000000000000020
x2 : 00000000bbe61e50 x3 : 00000000bbe6e1a0
x4 : 0000000000000020 x5 : 0000000000000020
x6 : 000000000000000a x7 : 0000000000000000
x8 : 0000000000000000 x9 : 0000000000000008
x10: 00000000ffffffd8 x11: 0000000000000006
x12: 000000000001869f x13: 0000000000002c50
x14: 0000000000000000 x15: 00000000ffffffff
x16: 0000000000000000 x17: 0000000000000000
x18: 00000000bbe61d98 x19: 00000000bbe4fa68
x20: 00000000bbe78c10 x21: 00000000bbe6e460
x22: 00000000bbe78c10 x23: 00000000bbe91780
x24: 00000000bbe6e510 x25: 00000000000001f8
x26: 00000000ffff8000 x27: 0000000000000000
x28: 0000000000000000 x29: 00000000bbe4fa10

Code: f900003f 9100a3a1 97ffff6e 35000100 (f94017a1)
Resetting CPU ...

Signed-off-by: Markus Niebel <Markus.Niebel@ew.tq-group.com>
Signed-off-by: Alexander Feilke <alexander.feilke@ew.tq-group.com>

net: fec_mxc: respect return value of phy_config

phy_config may fail - for instance in parsing device tree.
This should be handled correctly. So return errors from
phy_config to caller.

Signed-off-by: Markus Niebel <Markus.Niebel@ew.tq-group.com>
Signed-off-by: Alexander Feilke <alexander.feilke@ew.tq-group.com>

pico-imx8mq: Stop disabling device tree relocation

Remove setting of fdt_high to ~0, which disables device tree relocation,
from the default environment. Doing so prevents U-Boot from correcting
problems such as having an unaligned device tree and leads to various
failure modes in the OS.

Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Marek Vasut <marek.vasut@mailbox.org>

pcl063_ull: Stop disabling device tree relocation

Remove setting of fdt_high to ~0, which disables device tree relocation,
from the default environment. Doing so prevents U-Boot from correcting
problems such as having an unaligned device tree and leads to various
failure modes in the OS.

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

pcl063: Stop disabling device tree relocation

Remove setting of fdt_high to ~0, which disables device tree relocation,
from the default environment. Doing so prevents U-Boot from correcting
problems such as having an unaligned device tree and leads to various
failure modes in the OS.

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

liteboard: Stop disabling device tree relocation

Remove setting of fdt_high to ~0, which disables device tree relocation,
from the default environment. Doing so prevents U-Boot from correcting
problems such as having an unaligned device tree and leads to various
failure modes in the OS.

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

imx8qxp_mek: Stop disabling device tree relocation

Remove setting of fdt_high to ~0, which disables device tree relocation,
from the default environment. Doing so prevents U-Boot from correcting
problems such as having an unaligned device tree and leads to various
failure modes in the OS.

Signed-off-by: Tom Rini <trini@konsulko.com>
Acked-by: Peng Fan <peng.fan@nxp.com>

imx8qm_mek: Stop disabling device tree relocation

Remove setting of fdt_high to ~0, which disables device tree relocation,
from the default environment. Doing so prevents U-Boot from correcting
problems such as having an unaligned device tree and leads to various
failure modes in the OS.

Signed-off-by: Tom Rini <trini@konsulko.com>
Acked-by: Peng Fan <peng.fan@nxp.com>

imx8mq_phanbell: Stop disabling device tree relocation

Remove setting of fdt_high to ~0, which disables device tree relocation,
from the default environment. Doing so prevents U-Boot from correcting
problems such as having an unaligned device tree and leads to various
failure modes in the OS.

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

capricorn: Stop disabling device tree relocation

Remove setting of fdt_high to ~0, which disables device tree relocation,
from the default environment. Doing so prevents U-Boot from correcting
problems such as having an unaligned device tree and leads to various
failure modes in the OS.

Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
Reviewed-by: Heiko Schocher <hs@nabladev.com>

warp7: Stop disabling device tree relocation

Remove setting of fdt_high to ~0, which disables device tree relocation,
from the default environment. Doing so prevents U-Boot from correcting
problems such as having an unaligned device tree and leads to various
failure modes in the OS.

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

wandboard: Stop disabling device tree relocation

Remove setting of fdt_high to ~0, which disables device tree relocation,
from the default environment. Doing so prevents U-Boot from correcting
problems such as having an unaligned device tree and leads to various
failure modes in the OS.

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

udoo_neo: Stop disabling device tree relocation

Remove setting of fdt_high to ~0, which disables device tree relocation,
from the default environment. Doing so prevents U-Boot from correcting
problems such as having an unaligned device tree and leads to various
failure modes in the OS.

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

udoo: Stop disabling device tree relocation

Remove setting of fdt_high to ~0, which disables device tree relocation,
from the default environment. Doing so prevents U-Boot from correcting
problems such as having an unaligned device tree and leads to various
failure modes in the OS.

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

tqma6: Stop disabling device tree relocation

Remove setting of fdt_high to ~0, which disables device tree relocation,
from the default environment. Doing so prevents U-Boot from correcting
problems such as having an unaligned device tree and leads to various
failure modes in the OS.

Signed-off-by: Tom Rini <trini@konsulko.com>
Acked-by: Max Merchel <Max.Merchel@ew.tq-group.com>

pico-imx7d: Stop disabling device tree relocation

Remove setting of fdt_high to ~0, which disables device tree relocation,
from the default environment. Doing so prevents U-Boot from correcting
problems such as having an unaligned device tree and leads to various
failure modes in the OS.

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

pico-imx6ul: Stop disabling device tree relocation

Remove setting of fdt_high to ~0, which disables device tree relocation,
from the default environment. Doing so prevents U-Boot from correcting
problems such as having an unaligned device tree and leads to various
failure modes in the OS.

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

pico-imx6: Stop disabling device tree relocation

Remove setting of fdt_high to ~0, which disables device tree relocation,
from the default environment. Doing so prevents U-Boot from correcting
problems such as having an unaligned device tree and leads to various
failure modes in the OS.

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

novena: Stop disabling device tree relocation

Remove setting of fdt_high to ~0, which disables device tree relocation,
from the default environment. Doing so prevents U-Boot from correcting
problems such as having an unaligned device tree and leads to various
failure modes in the OS.

Signed-off-by: Tom Rini <trini@konsulko.com>
Acked-by: Marek Vasut <marek.vasut@mailbox.org>

nitrogen6x: Stop disabling device tree relocation

Remove setting of fdt_high to ~0, which disables device tree relocation,
from the default environment. Doing so prevents U-Boot from correcting
problems such as having an unaligned device tree and leads to various
failure modes in the OS.

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

mys_6ulx: Stop disabling device tree relocation

Remove setting of fdt_high to ~0, which disables device tree relocation,
from the default environment. Doing so prevents U-Boot from correcting
problems such as having an unaligned device tree and leads to various
failure modes in the OS.

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

mx7ulp_evk: Stop disabling device tree relocation

Remove setting of fdt_high to ~0, which disables device tree relocation,
from the default environment. Doing so prevents U-Boot from correcting
problems such as having an unaligned device tree and leads to various
failure modes in the OS.

Signed-off-by: Tom Rini <trini@konsulko.com>
Acked-by: Peng Fan <peng.fan@nxp.com>

mx7ulp_com: Stop disabling device tree relocation

Remove setting of fdt_high to ~0, which disables device tree relocation,
from the default environment. Doing so prevents U-Boot from correcting
problems such as having an unaligned device tree and leads to various
failure modes in the OS.

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

mx7dsabresd: Stop disabling device tree relocation

Remove setting of fdt_high to ~0, which disables device tree relocation,
from the default environment. Doing so prevents U-Boot from correcting
problems such as having an unaligned device tree and leads to various
failure modes in the OS.

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

mx6ullevk: Stop disabling device tree relocation

Remove setting of fdt_high to ~0, which disables device tree relocation,
from the default environment. Doing so prevents U-Boot from correcting
problems such as having an unaligned device tree and leads to various
failure modes in the OS.

Signed-off-by: Tom Rini <trini@konsulko.com>
Acked-by: Peng Fan <peng.fan@nxp.com>

mx6ul_14x14_evk: Stop disabling device tree relocation

Remove setting of fdt_high to ~0, which disables device tree relocation,
from the default environment. Doing so prevents U-Boot from correcting
problems such as having an unaligned device tree and leads to various
failure modes in the OS.

Signed-off-by: Tom Rini <trini@konsulko.com>
Acked-by: Peng Fan <peng.fan@nxp.com>

mx6sxsabresd: Stop disabling device tree relocation

Remove setting of fdt_high to ~0, which disables device tree relocation,
from the default environment. Doing so prevents U-Boot from correcting
problems such as having an unaligned device tree and leads to various
failure modes in the OS.

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

mx6sxsabreauto: Stop disabling device tree relocation

Remove setting of fdt_high to ~0, which disables device tree relocation,
from the default environment. Doing so prevents U-Boot from correcting
problems such as having an unaligned device tree and leads to various
failure modes in the OS.

Signed-off-by: Tom Rini <trini@konsulko.com>
Acked-by: Peng Fan <peng.fan@nxp.com>

mx6sllevk: Stop disabling device tree relocation

Remove setting of fdt_high to ~0, which disables device tree relocation,
from the default environment. Doing so prevents U-Boot from correcting
problems such as having an unaligned device tree and leads to various
failure modes in the OS.

Signed-off-by: Tom Rini <trini@konsulko.com>
Acked-by: Peng Fan <peng.fan@nxp.com>

mx6slevk: Stop disabling device tree relocation

Remove setting of fdt_high to ~0, which disables device tree relocation,
from the default environment. Doing so prevents U-Boot from correcting
problems such as having an unaligned device tree and leads to various
failure modes in the OS.

Signed-off-by: Tom Rini <trini@konsulko.com>
Acked-by: Peng Fan <peng.fan@nxp.com>

mx6sabre: Stop disabling device tree relocation

Remove setting of fdt_high to ~0, which disables device tree relocation,
from the default environment. Doing so prevents U-Boot from correcting
problems such as having an unaligned device tree and leads to various
failure modes in the OS.

Signed-off-by: Tom Rini <trini@konsulko.com>
Acked-by: Peng Fan <peng.fan@nxp.com>