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 <michal.simek@amd.com>
Link: https://patch.msgid.link/10dd9f35d03be0402ce13475f20b2cd3761189a6.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 <michal.simek@amd.com>
Link: https://patch.msgid.link/08e835a183c39de6f666375ac390eee6a8f3f12e.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 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 <michal.simek@amd.com>
Link: https://patch.msgid.link/2234d746ab5b8240e88b1a629d51f93751ee3b60.1782219202.git.michal.simek@amd.com
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 <michal.simek@amd.com>
Link: https://patch.msgid.link/d60073feed8da8d3aff9eabee6ab132e0bbd0f8e.1782219202.git.michal.simek@amd.com
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 <michal.simek@amd.com>
Link: https://patch.msgid.link/199ef6a1411c54f154fe4a43b5fef166b9927f7a.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 <michal.simek@amd.com>
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 <michal.simek@amd.com>
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 <michal.simek@amd.com>
Link: https://patch.msgid.link/1bf5b1d49abb271c2c5e7135837b740179b95553.1782219202.git.michal.simek@amd.com
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"
Fixes: fa2f0c97af ("soc: zynqmp: Add the IDcode for TEG variant")
Signed-off-by: Padmarao Begari <padmarao.begari@amd.com>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://patch.msgid.link/20260623150943.2662500-1-padmarao.begari@amd.com
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
}
===
Signed-off-by: Erich E. Hoover <erich.e.hoover@gmail.com>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/20260612150454.2194375-1-erich.e.hoover@gmail.com
AM011 Versal ACAP TRM, Table 43, defines:
- 0x006_0000_0000 - 0x007_FFFF_FFFF PCIe region 1
- 0x008_0000_0000 - 0x00F_FFFF_FFFF DDR controller 0 region 1
- 0x040_0000_0000 - 0x04F_FFFF_FFFF HBM0
- 0x050_0000_0000 - 0x05F_FFFF_FFFF HBM1
- 0x060_0000_0000 - 0x06F_FFFF_FFFF HBM2
- 0x070_0000_0000 - 0x07F_FFFF_FFFF HBM3
- 0x080_0000_0000 - 0x0BF_FFFF_FFFF PCIe region 2
- 0x0C0_0000_0000 - 0x0FF_FFFF_FFFF DDR controller 0 region 2
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.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/6fad36f9e7abdfee2fd29943f3a5b63d1421eaf9.1781179823.git.michal.simek@amd.com
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".
Signed-off-by: Suraj Kakade <suraj.hanumantkakade@amd.com>
Link: https://lore.kernel.org/r/20260610110557.2183203-1-suraj.hanumantkakade@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
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.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/837e21582e886f1be9f95901109745ac5a8b2a25.1780991287.git.michal.simek@amd.com
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.
Link: https://lore.kernel.org/r/20260705193251.2190705-1-sjg@chromium.org
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.
Signed-off-by: Simon Glass <sjg@chromium.org>
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.
Signed-off-by: Simon Glass <sjg@chromium.org>
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.
Signed-off-by: Simon Glass <sjg@chromium.org>
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>
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.
Signed-off-by: Simon Glass <sjg@chromium.org>
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.
Signed-off-by: Simon Glass <sjg@chromium.org>
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.
Signed-off-by: Simon Glass <sjg@chromium.org>
patman is now just a stub, so drop its requirements file and its
'patman test' run from the Azure and GitLab pipelines.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
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>
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>
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>
This reverts commit b42c67188c ("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>
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: 906ee6785b ("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>
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>
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>
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>
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>
Fix the incorrect use of 'your' instead of 'you are' and reflow the text
around it.
Fixes: af9e6ad4ab ("board_f: Add new function to allow runtime DTB selection")
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Michal Simek
Padmarao BegariandMichal Simek
Danish Ahmad RosdiandMichal Simek
Pranav TilakandMichal Simek
Marek VasutandMichal Simek
Erich E. HooverandMichal Simek
Suraj KakadeandMichal Simek
Rob Herring (Arm)andMichal Simek
Shaikh Mohammed SuhanandMichal Simek
Trapti Damodar BalgiandMichal Simek
Tom Rini
Simon GlassandTom Rini
Tanmay KathpaliaandPeng Fan
Ye LiandPeng Fan
Vincent JardinandPeng Fan
Aristo ChenandPeng Fan
Ilias ApalodimasandTom Rini
Neil ArmstrongandTom Rini
Andrew GoodbodyandTom Rini