versal: Enhance board support for AMD/Xilinx Versal ACAP and Versal NET#857
versal: Enhance board support for AMD/Xilinx Versal ACAP and Versal NET#857joft-mle wants to merge 13 commits intoOP-TEE:masterfrom
Conversation
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>
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>
The optee_os/ clean target already removes all tee* binaries. Signed-off-by: Joachim Foerster <joachim.foerster@missinglinkelectronics.com>
Signed-off-by: Joachim Foerster <joachim.foerster@missinglinkelectronics.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>
…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>
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>
… 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>
|
@jenswi-linaro |
|
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: |
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>
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>
- 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>
Signed-off-by: Joachim Foerster <joachim.foerster@missinglinkelectronics.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>
91386c3 to
52e54fb
Compare
|
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 |
|
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. |
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
|
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.