u-boot.git/arch/arm/mach-versal2/include, branch master

arm64: versal2: Move board_early_init_r clock setup to mach code

2026-07-08T06:55:51Z

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. Signed-off-by: Michal Simek Link: https://patch.msgid.link/08e835a183c39de6f666375ac390eee6a8f3f12e.1782219202.git.michal.simek@amd.com

arm64: versal2: Move bootmode decoding out of board code

2026-07-08T06:55:51Z

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. Signed-off-by: Michal Simek Link: https://patch.msgid.link/f3274ec77218373bc0452f6795a3ad6016be0058.1782219202.git.michal.simek@amd.com

arm64: versal2: Decouple multiboot register access from firmware

2026-07-08T06:55:51Z

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. Signed-off-by: Michal Simek Link: https://patch.msgid.link/0033a1fa8efb4ae0c3ac6a6f5c5c1b4e0f22f02c.1782219202.git.michal.simek@amd.com

arm: xilinx: Guard mach sys_proto.h against multiple inclusion

2026-07-08T06:55:51Z

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. Signed-off-by: Michal Simek Link: https://patch.msgid.link/1bf5b1d49abb271c2c5e7135837b740179b95553.1782219202.git.michal.simek@amd.com

arm64: xilinx: Add PMC PGGS3 and PGGS4 registers

2026-06-08T08:50:05Z

Add PMC Global PGGS3 and PGGS4 register defines to Versal and Versal Gen 2 hardware headers. These registers hold boot index and boot metadata required for FWU multi-bank update support. Signed-off-by: Padmarao Begari Signed-off-by: Michal Simek Link: https://lore.kernel.org/r/20260514102601.1759779-2-padmarao.begari@amd.com

arm64: versal2: Populate DRAM banks before page table size calculation

2026-02-13T07:16:24Z

Move DRAM bank detection from fdtdec to custom implementation to ensure memory banks are populated before get_page_table_size() is called during MMU initialization. The current fdtdec-based approach populates gd->bd->bi_dram[] too late in the boot sequence, causing get_page_table_size() to be called with unpopulated DRAM information. This prevents dynamic page table sizing based on actual memory configuration. Parse /memory nodes in dram_init() to fill versal2_mem_map[] early enough for MMU setup. Supports up to CONFIG_NR_DRAM_BANKS (36) non-contiguous banks with high memory regions (>4GB) and use __weak get_page_table_size implementation to estimate page table size based on the populated DRAM banks. Signed-off-by: Pranav Sanwal Signed-off-by: Michal Simek Link: https://lore.kernel.org/r/20260129120021.1328653-3-pranav.sanwal@amd.com

arm64: versal2: Read and show multiboot value

2025-12-19T07:25:27Z

SOC can boot from different boot medias and also different offsets that's why by default show multiboot value to be aware which image system is booting out of. It is especially useful for systems with A/B update enabled. Also limit zynqmp_pm_get_pmc_multi_boot_reg() usage only for Versal and Versal Gen 2. Signed-off-by: Michal Simek Link: https://lore.kernel.org/r/fd7564ce2f51d965c273e939e98de01beb92e6f5.1764232124.git.michal.simek@amd.com

ufs: amd-versal2: Use raw read/write for SLCR/CACHE registers

2025-04-16T11:42:06Z

Update the firmware driver UFS APIs zynqmp_pm_ufs_* to directly read/write to the pmc_iou_slcr and efuse_cache registers. Replace these raw reads/writes with the xilinx_pm_request() API with the correct arguments once the PM related changes are done. Signed-off-by: Venkatesh Yadav Abbarapu Signed-off-by: Michal Simek Link: https://lore.kernel.org/r/ee2d1ad2e07e96f1948ab6ffe8f3c50a3b8f9be9.1742462001.git.michal.simek@amd.com

amd: versal2: Add the UFS boot mode support

2025-04-16T11:42:06Z

Add the UFS boot mode support and update the boot_targets with ufs mode. If the UFS device is not accessible from APU and running this is detected as a warning, as the device is not accessible. Signed-off-by: Venkatesh Yadav Abbarapu Link: https://lore.kernel.org/r/20250225032806.1842581-1-venkatesh.abbarapu@amd.com Signed-off-by: Michal Simek

arm64: versal2: Show major and minor silicon version

2025-03-03T15:09:59Z

ES1 silicon is 0x10 (16) and production is 0x20 (32) but correct number to see are v1.0 or v2.0 instead of v16 or v32. Signed-off-by: Michal Simek Link: https://lore.kernel.org/r/20095339334fe07f373ffae3bdbfec51f5a00dc7.1739882585.git.michal.simek@amd.com