Hi,
[OD] The scenario we have in TF-A for pre-Armv8.4, is booting OP-TEE as the SPMC (or in other words a colocated SP+SPMC)., but that's a bare SPMD/SPMC boot case without exercising full fledged FF-A (only few direct message exchanges at the moment).
[VW] I think it makes sense to keep cactus alive for pre-8.4 in tfa-tests repo. Using cactus would help us verify the initial boot expectations without having to port OP-TEE. I guess, successful handling of the FFA_VERSION call would be a good milestone for us.
There is another OSS team you may interact with for the pre-Armv8.4 + FF-A story.
@Matteo may provide pointers?
[VW] Good to know.
-Varun
-----Original Message----- From: Olivier Deprez Olivier.Deprez@arm.com Sent: Tuesday, July 28, 2020 9:09 AM To: Varun Wadekar vwadekar@nvidia.com; Matteo Carlini Matteo.Carlini@arm.com Cc: tf-a@lists.trustedfirmware.org Subject: Re: cactus and ivy on Tegra194
External email: Use caution opening links or attachments
Hi Varun, See inline [OD] Regards, Olivier.
________________________________________ From: Varun Wadekar vwadekar@nvidia.com Sent: 27 July 2020 18:28 To: Olivier Deprez; tf-a@lists.trustedfirmware.org Subject: RE: cactus and ivy on Tegra194
Hi Olivier,
Thanks for your response. Looks like Ivy is still getting built in the tree and the fixes I have made are for the UART console driver - so can still be pushed upstream.
[OD] It is built although it has no usage in any of TF-A CI test AFAIK. It is still using the former SPCI Alpha SPRT which is now deprecated.
I should have mentioned earlier - Tegra194 is based off Arm v8.2. So, we cannot run Hafnium on that platform. The intent is to test the SPMD/SPMC and FF-A interface, before Hafnium comes along.
So, the question is, can you please post instructions for pre-8.4 platforms?
[OD] The scenario we have in TF-A for pre-Armv8.4, is booting OP-TEE as the SPMC (or in other words a colocated SP+SPMC)., but that's a bare SPMD/SPMC boot case without exercising full fledged FF-A (only few direct message exchanges at the moment).
There is another OSS team you may interact with for the pre-Armv8.4 + FF-A story. @Matteo may provide pointers?
The dual-cactus use case is interesting. Can we try that on pre-8.4 platforms too?
[OD] Cactus was re-purposed only for being used as S-EL1 partitions on top of SPMC/Hafnium. So unfortunately no, you cannot immediately re-use this without S-EL2. There is no plan to let Cactus run at secure physical FF-A instance, although maybe that may work with some adaptation.
The dual cactus case, is about instantiating two SPs (or VMs...) on top of Hafnium in the secure side. This is eventually the same binary payload run in two different sandboxes (differentiated by their FF-A id), to which direct message request can be emitted from TFTF to the corresponding FF-A id.
-Varun
-----Original Message----- From: Olivier Deprez Olivier.Deprez@arm.com Sent: Monday, July 27, 2020 1:36 AM To: tf-a@lists.trustedfirmware.org; Varun Wadekar vwadekar@nvidia.com Subject: Re: cactus and ivy on Tegra194
External email: Use caution opening links or attachments
Hi Varun,
Please consider Ivy (and Quark) payloads are remnant from older SPCI specs and must be considered deprecated. We did not clean this in deep to remove the related test code but AFAIK it's just not used anywhere in the test suites (although it may still be built). We may have a plan to upgrade this later when working on S-EL0 partitions on top of Hafnium, but that's not an immediate priority.
Considering Cactus, that's the bare-metal S-EL1 payload you can use in place of a real TOS on top of Hafnium. The intent is to test FF-A ABIs unitarily at secure virtual FF-A instance. TFTF at EL2 exercises the ABI at non-secure physical FF-A instance to communicate with the secure endpoint.
See below the build commands we use for FVP. Hopefully this should help porting to your platform. Notice it needs as well building the SPMC (aka Hafnium in the secure side), which only supports FVP at this moment (and Rpi, qemu...) It's not described here but I can guide you through this as well. I think you can just use a dummy BL32 payload for now, at least to test the build/integration.
If TFTF and TF-A reside in the same top level dir:
TFTF: this builds TFTF and cactus secure partitions make CROSS_COMPILE=aarch64-none-elf- PLAT=fvp TESTS=spm -j8
TF-A: this uses TFTF, and assembles two cactus secure partitions within the FIP make \ CROSS_COMPILE=aarch64-none-elf- \ SPD=spmd \ CTX_INCLUDE_EL2_REGS=1 \ ARM_ARCH_MINOR=4 \ BL33=../tf-a-tests/build/fvp/debug/tftf.bin \ BL32=<path-to-secure-hafnium-bin>/hafnium.bin \ SP_LAYOUT_FILE=../tf-a-tests/build/fvp/debug/sp_layout.json \ PLAT=fvp \ all fip
The tool last FIP tool entries are the two cactus instances: B4B5671E-4A90-4FE1-B81F-FB13DAE1DACB: offset=0x47DA3, size=0xC168, cmdline="--blob" D1582309-F023-47B9-827C-4464F5578FC8: offset=0x53F0B, size=0xC168, cmdline="--blob"
Regards, Olivier.
________________________________________ From: TF-A tf-a-bounces@lists.trustedfirmware.org on behalf of Varun Wadekar via TF-A tf-a@lists.trustedfirmware.org Sent: 27 July 2020 06:46 To: tf-a@lists.trustedfirmware.org Subject: [TF-A] cactus and ivy on Tegra194
Hello,
In order to test the SPM dispatcher from TF-A, we plan to enable 'cactus' and 'ivy' on Tegra194 platforms. I was able to muscle my way through all the compilation issues, but the final payload generation part is not that clear.
Can someone please help me with the steps to generate the final FIP package with all the payloads - TF-A, Cactus, Ivy?
Thanks.