Hello Olivier,
What are your thoughts on keeping Cactus alive for verifying FF-A tests on pre-8.4 Tegra platforms?
-Varun
-----Original Message----- From: TF-A tf-a-bounces@lists.trustedfirmware.org On Behalf Of Varun Wadekar via TF-A Sent: Tuesday, July 28, 2020 2:27 PM To: Olivier Deprez Olivier.Deprez@arm.com; Matteo Carlini Matteo.Carlini@arm.com Cc: tf-a@lists.trustedfirmware.org Subject: Re: [TF-A] cactus and ivy on Tegra194
External email: Use caution opening links or attachments
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. -- TF-A mailing list TF-A@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a
Hi Varun,
It depends on what you want to achieve. Cactus is just a bare S-EL1 SP / FF-A endpoint, without much intelligence. It is only capable of replying to direct message requests. It is meant to run on top of an SPMC (at S-EL2 or EL3??), or co-reside with a logical SPMC at same S-EL1 exception level. If there's no SPMC neither at S-EL2 nor S-EL1, then Cactus alone cannot handle requests normally meant for an SPMC like Setup and discovery, memory management etc.
Regards, Olivier.
________________________________________ From: Varun Wadekar vwadekar@nvidia.com Sent: 31 July 2020 01:49 To: Varun Wadekar; Olivier Deprez; Matteo Carlini Cc: tf-a@lists.trustedfirmware.org Subject: RE: cactus and ivy on Tegra194
Hello Olivier,
What are your thoughts on keeping Cactus alive for verifying FF-A tests on pre-8.4 Tegra platforms?
-Varun
-----Original Message----- From: TF-A tf-a-bounces@lists.trustedfirmware.org On Behalf Of Varun Wadekar via TF-A Sent: Tuesday, July 28, 2020 2:27 PM To: Olivier Deprez Olivier.Deprez@arm.com; Matteo Carlini Matteo.Carlini@arm.com Cc: tf-a@lists.trustedfirmware.org Subject: Re: [TF-A] cactus and ivy on Tegra194
External email: Use caution opening links or attachments
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. -- TF-A mailing list TF-A@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a
Hi,
I guess, we are going in circles. Let's start from the beginning.
We would like to use Cactus as FF-A endpoint on pre-8.4 platforms where SPMD+SPMC is running in EL3. The intent here is to test the SPMD/SPMC and FF-A interface on pre-8.4 Tegra platforms. From your response, it seems possible but not verified (?). This effort will allow us to identify the gaps with the current implementation.
Makes sense?
-Varun
-----Original Message----- From: Olivier Deprez Olivier.Deprez@arm.com Sent: Friday, July 31, 2020 8:56 AM To: Varun Wadekar vwadekar@nvidia.com Cc: tf-a@lists.trustedfirmware.org; Matteo Carlini Matteo.Carlini@arm.com Subject: Re: cactus and ivy on Tegra194
External email: Use caution opening links or attachments
Hi Varun,
It depends on what you want to achieve. Cactus is just a bare S-EL1 SP / FF-A endpoint, without much intelligence. It is only capable of replying to direct message requests. It is meant to run on top of an SPMC (at S-EL2 or EL3??), or co-reside with a logical SPMC at same S-EL1 exception level. If there's no SPMC neither at S-EL2 nor S-EL1, then Cactus alone cannot handle requests normally meant for an SPMC like Setup and discovery, memory management etc.
Regards, Olivier.
________________________________________ From: Varun Wadekar vwadekar@nvidia.com Sent: 31 July 2020 01:49 To: Varun Wadekar; Olivier Deprez; Matteo Carlini Cc: tf-a@lists.trustedfirmware.org Subject: RE: cactus and ivy on Tegra194
Hello Olivier,
What are your thoughts on keeping Cactus alive for verifying FF-A tests on pre-8.4 Tegra platforms?
-Varun
-----Original Message----- From: TF-A tf-a-bounces@lists.trustedfirmware.org On Behalf Of Varun Wadekar via TF-A Sent: Tuesday, July 28, 2020 2:27 PM To: Olivier Deprez Olivier.Deprez@arm.com; Matteo Carlini Matteo.Carlini@arm.com Cc: tf-a@lists.trustedfirmware.org Subject: Re: [TF-A] cactus and ivy on Tegra194
External email: Use caution opening links or attachments
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. -- TF-A mailing list TF-A@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a
Hi Varun,
"SPMD+SPMC is running in EL3" Is this something Nvidia is willing to develop, validate and maintain in the long run?
In such case, yes, Cactus can probably be re-used but to me that's a small / far-end detail in this picture. Implementing the full fledged SPMC at EL3 is a significant piece of work. But ok to see this originating from partners.
Regards, Olivier.
________________________________________ From: Varun Wadekar vwadekar@nvidia.com Sent: 31 July 2020 18:16 To: Olivier Deprez Cc: tf-a@lists.trustedfirmware.org; Matteo Carlini Subject: RE: cactus and ivy on Tegra194
Hi,
I guess, we are going in circles. Let's start from the beginning.
We would like to use Cactus as FF-A endpoint on pre-8.4 platforms where SPMD+SPMC is running in EL3. The intent here is to test the SPMD/SPMC and FF-A interface on pre-8.4 Tegra platforms. From your response, it seems possible but not verified (?). This effort will allow us to identify the gaps with the current implementation.
Makes sense?
-Varun
-----Original Message----- From: Olivier Deprez Olivier.Deprez@arm.com Sent: Friday, July 31, 2020 8:56 AM To: Varun Wadekar vwadekar@nvidia.com Cc: tf-a@lists.trustedfirmware.org; Matteo Carlini Matteo.Carlini@arm.com Subject: Re: cactus and ivy on Tegra194
External email: Use caution opening links or attachments
Hi Varun,
It depends on what you want to achieve. Cactus is just a bare S-EL1 SP / FF-A endpoint, without much intelligence. It is only capable of replying to direct message requests. It is meant to run on top of an SPMC (at S-EL2 or EL3??), or co-reside with a logical SPMC at same S-EL1 exception level. If there's no SPMC neither at S-EL2 nor S-EL1, then Cactus alone cannot handle requests normally meant for an SPMC like Setup and discovery, memory management etc.
Regards, Olivier.
________________________________________ From: Varun Wadekar vwadekar@nvidia.com Sent: 31 July 2020 01:49 To: Varun Wadekar; Olivier Deprez; Matteo Carlini Cc: tf-a@lists.trustedfirmware.org Subject: RE: cactus and ivy on Tegra194
Hello Olivier,
What are your thoughts on keeping Cactus alive for verifying FF-A tests on pre-8.4 Tegra platforms?
-Varun
-----Original Message----- From: TF-A tf-a-bounces@lists.trustedfirmware.org On Behalf Of Varun Wadekar via TF-A Sent: Tuesday, July 28, 2020 2:27 PM To: Olivier Deprez Olivier.Deprez@arm.com; Matteo Carlini Matteo.Carlini@arm.com Cc: tf-a@lists.trustedfirmware.org Subject: Re: [TF-A] cactus and ivy on Tegra194
External email: Use caution opening links or attachments
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. -- TF-A mailing list TF-A@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a
Hi,
I think, I misspoke. I meant SPMD in EL3 and SPMC in EL1 - the proposed pre-8.4 architecture from the spec. But since we do not support OP-TEE, planning to use Cactus and reuse tests from TF-A.
I understand that this does not allow us to verify the entire path, but it is the best we can do at this point.
-Varun
-----Original Message----- From: Olivier Deprez Olivier.Deprez@arm.com Sent: Friday, July 31, 2020 9:56 AM To: Varun Wadekar vwadekar@nvidia.com Cc: tf-a@lists.trustedfirmware.org; Matteo Carlini Matteo.Carlini@arm.com Subject: Re: cactus and ivy on Tegra194
External email: Use caution opening links or attachments
Hi Varun,
"SPMD+SPMC is running in EL3" Is this something Nvidia is willing to develop, validate and maintain in the long run?
In such case, yes, Cactus can probably be re-used but to me that's a small / far-end detail in this picture. Implementing the full fledged SPMC at EL3 is a significant piece of work. But ok to see this originating from partners.
Regards, Olivier.
________________________________________ From: Varun Wadekar vwadekar@nvidia.com Sent: 31 July 2020 18:16 To: Olivier Deprez Cc: tf-a@lists.trustedfirmware.org; Matteo Carlini Subject: RE: cactus and ivy on Tegra194
Hi,
I guess, we are going in circles. Let's start from the beginning.
We would like to use Cactus as FF-A endpoint on pre-8.4 platforms where SPMD+SPMC is running in EL3. The intent here is to test the SPMD/SPMC and FF-A interface on pre-8.4 Tegra platforms. From your response, it seems possible but not verified (?). This effort will allow us to identify the gaps with the current implementation.
Makes sense?
-Varun
-----Original Message----- From: Olivier Deprez Olivier.Deprez@arm.com Sent: Friday, July 31, 2020 8:56 AM To: Varun Wadekar vwadekar@nvidia.com Cc: tf-a@lists.trustedfirmware.org; Matteo Carlini Matteo.Carlini@arm.com Subject: Re: cactus and ivy on Tegra194
External email: Use caution opening links or attachments
Hi Varun,
It depends on what you want to achieve. Cactus is just a bare S-EL1 SP / FF-A endpoint, without much intelligence. It is only capable of replying to direct message requests. It is meant to run on top of an SPMC (at S-EL2 or EL3??), or co-reside with a logical SPMC at same S-EL1 exception level. If there's no SPMC neither at S-EL2 nor S-EL1, then Cactus alone cannot handle requests normally meant for an SPMC like Setup and discovery, memory management etc.
Regards, Olivier.
________________________________________ From: Varun Wadekar vwadekar@nvidia.com Sent: 31 July 2020 01:49 To: Varun Wadekar; Olivier Deprez; Matteo Carlini Cc: tf-a@lists.trustedfirmware.org Subject: RE: cactus and ivy on Tegra194
Hello Olivier,
What are your thoughts on keeping Cactus alive for verifying FF-A tests on pre-8.4 Tegra platforms?
-Varun
-----Original Message----- From: TF-A tf-a-bounces@lists.trustedfirmware.org On Behalf Of Varun Wadekar via TF-A Sent: Tuesday, July 28, 2020 2:27 PM To: Olivier Deprez Olivier.Deprez@arm.com; Matteo Carlini Matteo.Carlini@arm.com Cc: tf-a@lists.trustedfirmware.org Subject: Re: [TF-A] cactus and ivy on Tegra194
External email: Use caution opening links or attachments
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. -- TF-A mailing list TF-A@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a
Hi,
In the pre-Armv8.4 model from the spec, SP+SPMC conflate in the same execution level as two "logical" entities. Cactus implements the "SP" part, but not the SPMC.
So it means you need to add the "SPMC logic" to Cactus, and that's where the boundary can stretch a lot depending on how much you want to cover the spec.
The approach as you know, has been to implement this SPMC logic within OP-TEE... And there's no plan to backport this anywhere in TF-a-tests. But obviously this can be discussed as a partner contribution.
Regards, Olivier.
________________________________________ From: Varun Wadekar vwadekar@nvidia.com Sent: 31 July 2020 19:09 To: Olivier Deprez Cc: tf-a@lists.trustedfirmware.org; Matteo Carlini Subject: RE: cactus and ivy on Tegra194
Hi,
I think, I misspoke. I meant SPMD in EL3 and SPMC in EL1 - the proposed pre-8.4 architecture from the spec. But since we do not support OP-TEE, planning to use Cactus and reuse tests from TF-A.
I understand that this does not allow us to verify the entire path, but it is the best we can do at this point.
-Varun
-----Original Message----- From: Olivier Deprez Olivier.Deprez@arm.com Sent: Friday, July 31, 2020 9:56 AM To: Varun Wadekar vwadekar@nvidia.com Cc: tf-a@lists.trustedfirmware.org; Matteo Carlini Matteo.Carlini@arm.com Subject: Re: cactus and ivy on Tegra194
External email: Use caution opening links or attachments
Hi Varun,
"SPMD+SPMC is running in EL3" Is this something Nvidia is willing to develop, validate and maintain in the long run?
In such case, yes, Cactus can probably be re-used but to me that's a small / far-end detail in this picture. Implementing the full fledged SPMC at EL3 is a significant piece of work. But ok to see this originating from partners.
Regards, Olivier.
________________________________________ From: Varun Wadekar vwadekar@nvidia.com Sent: 31 July 2020 18:16 To: Olivier Deprez Cc: tf-a@lists.trustedfirmware.org; Matteo Carlini Subject: RE: cactus and ivy on Tegra194
Hi,
I guess, we are going in circles. Let's start from the beginning.
We would like to use Cactus as FF-A endpoint on pre-8.4 platforms where SPMD+SPMC is running in EL3. The intent here is to test the SPMD/SPMC and FF-A interface on pre-8.4 Tegra platforms. From your response, it seems possible but not verified (?). This effort will allow us to identify the gaps with the current implementation.
Makes sense?
-Varun
-----Original Message----- From: Olivier Deprez Olivier.Deprez@arm.com Sent: Friday, July 31, 2020 8:56 AM To: Varun Wadekar vwadekar@nvidia.com Cc: tf-a@lists.trustedfirmware.org; Matteo Carlini Matteo.Carlini@arm.com Subject: Re: cactus and ivy on Tegra194
External email: Use caution opening links or attachments
Hi Varun,
It depends on what you want to achieve. Cactus is just a bare S-EL1 SP / FF-A endpoint, without much intelligence. It is only capable of replying to direct message requests. It is meant to run on top of an SPMC (at S-EL2 or EL3??), or co-reside with a logical SPMC at same S-EL1 exception level. If there's no SPMC neither at S-EL2 nor S-EL1, then Cactus alone cannot handle requests normally meant for an SPMC like Setup and discovery, memory management etc.
Regards, Olivier.
________________________________________ From: Varun Wadekar vwadekar@nvidia.com Sent: 31 July 2020 01:49 To: Varun Wadekar; Olivier Deprez; Matteo Carlini Cc: tf-a@lists.trustedfirmware.org Subject: RE: cactus and ivy on Tegra194
Hello Olivier,
What are your thoughts on keeping Cactus alive for verifying FF-A tests on pre-8.4 Tegra platforms?
-Varun
-----Original Message----- From: TF-A tf-a-bounces@lists.trustedfirmware.org On Behalf Of Varun Wadekar via TF-A Sent: Tuesday, July 28, 2020 2:27 PM To: Olivier Deprez Olivier.Deprez@arm.com; Matteo Carlini Matteo.Carlini@arm.com Cc: tf-a@lists.trustedfirmware.org Subject: Re: [TF-A] cactus and ivy on Tegra194
External email: Use caution opening links or attachments
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. -- TF-A mailing list TF-A@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a
Hi,
I am trying to understand the path forward. Are you suggesting that Cactus would be deprecated in the long run and replaced by OP-TEE? Which also means that tf-a-tests will migrate to OP-TEE at some point?
The tf-a-tests story seems shaky otherwise.
-Varun
-----Original Message----- From: Olivier Deprez Olivier.Deprez@arm.com Sent: Friday, July 31, 2020 10:17 AM To: Varun Wadekar vwadekar@nvidia.com Cc: tf-a@lists.trustedfirmware.org; Matteo Carlini Matteo.Carlini@arm.com Subject: Re: cactus and ivy on Tegra194
External email: Use caution opening links or attachments
Hi,
In the pre-Armv8.4 model from the spec, SP+SPMC conflate in the same execution level as two "logical" entities. Cactus implements the "SP" part, but not the SPMC.
So it means you need to add the "SPMC logic" to Cactus, and that's where the boundary can stretch a lot depending on how much you want to cover the spec.
The approach as you know, has been to implement this SPMC logic within OP-TEE... And there's no plan to backport this anywhere in TF-a-tests. But obviously this can be discussed as a partner contribution.
Regards, Olivier.
________________________________________ From: Varun Wadekar vwadekar@nvidia.com Sent: 31 July 2020 19:09 To: Olivier Deprez Cc: tf-a@lists.trustedfirmware.org; Matteo Carlini Subject: RE: cactus and ivy on Tegra194
Hi,
I think, I misspoke. I meant SPMD in EL3 and SPMC in EL1 - the proposed pre-8.4 architecture from the spec. But since we do not support OP-TEE, planning to use Cactus and reuse tests from TF-A.
I understand that this does not allow us to verify the entire path, but it is the best we can do at this point.
-Varun
-----Original Message----- From: Olivier Deprez Olivier.Deprez@arm.com Sent: Friday, July 31, 2020 9:56 AM To: Varun Wadekar vwadekar@nvidia.com Cc: tf-a@lists.trustedfirmware.org; Matteo Carlini Matteo.Carlini@arm.com Subject: Re: cactus and ivy on Tegra194
External email: Use caution opening links or attachments
Hi Varun,
"SPMD+SPMC is running in EL3" Is this something Nvidia is willing to develop, validate and maintain in the long run?
In such case, yes, Cactus can probably be re-used but to me that's a small / far-end detail in this picture. Implementing the full fledged SPMC at EL3 is a significant piece of work. But ok to see this originating from partners.
Regards, Olivier.
________________________________________ From: Varun Wadekar vwadekar@nvidia.com Sent: 31 July 2020 18:16 To: Olivier Deprez Cc: tf-a@lists.trustedfirmware.org; Matteo Carlini Subject: RE: cactus and ivy on Tegra194
Hi,
I guess, we are going in circles. Let's start from the beginning.
We would like to use Cactus as FF-A endpoint on pre-8.4 platforms where SPMD+SPMC is running in EL3. The intent here is to test the SPMD/SPMC and FF-A interface on pre-8.4 Tegra platforms. From your response, it seems possible but not verified (?). This effort will allow us to identify the gaps with the current implementation.
Makes sense?
-Varun
-----Original Message----- From: Olivier Deprez Olivier.Deprez@arm.com Sent: Friday, July 31, 2020 8:56 AM To: Varun Wadekar vwadekar@nvidia.com Cc: tf-a@lists.trustedfirmware.org; Matteo Carlini Matteo.Carlini@arm.com Subject: Re: cactus and ivy on Tegra194
External email: Use caution opening links or attachments
Hi Varun,
It depends on what you want to achieve. Cactus is just a bare S-EL1 SP / FF-A endpoint, without much intelligence. It is only capable of replying to direct message requests. It is meant to run on top of an SPMC (at S-EL2 or EL3??), or co-reside with a logical SPMC at same S-EL1 exception level. If there's no SPMC neither at S-EL2 nor S-EL1, then Cactus alone cannot handle requests normally meant for an SPMC like Setup and discovery, memory management etc.
Regards, Olivier.
________________________________________ From: Varun Wadekar vwadekar@nvidia.com Sent: 31 July 2020 01:49 To: Varun Wadekar; Olivier Deprez; Matteo Carlini Cc: tf-a@lists.trustedfirmware.org Subject: RE: cactus and ivy on Tegra194
Hello Olivier,
What are your thoughts on keeping Cactus alive for verifying FF-A tests on pre-8.4 Tegra platforms?
-Varun
-----Original Message----- From: TF-A tf-a-bounces@lists.trustedfirmware.org On Behalf Of Varun Wadekar via TF-A Sent: Tuesday, July 28, 2020 2:27 PM To: Olivier Deprez Olivier.Deprez@arm.com; Matteo Carlini Matteo.Carlini@arm.com Cc: tf-a@lists.trustedfirmware.org Subject: Re: [TF-A] cactus and ivy on Tegra194
External email: Use caution opening links or attachments
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. -- TF-A mailing list TF-A@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a
Hi Varun,
Are you suggesting that Cactus would be deprecated in the long run and replaced by OP-TEE? Which also means that tf-a-tests will migrate to OP-TEE at some point?
No that's not the intent. Cactus remains a simple SP test payload on top of Hafnium/SPMC. Booting OP-TEE as a SP is another test case, to make sure we allow the proper system integration of a full featured TOS.
Using OP-TEE as SPMC at S-EL1 is a separate activity, see: https://lists.trustedfirmware.org/pipermail/op-tee/2020-July/000107.html
Regards, Olivier.
________________________________________ From: Varun Wadekar vwadekar@nvidia.com Sent: 31 July 2020 19:25 To: Olivier Deprez Cc: tf-a@lists.trustedfirmware.org; Matteo Carlini Subject: RE: cactus and ivy on Tegra194
Hi,
I am trying to understand the path forward. Are you suggesting that Cactus would be deprecated in the long run and replaced by OP-TEE? Which also means that tf-a-tests will migrate to OP-TEE at some point?
The tf-a-tests story seems shaky otherwise.
-Varun
-----Original Message----- From: Olivier Deprez Olivier.Deprez@arm.com Sent: Friday, July 31, 2020 10:17 AM To: Varun Wadekar vwadekar@nvidia.com Cc: tf-a@lists.trustedfirmware.org; Matteo Carlini Matteo.Carlini@arm.com Subject: Re: cactus and ivy on Tegra194
External email: Use caution opening links or attachments
Hi,
In the pre-Armv8.4 model from the spec, SP+SPMC conflate in the same execution level as two "logical" entities. Cactus implements the "SP" part, but not the SPMC.
So it means you need to add the "SPMC logic" to Cactus, and that's where the boundary can stretch a lot depending on how much you want to cover the spec.
The approach as you know, has been to implement this SPMC logic within OP-TEE... And there's no plan to backport this anywhere in TF-a-tests. But obviously this can be discussed as a partner contribution.
Regards, Olivier.
________________________________________ From: Varun Wadekar vwadekar@nvidia.com Sent: 31 July 2020 19:09 To: Olivier Deprez Cc: tf-a@lists.trustedfirmware.org; Matteo Carlini Subject: RE: cactus and ivy on Tegra194
Hi,
I think, I misspoke. I meant SPMD in EL3 and SPMC in EL1 - the proposed pre-8.4 architecture from the spec. But since we do not support OP-TEE, planning to use Cactus and reuse tests from TF-A.
I understand that this does not allow us to verify the entire path, but it is the best we can do at this point.
-Varun
-----Original Message----- From: Olivier Deprez Olivier.Deprez@arm.com Sent: Friday, July 31, 2020 9:56 AM To: Varun Wadekar vwadekar@nvidia.com Cc: tf-a@lists.trustedfirmware.org; Matteo Carlini Matteo.Carlini@arm.com Subject: Re: cactus and ivy on Tegra194
External email: Use caution opening links or attachments
Hi Varun,
"SPMD+SPMC is running in EL3" Is this something Nvidia is willing to develop, validate and maintain in the long run?
In such case, yes, Cactus can probably be re-used but to me that's a small / far-end detail in this picture. Implementing the full fledged SPMC at EL3 is a significant piece of work. But ok to see this originating from partners.
Regards, Olivier.
________________________________________ From: Varun Wadekar vwadekar@nvidia.com Sent: 31 July 2020 18:16 To: Olivier Deprez Cc: tf-a@lists.trustedfirmware.org; Matteo Carlini Subject: RE: cactus and ivy on Tegra194
Hi,
I guess, we are going in circles. Let's start from the beginning.
We would like to use Cactus as FF-A endpoint on pre-8.4 platforms where SPMD+SPMC is running in EL3. The intent here is to test the SPMD/SPMC and FF-A interface on pre-8.4 Tegra platforms. From your response, it seems possible but not verified (?). This effort will allow us to identify the gaps with the current implementation.
Makes sense?
-Varun
-----Original Message----- From: Olivier Deprez Olivier.Deprez@arm.com Sent: Friday, July 31, 2020 8:56 AM To: Varun Wadekar vwadekar@nvidia.com Cc: tf-a@lists.trustedfirmware.org; Matteo Carlini Matteo.Carlini@arm.com Subject: Re: cactus and ivy on Tegra194
External email: Use caution opening links or attachments
Hi Varun,
It depends on what you want to achieve. Cactus is just a bare S-EL1 SP / FF-A endpoint, without much intelligence. It is only capable of replying to direct message requests. It is meant to run on top of an SPMC (at S-EL2 or EL3??), or co-reside with a logical SPMC at same S-EL1 exception level. If there's no SPMC neither at S-EL2 nor S-EL1, then Cactus alone cannot handle requests normally meant for an SPMC like Setup and discovery, memory management etc.
Regards, Olivier.
________________________________________ From: Varun Wadekar vwadekar@nvidia.com Sent: 31 July 2020 01:49 To: Varun Wadekar; Olivier Deprez; Matteo Carlini Cc: tf-a@lists.trustedfirmware.org Subject: RE: cactus and ivy on Tegra194
Hello Olivier,
What are your thoughts on keeping Cactus alive for verifying FF-A tests on pre-8.4 Tegra platforms?
-Varun
-----Original Message----- From: TF-A tf-a-bounces@lists.trustedfirmware.org On Behalf Of Varun Wadekar via TF-A Sent: Tuesday, July 28, 2020 2:27 PM To: Olivier Deprez Olivier.Deprez@arm.com; Matteo Carlini Matteo.Carlini@arm.com Cc: tf-a@lists.trustedfirmware.org Subject: Re: [TF-A] cactus and ivy on Tegra194
External email: Use caution opening links or attachments
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. -- TF-A mailing list TF-A@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a
tf-a@lists.trustedfirmware.org
-
Olivier Deprez -
Varun Wadekar