HBM stands for high bandwidth memory and is a type of memory interface used
in 3D-stacked DRAM (dynamic random access memory) in some AMD GPUs (aka
graphics cards), as well as the server, high-performance computing (HPC)
and networking and client space. High Bandwidth Memory(HBM) has total 16
channels, one channel is divided into two pseudo channels which makes its
32 banks each with some amount of memory.
And then we have DDR_LOW PS low, DDR_HIGH0 PS high, DDR_HIGH1 PS very high
and pretty much there should be also place for PL DDR. So maximum number of
memory banks will be 36, updating the CONFIG_NR_DRAM_BANKS to 36.
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Link: https://lore.kernel.org/r/20250410092528.3713904-1-venkatesh.abbarapu@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
The mini u-boot is getting exception because of an initial
stack pointer address is used at near the top of memory,
and while executing u-boot is assigned pre-malloc and
global_data memory after initial stack pointer and updated
the stack pointer. Serial driver is used pre-malloc area
for serial operations before relocation. But pre-malloc area
is cleared while doing BSS at relocation time. The u-boot is
called board_init() function and doing printf, relocation serial
driver is not initialized yet, so it is using before relocation
serial operations but it is cleared by BSS and got the exception.
To fix, change an initial stack pointer address from near the
top of memory to near the relocation memory.
Fixes: 685874939a ("configs: versal: update initial stack pointer")
Signed-off-by: Padmarao Begari <padmarao.begari@amd.com>
Link: https://lore.kernel.org/r/20250407134544.3951763-1-padmarao.begari@amd.com
Signed-off-by: Michal Simek <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 <prasad.kummari@amd.com>
Link: https://lore.kernel.org/r/20250327105200.1262615-3-prasad.kummari@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
Add support for loading the secure & non-secure pdi images and
PL bitstream on the Versal NET platform. The FPGA driver is enabled
to load the bitstream in PDI format on the AMD Versal NET device.
PDI is the new programmable device image format for Versal NET,
and the bitstream for the Versal NET platform is generated exclusively
in this format.
The source code for the versalnet loadpdi command and the
CONFIG_CMD_VERSAL_NET 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 <prasad.kummari@amd.com>
Link: https://lore.kernel.org/r/20250327105200.1262615-2-prasad.kummari@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
Introducing additional flag to check whether an FPGA driver is able to
load a particular FPGA bitstream image.
Generally, flag variable is used to enable or disable certain features,
specify additional parameters (such as error handling), or modify how
the function operates.
Hence, in this function flags is an integer that can be used to pass
configuration options to the fpga_load function. Here, it's
initialized to 0, meaning no special options are enabled, but it could
modify the flags to influence the function's behavior.
Signed-off-by: Muhammad Hazim Izzat Zamri <muhammad.hazim.izzat.zamri@altera.com>
Link: https://lore.kernel.org/r/20250314021953.18379-3-muhammad.hazim.izzat.zamri@altera.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
Enabling the capability to automatically perform FPGA configuration
when booting Linux FIT image via bootm command. The FPGA
configuration bitstream shall be packed within the FIT image.
The FPGA data (full or partial) is checked by the SDM hardware,
for Intel SDM Mailbox based devices. Hence always return full
bitstream.
Second function is to enable the HPS to FPGA bridges when FPGA load
is completed successfully. This is to ensure the FPGA is accessible
by the HPS.
Signed-off-by: Muhammad Hazim Izzat Zamri <muhammad.hazim.izzat.zamri@altera.com>
Link: https://lore.kernel.org/r/20250314021953.18379-2-muhammad.hazim.izzat.zamri@altera.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
The set_dfu_alt_info() function calls the ALLOC_CACHE_ALIGN_BUFFER()
macro to declare a `buf' variable pointer into an array allocated on the
stack. It then calls the memset() function to clear the useable portion
of the array using the idiomatic expression `sizeof(buf)'.
While this would indeed work fine for an array, in the present case we
end up clearing only the size of a pointer.
Fix this by specifying the explicit size `DFU_ALT_BUF_LEN' instead.
Fixes: b86f43de0b ("xilinx: zynqmp: Add support for runtime dfu_alt_info setup")
Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com>
Cc: Michal Simek <michal.simek@amd.com>
Cc: Tom Rini <trini@konsulko.com>
Acked-by: Padmarao Begari <padmarao.begari@amd.com>
Link: https://lore.kernel.org/r/20250407170529.893307-6-vincent.stehle@arm.com
The set_dfu_alt_info() function calls the ALLOC_CACHE_ALIGN_BUFFER()
macro to declare a `buf' variable pointer into an array allocated on the
stack. It then calls the memset() function to clear the useable portion
of the array using the idiomatic expression `sizeof(buf)'.
While this would indeed work fine for an array, in the present case we
end up clearing only the size of a pointer.
Fix this by specifying the explicit size `DFU_ALT_BUF_LEN' instead.
Fixes: c67fecd212 ("ARM: zynq: Enable capsule update for qspi and mmc")
Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com>
Cc: Michal Simek <michal.simek@amd.com>
Cc: Tom Rini <trini@konsulko.com>
Acked-by: Padmarao Begari <padmarao.begari@amd.com>
Link: https://lore.kernel.org/r/20250407170529.893307-5-vincent.stehle@arm.com
The set_dfu_alt_info() function calls the ALLOC_CACHE_ALIGN_BUFFER()
macro to declare a `buf' variable pointer into an array allocated on the
stack. It then calls the memset() function to clear the useable portion
of the array using the idiomatic expression `sizeof(buf)'.
While this would indeed work fine for an array, in the present case we
end up clearing only the size of a pointer.
Fix this by specifying the explicit size `DFU_ALT_BUF_LEN' instead.
Fixes: 064c8978b4 ("arm64: versal: Enable capsule update (SD)")
Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com>
Cc: Michal Simek <michal.simek@amd.com>
Cc: Tom Rini <trini@konsulko.com>
Acked-by: Padmarao Begari <padmarao.begari@amd.com>
Link: https://lore.kernel.org/r/20250407170529.893307-4-vincent.stehle@arm.com
Added extended support for retrieving the PMC muti boot mode
register via the firmware interface, which is preferred when
U-Boot runs in EL2 and cannot directly access PMC registers
via raw reads. Ideally, all secure registers should be accessed
via xilinx_pm_request(). Introduced the secure
zynqmp_pm_get_pmc_multi_boot_reg() call, which uses
xilinx_pm_request() to read the PMC multi boot mode register.
BootROM increments the MultiBoot register (PMC_MULTI_BOOT) read
address offset by 32 KB and retries. For SD and eMMC boot modes,
it can search up to 8191 FAT files for the identification string.
A 13-bit mask (0x1FFF) is applied to PMC_MULTI_BOOT_MASK to obtain
the correct values in BootROM.
Signed-off-by: Prasad Kummari <prasad.kummari@amd.com>
Link: https://lore.kernel.org/r/20250305134845.3182193-1-prasad.kummari@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
Added extended support for retrieving the boot mode register
via the firmware interface, which is preferred when U-Boot
runs in EL2 and cannot directly access CRP registers via raw
reads. Ideally, all secure registers should be accessed via
xilinx_pm_request(). Introduced the secure zynqmp_pm_get_bootmode_reg()
call, which uses xilinx_pm_request() to read the boot mode register.
When CONFIG_ZYNQMP_FIRMWARE is enabled, the secure
zynqmp_pm_get_bootmode_reg() call is used; otherwise,
direct raw reads are performed in the case of mini U-Boot.
Signed-off-by: Prasad Kummari <prasad.kummari@amd.com>
Link: https://lore.kernel.org/r/20250219115301.3661036-1-prasad.kummari@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
Turn anonymous enum TCM_LOCK/TCM_SPLIT into enum tcm_mode {}, set
TCM_LOCK as 0 and TCM_SPLIT as 1 to match LOCK and SPLIT macros in
mach-zynqmp/mp.c, and unify all the functions and their parameters
on this one single enum tcm_mode {} instead of a mix of bool and u8.
No functional change intended.
Signed-off-by: Marek Vasut <marex@denx.de>
Tested-by: Love Kumar <love.kumar@amd.com>
Link: https://lore.kernel.org/r/20250206213039.42756-1-marex@denx.de
Signed-off-by: Michal Simek <michal.simek@amd.com>
Raspberry firmware prepares the FDT blob in memory at an address
that depends on both the memory size and the blob size [1].
After commit ade243a211 ("rpi: passthrough of the firmware provided FDT
blob") this FDT is passed to kernel through fdt_addr environment variable,
handled in set_fdt_addr() function in board file.
When u-boot environment is persistently saved, if a change happens
in loaded FDT (e.g. for a new overlay applied), firmware produces a FDT
address different from the saved one, but u-boot still use the saved
one because set_fdt_addr() function does not overwrite the fdt_addr
variable. So, for example, if there is a script that uses fdt commands for
e.g. manipulate the bootargs, boot hangs with error
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
Removing the fdt_addr variable in saved environment allows to boot.
With this patch set_fdt_addr() function always overwrite fdt_addr value.
[1] https://www.raspberrypi.org/forums//viewtopic.php?f=107&t=134018
Signed-off-by: Mauro Salvini <m.salvini@koansoftware.com>
Cc: Cédric Schieli <cschieli@gmail.com>
Cc: Matthias Brugger <mbrugger@suse.com>
rpi5 firmware sets uart_clk clock-frequency in
the firmware and patches it to the DT, copy it
over when loading a new DT.
Signed-off-by: Bruno Leite <brule@prevas.dk>
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
Tested-by: Peter Robinson <pbrobinson@gmail.com>
As the code is today, we get a warning about "select" statements on
"choice" options not doing anything. However, it also works as intended
because SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR is the default option
within that choice statement. To guard against future regressions, make
the choice statement in common/spl/Kconfig have an explicit default if
MVEBU_SPL_BOOT_DEVICE_MMC.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Stefan Roese <sr@denx.de>
This device uses the SCSI subsystem to interface with SATA devices.
Trying to use the sata command results in an unhandled exception.
This has the side effect of also causing bootflow scan to raise
an unhandled exception when it attempts to probe the SATA
subsystem. Disabling the sata command fixes this issue and does
not remove support for any boot devices.
Signed-off-by: Benjamin Schneider <ben@bens.haus>
Reviewed-by: Stefan Roese <sr@denx.de>
This file was using IS_ENABLED() to test for CONFIG flags but omitted
the CONFIG_ prefix and so did not work as expected.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Testing has shown that loading large initramfs causes data corruption
where the kernel image had been loaded to.
Debian 12 installation using a 17M initramfs boots fine, but the final
system with an initramfs of 27M obscurely fails to boot with bootz
reporting "Bad magic!".
Inspecting kernel_addr_r after this failed boot attempt does show
garbage in place of the expected zimage header.
The problem seems to occur on armada 388 only when sdhci sdma is enabled
in defconfig. Other armada boards such as turris omnia did not enable
the option.
Remove sdhci sdma from defconfig for now as a workaround.
Signed-off-by: Josua Mayer <josua@solid-run.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Enabling ODT is required to suppress reflection of the data signal on
DDR write operation. SolidRun Armada 388 SoM only connects M_ODT[0] even
when both chip-select are used.
Enable ODT[0] for both chip-select during write only.
See also commit d09f199097 ("board: solidrun: clearfog: enable ddr odt0
on write for both chip-select") where this was added to SolidRun
Clearfog board which is using the same System on Module but unlike
Helios-4 without ECC memory.
Signed-off-by: Josua Mayer <josua@solid-run.com>
J722S has hw rng, which can be used by OPTEE.
So remove option to use SW TRNG by OPTEE.
Signed-off-by: Udit Kumar <u-kumar1@ti.com>
Reviewed-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Dhruva Gole <d-gole@ti.com>
With the switch to using GCC 14.2.0 in commit 001bac5f16 ("Dockerfile:
Update to gcc-14.2.0 and clang-18") in CI, we should make buildman match
this.
Signed-off-by: Tom Rini <trini@konsulko.com>
Currently, phytec_get_product_name() function only takes care of PCM
SoM type, however in case of PCL, KSM or KSP SoM type it will return
error:
phytec_get_product_name: Invalid SOM type
Add support for other SoM types as defined in phytec_som_type_str enum
(see phytec_som_detection.h) to get rid of the error.
While at it, also simplify switch case statements by grouping them
together. This makes it more concise and readable.
Signed-off-by: Primoz Fiser <primoz.fiser@norik.com>
Reviewed-by: Daniel Schultz <d.schultz@phytec.de>
