Tom Rini [Wed, 19 Nov 2025 14:55:36 +0000 (08:55 -0600)]
sifive-unleashed: 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.
Tom Rini [Wed, 19 Nov 2025 14:55:19 +0000 (08:55 -0600)]
ae350: 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: Leo Yu-Chi Liang <ycliang@andestech.com>
Conor Dooley [Wed, 19 Nov 2025 12:38:43 +0000 (12:38 +0000)]
riscv: mpfs: move SoC level options to the CPU Kconfig
There are multiple boards that use the PolarFire SoC, so extract
the Kconfig sections that are determined at a CPU level from the board
Kconfigs now that we have a CPU Kconfig.
E Shattow [Thu, 30 Oct 2025 06:23:32 +0000 (23:23 -0700)]
ram: starfive: drop references to 16GB memory size
16GB memory size is not addressable on StarFive JH-7110 SoC because the
DRAM uncached alias begins at +8GB offset from start of DRAM. The logic
for 16GB memory size is a fall-through to the default for an unknown size.
Let's drop this unnecessary 16GB memory size and rely on the case default.
Randolph [Wed, 29 Oct 2025 08:23:28 +0000 (16:23 +0800)]
falcon: support booting linux from MMC/Parallel Flash
To support booting Linux from MMC, the file name should be
set up correctly. To support booting Linux from Parallel Flash,
the SPL_LOAD_FIT_ADDRESS should point to the Parallel Flash.
Tom Rini [Sun, 7 Dec 2025 14:10:24 +0000 (08:10 -0600)]
Merge patch series "Azure: Rework world build to directly use the container"
This series from Tom Rini <trini@konsulko.com> makes some of our Azure
jobs easier to follow by removing the abstraction of calling docker from
the job we're running and instead following normal Azure Pipelines
conventions.
Tom Rini [Wed, 26 Nov 2025 23:49:59 +0000 (17:49 -0600)]
Azure: Rework binman testsuite job to directly use the container
Similar to the changes made for the world build job, rework the binman
testsuite job as well. There's no functional changes, but makes our CI
clearer to others familiar with Azure pipelines.
Tom Rini [Wed, 26 Nov 2025 23:49:58 +0000 (17:49 -0600)]
Azure: Rework world build to directly use the container
While we had problems historically using buildman inside of a container
when invoked directly via Azure, rather than calling docker in our
script, that is no longer the case. We can make the job a bit easier to
understand by running it more normally. The challenge here is that our
container normally runs with an unprivileged user that we have populated
tools for and Azure creates and uses a new unprivileged user. Copy what
we need over to the new user.
Daniel Schultz [Mon, 24 Nov 2025 08:25:06 +0000 (00:25 -0800)]
board: phytec: phytec_som_detection: Add support for phyFLEX
phyFLEX are SoMs based on the FPSC standard.
Add additional "SOM types" for the phyFLEX modules base on the
FPSC Gamma specification. These modules come in four different
variants; prototypes (PT), standard product (SP), KSP (KP) and
KSM (KM).
- Fix the i.MX9 USB instance number for revision B0.
- Add nxp-imx9image etype for binman node.
- Use default for SYS_MALLOC_F_LEN for apalis-imx8 and colibri-imx8x.
- Switch phycore-imx93 to standard boot.
- Update the nitrogen6x maintainer.
Primoz Fiser [Fri, 5 Dec 2025 11:10:43 +0000 (12:10 +0100)]
board: phytec: phycore-imx93: Set boot_targets dynamically
Set boot_targets environment variable dynamically, so that when booting
from SD-card, boot binaries are also preferably fetched from the SD-card
by default. If the user decides to set their own boot_targets, we should
not overwrite them.
Primoz Fiser [Fri, 5 Dec 2025 11:10:42 +0000 (12:10 +0100)]
board: phytec: phycore-imx93: Switch to standard boot
Enable standard boot for the phyCORE-i.MX93 board and use it as a new
default. Add required standard boot variables to the environment, while
removing old boot scripts and now unnecessary environment variables.
Adjust variables according to the requirements of PHYTEC ampliphy-boot
distro-boot. Last but not least, order environment vars by alphabet and
run 'make savedefconfig' to resync defconfig.
Fedor Ross [Mon, 1 Dec 2025 16:08:06 +0000 (17:08 +0100)]
imx9: scmi: soc: USB instance number change for silicon revision B0
For silicon revision A1, the USB instance number for USB1 is 3 and for
USB2 it is 4. This changed for revision B0 where the USB instance number
for USB1 is 0 and for USB2 it is 1, which is the intended instance
number. Select the correct numbering according to the selected SoC
(IMX95) and its revision.
This patch is based on the information provided by:
"AN14750 Migration Guide from i.MX 95 A1 to B0; Rev. 1.0" .
Reviewed-by: Alice Guo <alice.guo@nxp.com> Signed-off-by: Fedor Ross <fedor.ross@ifm.com> Reviewed-by: Marek Vasut <marek.vasut@mailbox.org>
Tom Rini [Sat, 6 Dec 2025 17:46:15 +0000 (11:46 -0600)]
Merge patch series "test/py: fit: Deduplicate the test"
This series from Marek Vasut <marek.vasut@mailbox.org> cleans up some of
the FIT pytests we have and then extends mkimage to support including
the TEE in FIT images when using "-f auto" to create the resulting FIT.
Marek Vasut [Tue, 25 Nov 2025 15:42:57 +0000 (16:42 +0100)]
mkimage: Add support for bundling TEE in mkimage -f auto
Introduce two new parameters to be used with mkimage -f auto to bundle
TEE image into fitImage, using auto-generated fitImage. Add -z to specify
TEE file name and -Z to specify TEE load and entry point address. This is
meant to be used with systems which boot all of TEE, Linux and its DT from
a single fitImage, all booted by U-Boot.
Example invocation:
"
$ mkimage -E -A arm -C none -e 0xc0008000 -a 0xc0008000 -f auto \
-d arch/arm/boot/zImage \
-b arch/arm/boot/dts/st/stm32mp135f-dhcor-dhsbc.dtb \
-z ../optee_os/out/arm-plat-stm32mp1/core/tee-raw.bin \
-Z 0xde000000 \
/path/to/output/fitImage
"
Documentation update and test are also included, the test validates
both positive and negative test cases, where fitImage does not include
TEE and does include TEE blobs.
Acked-by: Quentin Schulz <quentin.schulz@cherry.de> Signed-off-by: Marek Vasut <marek.vasut@mailbox.org>
Marek Vasut [Tue, 25 Nov 2025 15:42:56 +0000 (16:42 +0100)]
test/py: fit: Deduplicate the test
Introduce generate_and_check_fit_image() and call it with various
parameters to test various configurations of the fitImage. This is
identical to the existing test, expect for the code duplication.
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de> Signed-off-by: Marek Vasut <marek.vasut@mailbox.org>
Tom Rini [Sat, 6 Dec 2025 17:44:56 +0000 (11:44 -0600)]
Merge patch series "fit: allow signing with an OpenSSL engine"
Quentin Schulz <foss+uboot@0leil.net> says:
I have a couple of products whose U-Boot FIT is signed via a proprietary
OpenSSL engine which only expects the name of a "slot" to select the key
to sign data with.
Currently mkimage fit support expects either a key-dir (-k) or a
key-file (-G) as a toggle for signing, however this doesn't apply to our
usecase because we use an OpenSSL engine (so no key-file to provide)
which doesn't mimic a directory layout like key-dir implies. Moreover,
binman really expects private keys (.key extension) to be available in
this key-dir directory, which we of course cannot provide.
This series allows to sign a FIT image with mkimage (and binman) with
an OpenSSL engine, including PKCS11 and custom engines. If a key-dir
needs to be passed (which is typical for PKCS11), one can do so by using
fit,engine-keydir.
Note that the public key (.crt extension) still needs to be available if
one wants to embed it for signature verification (which is probably what
one wants to do :) ). It is probably possible to use the engine for
getting the public key instead of storing it on disk, but this needs to
be added to fdt_add_pubkey and then binman, through a mechanism
different from fit,engine*.
One issue though is that since binman resolves key paths absolutely and
that I don't believe an OpenSSL engine would happen to have the exact
same key_id value than a local absolute path, fit,encrypt and
fit,engine cannot cohabit. An issue for the next person who wants
an OpenSSL engine AND encrypt the same FIT image, I don't.
Note that LibreSSL supports neither engines nor providers as far as I
could tell (engine support has been explicitly removed).
Note that OpenSSL engines have been deprecated since 3.0 (Q3-2021),
however note that OpenSSL 3.5 still seems to support engines (git grep)
and is EOL end of Q1 2030.
If anyone has an idea on how to test PKCS11 with SOftHSMv2 with id=
passed in fit,engine-keydir, I'm all ears.
I'm also wondering if the explanation around fit,engine-keydir aren't
too much. After all, they are passed verbatim to mkimage as -k argument
and the special cases are all specific to mkimage and not binman.
Quentin Schulz [Fri, 21 Nov 2025 17:15:00 +0000 (18:15 +0100)]
tools: binman: fit: add tests for signing with an OpenSSL engine
This adds a test that signs a FIT and verifies the signature with
fit_check_sign.
OpenSSL engines are typically for signing with external HW so it's not
that straight-forward to simulate.
For a simple RSA OpenSSL engine, a dummy engine with a hardcoded RSA
4096 private key is made available. It can be selected by setting the
OpenSSL engine argument to dummy-rsa-engine. This can only be done if
the engine is detected by OpenSSL, which works by setting the
OPENSSL_ENGINES environment variable. I have no clue if dummy-rsa-engine
is properly implementing what is expected from an RSA engine, but it
seems to be enough for testing.
For a simple PKCS11 engine, SoftHSMv2 is used, which allows to do PKCS11
without specific hardware. The keypairs and tokens are generated on the
fly. The "prod" token is generated with a different PIN (1234 instead of
1111) to also test MKIMAGE_SIGN_PIN env variable while we're at it.
Binman will not mess with the local SoftHSMv2 setup as it will only use
tokens from a per-test temporary directory enforced via the temporary
configuration file set via SOFTHSM2_CONF env variable in the tests. The
files created in the input dir should NOT be named the same as it is
shared between all tests in the same process (which is all tests when
running binman with -P 1 or with -T).
Once signed, it's checked with fit_check_sign with the associated
certificate.
Finally, a new softhsm2_util bintool is added so that we can initialize
the token and import keypairs. On Debian, the package also brings
libsofthsm2 which is required for OpenSSL to interact with SoftHSMv2. It
is not the only package required though, as it also needs p11-kit and
libengine-pkcs11-openssl (the latter bringing the former). We can detect
if it's properly installed by running openssl engine dynamic -c pkcs11.
If that fails, we simply skip the test.
The package is installed in the CI container by default.
Quentin Schulz [Fri, 21 Nov 2025 17:14:59 +0000 (18:14 +0100)]
tools: binman: fit: add support for OpenSSL engines
This adds support for using an OpenSSL engine for signing a FIT image.
To use it, one should set the fit,engine property at the FIT node level
with the engine to use. This will in turn call mkimage with the -N
option.
The -k argument to mkimage can be specified via fit,engine-keydir. If
not specified, -k is not passed to mkimage. This property is especially
useful for pkcs11 engine to specify slots, token label, etc...
As far as I could tell, mkimage encrypts and signs a FIT in one go, thus
the -k argument applies to both signing and encrypting. Considering we
reuse the -k argument for two different meanings (info to pass to the
engine when using an engine otherwise the directory where keys are
stored), we cannot reasonably encrypt using local keys and signing with
an engine, hence the enforced check. I believe it should be possible to
support encrypting and signing with the same engine (using different
key pairs of course, via different key-name-hint likely), but this is
left for the next person to implement.
This is why the property is named fit,engine and not fit,sign-engine.
Ditto for fit,engine-keydir.
The public key (with .crt extension) is still required if it needs to be
embedded in the SPL DTB for example. We could probably support
retrieving the public key from an engine, but this is a change to make
to fdt_add_pubkey.c.
Quentin Schulz [Fri, 21 Nov 2025 17:14:58 +0000 (18:14 +0100)]
tools: binman: mkimage: add support for passing the engine
mkimage has support for OpenSSL engines but binman currently doesn't for
direct callers of mkimage (e.g. the fit etype). This prepares for adding
support for OpenSSL engines for signing elements of a FIT image, which
will done in the next commit.
Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Quentin Schulz [Fri, 21 Nov 2025 17:14:57 +0000 (18:14 +0100)]
fit: support signing with only an engine_id
Currently, when one wants to use an OpenSSL engine to sign a FIT image,
one needs to pass a keydir (via -k) to mkimage which will then be
prepended to the value of the key-name-hint before being passed as
key_id argument to the OpenSSL Engine API, or pass a keyfile (via -G) to
mkimage.
My OpenSSL engine only has "slots" which are not mapped like
directories, so using keydir is not proper, though I could simply have
-k '' I guess but this won't work currently with binman anyway.
Additionally, passing a keyfile (-G) when using an engine doesn't make
sense as the key is stored in the engine.
Let simply allow FIT images be signed if both keydir and keyfile are
missing but an engine is to be used.
The keyname member is already filled by looking at key-name-hint
property in the FIT and passed to the engine, which is exactly what is
needed here.
Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Tom Rini [Fri, 5 Dec 2025 23:03:36 +0000 (17:03 -0600)]
Merge patch series "clk: Return value calculated by ERR_PTR"
Andrew Goodbody <andrew.goodbody@linaro.org> says:
Smatch reported an error where a value calculated by ERR_PTR was not
used. Fixing this to return the generated value led to a test failure
which meant updating the sandbox clock code so that it would still cause
the tests to pass with the above correction.
Debugging this problem led to a SIGSEGV which is addressed in 1/3.
Possible memory leaks noticed are addressed in 3/3.
Andrew Goodbody [Fri, 21 Nov 2025 17:34:33 +0000 (17:34 +0000)]
clk: Prevent memory leak on error
In clk_set_default_rates() memory is allocated to store the clock rates
that are read. Direct returns fail to free this memory leading to a
memory leak so instead use 'goto fail;' which will then perform the free
before exiting the function.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Andrew Goodbody [Fri, 21 Nov 2025 17:34:32 +0000 (17:34 +0000)]
clk: Return value calculated by ERR_PTR
In clk_set_default_get_by_id ret is passed to ERR_PTR but nothing is
done with the value that this calculates which is obviously not the
intention of the code. This is confirmed by the code around where this
function is called.
Instead return the value from ERR_PTR.
Then fixup the sandbox code so that the test dm_test_clk does not fail
as it relied on the broken behaviour.
Finally disable part of the test that does not work correctly with
CLK_AUTO_ID
This issue found by Smatch.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Andrew Goodbody [Fri, 21 Nov 2025 17:34:31 +0000 (17:34 +0000)]
clk: Prevent SIGSEGV on debug
If LOG_DEBUG is defined and a NULL clk is passed to clk_enable or
clk_disable then an attempt is made to dereference NULL in the debug
statement. Guard against this.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Marek Vasut [Thu, 20 Nov 2025 04:15:30 +0000 (05:15 +0100)]
boot: Check noffset before use
If noffset is negative, do not pass it to fit_get_name() and then further to
libfdt, this will crash sandbox with SIGSEGV because libfdt can not handle
negative node offsets without full tree check, which U-Boot inhibits to keep
size lower.
Instead, always check noffset before use, and if the return value indicates
failure, exit right away.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Acked-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Anshul Dalal [Thu, 20 Nov 2025 09:31:27 +0000 (15:01 +0530)]
configs: am64x, am65x: add CONFIG_DA8XX_GPIO
The DA8xx GPIO driver was not being built as part of the A53 U-Boot
image on AM64x and AM65x. This meant only i2c GPIO expanders were
accessible to the users from the U-Boot prompt.
Marian Cingel [Sat, 8 Nov 2025 23:23:25 +0000 (23:23 +0000)]
board: ti: CAT24C256WI-GT3 require min. 5ms delay (tWR) between write/read
Otherwise the custom-cape eeprom (at address 57) reports NACK which
results into "i2c_write: error waiting for data ACK (status=0x116)" and
terminates further scanning.
Signed-off-by: Marian Cingel <cingel.marian@gmail.com>
Sam Protsenko [Mon, 27 Oct 2025 00:24:58 +0000 (19:24 -0500)]
autoboot: Fix inconsistent countdown output
Commit 5f70be08b015 ("Fix autoboot countdown printing wrong") introduces
inconsistency in how the countdown is displayed. For example, in case
when BOOTDELAY=5, the next output is observed during the boot:
Hit any key to stop autoboot: 5
Hit any key to stop autoboot: 4
Hit any key to stop autoboot: 3
That happens due to different printf format (%2d vs %1d). Moreover, the
mentioned commit fails to handle the case when the user is holding some
key before the countdown is shown. E.g. if BOOTDELAY=101, the next
malformed output is being produced:
Hit any key to stop autoboot: 1 0
That's because the fast path code wasn't modified accordingly, and still
tries to erase the number using '\b\b\b' format.
Fix both issues by introducing a dedicated routine for printing the
whole countdown line.
Fixes: 5f70be08b015 ("Fix autoboot countdown printing wrong") Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> Reviewed-by: Tom Rini <trini@konsulko.com> Acked-by: David Zang <davidzangcs@gmail.com>
Tom Rini [Mon, 6 Oct 2025 15:38:59 +0000 (09:38 -0600)]
clk: ti: Tighten some TI clock driver dependencies
Attempting to build with "allyesconfig" means that we try and build all
available options for the sandbox platforms. Doing so exposes that the
drivers under drivers/clk/ti/ can only be compiled or linked on
ARCH_OMAP2PLUS platforms as some drivers require platform specific
headers while other drivers depend on these first drivers to link.
Express those requirements in Kconfig as well.
Reviewed-by: Manorit Chawdhry <m-chawdhry@ti.com> Signed-off-by: Tom Rini <trini@konsulko.com>
Tom Rini [Fri, 26 Sep 2025 15:31:40 +0000 (09:31 -0600)]
mtd: Tighten some driver dependencies
The ALTERA_QSPI driver conflicts with the regular FLASH_CFI_DRIVER as
both implement the same high level functionality and so use the same
global namespace. In a similar fashion, all NAND drivers are mutually
exclusive due to namespace collisions. For the remaining drivers which
did not already have some architecture specific dependency, add them.
Tom Rini [Fri, 5 Dec 2025 19:38:32 +0000 (13:38 -0600)]
Merge patch series "led: remove unused legacy LED code"
Quentin Schulz <quentin.schulz@cherry.de> says:
Only the Siemens corvus board seems to be using these two status LEDs
from the legacy LED API.
Since we're trying to get rid of the last users of the legacy LED API,
let's migrate Corvus to the modern LED API instead, which uses DM. For
Corvus's case, it also uses DM_GPIO (already enabled in defconfig).
Since there was no use for the green status_led (not compiled in), it
simply is removed without migrating it to the modern API. If need be, we
can always add a new gpio-led in the FDT.
Note that I do not own a Siemens Corvus board so it's a bit of a shot in
the dark whether it'll work on the first try, only build tested.
The red LED should be on whenever reaching U-Boot proper CLI, if not we
have an issue.
The LED should be controllable with the led command from U-Boot proper
CLI.
Quentin Schulz [Wed, 19 Nov 2025 17:01:15 +0000 (18:01 +0100)]
led: remove support for red LED in legacy API
To the exception of red_led_on in the arm-specific assembly code, all
code interacting with the red status LED was guarded by the
CONFIG_LED_STATUS_RED symbol, which is enabled in none of the upstream
defconfigs.
Since the last board which overrode the weak red_led_on function got
migrated to the new LED mechanism, there's also no user of the
arm-specific assembly code anymore, therefore it can be removed along
the other unreachable code sections.
Quentin Schulz [Wed, 19 Nov 2025 17:01:14 +0000 (18:01 +0100)]
corvus: migrate red LED to the modern API
red_led_on is either called from the legacy LED shell command (which is
disabled for corvus) or from arm-specific assembly code right before
jumping into board_init_r() in U-Boot proper.
Let's migrate to use the more modern LED subsystem by migrating to DM.
The default-state is set to on to mimic red_led_on() from the
arm-specific assembly code as a missing default-state FDT property
currently means the LED is not probed except if explicitly done via the
led shell command. Note though that this is running much later in the
boot process, once DM is started.
Quentin Schulz [Wed, 19 Nov 2025 17:01:12 +0000 (18:01 +0100)]
corvus: remove green led support
green_led_on and green_led_off are only called by the legacy LED command
(CONFIG_LED_STATUS_CMD) when CONFIG_LED_STATUS_GREEN is enabled, both of
which aren't enabled for corvus, so let's simply remove it as it's dead
code.
Tom Rini [Fri, 5 Dec 2025 16:35:49 +0000 (10:35 -0600)]
Merge patch series "led: remove unused legacy LED code"
Quentin Schulz <quentin.schulz@cherry.de> says:
This is a follow-up to:
- https://lore.kernel.org/u-boot/20251112-led-old-dt-v1-0-2892d49517db@cherry.de/
- https://lore.kernel.org/u-boot/20251114162417.4054006-1-patrice.chotard@foss.st.com/
to continue the effort of getting rid of the legacy LED API. This series
depends on the series listed above.
Quentin Schulz [Wed, 19 Nov 2025 16:43:48 +0000 (17:43 +0100)]
net: remove unreachable legacy LED code
The code is guarded by a condition none of the defconfigs meet (that is
CONFIG_SYS_FAULT_ECHO_LINK_DOWN and CONFIG_LED_STATUS_RED both enabled),
so we can remove the unreachable code sections.
When doing that, there's no caller for miiphy_link anymore, so it can be
removed.
This in turns makes CONFIG_SYS_FAULT_ECHO_LINK_DOWN and
CONFIG_SYS_FAULT_MII_ADDR unused so they are removed as well.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by: Tom Rini <trini@konsulko.com>
Quentin Schulz [Wed, 19 Nov 2025 16:43:47 +0000 (17:43 +0100)]
arm: omap3: remove leftover from CM_T35 support removal
Commit 76386d6195a1 ("arm: Remove cm_t35 board") removed support for the
board that was built when TARGET_CM_T35 is selected, but removal of the
symbol was forgotten, so let's fix this oversight.
While at it, update the README for omap3 to remove the last mention of
cm_t35.
malta: increase SYS_MALLOC_F_LEN and SYS_MALLOC_LEN
If CONFIG_CONSOLE_RECORD_INIT_F=y we need additional memory according to
CONFIG_CONSOLE_RECORD_OUT_SIZE_F. Similarly CONFIG_SYS_MALLOC_LEN must be
increased by CONSOLE_RECORD_OUT_SIZE.
Go with the default values for CONFIG_CONSOLE_RECORD_INIT_F and
CONFIG_SYS_MALLOC_LEN.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
We invoke the ut command in test_ut.py. Currently we only check for
failures. Instead we should also indicate if sub-tests were skipped.
With this change we will get output like the following for skipped tests:
test/py/tests/test_ut.py ..sssss......ss..............s.sssss.s.s...
================================ short test summary info ================================
SKIPPED [1] test/py/tests/test_ut.py:597: Test addrmap addrmap_test_basic has 1 skipped sub-test(s).
SKIPPED [1] test/py/tests/test_ut.py:597: Test bdinfo bdinfo_test_eth has 4 skipped sub-test(s).
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
_ update LED management for STMicroelectronics boards
_ Add 1 GiB DRAM support for STM32MP13x DHCOR SoM
_ Fix 512 MiB DRAM support for STM32MP13x DHCOR SoM
_ Fix handling OPTEE in middle of the DRAM
_ Add missing debug UART build for STM32MP1 DHSOM
Patrice Chotard [Fri, 14 Nov 2025 16:23:55 +0000 (17:23 +0100)]
ARM: dts: stm32: Drop "u-boot-led" and "error-led" from stm32mp157c-ed1-u-boot
Remove obsolete properties "u-boot, u-boot-led" and "u-boot,error-led"
from stm32mp157cf-ed1-u-boot.dtsi.
Remove led-red and led-blue nodes which are available in kernel DT.
See kernel series: https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=1022570
Patrice Chotard [Fri, 14 Nov 2025 16:23:54 +0000 (17:23 +0100)]
ARM: dts: stm32: Drop "u-boot-led" and "error-led" from stm32mp157c-ed1-scmi-u-boot
Remove obsolete properties "u-boot, u-boot-led" and "u-boot,error-led"
from stm32mp157c-ed1-scmi-u-boot.dtsi.
Remove led-red and led-blue nodes which are available in kernel DT.
See kernel series: https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=1022570
projects / thirdparty / u-boot.git / log
