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.
* 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>
Tom Rini [Fri, 26 Sep 2025 15:30:34 +0000 (09:30 -0600)]
usb: gadget: Tighten CI_UDC dependencies
This driver cannot build when DM_USB_GADGET is enabled as both options
control building of files that use the same global namespace and
functionality. In this case make CI_UDC depend on DM_USB_GADGET being
disabled as non-DM support is the legacy choice.
Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Tom Rini [Fri, 26 Sep 2025 15:30:33 +0000 (09:30 -0600)]
usb: host: xhci: Make U_BOOT_DRIVER entries unique
All instances of the U_BOOT_DRIVER must use a unique name or they will
lead to link time failures due to name space conflicts when both are
present. Most of the XHCI drivers follow pattern of xhci_xxx in their
name, but a few used "usb_xhci". Change these to follow the pattern of
the rest of the XHCI glue drivers.
Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
Peter Robinson [Fri, 26 Sep 2025 15:30:31 +0000 (09:30 -0600)]
usb: musb: drop musb legacy drivers
The last of the users of the legacy musb drivers have been
migrated so now remove the old musb stack, all users should
now be using the new musb stack if they need this functionality.
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
[trini: Remove a Makefile reference that was missed in v1] Signed-off-by: Tom Rini <trini@konsulko.com>
Peter Robinson [Fri, 26 Sep 2025 15:30:30 +0000 (09:30 -0600)]
omap3: evm: Drop old musb omap3 driver
The USB_OMAP3 driver was (re)added in commit e74e9f620a6 as part
of migrating to DM_USB but the config already had MUSB_OMAP2PLUS
which is the newer musb driver and what other omap3 devices use.
So drop it so we can drop the old driver.
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
Tom Rini [Fri, 3 Oct 2025 20:39:22 +0000 (14:39 -0600)]
usb: gadget: spl: Add missing dependency for SPL_USB_GADGET
It makes no sense to ask about nor enable SPL_USB_GADGET without
SPL_FRAMEWORK being enabled. Attempting to do so leads to Kconfig noting
dependency issues. Add the missing dependency.
Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Tom Rini [Thu, 6 Nov 2025 23:28:35 +0000 (17:28 -0600)]
Gitlab: Optimize the job dependency list more
In general, we want to fail the whole pipeline as soon as we can if we
spot an error while also letting bigger jobs get started as soon as
possible. Currently we use the "Run binman, buildman, dtoc, Kconfig and
patman testsuites" job from the testsuite stage to unblock the next
stage as this test is complex enough that if it passes, likely the whole
stager will pass. Using this same logic, unblock the world build (and
sjg-lab) stages if "sandbox test.py" has completed as if there's no
failures here, there's likely not failures in the rest of the test.py
stages.
Bin Meng [Wed, 5 Nov 2025 11:07:24 +0000 (19:07 +0800)]
scsi: Fix the name string memory leak during scsi scan
There is a memory leak during the scsi scan process due to the
strdup'ed name string is never freed. Actually it is unnecessary
to pass a strdup'ed name string to blk_create_devicef() as we can
use the name string on the stack directly.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
qfw: Fix segfault from uninitialized variables in sandbox
There are cases where qfw_read_entry() does not set the output parameter
passed by address. This occurs with qfw_sandbox_read_entry_dma, which
leaves the size variables uninitialized and causes a segfault when running
bootflow scan in U-Boot sandbox.
$ ./u-boot
...
U-Boot 2026.01-rc1-00199-gc2637036b8f0 (Nov 04 2025 - 10:32:21 +0100)
...
Hit any key to stop autoboot: 0
=> bootflow scan
efi_var_to_file() Cannot persist EFI variables without system partition
efi_tcg2_register() Missing TPMv2 device for EFI_TCG_PROTOCOL
efi_rng_register() Missing RNG device for EFI_RNG_PROTOCOL
scanning bus for devices...
[3] 1015761 segmentation fault (core dumped) ./u-boot
Initalize all these variables to 0 to fix this issue.
- Support scmi v3.2 CONFIG_SET for clock protocol
- A patchset from Marek to optimize the scmi clk booting time
- Fix scmi clk set_parent in non-CCF case
- Drop mmu_set_region_dcache_behaviour in firmware scmi
Tom Rini [Sun, 2 Nov 2025 20:08:12 +0000 (14:08 -0600)]
dm: Remove pre-schema tag support
Support for using "u-boot,dm-..." rather than "bootph-..." has been
deprecated since February 2023. Any platforms using this have had a
console message saying to migrate by 2023.07. Go and remove all support
here now, for the v2026.01 release.
The results of this change that aren't clear from the above are that we
still have a checkpatch.pl error message, and document in
doc/develop/spl.rst that they have been migrated since 2023. We also
change the key2dtsi.py tool to use the correct bootph phase rather than
the legacy phase.
Marek Vasut [Sun, 9 Nov 2025 01:35:09 +0000 (02:35 +0100)]
clk: scmi: Defer issue of SCMI_CLOCK_ATTRIBUTES
Instead of resolving clock control flags using SCMI_CLOCK_ATTRIBUTES
during probe for each and every clock, resolve the clock control
flags using SCMI_CLOCK_ATTRIBUTES when the clock control flags are
first used. Because most clock are never used by U-Boot, this allows
reducing the amount of SCMI_CLOCK_ATTRIBUTES considerably, and this
improve probe time of the scmi clock driver and U-Boot start up time.
On Renesas X5H, with 1700+ SCMI clock, the boot time improved by 1.7s .
Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Marek Vasut [Sun, 9 Nov 2025 01:35:08 +0000 (02:35 +0100)]
clk: scmi: Postpone clock name resolution
The clock names are retrived via SCMI_CLOCK_ATTRIBUTES, called for each
clock ID. This may take a lot of time to complete and is not strictly
necessary. Register each clock as "scmi-%zu" instead, and let the first
call of SCMI_CLOCK_ATTRIBUTES fill in the actual clock name.
This has a side effect, which can be considered both an upside and also
a downside. Unused clock are never renamed and retain their placeholder
"scmi-%zu" name, which avoids empty clock names for nameless SCMI clock,
and avoids the name resolution and improves boot time. But for those
SCMI clock which do have name, that name is not listed until the clock
are used.
This is a preparatory patch for deferred issue of SCMI_CLOCK_ATTRIBUTES.
Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Marek Vasut [Sun, 9 Nov 2025 01:35:06 +0000 (02:35 +0100)]
clk: scmi: Bulk allocate all sub-driver instance data
Allocate all sub-driver instance data at once. The amount of data that
have to be allocated is known up front, so is the size of the data, so
there is no need to call malloc() in a loop, mallocate all data at once.
The upside is, less heap fragmentation and fewer malloc() calls overall,
and a faster boot time.
The downside is, if some of the clock fail to register, then the clock
driver cannot free parts of the bulk allocated sub-driver instance data.
Such a failure can only occur if clk_register() were to fail, and if that
happens, the system has more significant problems. Worse, if a core clock
driver fails to probe, the system has even bigger problem.
Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Vinh Nguyen [Wed, 5 Nov 2025 03:42:26 +0000 (04:42 +0100)]
firmware: scmi: Add clock v3.2 CONFIG_SET support
SCMI v3.2 introduces a new clock CONFIG_SET message format that can
optionally carry also OEM specific configuration values beside the usual
clock enable/disable requests. Add support to use such new format when
talking to a v3.2 compliant SCMI platform.
Support existing enable/disable operations across different clock protocol
versions: this patch still does not add protocol operations to support the
new OEM specific optional configuration capabilities.
No functional change for the SCMI drivers users of the related enable and
disable clock operations.
[Marek: Remodel after Linux e49e314a2cf7 ("firmware: arm_scmi: Add clock v3.2 CONFIG_SET support")
Support both old < 2.1 and new >= 2.1 protocol versions.
Update commit message based on Linux one]
Signed-off-by: Vinh Nguyen <vinh.nguyen.xz@renesas.com> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Alice Guo <alice.guo@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Marek Vasut [Sat, 25 Oct 2025 21:35:09 +0000 (23:35 +0200)]
firmware: scmi: Drop mmu_set_region_dcache_behaviour() misuse
MMU region cache behavior configuration for SCMI/SMT mailboxes is
platform specific. Even on ARM systems, the mailbox memory may not
even be located in any cacheable MMU region and may instead reside
in some SRAM. Remove this non-generic cache behavior configuration
code from generic code path.
It is unlikely that any platform is affected by this change if it
did configure its MMU regions correctly on start up. Platforms
which might be affected are i.MX94/95 and STM32MP.
Fixes: 240720e9052f ("firmware: scmi: mailbox/smt agent device") Fixes: 2a3f161c8b16 ("scmi: correctly configure MMU for SCMI buffer") Fixes: b2ae10970d40 ("firmware: scmi: use PAGE_SIZE alignment for ARM64") Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Tested-by: Alice Guo <alice.guo@nxp.com> Tested-by: Patrice Chotard <patrice.chotard@foss.st.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Tom Rini [Fri, 7 Nov 2025 22:10:49 +0000 (16:10 -0600)]
Merge patch series "Add support for TI AM6254atl SiP"
Anshul Dalal <anshuld@ti.com> says:
This patch series adds support for AM6254atl SiP (or AM62x SiP for
short) to U-Boot.
The OPN (Orderable Part Number) 'AM6254atl' expands as follows[1]:
AM6254atl
||||
|||+-- Feature Lookup (L indicates 512MiB of integrated LPDDR4)
||+--- Device Speed Grade (T indicates 1.25GHz on A53 cores)
|+---- Silicon PG Revision (A indicates SR 1.0)
+----- Core configuration (4 indicates A53's in Quad core config)
AM62x SiP provides the existing AM62x SoC with 512MiB of DDR
integrated in a single packages. The first 4 patches in the series
are cherry-picked from the devicetree-rebasing repository at
'v6.18-rc2-dts'.
Tom Rini [Fri, 7 Nov 2025 22:09:39 +0000 (16:09 -0600)]
Merge patch series "Add PCIe Endpoint controller support for TI J784S4 SoC"
Hrushikesh Salunke <h-salunke@ti.com> says:
This series enables PCIe Endpoint mode on TI's J784S4 SoC. The J784S4
SoC features two Cadence PCIe controller instances (PCIe0 and PCIe1)
that can operate in endpoint mode. This series adds support for
configuring these controllers with up to 4 lanes.
Key changes include:
- Adding a stabilization delay after power domain reset to prevent
timing-related initialization issues
- SERDES mux configuration support for proper lane routing, which is
essential for SoCs where SERDES lanes are shared between multiple
controllers (PCIe, USB, etc.) with different configurations across
boot phases
- J784S4 SoC endpoint configuration with 4-lane support
- Disabling unconfigured endpoint functions to prevent enumeration
issues on the Root Complex side
This series has been tested on J784S4 EVM with PCIe endpoint boot
configuration. Following are the corresponding test logs.
Tom Rini [Fri, 7 Nov 2025 22:08:37 +0000 (16:08 -0600)]
Merge patch series "board: ti: am62x: Add EEPROM support and refactor board detection"
Guillaume La Roque (TI.com) <glaroque@baylibre.com> says:
This series adds EEPROM board detection support for AM62x and refactors
the board detection code across AM6x family boards to eliminate code
duplication.
The series introduces two new generic functions for AM6x boards:
- do_board_detect_am6(): Reads the on-board EEPROM with fallback logic
to alternate I2C addresses
- setup_serial_am6(): Sets up the serial number environment variable
from EEPROM data
This patch series adds basic support for the boards based on Airoha
EN7523/EN7529/EN7562 SoCs. Due to ATF restrictions these boards are
able to run 32-bit OS only.
This patch series adds support for the following hardware:
* console UART
* ethernet controller/switch
* spinand flash (in non-dma mode)
The following issues may be expected:
* Extra slow UBI attaching in U-Boot (up to 20 sec with fastmap enabled).
This is caused by the lack of DMA support in the U-Boot airoha-snfi driver.
* Linux airoha-snfi driver in some cases might damage you flash data
(see: https://lore.kernel.org/lkml/20251012121707.2296160-15-mikhail.kshevetskiy@iopsys.eu/)
* Latest linux kernel is recommended to properly support flashes
with more than one plane per lun
(see: https://lore.kernel.org/lkml/20251012121707.2296160-7-mikhail.kshevetskiy@iopsys.eu/)
* It's NOT recommended to use flashes working in continuous mode because
U-Boot airoha-snfi driver does not support such flashes properly.
The patches was tested on the board:
- SoC: Airoha EN7562
- RAM: 512 MB
- SPI NAND: 4 Gbit, made by Toshiba
- Linux boot: was NOT tested
The U-Boot was chain-loaded from the running U-Boot. Airoha ATF-2.3 does
not allow easily chain-loading of U-Boot from U-Boot, so a special FIT
image (mimic linux kernel) was created
1) Create u-boot.its file with the following contents:
Anshul Dalal [Sat, 25 Oct 2025 02:48:11 +0000 (08:18 +0530)]
ti: add support for AM6254atl SiP
TI's AM6254atl (or AM62x SiP for short) provides the existing AM62x SoC
with 512MiB of DDR integrated in a single package.
This patch adds the necessary U-Boot devie tree files, the required
defconfigs along with the documentation for the AM62x SiP EVM.
AM62x SiP differs from the already supported AM62x in following ways:
- OP-TEE for the AM62x resides from 0x9e800000 to 0xa0000000 which needs
to be moved to 0x80080000 to free up space at end of DDR in AM62x SiP
with 512MiB of memory. This is required to allow U-Boot to relocate to
end of DDR before booting to the kernel.
- Changes to the env:
1. splashimage address updated from 0x80200000 to 0x81a00000
2. DFU addresses updated to match updated TEXT_BASE for SPL and U-Boot
Anshul Dalal [Sat, 25 Oct 2025 02:48:10 +0000 (08:18 +0530)]
arm64: dts: ti: Add support for AM6254atl SiP SK
This patch adds the dt for SK-AM62-SIP, which uses the existing
SK-AM62 board design with the new AM6254atl SiP. This changes the
location of memory node from the board dts to SoC level dtsi
(k3-am6254atl in our case).
Therefore this patch introduces the new 'k3-am625-sk-common.dtsi'
which represents the common hardware used for both 'am625-sk' and
'am6254atl-sk' boards with the inheritance hierarchy modified to:
Anshul Dalal [Sat, 25 Oct 2025 02:48:08 +0000 (08:18 +0530)]
arm64: dts: ti: k3-am62*: remove SoC dtsi from common dtsi
The k3-am62x-sk-common dtsi represents the common hardware used across
am62x EVMs which can be configured with various DDR sizes or none (with
DDR integrated in the package) based on the specific am62x SoC used.
Therefore this patch moves the memory node and the SoC specific k3-am625
dtsi out of sk-common and into the board dts files. No functional change
is intended from this patch. The device-tree inheritance is changed as
follows:
Beleswar Padhi [Sat, 25 Oct 2025 02:48:07 +0000 (08:18 +0530)]
arm64: dts: ti: k3-am6*-boards: Add label to reserved-memory node
Add the label name 'reserved_memory' to the reserved-memory node in all
K3 AM6* board level dts files. This is done so that the node can be
referenced and extended to add more carveout entries as needed in future
refactoring patches.
configs: j784s4_evm_a72_defconfig: Enable configs for PCI Endpoint mode
TI's J784S4 SoC has two instances of PCIe Controller namely PCIe0 and
PCIe1 which are Cadence PCIe Controllers. Enable corresponding configs
to support PCIe Endpoint mode of operation on these instances.
pci_endpoint: pci_cdns_ti_ep: Enable PCIe Endpoint mode in J784S4 SoC
TI's J784S4 SoC has two instances of PCIe Controller namely PCIe0 and
PCIe1 which are Cadence PCIe Controllers. Add support to configure PCIe
instances in Endpoint mode of operation.
While at it disable all endpoint functions except function 0 during
probe to prevent the Root Complex from enumerating unconfigured
functions. This ensures only properly configured endpoint functions
are visible to the host and avoids enumeration issues with
multi-function devices.
pci_endpoint: pci_cdns_ti_ep: Add SERDES mux configuration support
Probe the mux device early in the SERDES configuration flow to ensure
proper lane routing before PHY initialization. This is required for SoCs
where SERDES lanes can be muxed between different controllers
(PCIe, USB, etc), and different mux configurations are required between
different boot phases.
pci_endpoint: pci_cdns_ti_ep: Add delay after power domain reset
Add a 1ms delay after powering on the PCIe power domain to ensure
the controller stabilizes before subsequent operations. This prevents
potential timing issues during PCIe endpoint initialization.
The delay allows sufficient time for the power domain to fully come
up and the hardware to be in a stable state before configuration
begins.
board: am65x: Use generic AM6x board detection function
Replace the board-specific implementation of do_board_detect()
with a call to the generic do_board_detect_am6() function to
avoid code duplication across AM6x family boards.
The generic function provides the same functionality with
additional fallback logic to try alternate EEPROM addresses.
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org> Signed-off-by: Guillaume La Roque (TI.com) <glaroque@baylibre.com>
board: am64x: Use generic AM6x board detection functions
Replace the board-specific implementation of do_board_detect() and
setup_serial() with calls to the generic do_board_detect_am6() and
setup_serial_am6() functions.
The generic function provides the same functionality with
additional fallback logic to try alternate EEPROM addresses.
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org> Signed-off-by: Guillaume La Roque (TI.com) <glaroque@baylibre.com>
I2C EEPROM data contains the board name and its revision.
Add support for:
- Reading EEPROM data and store a copy at end of SRAM
- Updating env variable with relevant board info
- Printing board info during boot
Use the generic do_board_detect_am6() and setup_serial_am6()
functions to avoid code duplication across AM6x family boards.
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org> Signed-off-by: Guillaume La Roque (TI.com) <glaroque@baylibre.com>
projects / thirdparty / u-boot.git / log
