Tom Rini [Wed, 26 Nov 2025 16:30:24 +0000 (10:30 -0600)]
CI: Update to latest container
- Move to jammy-20251013 tag
- Bring in tkinter so that FATtools should run and more tests should be
run.
- Update to QEMU 10.0.6
- Pick tags for (most of) trace-cmd
Tom Rini [Wed, 26 Nov 2025 16:21:54 +0000 (10:21 -0600)]
Dockerfile: Update building trace tools slightly
We have not been picking a tag for the trace-cmd build process.
Currently the tip of libtraceevent fails to build. Address both problems
here by picking recent stable tags for libtraceevent and libtracefs
(trace-cmd has no recent tags). Further, as it is often reported that
this fails to build due to a race, stop using "make -j$(nproc)" as this
is also small enough of a set of builds to not be an issue.
Tom Rini [Thu, 13 Nov 2025 22:09:56 +0000 (16:09 -0600)]
Dockerfile: Include python3-tk for FATtools
In some cases our tests for exFAT don't run because we fail to be able
to create the underlying image. This is in turn because while creation
of the image succeeds, it seems that some way of how we invoke FATtools
wants to import tkinter, that fails and so the test stops there. Having
tkinter available (and then presumably a fallback to non-GUI because
it's not available) leads to the tests running as expected.
Reviewed-by: Marek Vasut <marek.vasut@mailbox.org> Signed-off-by: Tom Rini <trini@konsulko.com>
Tom Rini [Wed, 19 Nov 2025 14:32:58 +0000 (08:32 -0600)]
Docker: Update QEMU to 10.0.6
The QEMU project has the 10.0.x series as an LTS release. While we are
not doing an LTS ourselves, we can be confident in the changes between
10.0.2 and 10.0.6, so update ourselves.
Jonas Karlman [Sun, 16 Nov 2025 01:45:29 +0000 (01:45 +0000)]
rockchip: rk3588: Map SCMI shared memory area as non-cacheable
The SCMI shared memory area is no longer automatically marked as
non-cacheable after the commit a5a0134570c8 ("firmware: scmi: Drop
mmu_set_region_dcache_behaviour() misuse").
This change in behavior cause Rockchip RK3588 boards to fail boot with:
SoC: RK3588
DRAM: 8 GiB
scmi-over-smccc scmi: Channel unexpectedly busy
scmi_base_drv scmi-base.0: getting protocol version failed
scmi-over-smccc scmi: failed to probe base protocol
initcall_run_r(): initcall initr_dm() failed
### ERROR ### Please RESET the board ###
Update the memory mapping on RK3588 to mark the SCMI shared memory area
as non-cacheable to fix the SCMI shared memory based transport issue
that prevented RK3588 boards from booting.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
boot: pxe_utils: Fix memory allocation issues in overlay_dir handling
Fix two memory allocation bugs in label_boot_extension():
1. When label->fdtdir is not set, overlay_dir was used without any
memory allocation.
2. When label->fdtdir is set, the allocation size was incorrect,
using 'len' (just the fdtdir length) instead of 'dir_len' (which
includes the trailing slash and null terminator).
Resolve both issues by moving the memory allocation and string
formatting outside the conditional block, resulting in clearer code
flow and correct sizing in all cases.
Francois Berder [Tue, 11 Nov 2025 10:37:35 +0000 (11:37 +0100)]
upl: Fix buf array size
Size of array buf was incorrect due to sizeof returning the
size of an integer (typically 32 bits) instead of a u64 type
(64 bits). Hence, buf array was shorter than expected.
Signed-off-by: Francois Berder <fberder@outlook.fr> Reviewed-by: Simon Glass <sjg@chromium.org>
* board: ti: am6254atl_sk: correct value of PRELOADED_BL33_BASE
* pytest: fix u-boot-test-flash typo
* samsung: Fix PXE description for the E850-96 board
* board: ti: k3: Update TI firmware repository URL to GitHub
* add missing macro descriptions to include/test/ut.h and add it to
the API documenation
* rearrange the description of DM tests and describe return values
Testing:
* Enable CI testing ACPI on qemu-riscv64_smode_acpi_defconfig
* Add qemu-riscv64_smode_defconfig to the CI tests
* Generalize tests such that they can run on RISC-V QEMU
- fdt_test_apply requires CONFIG_OF_LIBFDT_OVERLAY
- cmd/fdt: do not assume RNG device exists
- cmd/bdinfo: make no flash assumption
- cmd/bdinfo: consider arch_print_bdinfo() output
- common/print: do not use fixed buffer addresses
- cmd/fdt: do not use fixed buffer addresses
- raise CONFIG_CONSOLE_RECORD_OUT_SIZE default to 0x6000
* enable CONFIG_CONSOLE_RECORD=y on qemu-riscv64_smode_acpi
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEbcT5xx8ppvoGt20zxIHbvCwFGsQFAmkg1IsACgkQxIHbvCwF
# GsQVLA//dmiApob+J9FUhD8joD+DaKSNfLYmv8zwfIFL2xRxx7D+CQT+r+I9FJYI
# KojiLyn4PE/5VOm+wrsvAoYoMLJwAHvg5nmYJLLzvm6V//DLd1AEopP/+Uh8gEVW
# xYGLcvDyGgZpraAhcmqRnAS89py3SigwGzhcUMbT6ZC6pgMVEsBpg8XeMpY7N05c
# rwyqFAAPD8RcF7veQCpry87NiK5o+9YuM1zKl5sDFOpEWKq5ToNwhQ00bnux9lUd
# HWz9X6ge58iFiMXRqUCnOaPeXeChn9ejyEiKtfQ0JtykOf9NT2WMdD2VKe9PCYsd
# f7OynJTGG2OXTKBhon/xj75itiTm7EELc/FHwHEdtZIIHgpi/C33yQgKxLf9mtUo
# Z7DKYpPoaTCbJhs9LCK942KPtshbtAJLKTVqyBPo7Jn0mneeCQUsbaQRU7JruJTK
# hKluUjsAry3Do3wv/w6B8R6MMgfpBktPkqjg9e/maSdhYdkNAYpjajtORgpqmJRV
# HTGJXfL3qFC50jlenlMYOm4Qake33MIMzubaxoM3j5ENDUJ7KAbWADEoWDpve8Tu
# b/fX8uuW+g2T18Y/M9Bsk/jaUjDTx0xtZUSYNIIQJFDaJMzUxGYWlmtXhLZwFU8g
# 7S5pBmgxoSAtQSMAeoJPJp9FSgXYqiGLUeSwcOH2NaPn0lLFvK0=
# =D0Yy
# -----END PGP SIGNATURE-----
# gpg: Signature made Fri 21 Nov 2025 03:07:23 PM CST
# gpg: using RSA key 6DC4F9C71F29A6FA06B76D33C481DBBC2C051AC4
# gpg: Good signature from "Heinrich Schuchardt <xypron.glpk@gmx.de>" [unknown]
# gpg: aka "[jpeg image of size 1389]" [unknown]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 6DC4 F9C7 1F29 A6FA 06B7 6D33 C481 DBBC 2C05 1AC4
Sam Protsenko [Tue, 18 Nov 2025 21:00:55 +0000 (15:00 -0600)]
doc: samsung: Fix PXE doc for E850-96 board
As stated in PXELINUX doc [1], the PXE configuration file has to be in
the format of "01-MAC-address" for Ethernet connections:
The hardware type (using its ARP "htype" code) and address, all in
lowercase hexadecimal with dash separators. For example, for an
Ethernet (i.e. ARP hardware type "1") with address
"88:99:AA:BB:CC:DD", it would search for the filename
"01-88-99-aa-bb-cc-dd".
Indeed, PXE implementation in U-Boot looks for files like that, as can
be seen from this call chain:
Mention the fact that PXE expects the configuration file to be prepended
with "01" in the PXE section of E850-96 documentation. While at it, fix
some other minor issues in PXE section.
doc: board: ti: k3: Update TI firmware repository URL to GitHub
Update the TI firmware repository URL from git.ti.com to the
GitHub mirror at github.com/TexasInstruments/ti-linux-firmware
which is much more reliable.
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reported-by: Tom Rini <trini@konsulko.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
QEMU comes with its own OpenSBI. For running RISC-V virtual machine
using one of qemu-riscv64_smode_defconfig or
qemu-riscv64_smode_acpi_defconfig is the natural choice.
Add the riscv64 smode configurations to the test scope.
Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
configs: CONFIG_CONSOLE_RECORD=y on qemu-riscv64_smode_acpi
For testing ACPI on QEMU we need a defconfig that supports acpi command
test.
Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
On x86 commit 9b35dbc93fd4 ("x86: Show the timestamp counter with bdinfo")
has added another bdinfo output line.
On RISC-V commit 66b5ee9c558e ("riscv: add RISC-V fields to bdinfo
command") implemented arch_print_bdinfo().
Update the bdinfo test accordingly.
Fixes: 9b35dbc93fd4 ("x86: Show the timestamp counter with bdinfo") Fixes: 66b5ee9c558e ("riscv: add RISC-V fields to bdinfo command") Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
In fdt_test_chosen() currently we test if DM_RNG is configured.
CONFIG_DM_RNG=y does not imply that a RNG device actually exists.
For instance QEMU may be called with -device virtio-rng-device or not.
The current test framework evicts the virtio RNG device even if QEMU is
called with -device virtio-rng-device.
In the fdt_test_chosen() check if a RNG device exists.
Ignore 'No RNG device' messages.
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
This pull request enhances NAND and SPI flash support, primarily
focusing on the Airoha EN7523 platform. The Airoha SPI driver receives
a major update, adding DMA, dual/quad-wire modes, and a critical
workaround to prevent flash damage if the UART_TXD pin shorts to Ground.
New chips supported include FudanMicro FM25S01A SPI-NAND and several
Winbond SPI NOR devices. Fixes include correcting Kconfig dependencies,
updating the mtd benchmark command to use lldiv(), and addressing minor
bugs in the generic spi-mem and SPL NAND code.
Fix compiler warnings about casting integers to pointers of different
sizes by using uintptr_t as intermediate type. This ensures proper
type conversion across 32-bit and 64-bit architectures.
Wolfgang Wallner [Wed, 29 Oct 2025 09:22:47 +0000 (10:22 +0100)]
arm: dts: brcp1: Move SPL partition to offset 0x8000 in SPI flash
The ROM code of Xilinx Zynq searches the boot flash for a "BootROM header"
at increments of 32k (0x8000), beginning with 0x0000 for a
configuration without authentication and beginning with 0x8000
for a configuration with authentication. [1]
Move the offset of the SPL partition on the brcp1 board to 0x8000
so that both cases are the same, e.g. a board that is configured
without authentication can boot an SPL partition with or without
authentication.
Quentin Schulz [Tue, 11 Nov 2025 11:52:34 +0000 (12:52 +0100)]
lib: optee: forbid OP-TEE OS loading without adding OP-TEE OS reserved-memory nodes
I've spent time trying to figure out why my board (Rockchip PX30-based)
suddenly boot loops when running a specific program in Linux userspace
after working on a U-Boot upgrade. I actually inadvertently had the TEE
environment variable set for a device which doesn't actually need to run
any TEE OS (so had OPTEE_LIB disabled).
It is currently possible to build an image with an OP-TEE OS (via the
TEE environment variable) without OPTEE_LIB. U-Boot will happily load
the TEE OS and the next OS (e.g. the Linux kernel).
This is an issue because on FDT-enabled devices, OP-TEE OS adds nodes to
the reserved-memory FDT node for the memory regions it just reserved for
itself. This updated FDT is then passed to U-Boot proper which should
know better not to use memory from there. The actual issue is that
without OPTEE_LIB and OF_LIBFDT enabled, U-Boot proper will not copy
those nodes over to the next OS's FDT before starting it. This results
in the next OS's (e.g. Linux kernel) to not be aware of reserved memory,
incurring random crashes or device reboots when it tries to access
secure reserved memory area.
On Rockchip, the U-Boot FIT image which contains both the TEE OS and
U-Boot proper is generated by binman. Unfortunately, binman doesn't seem
to have access to Kconfig symbols (grep CONFIG_ doesn't return anything
meaningful and binman is either configured through FDT nodes or via CLI
arguments, c.f. cmd_binman in the root Makefile) so we cannot try to be
smart and guide the user to the correct Kconfig option to select if TEE
is set. We could add a property based on the presence of OPTEE_LIB in
rockchip-u-boot.dtsi for example and have a custom message based on
that, the issue is that I assume all FDT-based platforms do actually
need to do this dance, and not only Rockchip.
Another option could be to add a CLI argument to binman through which
we would pass the state of OPTEE_LIB and error out the build in that
case, but that feels like opening the door to other various dirty hacks.
Another option is to propagate the TEE environment variable to the
preprocessor of the FDT (via dtc_cpp_flags) and then we can do
#if defined(TEE) && !IS_ENABLED(CONFIG_OPTEE_LIB)
#error "CONFIG_OPTEE_LIB must be enabled!"
#endif
but we have the same issue as above, it is then Rockchip-specific and
doesn't feel right to me.
Yet another option is to remove the @tee-SEQ node from the binman FIT
description when OPTEE_LIB isn't set but then we would lose the
following nice message when no TEE is provided:
Image 'simple-bin' is missing optional external blobs but is still functional: tee-os
and even worse, build without any TEE OS even though we could provide
one via the TEE environment variable.
Finally, another option could be to move this hack under
arch/arm/mach-rockchip/Kconfig to make it Rockchip-specific or add a
depends on ARCH_ROCKCHIP. However OP-TEE OS on Aarch32 Rockchip boards
doesn't actually need any of that if SPL_OPTEE_IMAGE is set because
arch/arm/mach-rockchip/sdram.c then marks some hardcoded memory regions
in RAM as holes in DRAM, which has the same effect as reserved memory
regions I guess. I assume other platforms may use something different,
so it may be casting too wide of a net.
This commit is what I could come up with as a stopgap measure to avoid
building images that simply cannot reliably work and fail randomly.
Tom Rini [Thu, 6 Nov 2025 23:28:38 +0000 (17:28 -0600)]
smbios: Fix warning when building with clang
When building with clang, we see warnings such as:
error: field max_size within 'struct smbios_type7' is less aligned than
'union cache_size_word' and is usually due to 'struct smbios_type7'
being packed, which can lead to unaligned accesses
[-Werror,-Wunaligned-access]
when building drivers/sysinfo/smbios.c. Resolve this error by packing
the unions as well after verifying they are complete (16 or 32 bits).
Reviewed-by: Raymond Mao <raymondmaoca@gmail.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by: Tom Rini <trini@konsulko.com>
Tom Rini [Tue, 18 Nov 2025 21:53:18 +0000 (15:53 -0600)]
Merge patch series "Fixes for Clang builds for AArch64, improve CROSS_COMPILE handling"
Dmitrii Sharshakov <d3dx12.xx@gmail.com> says:
Initially fix the inconsistency reported in reply to the previous
series and also make sure AArch64 images can be built with latest
Clang versions by guarding AArch32-specific options behind extra
config checks.
Tested qemu_arm_defconfig and qemu_arm64_defconfig with Clang 21,
mainline (to be 22) ce7f9f9c and also Clang 18 (for AArch64 only, as I
have not managed to build an AArch32 image with clang-18).
build: fix prefix for Clang when CROSS_COMPILE is an absolute path
Clang cross-compilation worked when cross binutils were available
in PATH. However, when binutils are not in the PATH clang failed to
discover the assembler, falling back to host one.
Make --prefix always absolute, Clang supports this and will search for
e.g. $(prefix)-as for assembler. This makes sure user does not have to
add cross binutils to PATH for Clang build.
Fixes build for these examples (with qemu_arm(64)_defconfig):
make CC=clang-21 CROSS_COMPILE=/.../bin/arm-none-eabi-
make CC=clang-20 CROSS_COMPILE=/.../bin/aarch64-linux-gnu-
Also validated for the case when provided with cross toolchain on PATH:
PATH=/.../bin:$PATH make CC=clang-21 CROSS_COMPILE=arm-none-eabi- -j20
This patch does not affect GCC builds, and they have _not_ been
validated against regressions.
Reported-by: Tom Rini <trini@konsulko.com> Closes: https://lore.kernel.org/u-boot/20251106221355.GZ6688@bill-the-cat/ Signed-off-by: Dmitrii Sharshakov <d3dx12.xx@gmail.com>
spi: airoha: en7523: workaround flash damaging if UART_TXD was short to GND
We found that some serial console may pull TX line to GROUND during board
boot time. Airoha uses TX line as one of it's BOOT pins. This will lead
to booting in RESERVED boot mode.
It was found that some flashes operates incorrectly in RESERVED mode.
Micron and Skyhigh flashes are definitely affected by the issue,
Winbond flashes are NOT affected.
Details:
--------
DMA reading of odd pages on affected flashes operates incorrectly. Page
reading offset (start of the page) on hardware level is replaced by 0x10.
Thus results in incorrect data reading. Usage of UBI make things even
worse. Any attempt to access UBI leads to ubi damaging. As result OS loading
becomes impossible.
Non-DMA reading is OK.
This patch detects booting in reserved mode, turn off DMA and print big
fat warning.
spi: airoha: avoid usage of flash specific parameters
The spinand driver do 3 type of dirmap requests:
* read/write whole flash page without oob
(offs = 0, len = page_size)
* read/write whole flash page including oob
(offs = 0, len = page_size + oob_size)
* read/write oob area only
(offs = page_size, len = oob_size)
The trick is:
* read/write a single "sector"
* set a custom sector size equal to offs + len. It's a bit safer to
round up "sector size" value 64.
* set the transfer length equal to custom sector size
And it works!
Thus we can find all data directly from dirmap request, so flash specific
parameters is not needed anymore. Also
* airoha_snand_nfi_config(),
* airoha_snand_nfi_setup()
functions becomes unnecessary.
spi: airoha: set custom sector size equal to flash page size
Set custom sector size equal to flash page size including oob. Thus we
will always read a single sector. The maximum custom sector size is
8187, so all possible flash sector sizes are supported.
This patch is a necessary step to avoid usage of flash specific
parameters.
spi: airoha: buffer must be 0xff-ed before writing
During writing, the entire flash page (including OOB) will be updated
with the values from the temporary buffer, so we need to fill the
untouched areas of the buffer with 0xff value to prevent accidental
data overwriting.
spi: airoha: support of dualio/quadio flash reading commands
Airoha snfi spi controller supports acceleration of DUAL/QUAD
operations, but does not supports DUAL_IO/QUAD_IO operations.
Luckily DUAL/QUAD operations do the same as DUAL_IO/QUAD_IO ones,
so we can issue corresponding DUAL/QUAD operation instead of
DUAL_IO/QUAD_IO one.
spi: airoha: return an error for continuous mode dirmap creation cases
This driver can accelerate single page operations only, thus
continuous reading mode should not be used.
Continuous reading will use sizes up to the size of one erase block.
This size is much larger than the size of single flash page. Use this
difference to identify continuous reading and return an error.
spi: airoha: add support of dual/quad wires spi modes to exec_op() handler
Booting without this patch and disabled dirmap support results in
[ 2.980719] spi-nand spi0.0: Micron SPI NAND was found.
[ 2.986040] spi-nand spi0.0: 256 MiB, block size: 128 KiB, page size: 2048, OOB size: 128
[ 2.994709] 2 fixed-partitions partitions found on MTD device spi0.0
[ 3.001075] Creating 2 MTD partitions on "spi0.0":
[ 3.005862] 0x000000000000-0x000000020000 : "bl2"
[ 3.011272] 0x000000020000-0x000010000000 : "ubi"
...
[ 6.195594] ubi0: attaching mtd1
[ 13.338398] ubi0: scanning is finished
[ 13.342188] ubi0 error: ubi_read_volume_table: the layout volume was not found
[ 13.349784] ubi0 error: ubi_attach_mtd_dev: failed to attach mtd1, error -22
[ 13.356897] UBI error: cannot attach mtd1
If dirmap is disabled or not supported in the spi driver, the dirmap requests
will be executed via exec_op() handler. Thus, if the hardware supports
dual/quad spi modes, then corresponding requests will be sent to exec_op()
handler. Current driver does not support such requests, so error is arrised.
As result the flash can't be read/write.
This patch adds support of dual and quad wires spi modes to exec_op() handler.
This operation is not needed because airoha_snand_write_data() and
airoha_snand_read_data() will properly handle data transfers above
SPI_MAX_TRANSFER_SIZE.
A quick analysis shows that the only caller of the suspicious code is the
spinand_select_op_variant() function from the drivers/mtd/nand/spi/core.c
file.
According to the code the value of op->data.nbytes is equal to
Therefore it's maximum value a bit larger than 4Kb (I never seen flashes
with page size large than 4Kb). So op->data.nbytes always fits within
13 bits. As result an overflow will never happen.
Anyway it's better fix an issue to eliminate the error message.
Tom Rini [Tue, 18 Nov 2025 15:36:53 +0000 (16:36 +0100)]
nand: raw: Kconfig: Correct some dependency issues
The hidden symbol SPL_SYS_NAND_SELF_INIT was not being used correctly
leading to Kconfig dependency issues seen with "make allyesconfig". As
it's a select'd symbol we don't need to have a depends line on it, and
then in turn we need to also update the logic on SYS_NAND_PAGE_SIZE and
SYS_NAND_OOBSIZE.
Miquel Raynal [Tue, 18 Nov 2025 15:32:24 +0000 (16:32 +0100)]
mtd: spinor: winbond: Describe several chips
All these chips are dual and quad capable. They are also DTR capable,
but the core is not yet ready for that.
Performances of all chips are comparable at 30MHz and are as follow:
Eraseblock single read speed: 938kiB/s
Eraseblock dual read speed: 1068kiB/s
Eraseblock quad read speed: 3751kiB/s
dhelectronics:
- Move dh_add_item_number_and_serial_to_env() to common code
- Read values from M24256 write-lockable page on STM32MP13xx DHCOR
- Add MAC address readout from fuses on DH STM32MP1 DHSOM
- Keep the reg11 and reg18 regulators always enabled on STM32MP13xx DHCOR.
- Fix boot for stm32mp15xx-dhsom.
- Fix build of ST DFU virt code on DH STM32MP1 DHSOM
- Introduce DH STM32MP13x target.
STM32MP2:
- Add support for stm32mp257-dk board.
- Fix arm, smc-id value for stm32mp23/25.
- Fix stm32mp235f-dk boot (add syscon compatible, add txbyteclk).
- Add display support:
- Introduce LVDS driver.
- Add LTDC support.
- Add Ethernet support for stm32mp255.
STM32MP13:
- Add ADC support.
- Add power check for stm32mp135f-dk board.
Marek Vasut [Thu, 23 Oct 2025 21:48:26 +0000 (23:48 +0200)]
ARM: stm32: Add MAC address readout from fuses on DH STM32MP1 DHSOM
Add support for reading out the MAC address from SoC fuses on DH STM32MP1 DHSOM.
The DH STM32MP1 DHSOM may contain external ethernet MACs, which benefit from the
MAC address stored in SoC fuses as well, handle those consistently. This however
means the architecture setup_mac_address() cannot be used and instead a simpler
local fuse read out is implemented in the board file.
Signed-off-by: Marek Vasut <marek.vasut@mailbox.org> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Marek Vasut [Thu, 23 Oct 2025 21:48:25 +0000 (23:48 +0200)]
ARM: stm32: Read values from M24256 write-lockable page on STM32MP13xx DHCOR
The STM32MP13xx DHCOR SoM is populated with M24256 EEPROM that contains
an additional write-lockable page called ID page, which is populated with
a structure containing ethernet MAC addresses, DH item number and DH serial
number.
Read out the MAC address from the WL page between higher priority SoC fuses
and lower priority plain EEPROM storage area. Read out the DH item and serial
numbers and set environment variables accordingly.
Signed-off-by: Marek Vasut <marek.vasut@mailbox.org> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Marek Vasut [Fri, 31 Oct 2025 04:16:09 +0000 (05:16 +0100)]
ARM: stm32: Add missing build of ST DFU virt code on DH STM32MP1 DHSOM
Commit 6d91f0a3a14d ("board: st: common: cleanup dfu support") split
the vendor-specific DFU implementation into two files, but failed to
update other non-ST boards. This did not lead to noticeable breakage
with plain simple dfu-util, but it makes the ST proprietary programmer
CLI tool end in an infinite loop. Update the Makefile accordingly to
allow even that kind of tooling to work.
Marek Vasut [Thu, 23 Oct 2025 21:46:05 +0000 (23:46 +0200)]
ARM: dts: stm32: Fix STM32MP15xx DHSOM boot breakage due to ETZPC
Switch etzpc bus to simple-bus to prevent breakage on non-TFA systems.
This fixes boot of every STM32MP15xx DHSOM device.
Fixes: ad3cdc677dda ("ARM: stm32mp: add ETZPC system bus driver for STM32MP1") Signed-off-by: Marek Vasut <marek.vasut@mailbox.org> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Asadeds [Tue, 28 Oct 2025 05:39:26 +0000 (11:09 +0530)]
arm: stm32mp25: add ethernet support for stm32mp255 series
Add missing CPU_STM32MP255* cases in get_eth_nb() so that U-Boot
correctly reports 2 Ethernet interfaces on stm32mp255 devices.
This fixes the "ethernet not found" error during boot.
video: stm32: ltdc: properly search the first available panel
Initially there was only one DSI bridge with one panel attached to this
device. This explained the call to uclass_first_device_err(UCLASS_PANEL,
...) which worked fine at the time.
Now that multiple bridges and panels, with different technologies, can
be plugged onto the board this way to get the panel device is outdated.
The lookup is done is two steps. First we circle through the
UCLASS_VIDEO_BRIDGE, and once we get one, we search through its
endpoints until we get a UCLASS_PANEL device available.
video: stm32: ltdc: support new hardware version for STM32MP25 SoC
STM32MP2 SoCs feature a new version of the LTDC IP. This new version
features a bus clock, as well as a 150MHz pad frequency. Add its
compatible to the list of device to probe and handle quirks. The new
hardware version features a bus clock.
The LVDS Display Interface Transmitter handles the LVDS protocol:
it maps the pixels received from the upstream Pixel-DMA (LTDC)
onto the LVDS PHY.
The LVDS controller driver supports the following high-level features:
• FDP-Link-I and OpenLDI (v0.95) protocols
• Single-Link or Dual-Link operation
• Single-Display or Double-Display (with the same content
duplicated on both)
• Flexible Bit-Mapping, including JEIDA and VESA
• RGB888 or RGB666 output
• Synchronous design, with one input pixel per clock cycle
• No resolution limitation.
video: simple_panel: add support for "panel-lvds" display
Add the compatible "panel-lvds" for simple-panel driver in U-Boot. In
Linux this compatible is managed by the driver
drivers/gpu/drm/panel/panel-lvds.c but in U-Boot the specific LVDS
features (bus_format/bus_flags) are not supported.
ofnode: support panel-timings in ofnode_decode_display_timing
The "Display Timings" in panel-common.yaml can be provided by 2 properties
- panel-timing: when display panels are restricted to a single resolution
the "panel-timing" node expresses the required timings.
- display-timings: several resolutions with different timings are supported
with several timing subnode of "display-timings" node
This patch update the parsing function to handle this 2 possibility
when index = 0.
Olivier Moysan [Fri, 14 Nov 2025 16:08:52 +0000 (17:08 +0100)]
adc: stm32mp13: add support of adc to stm32mp13
Add support of STM32 ADCs to STM32MP13x. This patch introduces
stm32_adc_regspec structure, as this is already done in kernel
driver, to manage smartly the differences in register set
between STMP32MP15 and STM32MP13 ADCs.
Tom Rini [Wed, 12 Nov 2025 21:18:41 +0000 (15:18 -0600)]
ufs: rcar-gen5: Use a unique U_BOOT_DRIVER name
All instances of U_BOOT_DRIVER must be unique or we will have link time
failures. It is possible to enable both ufs-renesas-rcar.c and
ufs-renesas-rcar-gen5.c at the same time, so give
ufs-renesas-rcar-gen5.c a new unique U_BOOT_DRIVER name.
Fixes: 3351fe7ecc1a ("ufs: Add UFS driver for Renesas R-Car X5H") Signed-off-by: Tom Rini <trini@konsulko.com> Acked-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Link: https://patch.msgid.link/20251112211841.1428696-1-trini@konsulko.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
* Correct the linux/arm64 platform string for Docker builds
* Complete pytest dependencies list with missing packages
UEFI:
* Use Sphinx style comments in efi_selftest_console.c
* Don't include asm/global_data.h in lib/efi_client/efi_app.c twice
* efi_client: correct memset() return value
* Assure fitImage from capsule is used from 8-byte aligned address
* Fix warning when building efi_selftest_snp with clang
Marek Vasut [Thu, 13 Nov 2025 11:55:49 +0000 (12:55 +0100)]
efi_loader: Assure fitImage from capsule is used from 8-byte aligned address
The fitImage may be stored in EFI update capsule at address that
is not aligned to 8 bytes. Since fitImage is a DT, new version of
libfdt 1.7.2 rejects such an unaligned DT. Patch the code and copy
the fitImage into aligned buffer in case it is not aligned. This
does increase overhead for unaligned fitImages in EFI capsules, but
tries to keep the overhead low for aligned ones.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Tom Rini [Thu, 6 Nov 2025 23:28:39 +0000 (17:28 -0600)]
efi_selftest: efi_selftest_snp: Fix warning when building with clang
When building with clang, we see a warning:
lib/efi_selftest/efi_selftest_snp.c:63:18: error: field dhcp_hdr within
'struct dhcp' is less aligned than 'struct dhcp_hdr' and is usually due
to 'struct dhcp' being packed, which can lead to unaligned accesses
[-Werror,-Wunaligned-access]
when building lib/efi_selftest/efi_selftest_snp.c. Resolve this error by
packing struct dhcp_hdr as well, as the only place it is used also is
packed.
Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Rev.0.81 of the R-Car V4M Series Hardware User’s Manual removed the
"STPWT_EXTFXR" signal from the pin control register tables. As this is
further unused in the pin control driver, it can be removed safely.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Huy Bui [Fri, 7 Nov 2025 16:16:56 +0000 (17:16 +0100)]
pinctrl: renesas: r8a779h0: Remove CC5_OSCOUT
Rev.0.71 of the R-Car V4M Series Hardware User’s Manual removed the
"CC5_OSCOUT" signal from the pin control register tables. As this is
further unused in the pin control driver, it can be removed safely.
Huy Bui [Fri, 7 Nov 2025 16:16:55 +0000 (17:16 +0100)]
pinctrl: renesas: r8a779g0: Remove STPWT_EXTFXR
Rev.1.30 of the R-Car V4H Series Hardware User’s Manual removed the
"STPWT_EXTFXR" signal from the pin control register tables. As this is
further unused in the pin control driver, it can be removed safely.
Huy Bui [Fri, 7 Nov 2025 16:16:54 +0000 (17:16 +0100)]
pinctrl: renesas: r8a779g0: Remove CC5_OSCOUT
Rev.1.30 of the R-Car V4H Series Hardware User’s Manual removed the
"CC5_OSCOUT" signal from the pin control register tables. As this is
further unused in the pin control driver, it can be removed safely.
Thanh Quan [Fri, 7 Nov 2025 16:16:53 +0000 (17:16 +0100)]
pinctrl: renesas: r8a779g0: Remove AVB[01]_MII
Rev.1.30 of the R-Car V4H Series Hardware User’s Manual removed the
"AVB[01]_MII_*" signals from the pin control register tables. As these
are further unused in the pin control driver, they can be removed
safely.
Signed-off-by: Thanh Quan <thanh.quan.xn@renesas.com> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
projects / thirdparty / u-boot.git / log
