| Age | Commit message (Collapse) | Author |
|---|
|
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.
Signed-off-by: Michal Simek <[email protected]>
Link: https://patch.msgid.link/c332ab27f66f1c808f32a4bcb453d9e8da543331.1782219202.git.michal.simek@amd.com
|
|
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 <[email protected]>
Link: https://patch.msgid.link/08e835a183c39de6f666375ac390eee6a8f3f12e.1782219202.git.michal.simek@amd.com
|
|
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 <[email protected]>
Link: https://patch.msgid.link/f3274ec77218373bc0452f6795a3ad6016be0058.1782219202.git.michal.simek@amd.com
|
|
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 <[email protected]>
Link: https://patch.msgid.link/0033a1fa8efb4ae0c3ac6a6f5c5c1b4e0f22f02c.1782219202.git.michal.simek@amd.com
|
|
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 <[email protected]>
Link: https://patch.msgid.link/1bf5b1d49abb271c2c5e7135837b740179b95553.1782219202.git.michal.simek@amd.com
|
|
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.
Signed-off-by: Michal Simek <[email protected]>
Link: https://lore.kernel.org/r/156e48d8228acfeba8866618038b48cd51490ea7.1781179823.git.michal.simek@amd.com
|
|
Currently, the bi_dram[] information is stored in the board info
structure (bd). Because bd is only valid after reserve_board(),
dram_init_banksize() must be called late in the initialization process.
This limitation is problematic, as it forces us to rely on a variety of
bespoke functions to determine board RAM, bank memory sizes, and other
early setup requirements.
By moving bi_dram[] into the global data (gd), we can run it earlier.
This is particularly convenient since boards define their own
dram_init_banksize() routines, which do not always rely on parsing
Device Tree (DT) memory nodes.
Additionally, U-Boot defaults to relocating to the top of the first memory
bank. While boards currently use custom functions to override this
behavior, having the DRAM bank information available earlier in gd makes
relocating to a different bank trivial and standardizes the process.
Reviewed-by: Anshul Dalal <[email protected]>
Tested-by: Michal Simek <[email protected]> # Versal Gen 2 Vek385
Tested-by: Anshul Dalal <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
Tested-by: Christophe Leroy (CS GROUP) <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Michal Simek <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
The AMD Versal Gen 2 PCIe host controller places its DBI registers
(0x100000000000, 1 MB) and config space (0x100000100000, 255 MB)
above 1 TB. Without MMU entries covering these ranges, U-Boot faults
when the PCIe driver accesses them.
The two regions are merged into a single entry as these are
contiguous and share identical MMU attributes. Add this
entry under a CONFIG_IS_ENABLED(PCIE_DW_AMD) guard so it is only
included when the PCIe driver is configured. VERSAL2_MEM_MAP_USED is
adjusted from 5 to 6 accordingly, keeping the DRAM bank index correct.
Signed-off-by: Pranav Sanwal <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Michal Simek <[email protected]>
|
|
Add and enable the GIC600 support configuration by default for
Versal Gen 2.
Signed-off-by: Padmarao Begari <[email protected]>
Signed-off-by: Michal Simek <[email protected]>
Link: https://lore.kernel.org/r/e3135eee33282281572fbc960aa45b5d0f355158.1772098079.git.michal.simek@amd.com
|
|
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 <[email protected]>
Signed-off-by: Michal Simek <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
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 <[email protected]>
Link: https://lore.kernel.org/r/fd7564ce2f51d965c273e939e98de01beb92e6f5.1764232124.git.michal.simek@amd.com
|
|
Add support for loading the secure & non-secure pdi images and PL
bitstream on the Versal Gen2 platform. The FPGA driver is enabled
to load the bitstream in PDI format on the AMD Versal Gen2 device.
PDI is the new programmable device image format for Versal Gen2,
and the bitstream for the Versal Gen2 platform is generated exclusively
in this format.
With the enhanced SMC format in TF-A ensuring transparent payload
forwarding for Versal Gen2, the u-boot driver must now handle the
word swapping of PDI address that was previously done in TF-A for
this API. The source code for the Versal2 loadpdi command and the
CONFIG_CMD_VERSAL2 configuration has been removed. It now utilizes
the fpga load <dev> <address> <length> command to load secure &
non-secure pdi images.
Signed-off-by: Prasad Kummari <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Michal Simek <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Michal Simek <[email protected]>
Link: https://lore.kernel.org/r/ee2d1ad2e07e96f1948ab6ffe8f3c50a3b8f9be9.1742462001.git.michal.simek@amd.com
|
|
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 <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Michal Simek <[email protected]>
|
|
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 <[email protected]>
Link: https://lore.kernel.org/r/20095339334fe07f373ffae3bdbfec51f5a00dc7.1739882585.git.michal.simek@amd.com
|
|
Add support for AMD Versal Gen 2. SoC is based on Cortex-a78ae 4 cluster/2
cpu core each. A lot of IPs are shared with previous families. There are
couple of new IP blocks where the most interesting from user point of view
is UFS.
Signed-off-by: Michal Simek <[email protected]>
Link: https://lore.kernel.org/r/bc2b70831ce1031bd0fac32357bff84936e1310f.1716994063.git.michal.simek@amd.com
|
