versal: Enhance board support for AMD/Xilinx Versal ACAP and Versal NET#857
Open
joft-mle wants to merge 13 commits intoOP-TEE:masterfrom
Open
versal: Enhance board support for AMD/Xilinx Versal ACAP and Versal NET#857joft-mle wants to merge 13 commits intoOP-TEE:masterfrom
joft-mle wants to merge 13 commits intoOP-TEE:masterfrom
Conversation
This was referenced Mar 6, 2026
Contributor
|
@jenswi-linaro |
Contributor
|
I had to do the following changes to boot over jtag
could you have a look and retest please OPTEE boot: xtest execution: OP-TEE tree: |
joft-mle
force-pushed
the
mle/versal-net-upgrade
branch
from
91386c3 to
52e54fb
Compare
Author
|
Hi @ldts,
Yes, I can reproduce this when enabling ccache (always had it disabled). The problem is caused by the way those However, when I don't know what the preferred style would be here to solve this issue. In the 2026/03/16 force-push I've used the following trick to remove those quotes, e.g. to call |
Author
|
Hi @ldts,
Right, when accessing a non-existent value of a TCL array (environment variable So I've added an appropriate check for its existence in the 2026/03/16 force-push. |
Author
As you already pointed out here, this is occurring due to missing support to read the DNA from the Versal chip to derive the HUK from, which means missing XilNVM module in (default) PLM Firmware; for completeness and how to produce a PLM Firmware image including this and other required features, see my reply. I'm not sure why
|
joft-mle
force-pushed
the
mle/versal-net-upgrade
branch
from
52e54fb to
67a3d75
Compare
Author
|
Hi @ldts, @jenswi-linaro, @nathan-menhorn, in today's 2026/04/14 force-push the following issues have been addressed:
|
|
@joft-mle |
Simply assume that a typical Versal NET board has exactly one of the two built-in UART peripherals enabled and that this UART does appear as Linux device ttyAMA0, which is the default in buildroot. Signed-off-by: Joachim Foerster <joachim.foerster@missinglinkelectronics.com> Reviewed-by: Nathan Menhorn <nathan.menhorn@amd.com> Tested-by: Nathan Menhorn <nathan.menhorn@amd.com> Reviewed-by: Lucas Kiker <lucas.kiker@amd.com>
To whichever package the symbol refers to? There is no reason for disabling any (compile) tests. Signed-off-by: Joachim Foerster <joachim.foerster@missinglinkelectronics.com> Reviewed-by: Nathan Menhorn <nathan.menhorn@amd.com> Tested-by: Nathan Menhorn <nathan.menhorn@amd.com> Reviewed-by: Lucas Kiker <lucas.kiker@amd.com>
The optee_os/ clean target already removes all tee* binaries. Signed-off-by: Joachim Foerster <joachim.foerster@missinglinkelectronics.com> Reviewed-by: Nathan Menhorn <nathan.menhorn@amd.com> Tested-by: Nathan Menhorn <nathan.menhorn@amd.com> Reviewed-by: Lucas Kiker <lucas.kiker@amd.com>
Signed-off-by: Joachim Foerster <joachim.foerster@missinglinkelectronics.com> Reviewed-by: Nathan Menhorn <nathan.menhorn@amd.com> Tested-by: Nathan Menhorn <nathan.menhorn@amd.com> Reviewed-by: Lucas Kiker <lucas.kiker@amd.com>
This commit comprises the following changes next to merging: - Use a dedicated U-Boot config snippet (kconfigs/u-boot_versal*.conf) instead of (mis-)using the Linux config snippet (kconfigs/versal.conf) (at least in former versal_net.mk). This enables TEE support in U-Boot on Versal now, too. - For devicetree built into U-Boot use xilinx-versal-virt for Versal, like xilinx-versal-net-virt for Versal NET, since it gets overridden at runtime by dedicated devicetree anyway (see .bif). - Target image* always concern all images, including fitimage. Signed-off-by: Joachim Foerster <joachim.foerster@missinglinkelectronics.com> Reviewed-by: Nathan Menhorn <nathan.menhorn@amd.com> Tested-by: Nathan Menhorn <nathan.menhorn@amd.com> Reviewed-by: Lucas Kiker <lucas.kiker@amd.com>
…E OS, only
VERSAL_UART1= : PS UART0 = primary, PS UART1 = secondary
VERSAL_UART1=y : PS UART1 = primary, PS UART0 = secondary
| VERSAL_UART2ND_OPTEE= | VERSAL_UART2ND_OPTEE=y |
---------------|-----------------------|------------------------|
VERSAL_UART1= | (1) | (2) |
VERSAL_UART1=y | (3) | (4) |
(1) ATF, OP-TEE OS on PS UART0
(2) ATF on PS UART0, OP-TEE OS on PS UART1
(3) ATF, OP-TEE OS on PS UART1
(4) ATF on PS UART1, OP-TEE OS on PS UART0
Signed-off-by: Joachim Foerster <joachim.foerster@missinglinkelectronics.com>
Reviewed-by: Nathan Menhorn <nathan.menhorn@amd.com>
Tested-by: Nathan Menhorn <nathan.menhorn@amd.com>
Reviewed-by: Lucas Kiker <lucas.kiker@amd.com>
At least for platform "versal". Associated boards have their devicetrees generated by PetaLinux, for example and as such typically don't have any such memory reservations by default. Signed-off-by: Joachim Foerster <joachim.foerster@missinglinkelectronics.com> Reviewed-by: Nathan Menhorn <nathan.menhorn@amd.com> Tested-by: Nathan Menhorn <nathan.menhorn@amd.com> Reviewed-by: Lucas Kiker <lucas.kiker@amd.com>
… NET with Versal
This commit combines the following core changes for Versal and Versal NET:
- .bif and .its files get generated from templates, by replacing certain
"variables" (%VAR%) during the build process, or even deleting certain
"partitions" (== binaries included in BOOT.BIN).
- To get hold of a .pdi file and .dtb file, the build process now allows
the user to either specify a PetaLinux project/BSP directory (BSP_PATH) or
a .pdi file (PDI_PATH) and a .dtb file (DTB_PATH) directly.
- To replace the PLM firmware and/or PSM firmware in the selected .pdi file
by custom .elf files, the user may provide paths to them (PLM_PATH and/or
PSM_PATH).
- By default the U-Boot FIT image is included in BOOT.BIN. To not do that
the user may set IUB_BIF_PATH=n (magic value "n").
- U-Boot configuration is modified to automatically boot the included
U-Boot FIT image, if it is included in BOOT.BIN.
For Versal, this commit does the following changes:
- Like for Versal NET, the U-Boot FIT image is by default included in the
BOOT.BIN to avoid handling extra boot files, an SDcard etc. when booting a
board.
For Versal NET, this commit does the following changes:
- Like for Versal, the Linux kernel, device tree and the OP-TEE related
device tree overlay "versal-optee.dtbo" are now also included in the U-Boot
FIT image, instead of just the ramdisk (rootfs).
- Where needed, the position of components to be loaded in memory are
adjusted to adhere to the following map - as indicated by various consulted
sources:
- 0x22200000 - 64M - OP-TEE (system and optionally static shared memory)
- 0x26200000 - 1M - ATF
- 0x26300000 - 14M - U-Boot
- 0x27100000 - 512k - Device Tree (and optionally Overlays)
- 0x27180000 - 512k - U-Boot boot script
- 0x27200000 - 398M - Linux kernel or U-Boot image (comprising kernel,
dtbs, ramdisk)
The U-Boot FIT image is designed so that the actual Linux kernel image
and Device Tree object(s) are loaded to 0x40200000 and 0x40000000, since
the area up until 0x10000000 (first 256M) can be special on Versal NET
boards.
Signed-off-by: Joachim Foerster <joachim.foerster@missinglinkelectronics.com>
Reviewed-by: Nathan Menhorn <nathan.menhorn@amd.com>
Tested-by: Nathan Menhorn <nathan.menhorn@amd.com>
Reviewed-by: Lucas Kiker <lucas.kiker@amd.com>
At least with PLM firmware releases v2024.1 and v2024.2 and when referencing an ELF file with proper attributes in the .bif file, the PLM firmware is able to provide the BL32 entry point address to TF-A and no workarounds involving hard-coded addresses in TF-A (BL32_BASE, VERSAL_BL32_MEM_BASE; see [1], [2]) are needed anymore. This commit obviously assumes that the above is true for even newer PLM firmware releases, too. However, the OP-TEE OS tee.elf file does by itself not suffice for that purpose since OP-TEE OS entry code (entry_a64.S [3]) depends on a struct boot_embdata [4] placed right at symbol __data_end. The script gen_tee_bin.py [5] does this placement while crafting tee-raw.bin (and similarly tee.bin) from tee.elf. Thus we wrap the tee-raw.bin file in ELF format with a single .text section and the appropriate entry point. [1] ldts/arm-trusted-firmware@011bc68 [2] https://github.com/Xilinx/arm-trusted-firmware/blob/e4a37b000fb9a708112da1e06da0e8fad939dc86/plat/xilinx/versal/bl31_versal_setup.c#L130 [3] https://github.com/OP-TEE/optee_os/blob/3322f1326f141ef3f41ac7a1c1e08ca23a869fd4/core/arch/arm/kernel/entry_a64.S#L222 [4] https://github.com/OP-TEE/optee_os/blob/3322f1326f141ef3f41ac7a1c1e08ca23a869fd4/core/include/kernel/boot.h#L35 [5] https://github.com/OP-TEE/optee_os/blob/master/scripts/gen_tee_bin.py Signed-off-by: Joachim Foerster <joachim.foerster@missinglinkelectronics.com> Reviewed-by: Nathan Menhorn <nathan.menhorn@amd.com> Tested-by: Nathan Menhorn <nathan.menhorn@amd.com> Reviewed-by: Lucas Kiker <lucas.kiker@amd.com>
Using the "Build from Git" flow present in AMD/Xilinx embeddedsw repository. If BSP_PATH is used, by default PLM_PATH and PSM_PATH are however still automatically set to firmware binaries found in this BSP/PetaLinux project directory! To force building firmware binaries from scratch in any case, whether using BSP_PATH or not, use PLM_PATH=generate and PSM_PATH=generate on the "make" command line, next to CROSS_COMPILE_FIRMWARE=$XILINX_VIVADO/gnu/microblaze/lin/bin/mb-gcc or CROSS_COMPILE_FIRMWARE=$PETALINUX/components/xsct/gnu/microblaze/lin/bin/mb-gcc to point to AMD/Xilinx MicroBlaze toolchain, for example as part of the Vitis/Vivado or the PetaLinux installation. As before, to explicitly skip including any reference to a firmware binary in the generated .bif file, use PLM_PATH= and PSM_PATH= explicitly. Note that not including one in the .bif file means that bootgen takes the firmware binaries from the .pdi file and puts them into the newly generated BOOT.BIN. Signed-off-by: Joachim Foerster <joachim.foerster@missinglinkelectronics.com> Reviewed-by: Nathan Menhorn <nathan.menhorn@amd.com> Tested-by: Nathan Menhorn <nathan.menhorn@amd.com> Reviewed-by: Lucas Kiker <lucas.kiker@amd.com>
- Use xsdb instead of xsct. - Offer option -i to enter interactive mode after initialing loading of BOOT.BIN. - Offer option -u to specify hw_server URL (tcp:<host>:<port>) of an already running hw_server instance, instead of starting a new, local hw_server (when executing "connect" without "-url ..."). - Advertise custom commands in interactive mode. Signed-off-by: Joachim Foerster <joachim.foerster@missinglinkelectronics.com> Reviewed-by: Nathan Menhorn <nathan.menhorn@amd.com> Tested-by: Nathan Menhorn <nathan.menhorn@amd.com> Reviewed-by: Lucas Kiker <lucas.kiker@amd.com>
Signed-off-by: Joachim Foerster <joachim.foerster@missinglinkelectronics.com> Reviewed-by: Nathan Menhorn <nathan.menhorn@amd.com> Tested-by: Nathan Menhorn <nathan.menhorn@amd.com> Reviewed-by: Lucas Kiker <lucas.kiker@amd.com>
- A PetaLinux BSP (or project) (BSP_PATH) is identified by its
characteristic .petalinux subdirectory.
- Both flavors pick up a local BSP subdirectory ("versal-bsp" /
"versal-net-bsp").
- Both flabors automatically pick up a "design.pdi" and "design.dtb" from
such a local subdirectory (PDI_PATH and DTB_PATH), if that subdirectory is
not a PetaLinux BSP.
Signed-off-by: Joachim Foerster <joachim.foerster@missinglinkelectronics.com>
Reviewed-by: Nathan Menhorn <nathan.menhorn@amd.com>
Tested-by: Nathan Menhorn <nathan.menhorn@amd.com>
Reviewed-by: Lucas Kiker <lucas.kiker@amd.com>
joft-mle
force-pushed
the
mle/versal-net-upgrade
branch
from
67a3d75 to
70c7040
Compare
Author
|
Hi @ldts, @jenswi-linaro, @nathan-menhorn, @lucaskiker-amd, in today's 2026/04/15 force-push the following issues have been addressed:
|
| -Ttext $(shell cat $(OPTEE_OS_RAWBIN_ELF).load) \ | ||
| -e $(shell cat $(OPTEE_OS_RAWBIN_ELF).load) \ | ||
| $< -o $@ | ||
| .PHONY: $(OPTEE_OS_RAWBIN_OBJ) $(OPTEE_OS_RAWBIN_ELF).load $(OPTEE_OS_RAWBIN_ELF) |
Contributor
There was a problem hiding this comment.
If this fixes an issue, it means that you're missing relevant dependencies.
.PHONY is only supposed to be used on targets that don't have a matching filename.
Author
There was a problem hiding this comment.
Hmmm, I'd say $(OPTEE_OS_RAWBIN_OBJ) correctly depends on $(OPTEE_OS_RAWBIN), which correctly depends on optee-os-common, which is .PHONY - and which actually produces $(OPTEE_OS_RAWBIN) . However, the "outer" make, which is processing versal.mk is not "aware" (?) of the latter directly, since that production is done by the "inner" make triggered by optee-os-common commands. Same is true for the other two OPTEE_OS_RAWBIN_ELF* targets. Without making them .PHONY, the effect is that they are not reliably rebuilt despite optee-os-common being successfully rebuilt every time. To me it looks like "undetermined behavior".
Dependency chains:
bootimage=>$(BIF_PATH)=>$(OPTEE_OS_RAWBIN_ELF)=>$(OPTEE_OS_RAWBIN_OBJ)=>$(OPTEE_OS_RAWBIN)=>optee-os-common(is.PHONY)$(OPTEE_OS_RAWBIN_ELF).load=>$(OPTEE_OS_ELF)=>optee-os-common(is.PHONY)
bootimage=>optee-os=>optee-os-common(is.PHONY)
I suspect that the whole issue might have something to do with the fact that optee-os-common is .PHONY itself and/or with the "inner" vs. "outer" make situation??
Contributor
There was a problem hiding this comment.
I think the problem stems from the outer make not knowing what the inner make is doing (producing). You could move these transformations into core/arch/arm/plat-versal2/link.mk. core/arch/arm/plat-imx/link.mk does something similar.
Another option is to add all these commands to the $(BIF_PATH) target below since you don't seem to mind doing it unconditionally.
In both cases, you need to let the $(BIF_PATH) target depend on optee-os.
Contributor
|
@ldts, do you want to take a look at this? Or should I do a quick scan to see if anything stands out? |
Contributor
|
I did test it some weeks ago and it was functional after the fixes. In fact the new implementation looked better than what I originally provided so I would pick it up. I can retest it all again in a few days (ie by friday) |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This pull request is build on top of previous work by @jcorbier & Co in merged PR #815 .
This pull request extends the existing AMD/Xilinx Versal ACAP and NET build instructions regarding the following aspects:
This pull request depends on and shall be merged after optee_os.git PR #7726 has been merged.
See optee_docs.git PR #280 for updated documentation.