The 9Tripod X3568 v4 is an RK3568-based SBC, just like the RK3568-EVB.
It always uses soldered connections between the X3568CV2/X3568CV3/X3568CV4 core board
and the X3568bv4 I/O board.
The differences between the core boards
- PCB size, layout
- CPU (RK3568B2/RK3568J)
- Memory type (DDR4/LPDDR4/LPDDR4X) and size
- eMMC size
- DSI/EDP resistor values
Although the components vary, they maintain full compatibility.
The X3568 board has multiple hardware revisions, and we currently support v4 (I/O board).
Specification:
- SoC: RockChip RK3568 ARM64 (4 cores)
- eMMC: 16-128 GB
- RAM: 2-16 GB
- Power: DC 12V 2A
- Ethernet: 2x YT8521SC RGMII (10/100/1000 Mbps)
- Wireless radio: 802.11b/g/n/ac/ax dual-band
- LED:
Power: AlwaysOn
User: GPIO
- Button:
VOL+: SARADC/0 <35k µV>
VOL-: SARADC/0 <450k µV>
Power/Reset: PMIC RK809
- CAN
CAN/1: 4-pin (PH 2.0)
- PWM
PWM/4: Backlight DSI/0 DSI/1
PWM/7: IR Receiver [may not install]
- UART:
UART/2: Debug TTL - 1500000 8N1 (1.25mm)
UART/3: TTL (PH 2.0)
UART/4: TTL (PH 2.0)
UART/8: AP6275S Bluetooth
UART/9: TTL (PH 2.0)
- I2C:
I2C/0: PMIC RK809
I2C/1: Touchscreen DSI/0 DSI/1
I2C/4: Camera
I2C/5: RTC@51 PCF8563
- I2S:
I2S/0: miniHDMI Sound
I2S/1: RK809 Audio Codec
I2S/3: AP6275S Bluetooth Sound
- SDMMC:
SDMMC/0: microSD (TF) slot
SDMMC/2: AP6275S SDIO WiFi card
- Camera: 1x CSI
- Video: miniHDMI / DSI0 (MIPI/LVDS) / DSI1 (MIPI/EDP)
- Audio: miniHDMI / MIC on-board / Speaker / SPDIF / 3.5mm Headphones / AP6275S Bluetooth
- USB:
USB 2.0 HOST x2
USB 2.0 HOST x3 (4-pin)
USB 2.0 OTG x1 (shared with USB 3.0 OTG/HOST) [slot may not install]
USB 3.0 HOST x1
USB 3.0 OTG/HOST x1
- SATA: 1x SATA 3.0 with Power/4-pin [slot may not install]
- PCIe: 1x PCIe 3.0 x2 (x4 connector) [power/clock/slot may not install]
board: rockchip: set M.2 NVMe PERSTN low in spl_board_init on Jaguar
As it is, an NVMe's built-in PERSTN pull-up fights against the
SoC's built-in pull-down which results in an undefined logic state
on the Samsung SSD 980 and likely others.
Fix that by forcing PERSTN low as early as possible, which is SPL.
Both Linux and U-Boot (via "pci enum") set the pin high later
as needed and the NVMe is detected fine.
Oscillocope shots ("x" means undefined logic state at around 1.5V):
Before:
3V3 ____|‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾
PERSTN ____xxxxxxxxxxxxxxx_|‾‾‾‾‾
PCICLK ____∿∿∿∿∿∿∿∿∿∿∿∿___∿∿∿∿∿∿∿
^U-Boot ^ Linux
After:
3V3 ____|‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾
PERSTN ____x_______________|‾‾‾‾‾
PCICLK ____∿∿∿∿∿∿∿∿∿∿∿∿___∿∿∿∿∿∿∿
^U-Boot ^ Linux
With this change, the power-up sequence conforms to PCIe specs,
except a remaining short PERSTN glitch. The glitch is about 400ms
long. It could be shortened by moving the logic to TPL, but
completely fixing it is only possible in hardware.
The oobfree[0].length calculation depends on the
rknand->metadata_size value, but this is calculated
after the function rk_nfc_ecc_init is called. Move this
calculation to a location before it's value is required.
Jonas Karlman [Tue, 7 Jul 2026 10:09:17 +0000 (10:09 +0000)]
arm: dts: rockchip: Align OTP nodes for RK3528/RK356x with Linux v7.1
The <soc>-u-boot.dtsi OTP nodes for RK3528/RK356x use different names
compared to the OTP nodes that was merged in Linux v7.1. This causes
build issues when dts/upstream pulls in updated DTs, i.e.:
ERROR (duplicate_label): /soc/nvmem@ffce0000: Duplicate label 'otp'
on /soc/nvmem@ffce0000 and /soc/efuse@ffce0000
ERROR (duplicate_label): /nvmem@fe38c000: Duplicate label 'otp'
on /nvmem@fe38c000 and /efuse@fe38c000
Align the OTP node names in <soc>-u-boot.dtsi with the node names used
in upstream Linux v7.1 to avoid build issues when latest DTs are synced.
Also drop the unused RK356x id@a subnode as it has moved under a
nvmem-layout node in the merged upstream DT.
MAINTAINERS: add myself as ARM ROCKCHIP maintainer
Kever has been pulled into different responsibilities at Rockchip and
this means he has less to no time for his maintainership in U-Boot as
has been seen for about a year now. Let's try to improve the situation
and have Rockchip-related things merged again by adding myself as
another maintainer.
MAINTAINERS: add more Rockchip drivers to ARM ROCKCHIP
A few drivers are not using "rockchip" in their path so they aren't
currently detected by get_maintainer.pl as belonging to the ARM ROCKCHIP
entry, so let's fix that oversight by adding them individually. We could
use N: rk_ but I feel this isn't distinctive enough to avoid too many
false positive and I don't want to be keeping a list of things to not
match against.
Rockchip has an RV11xx SoC series (RV1103, RV1106, RV1126) so let's
match *anything* in U-Boot which contains this string in the path and
not only the U-Boot Device Trees.
Rockchip also manufactures PMICs and regulators typically under the
RK8xx naming scheme (e.g. RK806, RK808, RK860, etc.) so let's match
files with rk8 in their path.
Most Rockchip SoCs have their name start with rk3xxx. Historically, the
second digit is for the generation of SoC, e.g. rk31xx was before
rk32xx, itself before rk33xx and now rk35xx (and the expected rk36xx end
of this year). We won't talk about the rk30xx timeline but it's also
prefixed the same way. So let's match *anything* in U-Boot which
contains rk3 in the path to simplify the MAINTAINERS entry and hopefully
catch as much as possible.
board/firefly/ and board/pine64/ only contain subdirectories and each of
them have rk3 in their name.
PX5 is a Rockchip SoC, so let's match *anything* in U-Boot which
contains this string in the path. However, this matches a bit too much,
specifically the PPC-based kmsupx5_defconfig so we need to exclude it
explicitly.
Michal Simek [Mon, 29 Jun 2026 09:46:36 +0000 (11:46 +0200)]
arm: dts: zynqmp: Fix space indentation to use tabs
Fix indentation issues where spaces were used instead of tabs in several
ZynqMP device tree overlay files. Device tree files should use tabs for
indentation to maintain consistency with the kernel coding style.
Harini T [Mon, 29 Jun 2026 09:46:33 +0000 (11:46 +0200)]
arch: arm: dts: Add RTC clock nodes for ZynqMP platform
Add fixed RTC clock nodes at 32.768 kHz for ZynqMP. The RTC driver uses
this clock to calculate the calibration value, replacing the deprecated
calibration device tree property.
Michal Simek [Tue, 23 Jun 2026 12:53:43 +0000 (14:53 +0200)]
arm64: versal-net: Add mmc_get_env_dev() and deduplicate MMC handling
The SD and eMMC cases in boot_targets_setup() duplicated the MMC device
lookup, and versal-net relied on the weak mmc_get_env_dev() default
instead of selecting the device matching the boot mode (unlike versal and
zynqmp).
Factor the lookup into mmc_get_bootseq(), mirroring spi_get_bootseq():
it maps the boot mode to the MMC node and returns the device sequence,
optionally handing back the mode banner so only boot_targets_setup()
prints it. mmc_get_env_dev() is now provided as a thin wrapper, and the
SD/eMMC cases call the helper instead of open-coding the lookups. The
local udevice pointer in boot_targets_setup() is no longer needed.
Michal Simek [Tue, 23 Jun 2026 12:53:42 +0000 (14:53 +0200)]
arm64: versal-net: Look up eMMC device in boot_targets_setup()
The EMMC_MODE case set bootseq from dev_seq(dev) without ever assigning
dev, so it used an uninitialized pointer and produced a bogus device
sequence in boot_targets.
eMMC is wired to the SD1 controller (mmc@f1050000, see
versal-net-mini-emmc.dts). Look that device up like the SD cases do
before using its sequence number.
Michal Simek [Tue, 23 Jun 2026 12:53:41 +0000 (14:53 +0200)]
arm64: versal-net: Do not print bootmode from spi_get_env_dev()
spi_get_bootseq() printed the QSPI/OSPI mode banner, which is noise when
called from spi_get_env_dev() during environment setup. The banner is
only meaningful for the "Bootmode:" announcement in boot_targets_setup().
Make spi_get_bootseq() a pure lookup that returns the banner string
through an optional output argument instead of printing it.
spi_get_env_dev() passes NULL and stays silent, while
boot_targets_setup() prints the returned mode name as before.
The QSPI and OSPI cases only differ in the SPI device name. Pick the name
in the switch and perform a single uclass_get_device_by_name() lookup
afterwards, instead of repeating the lookup and dev_seq() in every case.
spi_get_env_dev() and boot_targets_setup() both decoded the QSPI/OSPI
boot modes into a SPI device sequence number with identical
uclass_get_device_by_name() lookups.
Factor that logic into a single spi_get_bootseq() helper that takes the
bootmode and returns the device sequence. spi_get_env_dev() becomes a
thin wrapper around it, and boot_targets_setup() calls it for the
QSPI/OSPI cases instead of open-coding the lookups. Passing the bootmode
in avoids reading the bootmode register twice in boot_targets_setup().
Michal Simek [Tue, 23 Jun 2026 12:53:38 +0000 (14:53 +0200)]
arm64: zynqmp: Decouple MMIO accessors from firmware
zynqmp_mmio_read() and zynqmp_mmio_write() selected between direct MMIO
and the firmware (PM_MMIO_READ/WRITE) interface with an in-function
IS_ENABLED(CONFIG_ZYNQMP_FIRMWARE) / current_el() check. Generic arch
code should not carry firmware-specific ifdefs, and with SCMI the access
method changes again.
Split the accessors like the multiboot and bootmode hooks: the weak
default in arch/arm/mach-zynqmp does the direct MMIO access (used in SPL,
at EL3 and when no firmware is present), while firmware-zynqmp.c provides
a strong definition that issues the firmware call and falls back to the
direct access in SPL/EL3 where the SMC path is unavailable. The raw MMIO
primitives zynqmp_mmio_rawread() and zynqmp_mmio_rawwrite() are exported
for the shared fallback, and the read-modify-write helper now uses the
raw read instead of routing through the firmware-aware accessor.
The firmware-vs-MMIO decision is selected at link time, so adding SCMI
later only requires a third strong definition with no changes to generic
code.
Michal Simek [Tue, 23 Jun 2026 12:53:37 +0000 (14:53 +0200)]
arm64: versal-net: Move bootmode decoding out of board code
versal_net_get_bootmode() open-coded the
IS_ENABLED(CONFIG_ZYNQMP_FIRMWARE) selection between the firmware call
zynqmp_pm_get_bootmode_reg() and a direct readl() in board code. Like
the Versal change, move the whole function behind an overridable hook so
generic board code stays free of firmware specifics and is ready for
SCMI.
The weak versal_net_get_bootmode() in arch/arm/mach-versal-net does the
plain MMIO read via versal_net_bootmode_reg() and decodes it (used at EL3
and without firmware). When CONFIG_ZYNQMP_FIRMWARE is enabled,
firmware-zynqmp.c provides a strong definition that reads the register
through the firmware call, falling back to the direct read at EL3 where
the SMC path to firmware is unavailable. This preserves the existing
firmware-based bootmode behaviour while removing the firmware interface
from board code; the now unused zynqmp_firmware.h include is dropped.
Michal Simek [Tue, 23 Jun 2026 12:53:36 +0000 (14:53 +0200)]
arm64: versal-net: Move SoC detection out of board code
soc_detection() and soc_name_decode() read the PMC_TAP version/idcode
registers and decode the platform. This is SoC information rather than
board policy, and a firmware interface could provide it instead, so it
does not belong in board code.
Move both functions, together with the shared platform_id and
platform_version state, into arch/arm/mach-versal-net where they still
override the weak stubs in the Xilinx common board code. The board file
drops the now unused linux/bitfield.h include.
Michal Simek [Tue, 23 Jun 2026 12:53:35 +0000 (14:53 +0200)]
arm64: versal2: Move SoC detection out of board code
soc_detection() and soc_name_decode() read the PMC_TAP version/idcode
registers and decode the platform. This is SoC information rather than
board policy, and a firmware interface could provide it instead, so it
does not belong in board code.
Move both functions, together with the shared platform_id and
platform_version state, into arch/arm/mach-versal2 where they still
override the weak stubs in the Xilinx common board code. The board file
drops the now unused linux/bitfield.h include.
Michal Simek [Tue, 23 Jun 2026 12:53:34 +0000 (14:53 +0200)]
arm64: zynqmp: Move board_early_init_r clock setup to mach code
board_early_init_r() programmed the system timestamp counter directly
with readl()/writel() in board code. This is SoC register setup rather
than board policy, and similar code exists across the Xilinx SoCs.
Move it into zynqmp_timer_setup() in arch/arm/mach-zynqmp so the board
hook only keeps the EL3 guard and calls the helper. The asm/arch/clk.h
include (for zynqmp_get_system_timer_freq()) moves to cpu.c along with
the code.
Michal Simek [Tue, 23 Jun 2026 12:53:33 +0000 (14:53 +0200)]
arm64: versal-net: Move board_early_init_r clock setup to mach code
board_early_init_r() programmed the IOU switch clock and the system
timestamp counter directly with readl()/writel() in board code. This is
SoC register setup rather than board policy, and the same block is
duplicated across the Xilinx SoCs.
Move it into versal_net_timer_setup() in arch/arm/mach-versal-net so the
board hook only keeps the EL3 guard and calls the helper.
Michal Simek [Tue, 23 Jun 2026 12:53:32 +0000 (14:53 +0200)]
arm64: versal2: Move board_early_init_r clock setup to mach code
board_early_init_r() programmed the IOU switch clock and the system
timestamp counter directly with readl()/writel() in board code. This is
SoC register setup rather than board policy, and the same block is
duplicated across the Xilinx SoCs.
Move it into versal2_timer_setup() in arch/arm/mach-versal2 so the board
hook only keeps the EL3 guard and calls the helper.
Michal Simek [Tue, 23 Jun 2026 12:53:31 +0000 (14:53 +0200)]
arm64: versal: Move board_early_init_r clock setup to mach code
board_early_init_r() programmed the IOU switch clock and the system
timestamp counter directly with readl()/writel() in board code. This is
SoC register setup rather than board policy, and the same block is
duplicated across the Xilinx SoCs.
Move it into versal_timer_setup() in arch/arm/mach-versal so the board
hook only keeps the EL3 guard and calls the helper.
Michal Simek [Tue, 23 Jun 2026 12:53:30 +0000 (14:53 +0200)]
arm64: versal: Move bootmode decoding out of board code
versal_get_bootmode() lived in board code and open-coded the
IS_ENABLED(CONFIG_ZYNQMP_FIRMWARE) selection between the firmware call
zynqmp_pm_get_bootmode_reg() and a direct readl(). To keep generic board
code free of firmware specifics and SoC register details and ready for
SCMI, move the whole function, including the alt-shift and mask decoding,
behind an overridable hook.
The weak versal_get_bootmode() in arch/arm/mach-versal does the plain
MMIO read via versal_bootmode_reg() and decodes it (used at EL3 and
without firmware). When CONFIG_ZYNQMP_FIRMWARE is enabled,
firmware-zynqmp.c provides a strong definition that reads the register
through the firmware call, falling back to the direct read at EL3 where
the SMC path to firmware is unavailable. This preserves the existing
firmware-based bootmode behaviour while removing the firmware interface
from board code; the now unused zynqmp_firmware.h include is dropped.
Michal Simek [Tue, 23 Jun 2026 12:53:29 +0000 (14:53 +0200)]
arm64: versal: Decouple multiboot register access from firmware
versal_multi_boot() in board code selected between the firmware call
zynqmp_pm_get_pmc_multi_boot_reg() and a direct readl() based on an
IS_ENABLED(CONFIG_ZYNQMP_FIRMWARE) check. Generic board code should not
carry firmware-specific ifdefs, and this becomes harder to maintain once
SCMI introduces yet another access method.
Introduce an overridable accessor versal_pmc_multi_boot(). The weak
default lives in arch/arm/mach-versal and performs the plain MMIO read
(used at EL3 and when no firmware is present). When CONFIG_ZYNQMP_FIRMWARE
is enabled, firmware-zynqmp.c provides a strong definition that issues the
firmware call, falling back to the direct read at EL3 where the SMC path
to firmware is unavailable. The shared MMIO read is factored into
versal_multi_boot_reg() so the firmware override does not duplicate it.
versal_multi_boot() keeps the generic JTAG/QEMU workaround and simply
calls the accessor, so board code no longer references the firmware
interface for the multiboot register. The firmware-vs-MMIO decision is
selected at link time, and adding SCMI later only requires a third strong
definition with no board-code changes.
Michal Simek [Tue, 23 Jun 2026 12:53:28 +0000 (14:53 +0200)]
arm64: versal2: Move bootmode decoding out of board code
versal2_get_bootmode() lived in board code and accessed the CRP boot
mode register with a direct readl(). To keep generic board code free of
SoC register details and ready for firmware/SCMI based access, move the
whole function, including the alt-shift and mask decoding, into
arch/arm/mach-versal2 as a __weak default.
Board code now simply calls versal2_get_bootmode(). When a firmware
based implementation is available and tested it can provide a strong
definition that overrides the weak one at link time; until then only the
weak MMIO version is built.
Michal Simek [Tue, 23 Jun 2026 12:53:27 +0000 (14:53 +0200)]
arm64: versal2: Decouple multiboot register access from firmware
versal2_multi_boot() in board code selected between the firmware call
zynqmp_pm_get_pmc_multi_boot_reg() and a direct readl() based on an
IS_ENABLED(CONFIG_ZYNQMP_FIRMWARE) check. Generic board code should not
carry firmware-specific ifdefs, and this becomes harder to maintain once
SCMI introduces yet another access method.
Introduce an overridable accessor versal2_pmc_multi_boot(). The weak
default lives in arch/arm/mach-versal2 and performs the plain MMIO read
(used at EL3 and when no firmware is present). When CONFIG_ZYNQMP_FIRMWARE
is enabled, firmware-zynqmp.c provides a strong definition that issues the
firmware call, falling back to the direct read at EL3 where the SMC path
to firmware is unavailable. The shared MMIO read is factored into
versal2_multi_boot_reg() so the firmware override does not duplicate it.
versal2_multi_boot() keeps the generic JTAG/QEMU workaround and simply
calls the accessor, so board code no longer references the firmware
interface and the now unused zynqmp_firmware.h include is dropped. The
firmware-vs-MMIO decision is selected at link time, and adding SCMI later
only requires a third strong definition with no board-code changes.
Michal Simek [Tue, 23 Jun 2026 12:53:26 +0000 (14:53 +0200)]
arm: xilinx: Guard mach sys_proto.h against multiple inclusion
The Versal and Versal Gen 2 mach sys_proto.h headers lacked an include
guard. mach-versal/sys_proto.h additionally defines enum tcm_mode, so
including it twice in one translation unit fails to build with a
redeclaration error.
This is about to happen in firmware-zynqmp.c, which needs the SoC
prototypes unconditionally for the upcoming weak/strong multiboot and
bootmode accessors. Add the standard _ASM_ARCH_SYS_PROTO_H guard, as
already used by mach-zynqmp, so the header can be included more than once.
Padmarao Begari [Tue, 23 Jun 2026 15:08:22 +0000 (20:38 +0530)]
soc: xilinx: zynqmp: Add TCG variant detection for ZU3TCG
The XCZU3TCG device shares IDCODE 0x04718093 with XCZU3TEG but has
the GPU disable eFuse bit set (Consumer Grade, no GPU). Previously,
the TEG detection branch appended "teg" unconditionally, causing
U-Boot to report the device as zu3teg and failing bitstream ID
checks for xczu3tcg bitstreams.
Check EFUSE_GPU_DIS_MASK in the TEG branch to distinguish the two
sub-variants, mirroring the existing EG/CG detection logic:
- GPU disabled -> TCG family -> "zu3tcg"
- GPU enabled -> TEG family -> "zu3teg"
Pranav Tilak [Tue, 23 Jun 2026 03:53:51 +0000 (09:23 +0530)]
ufs: amd-versal2: Fix missing .priv_auto in driver registration
Add missing .priv_auto field to the driver. Without it,
struct ufs_versal2_priv is never properly allocated and dev_get_priv()
returns NULL, leading to DDR corruption at low DDR addresses.
Fixes: b5ac5f030720 ("ufs: ufs-amd-versal2: Add support for AMD UFS controller") Signed-off-by: Pranav Tilak <pranav.vinaytilak@amd.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Michal Simek <michal.simek@amd.com> Link: https://lore.kernel.org/r/20260623035411.2088224-1-pranav.vinaytilak@amd.com
Marek Vasut [Wed, 17 Jun 2026 02:48:46 +0000 (04:48 +0200)]
MAINTAINERS: Replace Zynq/ZynqMP with N:
Use N: to match on all zynq/zynqmp files, drop the large list of
entries which represent the same set of relevant files and miss a
few in the process. Combine Zynq and ZynqMP entries into single
entry to further cut down the duplication.
Erich E. Hoover [Fri, 12 Jun 2026 15:04:54 +0000 (09:04 -0600)]
mkimage: allow zynqmpbif to use a register initialization file
The ZynqMP Boot Image Format allows specifying the register
initialization file with the "[init]" attribute. Since this
feature is already supported by the "zynqmpimage" backend, this
commit leverages that existing capability to add support for the
"[init]" attribute in the zynqmpbif backend:
https://docs.amd.com/r/en-US/ug1283-bootgen-user-guide/init
This currently uses the same register initialization file format as
zynqmpimage (ASCII text hex values with each line composed of a pair
of register address and value), for example:
===
0xff003248 0x12345678
===
It is not, yet, compatible with the format used by bootgen:
https://docs.amd.com/r/en-US/ug1283-bootgen-user-guide/Initialization-Pairs-and-INT-File-Attribute
Use this feature, with other zynqmpbif options, like so:
===
image : {
[init] reginit.int
[bootloader] fsbl.elf
[pmufw_image] pmufw.elf
[destination_cpu=a53-0, exception_level=el-3] bl31.elf
[destination_cpu=a53-0, exception_level=el-2, load=0x08000000,
startup=0x08000000] u-boot.bin
}
===
The old static normal-memory mapping spans PCIe, while DDR coverage is
already populated later from the DRAM banks discovered by mem_map_fill().
Drop the stale static mapping so the MMU table matches the Versal address
map. Also matting was using wrong attributes.
Michal Simek [Thu, 11 Jun 2026 12:10:25 +0000 (14:10 +0200)]
arm64: versal2: Drop static DDR MMU mappings
DDR coverage is already populated later from the DRAM banks discovered by
mem_map_fill(). Drop the stale static mappings so the MMU table matches
address map more closely.
Suraj Kakade [Wed, 10 Jun 2026 11:05:31 +0000 (16:35 +0530)]
amd: versal2: detect spi env bus from boot mode
Add spi_get_env_dev() to dynamically detect the correct SPI
bus based on the actual boot mode at runtime. This ensures
environment variables are always loaded from the correct SPI
flash controller regardless of the bus numbering.
For example, on some Versal Gen 2 boards, SPI is disabled in DTS
leaving bus 0 empty in DM. Only QSPI is enabled at bus 1. The
default CONFIG_ENV_SPI_BUS=0 causes U-Boot to search for environment
at bus 0 which does not exist, triggering the warning
"spi_flash_probe_bus_cs() failed, using default environment".
Michal Simek [Tue, 9 Jun 2026 07:48:21 +0000 (09:48 +0200)]
arm64: zynqmp: dts: Fix file descriptions to match actual filenames
Fix descriptions that don't match their filenames:
- zynqmp-sc-vpk180-revB.dtso: described as revA instead of revB
- zynqmp-sck-kv-g-revB.dtso: described as revA instead of revB
Michal Simek [Tue, 9 Jun 2026 07:48:19 +0000 (09:48 +0200)]
arm64: zynqmp: Add CMA reserved-memory for runtime FPGA loading
Add CMA (Contiguous Memory Allocator) reserved-memory regions to all
Xilinx arm64 board device trees to support runtime FPGA programming.
The CMA pool uses dynamic allocation constrained to the low 2 GB DDR region
via alloc-ranges so that the kernel places it within the 32-bit addressable
space.
CMA sizes are chosen per silicon family to accommodate the maximum PL
bitstream/PDI size:
- Kria K24 SOM: 64 MB
- ZynqMP boards: 128 MB
For Kria K24 SOM the CMA inherited from K26 is overridden to 64 MB.
For Kria SOMs, the CMA node is added to the SOM DTS only, not to
carrier board overlays.
Michal Simek [Tue, 9 Jun 2026 07:48:18 +0000 (09:48 +0200)]
arm64: zynqmp: Use fixed-partitions for MTD
Describe flash and NAND MTD partitions using the fixed-partitions
compatible under a dedicated partitions subnode. U-Boot only creates
slave MTD devices from this binding in add_mtd_partitions_of(), so
mtd list can show named partitions.
Michal Simek [Tue, 9 Jun 2026 07:48:17 +0000 (09:48 +0200)]
arm64: zynqmp: Drop incorrect #phy-cells from ethernet-phy nodes
The #phy-cells property is meant for generic PHY providers
(Documentation/devicetree/bindings/phy/phy-bindings.txt) and is not a
valid property for ethernet-phy nodes. Its presence triggers a
dt-validate warning:
ethernet-phy@x (ethernet-phy-id001c.c816): Unevaluated properties
are not allowed ('#phy-cells' was unexpected)
arm64: zynqmp-dlc21-revA: add mac nvmem cell for gem0
Enable nvmem support for MAC address retrieval from EEPROM for
ethernet@ff0b0000.
Add nvmem-cells and nvmem-cell-names to the GEM0 node, and define a
mac-address@20 cell under the EEPROM node on I2C0.
This allows U-Boot to read the MAC address from EEPROM at offset 0x20.
Tom Rini [Mon, 6 Jul 2026 14:12:19 +0000 (08:12 -0600)]
Merge patch series "Remove patman from the U-Boot tree"
Simon Glass <sjg@chromium.org> says:
patman is now maintained as a standalone 'patch-manager' package, so
remove it from the tree. The command becomes a stub that tells people to
run 'pip install patch-manager'.
buildman still imports the shared modules commit and patchstream (along
with their dependencies), so this series leaves those in place. It drops
the tool's code, tests, CI hooks and packaging, and removes the in-tree
documentation, moving the b4 contributor guide alongside the patman note
in the patch-sending docs. It also adds a .patman-defaults file so the external
tool is set up for U-Boot, next to the existing .b4-config. Where the CI
jobs relied on patman's requirements for the setuptools that pylibfdt
needs, they now install scripts/dtc/pylibfdt/requirements.txt instead.
More could be done here: commit and patchstream (and their dependencies
series, get_maintainer and settings) only remain because buildman still
imports them. A follow-up could move those into u_boot_pylib (or
buildman itself) and drop the rest, leaving tools/patman as just the
stub.
Simon Glass [Sun, 5 Jul 2026 19:32:17 +0000 (13:32 -0600)]
patman: Remove the patch-management code
Delete the command-line tool and its supporting modules, now that this
functionality lives in the standalone patch-manager package.
Keep the modules that buildman still imports (commit and patchstream,
plus their dependencies series, get_maintainer and settings), along with
the stub command. Trim __init__.py to match.
Simon Glass [Sun, 5 Jul 2026 19:32:16 +0000 (13:32 -0600)]
patman: Remove the test suite
These tests cover the patch-management functionality, which is being
removed from the tree in favour of the standalone patch-manager package.
Drop the tests and their data files.
Simon Glass [Sun, 5 Jul 2026 19:32:15 +0000 (13:32 -0600)]
patman: Replace the tool with a stub for patch-manager
patman is now maintained as a standalone 'patch-manager' package, rather
than in the U-Boot tree. Replace the command with a small stub which
tells people how to install it.
buildman still uses the shared modules commit and patchstream (and their
dependencies), so leave those in place; the patches that follow remove
the patch-management code itself.
Simon Glass [Sun, 5 Jul 2026 19:32:14 +0000 (13:32 -0600)]
patman: Add a .patman-defaults file for U-Boot
patman is now installed from the separate patch-manager package. It reads
a .patman-defaults file from the tree root as its lowest-priority config,
so a project can ship defaults that developers still override from their
own ~/.patman, a local .patman or the command line. This behaviour is new
in patman version 0.0.20
Add one for U-Boot, alongside .b4-config, pinning the patchwork server and
the get_maintainer.pl invocation so the tool works out of the box without
depending on patman's built-in defaults. A few other settings are listed,
commented out, as a starting point.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
Simon Glass [Sun, 5 Jul 2026 19:32:22 +0000 (13:32 -0600)]
test: Stop running the patman tests
The patman tests no longer exist in the tree, so drop them from the
test/run script (used by 'make tcheck' and friends) and from the
tools-testing example in the documentation.
Simon Glass [Sun, 5 Jul 2026 19:32:21 +0000 (13:32 -0600)]
tools: Stop packaging patman as a pip module
patman is no longer shipped from the U-Boot tree, so drop it from the
'make pip' target and from make_pip.sh, and remove its packaging files
(setup.py, pyproject.toml, requirements.txt). Nothing else refers to
them by this point in the series, so they can go.
Also fix binman's pyproject.toml, which declares package-data for a
'patman' package (a copy-paste leftover); use 'binman' instead.
Simon Glass [Sun, 5 Jul 2026 19:32:20 +0000 (13:32 -0600)]
tools: docker: Drop patman from the CI image
The CI runner image pre-caches pip packages by downloading each tool's
requirements.txt from master. A later patch removes patman's
requirements.txt from the tree, so stop fetching and installing it.
The same step already installs setuptools explicitly (patman's
requirements list it too), so this needs nothing further.
This takes effect the next time someone rebuilds the image; the existing
image keeps working in the meantime.
Simon Glass [Sun, 5 Jul 2026 19:32:18 +0000 (13:32 -0600)]
CI: Install pylibfdt's requirements in the tool jobs
The GitLab and Azure tool-test and pylint jobs build the pylibfdt
bindings, which need setuptools. That currently comes only from patman's
requirements.txt, which a later patch drops. Install
scripts/dtc/pylibfdt/requirements.txt in those jobs, the proper source
for that dependency, so setuptools survives patman's removal.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
Simon Glass [Sun, 5 Jul 2026 19:32:13 +0000 (13:32 -0600)]
doc: Remove the patman documentation
The full patman manual now lives with the standalone patch-manager
package, making the 1000-line copy in the tree redundant.
Remove the in-tree manual, its README and the doc/develop/patman.rst
toctree page.
The sending-patches guide already introduces patman, so point it at the
patch-manager package instead of the now-dead ':doc:' cross-reference
and, with the manual gone, add a couple of lines on how the tool works.
Point the SPI howto at that guide too, rather than repeating the install
details.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Simon Glass [Sun, 5 Jul 2026 19:32:12 +0000 (13:32 -0600)]
doc: Move the b4 guide into sending_patches
The b4 contributor guide sits in the coding-style document, which is an
odd place for it. Move it into sending_patches.rst, next to the patman
note, so both patch-sending tools are described together.
The b4_contrib label moves with it, so the reference from process.rst
still resolves.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org> Reviewed-by: Tom Rini <trini@konsulko.com>
Tanmay Kathpalia [Mon, 29 Jun 2026 06:16:15 +0000 (23:16 -0700)]
Revert "mmc: sdhci-cadence: trigger tuning for SD HS mode on SD6HC (v6) PHY"
This reverts commit b42c67188c14 ("mmc: sdhci-cadence: trigger tuning
for SD HS mode on SD6HC (v6) PHY").
The reverted patch introduced several issues:
1. Non-standard tuning trigger: The SD Physical Layer Specification
only mandates execute_tuning for SDR50 and SDR104 UHS-I modes.
Triggering tuning for SD High Speed mode is outside the spec and
is handled via a non-standard set_ios_post callback rather than
through the established SDHCI framework tuning path.
2. Non-standard device tree property: The patch introduced a new
"cdns,sd-hs-tuning" DT property to opt into SD HS tuning. This
is not aligned with existing DT bindings and bypasses the standard
MMC capability negotiation mechanism.
3. Incorrect tunable mode allowlist: The sdhci_cdns6_mode_is_tuned()
function includes SD_HS, UHS_SDR50, and MMC_HS_400_ES as tunable
modes. According to the Cadence SD6HC IP User Guide (section 7.5.2,
Figure 18), tuning is only required for UHS-I SDR104 (SD) and
HS200 (eMMC). SD High Speed, UHS-I SDR50, and DDR50 only require
a PHY settings update from the pre-calculation script, not the
tuning procedure. HS400 transitions through HS200 and reuses its
tuned DLL value with a partial settings update. HS400ES only
requires a plain settings update from the calculation script with
no dependency on HS200 tuning.
4. Tuned state management outside the framework: The patch manually
tracks tuned DLL state (tuned_mode, tuned_dll_slave_ctrl) and
restores it across PHY reconfigurations. This duplicates
responsibility that belongs in the core MMC tuning framework and
adds unnecessary complexity to the driver.
Reverting to realign the driver with the IP documentation and the SD
Physical Layer Specification.
Signed-off-by: Tanmay Kathpalia <tanmay.kathpalia@altera.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Tanmay Kathpalia [Thu, 14 May 2026 18:54:11 +0000 (11:54 -0700)]
mmc: sd: fix redundant 1.8V voltage switch on cold boot with UHS card
When a UHS card successfully negotiates 1.8V signaling during normal
initialization, the host voltage switch is performed as part of the
ACMD41 handshake. Without this fix, the warm-reboot recovery path
would fire again immediately after, switching the host voltage a
second time unnecessarily.
Add a check so the recovery path is only entered when the voltage
switch was not already performed during the current initialization
session.
Fixes: 906ee6785b1c ("mmc: sd: Handle UHS-I voltage signaling without power cycle") Signed-off-by: Tanmay Kathpalia <tanmay.kathpalia@altera.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Ye Li [Tue, 9 Jun 2026 03:54:32 +0000 (11:54 +0800)]
power: domain: scmi: Allow failure in getting power domain attribute
When one power domain fails to get attribute, continue getting attribute
for remaining power domains, not return probe failure. So other power
domains are still functional.
It is possible that one power domain is assigned to other agent or this
power domain is disabled by HW fuse, so platform returns denied or other
error.
Signed-off-by: Ye Li <ye.li@nxp.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Marek Vasut [Sun, 21 Jun 2026 02:40:23 +0000 (04:40 +0200)]
crypto: fsl: Hide CAAM_64BIT symbol behind FSL_CAAM
Make CAAM_64BIT selectable only in case FSL_CAAM is selected,
otherwise CAAM_64BIT shows up in configs of unrelated platforms.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Heiko Schocher <hs@nabladev.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Vincent Jardin [Thu, 2 Jul 2026 15:09:49 +0000 (17:09 +0200)]
gpio: mpc8xxx: add set_flags/get_flags ops
mpc8xxx_gpio_open_drain_on() / _off() helpers can program GPODR
(open-drain enable) on QorIQ silicon, but they are not called.
The open-drain capability is therefore unreachable from the GPIO uclass.
Adding a set_flags op for the GPIOD_OPEN_DRAIN, plus a get_flags for the
reports of state by reading GPDIR and GPODR back.
For existing callers, it is unchanged: direction_input,
direction_output, get_value, set_value and get_function still drive
the same registers as before. The new ops only become observable when
a caller explicitly asks for the GPIOD_OPEN_DRAIN flag (or queries
flags via the uclass).
Signed-off-by: Vincent Jardin <vjardin@free.fr> Signed-off-by: Peng Fan <peng.fan@nxp.com>
ls1028ardb: Move environment variables to .env file
Move the bulk of the board environment from CFG_EXTRA_ENV_SETTINGS in
ls1028ardb.h to board/nxp/ls1028a/ls1028ardb.env. Because the board
directory is shared with ls1028aqds, the file is selected through
CONFIG_ENV_SOURCE_FILE rather than the SYS_BOARD default.
The distro_bootcmd machinery cannot be expressed in a .env file. The
BOOTENV macro expands to environment text with embedded NUL separators,
and the board overrides three distro variables (boot_scripts,
boot_a_script and scan_dev_for_boot_part) that must follow BOOTENV to
take effect. BOOTENV and those three overrides therefore remain in
CFG_EXTRA_ENV_SETTINGS, which is concatenated after the .env text, while
every other variable moves to the .env file.
The resulting default environment is functionally unchanged for both the
ls1028ardb_tfa and ls1028ardb_tfa_SECURE_BOOT defconfigs. This was
verified with an order aware comparison of the default environment before
and after the change. The only difference is that three accidental double
spaces in xspi_bootcmd, sd_bootcmd and emmc_bootcmd collapse to single
spaces, because the preprocessor normalises whitespace in the now
unquoted text, which does not affect command parsing.
Signed-off-by: Aristo Chen <aristo.chen@canonical.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Neil Armstrong [Thu, 25 Jun 2026 15:36:15 +0000 (17:36 +0200)]
treewide: change email links from mailman to patch.msgid.link with message-id
In preparation of the migration of the mailman mailing-list currently
hosted on the denx.de infrastructure, migrate the links in the code,
comments and documentation to https://patch.msgid.link to be future proof
and always link to the expected content data and uses the message-id in
the URL which will help find the appropriate e-mail in the future.
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
Michal Simek [Mon, 29 Jun 2026 15:44:01 +0000 (17:44 +0200)]
.mailmap: Run mailmapper and sync name locations
The patch is output from
scripts/mailmapper > tmp; mv tmp .mailmap
with moving <swarren@wwwdotorg.org> and <swarren@wwwdotorg.org> to the same
block with "This contributor prefers not to receive mails" description.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Michal Simek [Mon, 29 Jun 2026 15:44:00 +0000 (17:44 +0200)]
.mailmap: update e-mail address for Abbarapu Venkatesh Yadav
Name and email address has changed but format wasn't correct. Keep origin
line which is doing conversion from xilinx.com to amd.com and then have
conversion from AMD to Qualcomm. Also move name to proper location.
Fixes: f21920f7e795 (".mailmap: update e-mail address for Abbarapu Venkatesh Yadav") Signed-off-by: Michal Simek <michal.simek@amd.com>
.mailmap: map old addresses to their up-to-date counterparts
This essentially maps @free-electrons.com to @bootlin.com addresses.
Signed-off-by: João Marcos Costa <joaomarcos.costa@bootlin.com> Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
drivers: sysreset: revert support for args in request
This reverts:
- commit e49c84f7bb7b ("doc: usage: cmd: reset: specify when the -edl
option is available")
- commit 1076feb8a3f9 ("cmd: boot: fix edl being shown when not
supported")
- commit 63c806ba0e12 ("qcom_defconfig: enable psci based sysreset")
- commit ef06c5d76ff4 ("cmd: boot: Add '-edl' option to reset command
documentation")
- commit 32825eaddc37 ("sysreset: Implement PSCI based reset to EDL mode
for QCOM SoCs")
- commit fcb48b89813b ("drivers: sysreset: Add sysreset op that can take
arguments")
There was a conflict reverting commit 63c806ba0e12 ("qcom_defconfig:
enable psci based sysreset") due to commit 02ef1859b44f ("configs:
Resync with savedefconfig"), but the conflict resolution was trivial.
The args support for the sysreset uclass contains a logic bug. The first
sysreset device implementing the request_arg callback will consume the
args, not support the specified arg and thus return -EPROTONOSUPPORT
which will stop the iteration over all sysreset devices.
This is an issue if one has multiple sysreset devices and each with
support for different (valid) args. If a sysreset device implements a
-dummy argument and another -foo and a user calls reset -dummy from the
U-Boot CLI, it'll depend on which sysreset device will be attempted
first. If it is the one implementing -foo, it'll return it doesn't
support the argument with -EPROTONOSUPPORT in which case the device
implementing -dummy will never be attempted and instead we'll do a cold
reset which is very likely not what's expected from the user.
Casey suggested[1] we revert this and start from scratch again with a
different implementation instead.
Denis Mukhin [Tue, 23 Jun 2026 22:06:29 +0000 (15:06 -0700)]
bootdev: scan boot devices at each priority level
Currently, default 'bootflow scan -lb' will stop booting the board if
any of higher-priority bootdevs fail to be hunted even if there are
bootdevs of lower priority.
For example, if the board has both NVMe (priority 4) and USB MSD devices
(priority 5), and if NVMe bootdev hunt fails (in the event of a bad NVMe
firmware update), USB (which may be a recovery bootdev) is never hunted
automatically, leaving the board at the U-Boot prompt (user intervention
is needed, e.g. something like 'bootflow scan usb' to hunt USB).
Fix bootdev_next_prio() to scan bootdevs at the lower priority level by
not exiting the scan loop early.
Keep the existing logging verbosity unchanged and rely on the failing
subsystem to provide a suitable diagnostic message.
Signed-off-by: Denis Mukhin <dmukhin@ford.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Tom Rini [Fri, 3 Jul 2026 16:13:14 +0000 (10:13 -0600)]
Merge patch series "bootm: fix flush_cache() with IH_TYPE_KERNEL_NOLOAD"
This patch series from Nora Schiffer <nora.schiffer@ew.tq-group.com>
addresses a few issues with correctly handling IH_TYPE_KERNEL_NOLOAD in
a few cases.
Nora Schiffer [Mon, 22 Jun 2026 11:19:33 +0000 (13:19 +0200)]
bootm: allow omitting entry point for IH_TYPE_KERNEL_NOLOAD
For IH_TYPE_KERNEL_NOLOAD, the entry point is given relative to the
image start, making 0 a valid default, and for IH_OS_EFI, it is ignored
altogether, so it may be preferable to omit it.
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Nora Schiffer [Mon, 22 Jun 2026 11:19:31 +0000 (13:19 +0200)]
bootm: fix flush_cache() with IH_TYPE_KERNEL_NOLOAD
`flush_start` must be set after `load` has been assigned.
Fixes: 69544c4fd8b1 ("bootm: Support kernel_noload with compression") Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Tom Rini [Fri, 3 Jul 2026 16:10:34 +0000 (10:10 -0600)]
Merge patch series "TI: AM64-EVM/SK: Enable MAIN UART1 for SYSFW tracing"
Vishal Mahaveer <vishalm@ti.com> says:
Collecting SYSFW traces from DMSC firmware is broken on the current
codebase. These changes enables MAIN_UART1 for collecting SYSFW traces
when the trace option is enabled in the boardcfg.
Vishal Mahaveer [Fri, 5 Jun 2026 19:38:28 +0000 (14:38 -0500)]
arm: mach-k3: am642: Update MAIN UART1 serial alias from 3 to 1
The upstream device tree changed the serial alias for MAIN UART1 from
serial3 to serial1. Update the board initialization code to match this
change by modifying the UCLASS_SERIAL sequence number lookup.
This ensures proper pin control configuration for the UART used by
system firmware (SYSFW).
Vincent Jardin [Wed, 20 May 2026 15:00:21 +0000 (17:00 +0200)]
mtd: spi-nor: Add gd55lb02gf chips
Add the GigaDevice GD55LB02GF (256 Mo) similar to gd55lb02ge with
the same read path flags.
SPI_NOR_HAS_LOCK and SPI_NOR_HAS_TB do not match this chip's
status register layout: the GD55LB02GF uses a 5-bit block protect
field BP0..BP4 plus a CMP bit in SR2 for direction (see datasheet
"Status Register Block Protection").
The generic stm-lock helpers drive only BP0..BP2 and assume SR1
bit 5 is TB, but on this part SR1 bit 5 is BP3.
Enabling either flag would leave BP3..BP4 unmanaged or corrupt
BP3 on every lock op.
A proper support needs a vendor specific lock callback, it is out
of scope for this table update.
Aristo Chen [Fri, 19 Jun 2026 14:45:51 +0000 (14:45 +0000)]
bootm: move OS index bound check into the legacy path
Commit 103b1e7ce8cc ("bootm: bound-check OS index in
bootm_os_get_boot_func()") added a range check to the shared accessor so
an out-of-range OS id can no longer drive an out-of-bounds read of
boot_os[]. That accessor is reached by every image format, but only a
legacy uImage can deliver an unchecked value. bootm_find_os() takes the
raw 8-bit ih_os byte straight from image_get_os() for legacy images,
whereas the FIT path reaches the accessor only after fit_image_load()
has rejected any image whose os is not one of the supported types, and
the Android path hardcodes IH_OS_LINUX. The check can therefore never
fail for FIT, where it only adds confusion and code.
Move the test to the legacy branch of bootm_find_os(), rejecting an
out-of-range OS where the untrusted byte enters. This keeps the FIT path
clear and lets the check be compiled out when CONFIG_LEGACY_IMAGE_FORMAT
is disabled. A valid OS id that has no handler is still reported by the
existing NULL return path in bootm_run_states().
Suggested-by: Simon Glass <sjg@chromium.org> Signed-off-by: Aristo Chen <aristo.chen@canonical.com> Reviewed-by: Simon Glass <sjg@chromium.org>
projects / thirdparty / u-boot.git / log
