summaryrefslogtreecommitdiff
path: root/board/xilinx
AgeCommit message (Collapse)Author
4 daysarm64: versal-net: Add mmc_get_env_dev() and deduplicate MMC handlingMichal Simek
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. Signed-off-by: Michal Simek <[email protected]> Link: https://patch.msgid.link/7750a79c17146c66adeb83ad6d1bfa78b22ec8fa.1782219202.git.michal.simek@amd.com
4 daysarm64: versal-net: Look up eMMC device in boot_targets_setup()Michal Simek
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. Signed-off-by: Michal Simek <[email protected]> Link: https://patch.msgid.link/bf779dcdd30c900d7614c0fa8382cb3f4cb57c20.1782219202.git.michal.simek@amd.com
4 daysarm64: versal-net: Do not print bootmode from spi_get_env_dev()Michal Simek
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. Signed-off-by: Michal Simek <[email protected]> Link: https://patch.msgid.link/ae257af9d2fe026306b32c647e406450319a3c7a.1782219202.git.michal.simek@amd.com
4 daysarm64: versal-net: Simplify spi_get_bootseq() bootmode switchMichal Simek
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. No functional change. Signed-off-by: Michal Simek <[email protected]> Link: https://patch.msgid.link/191f0f583e2d02c184ea2a2a2fe0ef473ca9fe61.1782219202.git.michal.simek@amd.com
4 daysarm64: versal-net: Deduplicate SPI bootmode handlingMichal Simek
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(). No functional change. Signed-off-by: Michal Simek <[email protected]> Link: https://patch.msgid.link/f98037220a20c441f0ea964f94647948bc035997.1782219202.git.michal.simek@amd.com
4 daysarm64: versal-net: Move bootmode decoding out of board codeMichal Simek
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. Signed-off-by: Michal Simek <[email protected]> Link: https://patch.msgid.link/be67e9c6d0bc36840a46594413886d2003967c64.1782219202.git.michal.simek@amd.com
4 daysarm64: versal-net: Move SoC detection out of board codeMichal Simek
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. Signed-off-by: Michal Simek <[email protected]> Link: https://patch.msgid.link/8757111cb254543d61541fb030d51f62c3c555a8.1782219202.git.michal.simek@amd.com
4 daysarm64: zynqmp: Move board_early_init_r clock setup to mach codeMichal Simek
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. Signed-off-by: Michal Simek <[email protected]> Link: https://patch.msgid.link/2d8f2419fab314b4ff8fd53b846e1dd6151586d3.1782219202.git.michal.simek@amd.com
4 daysarm64: versal-net: Move board_early_init_r clock setup to mach codeMichal Simek
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. Signed-off-by: Michal Simek <[email protected]> Link: https://patch.msgid.link/10dd9f35d03be0402ce13475f20b2cd3761189a6.1782219202.git.michal.simek@amd.com
4 daysarm64: versal: Move board_early_init_r clock setup to mach codeMichal Simek
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. Signed-off-by: Michal Simek <[email protected]> Link: https://patch.msgid.link/2234d746ab5b8240e88b1a629d51f93751ee3b60.1782219202.git.michal.simek@amd.com
4 daysarm64: versal: Move bootmode decoding out of board codeMichal Simek
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. Signed-off-by: Michal Simek <[email protected]> Link: https://patch.msgid.link/d60073feed8da8d3aff9eabee6ab132e0bbd0f8e.1782219202.git.michal.simek@amd.com
4 daysarm64: versal: Decouple multiboot register access from firmwareMichal Simek
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. Signed-off-by: Michal Simek <[email protected]> Link: https://patch.msgid.link/199ef6a1411c54f154fe4a43b5fef166b9927f7a.1782219202.git.michal.simek@amd.com
2026-06-25Kconfig: board: restyleJohan Jonker
Restyle all Kconfigs: Menu entries : no space left Menu attributes: 1 TAB Help text : 1 TAB + 2 spaces Signed-off-by: Johan Jonker <[email protected]> Reviewed-by: Tom Rini <[email protected]>
2026-06-24treewide: move bi_dram[] from bd to gdIlias Apalodimas
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]>
2026-06-08board: xilinx: Add FWU boot index supportPadmarao Begari
Add fwu_plat_get_alt_num() and fwu_plat_get_bootidx() platform callbacks required for FWU multi-bank update on Versal and Versal Gen 2. The boot index is read from the PMC Global PGGS4 register which is populated by PLM with a magic number and boot partition index. Uses firmware IOCTL when CONFIG_ZYNQMP_FIRMWARE is enabled, otherwise falls back to direct MMIO read. Signed-off-by: Padmarao Begari <[email protected]> Signed-off-by: Michal Simek <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2026-06-08board: xilinx: Add capsule and FWU supportPadmarao Begari
Guard configure_capsule_updates() so it is skipped when FWU multi-bank update is enabled. Add set_dfu_alt_info() for FWU multi-bank mode to generate DFU alt info dynamically from NOR flash MTD partitions using fwu_gen_alt_info_from_mtd(). Signed-off-by: Padmarao Begari <[email protected]> Signed-off-by: Michal Simek <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2026-06-08board: zynqmp: Remove hardcoded USB ethernet initializationPranav Sanwal
usb_ether_init() called in board_late_init() when CONFIG_USB_ETHER was enabled without CONFIG_USB_GADGET_DOWNLOAD. This makes USB ethernet gadget a fixed default, with no way to opt out at runtime without a rebuild. Remove the hardcoded call. If USB ethernet gadget functionality is needed, it can be added via the preboot environment variable. Signed-off-by: Pranav Sanwal <[email protected]> Signed-off-by: Michal Simek <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2026-04-27Merge patch series "net: migrate NO_NET out of the networking stack choice"Tom Rini
Quentin Schulz <[email protected]> says: This migrates the net options away from the main Kconfig to net/Kconfig, rename the current NET option to NET_LEGACY to really highlight what it is and hopefully encourage more people to use lwIP, add a new NET menuconfig (but keep NO_NET as an alias to NET=n for now) which then allows us to replace all the "if legacy_stack || lwip_stack" checks with "if net_support" which is easier to read and maintain. The only doubt I have is wrt SYS_RX_ETH_BUFFER which seems to be needed for now even when no network is configured? Likely due to include/net-common.h with PKTBUFSRX? No change in behavior is intended. Only change in defconfig including other defconfigs where NO_NET=y or NET is not set, in which case NO_NET is not set or NET=y should be set in the top defconfig. Similar change required for config fragments. See commit log in patch adding NET menuconfig for details. This was tested based on 70fd0c3bb7c2 ("x86: there is no CONFIG_UBOOT_ROMSIZE_KB_12288"), from within the GitLab CI container trini/u-boot-gitlab-ci-runner:noble-20251013-23Jan2026 and set up similarly as in "build all platforms in a single job" GitLab CI job. #!/usr/bin/env bash set -o pipefail set -eux ARGS="-BvelPEWM --reproducible-builds --step 0" ./tools/buildman/buildman -o ${O} --force-build $ARGS -CE $* ./tools/buildman/buildman -o ${O} $ARGS -Ssd $* O=../build/u-boot/ ../u-boot.sh -b master^..b4/net-kconfig |& tee ../log.txt I can't really decipher the log.txt, but there's no line starting with + which would be an error according to tools/buildman/builder.py help text. Additionally, because I started the script with set -e set and because buildman has an exit code != 0 when it fails to build a board, and I have the summary printed (which is the second buildman call), I believe it means all builds passed. The summary is the following: aarch64: (for 537/537 boards) all +0.0 rodata +0.0 uniphier_v8 : all +1 rodata +1 u-boot: add: 0/0, grow: 1/0 bytes: 1/0 (1) function old new delta data_gz 10640 10641 +1 arm: (for 733/733 boards) all -0.0 rodata -0.0 uniphier_v7 : all -1 rodata -1 u-boot: add: 0/0, grow: 0/-1 bytes: 0/-1 (-1) function old new delta data_gz 11919 11918 -1 opos6uldev : all -3 rodata -3 u-boot: add: 0/0, grow: 0/-1 bytes: 0/-3 (-3) function old new delta data_gz 18778 18775 -3 uniphier_ld4_sld8: all -3 rodata -3 u-boot: add: 0/0, grow: 0/-1 bytes: 0/-3 (-3) function old new delta data_gz 11276 11273 -3 stemmy : all -20 rodata -20 u-boot: add: 0/0, grow: 0/-1 bytes: 0/-20 (-20) function old new delta data_gz 15783 15763 -20 As far as I could tell this data_gz is an automatically generated array when CONFIG_CMD_CONFIG is enabled. It is the compressed .config stored in binary form. Because I'm changing the name of symbols, replacing a menu with a menuconfig, additional text makes it to .config and the "# Networking" section in .config disappears. Here is the diff for the 5 defconfigs listed above, generated with: for f in build/*-m; do diff --unified=0 $f/.config $(dirname $f)/$(basename -a -s '-m' $f)/.config done (-m is the build directory for master, and without the suffix, it's the top commit of this series) """ --- build/opos6uldev-m/.config 2026-04-20 10:53:49.804528526 +0200 +++ build/opos6uldev/.config 2026-04-20 11:03:37.430242767 +0200 @@ -970,4 +969,0 @@ - -# -# Networking -# @@ -975,0 +972 @@ +CONFIG_NET_LEGACY=y --- build/stemmy-m/.config 2026-04-20 11:01:33.653698123 +0200 +++ build/stemmy/.config 2026-04-20 11:04:53.452577311 +0200 @@ -733,4 +732,0 @@ - -# -# Networking -# @@ -738,2 +733,0 @@ -# CONFIG_NET is not set -# CONFIG_NET_LWIP is not set --- build/uniphier_ld4_sld8-m/.config 2026-04-20 11:00:41.605469071 +0200 +++ build/uniphier_ld4_sld8/.config 2026-04-20 11:04:22.226439899 +0200 @@ -997,4 +996,0 @@ - -# -# Networking -# @@ -1002,0 +999 @@ +CONFIG_NET_LEGACY=y --- build/uniphier_v7-m/.config 2026-04-20 10:53:04.019307319 +0200 +++ build/uniphier_v7/.config 2026-04-20 11:03:01.688085486 +0200 @@ -1004,4 +1003,0 @@ - -# -# Networking -# @@ -1009,0 +1006 @@ +CONFIG_NET_LEGACY=y --- build/uniphier_v8-m/.config 2026-04-20 10:43:05.614441175 +0200 +++ build/uniphier_v8/.config 2026-04-20 10:41:03.214852130 +0200 @@ -875,4 +874,0 @@ - -# -# Networking -# @@ -880,0 +877 @@ +CONFIG_NET_LEGACY=y """ This is fine: - Networking menu doesn't exist anymore so "#\n# Networking\n#\n" won't be in .config anymore. - opos6uldev, uniphier_ld4_sld8, uniphier_v7 and uniphier_v8 all have (old) CONFIG_NET enabled, (new) CONFIG_NET will still be set but CONFIG_NET_LEGACY also needs to be defined now to reflect the stack choice (even if default), - stemmy has CONFIG_NO_NET set, which means CONFIG_NET and CONFIG_NET_LWIP are not reachable anymore hence why they don't need to be part of .config, GitLab CI was run on this series (well, not exactly, but it's only changes to the git logs that were made): https://source.denx.de/u-boot/contributors/qschulz/u-boot/-/pipelines/29849 It passes. Link: https://lore.kernel.org/r/[email protected]
2026-04-27simplify NET_LEGACY || NET_LWIP condition with NET conditionQuentin Schulz
Since the move to make NET a menuconfig and NO_NET a synonym of NET=n, when NET is enabled, NET_LEGACY || NET_LWIP is necessarily true, so let's simplify the various checks across the codebase. SPL_NET_LWIP doesn't exist but SPL_NET_LEGACY is an alias for SPL_NET so the proper symbol is still defined in SPL whenever needed. Signed-off-by: Quentin Schulz <[email protected]> Reviewed-by: Simon Glass <[email protected]> Reviewed-by: Peter Robinson <[email protected]> Reviewed-by: Tom Rini <[email protected]>
2026-04-27rename NET to NET_LEGACYQuentin Schulz
Highlight that NET really is the legacy networking stack by renaming the option to NET_LEGACY. This requires us to add an SPL_NET_LEGACY alias to SPL_NET as otherwise CONFIG_IS_ENABLED(NET_LEGACY) will not work for SPL. The "depends on !NET_LWIP" for SPL_NET clearly highlights that it is using the legacy networking app so this seems fine to do. This also has the benefit of removing potential confusion on NET being a specific networking stack instead of "any" network stack. Signed-off-by: Quentin Schulz <[email protected]> Acked-by: Ilias Apalodimas <[email protected]> Reviewed-by: Peter Robinson <[email protected]> Reviewed-by: Tom Rini <[email protected]>
2026-04-23board: xilinx: zynqmp: Register alternate FPGA device for zu63dr_SEMichal Simek
The zu63dr_SE and zu67dr_SE devices share the same silicon ID code 0x046D7093 and cannot be distinguished at runtime. The SOC driver reports zu67dr_SE for this ID, which causes fpga loadb to reject zu63dr_SE bitstreams. Register zu63dr_SE as an alternate FPGA device when zu67dr_SE is detected. This allows users to load either bitstream by selecting the appropriate device number: - Device 0 (zu67dr_SE): fpga loadb 0 ${loadaddr} ${filesize} - Device 1 (zu63dr_SE): fpga loadb 1 ${loadaddr} ${filesize} Signed-off-by: Michal Simek <[email protected]> Link: https://lore.kernel.org/r/591134b1c66701fa14a21fecac4f7a772ddba876.1775558062.git.michal.simek@amd.com
2026-02-17treewide: Clean up DECLARE_GLOBAL_DATA_PTR usagePeng Fan
Remove DECLARE_GLOBAL_DATA_PTR from files where gd is not used, and drop the unnecessary inclusion of asm/global_data.h. Headers should be included directly by the files that need them, rather than indirectly via global_data.h. Reviewed-by: Patrice Chotard <[email protected]> #STMicroelectronics boards and STM32MP1 ram test driver Tested-by: Anshul Dalal <[email protected]> #TI boards Acked-by: Yao Zi <[email protected]> #TH1520 Signed-off-by: Peng Fan <[email protected]>
2026-01-12board: zynqmp: allow env in fat/ext when booting out of qspiNeal Frager
Allow saving the environment in fat and in ext4 when bootmode is qspi. Signed-off-by: Ricardo Salveti <[email protected]> Signed-off-by: Neal Frager <[email protected]> Signed-off-by: Michal Simek <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2026-01-02kbuild: Bump the build system to 6.1Sughosh Ganu
Our last sync with the kernel was 5.1. We are so out of sync now, that tracking the patches and backporting them one by one makes little sense and it's going to take ages. This is an attempt to sync up Makefiles to 6.1. Unfortunately due to sheer amount of patches this is not easy to review, but that's what we decided during a community call for the bump to 5.1, so we are following the same guidelines here. Signed-off-by: Sughosh Ganu <[email protected]> Signed-off-by: Ilias Apalodimas <[email protected]>a #rebased on -next
2025-12-19board: xilinx: add SPL boot device supportPadmarao Begari
Add board_boot_order() function and remove spl_boot_device() function because it is called from weak board_boot_order(). Add support to U-Boot SPL for booting from RAM or SPI, as configured in defconfig. Signed-off-by: Padmarao Begari <[email protected]> Signed-off-by: Michal Simek <[email protected]> Link: https://lore.kernel.org/r/a1f26a9392128309a1affed28b14809845714c21.1764747417.git.michal.simek@amd.com
2025-12-19board: xilinx: Retry FRU EEPROM read on timeoutPadmarao Begari
Wrap the dm_i2c_read() call is used for FRU EEPROM reads in a retry loop, attempting up to EEPROM_FRU_READ_RETRY times if a -ETIMEDOUT error is returned. The loop exits immediately on success or any error other than -ETIMEDOUT. This improves robustness against transient I2C timeouts during FRU detection and decoding. Signed-off-by: Padmarao Begari <[email protected]> Reviewed-by: Matthias Brugger <[email protected]> Signed-off-by: Michal Simek <[email protected]> Link: https://lore.kernel.org/r/9556d204c351d2dc40176a31dab11f789fd1cc7f.1763542221.git.michal.simek@amd.com
2025-12-19board: xilinx: Update ESRT after copying GUIDPadmarao Begari
The EFI System Resource Table (ESRT) is updated after the firmware image GUID is copied to the fw_images structure. This ensures that the ESRT accurately reflects the current firmware resources. Signed-off-by: Padmarao Begari <[email protected]> Signed-off-by: Michal Simek <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2025-10-09board: xilinx: update guid based on metadataPadmarao Begari
The generated GUID applies to all Xilinx platforms but is not specific to any individual board. For FWU multi bank update, use the image UUID (GUID) from the FWU metadata structure rather than embedding a generated GUID into the U-Boot build. Signed-off-by: Padmarao Begari <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Michal Simek <[email protected]>
2025-10-09drivers: firmware: update xilinx_pm_request to support max payloadNaman Trivedi
Currently xilinx_pm_request API supports four u32 payloads. However the legacy SMC format supports five u32 request payloads and extended SMC format supports six u32 request payloads. Add support for the same in xilinx_pm_request API. Also add two dummy arguments to all the callers of xilinx_pm_request. The TF-A always fills seven u32 return payload so add support for the same in xilinx_pm_request API. Signed-off-by: Naman Trivedi <[email protected]> Signed-off-by: Venkatesh Yadav Abbarapu <[email protected]> Acked-by: Senthil Nathan Thangaraj <[email protected]> Signed-off-by: Michal Simek <[email protected]> Link: https://lore.kernel.org/r/5ae6b560741f3ca8b89059c4ebb87acf75b4718e.1756388537.git.michal.simek@amd.com
2025-08-26xilinx: Make XILINX_OF_BOARD_DTB_ADDR depending on OF_BOARD onlyMichal Simek
board_fdt_blob_setup() is guarded by OF_BOARD already that's why make no sense to depend also on OF_SEPARATE. Signed-off-by: Michal Simek <[email protected]> Link: https://lore.kernel.org/r/063b2e618afb05a32d66218f3631a5f23b30ea3e.1753172103.git.michal.simek@amd.com
2025-08-14xilinx: mbv: Disable OF_HAS_PRIOR_STAGEMichal Simek
There is no reason to use OF_BOARD for MBV because reduced DT is used by SPL and full DT is passed via u-boot.img or u-boot.itb. There is no reason to pick up DTB from certain address. Signed-off-by: Michal Simek <[email protected]> Reviewed-by: Leo Yu-Chi Liang <[email protected]>
2025-07-24treewide: Remove empty board_init() function from all boardsSam Protsenko
Commit 86acdce2ba88 ("common: add config for board_init() call") introduced CONFIG_BOARD_INIT option. This option can be disabled for the boards where board_init() function is not needed. Remove empty board_init() calls for all boards where it's possible, and disable CONFIG_BOARD_INIT in all related defconfigs. This cleanup was made semi-automatically using these scripts: [1]. No functional change, but the binary size for the modified boards is reduced a bit. [1] https://github.com/joe-skb7/uboot-convert-scripts/tree/master/remove-board-init Signed-off-by: Sam Protsenko <[email protected]> Tested-by: Adam Ford <[email protected]> #imx8mm_beacon Tested-by: Bryan Brattlof <[email protected]> Acked-by: Peng Fan <[email protected]> #NXP boards
2025-07-08arm64: zynqmp: Enable rng-seed generationMichal Simek
SOM has TPM with RNG in it that's why enable rng-seed generation. Acked-by: Ilias Apalodimas <[email protected]> Signed-off-by: Michal Simek <[email protected]> Link: https://lore.kernel.org/r/0e55eb3eade94e9cd0ffe04da0618aa6b1589f01.1751442246.git.michal.simek@amd.com
2025-06-02include/mtd.h: Cleanup usageTom Rini
There are only a few things found in <mtd.h> today. Go through and audit the C files which include <mtd.h> and remove it when not required. Then, add it to the files which had either missed it or had an indirect inclusion of it. Signed-off-by: Tom Rini <[email protected]>
2025-04-16board: xilinx: Store board info data in data sectionPadmarao Begari
Line 171 in README is describing that before relocation no code should use global variable because global variables are placed to BSS section which is initialized to 0 after relocation. In the case of ZynqMP, where DTB reselection is enabled, the EEPROM is read again after relocation. This prevents the issue from being observed. However, in Versal Gen 2, where DTB reselection is also enabled, the EEPROM is not read after relocation because it is not yet wired in board_init(). This leads to a situation where the code accesses an incorrect memory location, because none is really checking the board_info is valid or not. To fix, move the board_info into the data section and also check whether it is valid or not. Signed-off-by: Padmarao Begari <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Michal Simek <[email protected]>
2025-04-16arm64: zynqmp: Start usb automatically via preboot on KriaVenkatesh Yadav Abbarapu
U-Boot configures the USB config object which enables power for the IP, without this the linux usb driver won't work. So add "usb start" as part of preboot command. Fixes: dd4a82201694 ("arm64: zynqmp: Introduce kria SOM defconfig") Signed-off-by: Venkatesh Yadav Abbarapu <[email protected]> Signed-off-by: Michal Simek <[email protected]> Link: https://lore.kernel.org/r/180c9776b03d57d8218d161924363906ef354394.1744272843.git.michal.simek@amd.com
2025-04-16xilinx: Free memory when variable is saved in boot_targets_setup()Michal Simek
When boot_targets variable is saved there is no reason to keep string in malloc area that's why free it. This change is already done in ZynqMP code. Signed-off-by: Michal Simek <[email protected]> Link: https://lore.kernel.org/r/fa10fc22193a1a23258466056b3d02f7496fccfe.1744270729.git.michal.simek@amd.com
2025-04-16xilinx: versal: remove versal loadpdi commandPrasad Kummari
The source code for the versal loadpdi command and the CONFIG_CMD_VERSAL 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]>
2025-04-16arm64: versal-net: Add PL bit stream load supportPrasad Kummari
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Michal Simek <[email protected]>
2025-04-16arm64: zynqmp: fix dfu alt buffer clearingVincent Stehlé
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: b86f43de0be0 ("xilinx: zynqmp: Add support for runtime dfu_alt_info setup") Signed-off-by: Vincent Stehlé <[email protected]> Cc: Michal Simek <[email protected]> Cc: Tom Rini <[email protected]> Acked-by: Padmarao Begari <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2025-04-16xilinx: zynq: fix dfu alt buffer clearingVincent Stehlé
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: c67fecd2125b ("ARM: zynq: Enable capsule update for qspi and mmc") Signed-off-by: Vincent Stehlé <[email protected]> Cc: Michal Simek <[email protected]> Cc: Tom Rini <[email protected]> Acked-by: Padmarao Begari <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2025-04-16arm64: versal: fix dfu alt buffer clearingVincent Stehlé
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: 064c8978b44f ("arm64: versal: Enable capsule update (SD)") Signed-off-by: Vincent Stehlé <[email protected]> Cc: Michal Simek <[email protected]> Cc: Tom Rini <[email protected]> Acked-by: Padmarao Begari <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2025-04-16xilinx: versal: add firmware access to PMC multi Boot mode registerPrasad Kummari
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Michal Simek <[email protected]>
2025-04-16xilinx: versal: add firmware access to CRP Boot mode registerPrasad Kummari
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Michal Simek <[email protected]>
2025-04-11Merge patch series "Switch to using $(PHASE_) in Makefiles"Tom Rini
Tom Rini <[email protected]> says: This series switches to always using $(PHASE_) in Makefiles when building rather than $(PHASE_) or $(XPL_). It also starts on documenting this part of the build, but as a follow-up we need to rename doc/develop/spl.rst and expand on explaining things a bit. Link: https://lore.kernel.org/r/[email protected]
2025-04-11Kbuild: Always use $(PHASE_)Tom Rini
It is confusing to have both "$(PHASE_)" and "$(XPL_)" be used in our Makefiles as part of the macros to determine when to do something in our Makefiles based on what phase of the build we are in. For consistency, bring this down to a single macro and use "$(PHASE_)" only. Signed-off-by: Tom Rini <[email protected]>
2025-04-11board: remove capsule update support in set_dfu_alt_info()Jonathan Humphreys
Now that capsule update sets the dfu_alt_info environment variable explicitly, there is no need to support it in the set_dfu_alt_info() function. Decouple SET_DFU_ALT_INFO from EFI_CAPSULE_FIRMWARE_FIT and EFI_CAPSULE_FIRMWARE_RAW. For many boards, this was the only use of set_dfu_alt_info() so remove the function entirely. Fixes: a9e6f01a941f ("efi: Define set_dfu_alt_info() for boards with UEFI capsule update enabled") Signed-off-by: Jonathan Humphreys <[email protected]> Signed-off-by: Michal Simek <[email protected]> Reviewed-by: Mattijs Korpershoek <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> # for board/libre-computer/* Reviewed-by: Ilias Apalodimas <[email protected]> Reviewed-by: Wadim Egorov <[email protected]> # for
2025-04-11xilinx: dfu: Fill directly update_info.dfu_stringMichal Simek
Directly fill update_info.dfu_string to prepare platforms to switch from using dfu_alt_info variable to dfu_string which contains description for capsule update when switch is done. Signed-off-by: Michal Simek <[email protected]> Reviewed-by: Mattijs Korpershoek <[email protected]> Acked-by: Ilias Apalodimas <[email protected]>
2025-03-03xilinx: zynq: Guard code around SPL_FS_LOAD_PAYLOAD_NAMEMichal Simek
Guard code around CONFIG_SPL_FS_LOAD_PAYLOAD_NAME usage to avoid compilation failure. Signed-off-by: Michal Simek <[email protected]> Link: https://lore.kernel.org/r/f15a9762494945814b06a71db90ee4db59dd17ed.1738910601.git.michal.simek@amd.com
2025-02-05zynqmp: Save "bootseq" environment variable in decimal formatBenjamin Szőke
In U-Boot, most of mmc releated commands uses decimal value in arguments, like "mmc dev ${bootseq}" or "bootargs=root=/dev/mmcblk${bootseq}p2". In order to improve compatibilities, export "bootseq" number to environment variable in decimal format instead of hex. Signed-off-by: Benjamin Szőke <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Michal Simek <[email protected]>
generated by cgit v1.3.1 (git 2.54.0) at 2026-07-12 03:06:43 +0000