- TF-A - lists.trustedfirmware.org

Re: [TF-A] [Hafnium] Fw: Automate generation of Partition's specific configuration

by Joao Alves

Hi Raghu, Thank you very much for your feedback! It seems like a good idea to automate it and the approach looks fine to me. Is my understanding correct that the generated *dtsi* files will need to be included in the *dts* files once and the hope is if there is a change, the dts files need not change since the dtsi files will be regenerated every time during build? Yes, your understanding is correct. The other way this could be done is that the tool can generate dts files which have nodes that change at build time, which can then be compiled and added as dtb files, added to the FIP. That way fvp_tb_fw_config.dts and fvp_spmc_manifest.dts will remain the same and not have any dependency on a changing dtsi file. I’d prefer that dts files that change frequently like in this case be autogenerated entirely and as separate files. That _seems_ cleaner but may not work out so in practice. I agree with you that the approach you described above would make the whole process a bit cleaner. One way this could be done is by passing the *.pre.dts files (generated after the initial processing from dtc) to the script that are part of the patch. Last time I worked on this, I added the possibility to generate the nodes structure to an already existing dts file. Thus, expanding the previous configuration with the values of the new nodes. However, this work needs further testing. Alternatively, the python package I am using in the script can parse and generate dtb instead of dts. I was thinking to add the option to the dts_gen.py script (maybe rename it as well) to operate over the dtb format. So, making sure that "in-place" changes are working , and adding the option to operate over dtb files should allow for the cleaner approach that you referred. As is and making the referred changes, most of the script's logic should be preserved, so I don't think there will be a lot of changes to the current implementation, which is good. Please let me know if I was not very clear, or if you have any other comments. Also thanks @Gyorgy Szing<mailto:Gyorgy.Szing@arm.com> for the feedback on the current state of the patch, I appreciate it. Let me know if anyone has questions, or any other comments to the scripts and/or current discussion. I will notify once the work progresses. Best regards, João Alves ________________________________ From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> on behalf of Raghu Krishnamurthy via Hafnium <hafnium(a)lists.trustedfirmware.org> Sent: Friday, August 7, 2020 5:54 PM To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org>; hafnium(a)lists.trustedfirmware.org <hafnium(a)lists.trustedfirmware.org> Subject: Re: [Hafnium] [TF-A] Fw: Automate generation of Partition's specific configuration Hi, It seems like a good idea to automate it and the approach looks fine to me. Is my understanding correct that the generated *dtsi* files will need to be included in the *dts* files once and the hope is if there is a change, the dts files need not change since the dtsi files will be regenerated every time during build? The other way this could be done is that the tool can generate dts files which have nodes that change at build time, which can then be compiled and added as dtb files, added to the FIP. That way fvp_tb_fw_config.dts and fvp_spmc_manifest.dts will remain the same and not have any dependency on a changing dtsi file. I’d prefer that dts files that change frequently like in this case be autogenerated entirely and as separate files. That _seems_ cleaner but may not work out so in practice. Thanks Raghu From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Joao Alves via TF-A Sent: Monday, August 3, 2020 10:08 AM To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Fw: Automate generation of Partition's specific configuration Hi all, Forwarding email below as the referred work may be useful/relevant for other parts of the TF-A project as well. Best regards, João Alves _____ From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org <mailto:hafnium-bounces@lists.trustedfirmware.org> > on behalf of Joao Alves via Hafnium <hafnium(a)lists.trustedfirmware.org <mailto:hafnium@lists.trustedfirmware.org> > Sent: Monday, August 3, 2020 5:59 PM To: hafnium(a)lists.trustedfirmware.org <mailto:hafnium@lists.trustedfirmware.org> <hafnium(a)lists.trustedfirmware.org <mailto:hafnium@lists.trustedfirmware.org> > Subject: [Hafnium] Automate generation of Partition's specific configuration Hello all, I have been trying to ease the process of adding a Secure Partition to a system using Secure Hafnium. There is no way to automatically generate SP's specific configuration into TF-A's code-base. Considering FVP as the target platform, we need to manually add partition's specific configuration to files "fvp_tb_fw_config.dts" and "fvp_spmc_manifest.dts" (files held in FVP platform specific folder of TF-A codebase). The following snippet shows the hypervisor node from "fvp_spmc_manifest.dts", for the simple case of having in the system two Cactus Secure Partitions: hypervisor { compatible = "hafnium,hafnium"; vm1 { is_ffa_partition; debug_name = "cactus-primary"; load_address = <0x7000000>; }; vm2 { is_ffa_partition; debug_name = "cactus-secondary"; load_address = <0x7100000>; vcpu_count = <2>; mem_size = <1048576>; }; }; Some of the above properties are available in the partition's manifest, for example "debug_name" and "load_address". If changing one of these values in the partition's manifest or adding another SP, we also need to update the referred files. In order to avoid the burden of having to manually update partition's specific configuration and to make whole system more scalable, I started to write a script that is able to generate a specific node structure and fetch any property value from a any dts file. Then, applied it to fetch/generate SPs specific configuration and include it in aforementioned configuration files. Although it is still a Work In Progress, the work can be found in the patch: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/5150. The implementation is divided between two scripts: * "dts_gen.py" - This is a generic solution for the problem. It can fetch/generate/alter any configuration using dts files. * "sp_dts_gen.py" - Uses the previous command to solve the specific problem regarding SPs specific configuration. Although is still Work In Progress, I am looking to obtain feedback/reviews from anyone that could be interested in using this implementation. The above files contain a lot of comments on how to use them, and also describing the implementation. If the obtained feedback is good, I can work on integrating this in TF-A's build-system. Let me know if anyone has questions. Best regards, João Alves -- Hafnium mailing list Hafnium(a)lists.trustedfirmware.org <mailto:Hafnium@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/hafnium -- Hafnium mailing list Hafnium(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/hafnium

5 years, 9 months

1
0
0 0

Cancelled event with note: TF-A Tech Forum @ Thu 13 Aug 2020 16:00 - 17:00 (BST) (tf-a@lists.trustedfirmware.org)

by Bill Fletcher

This event has been cancelled with this note: " Next TF-A Tech Forum is now scheduled for 26th August" Title: TF-A Tech Forum We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   When: Thu 13 Aug 2020 16:00 – 17:00 United Kingdom Time Calendar: tf-a(a)lists.trustedfirmware.org Who: * Bill Fletcher- creator * marek.bykowski(a)gmail.com * okash.khawaja(a)gmail.com * tf-a(a)lists.trustedfirmware.org Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

5 years, 9 months

1
0
0 0

TF-A Tech Forum CANCELLED @ Thr 13th August 2020 16:00-1700 BST

by Joanna Farley

Apologies everyone, I need to cancel this week’s TF-A Tech Forum as presenters for our next subjects are all on vacation or have yet to complete preparation of the necessary material. As a reminder we have a scheduling page https://developer.trustedfirmware.org/w/tf_a/tf-a-tech-forum-scheduling/ If anybody has subjects they are willing to present please reach out to me so we can find you an appropriate slot. Next TF-A Tech Forum is now scheduled for 26th August. Thanks Joanna

5 years, 9 months

1
0
0 0

Missing properties from cactus dts

by Varun Wadekar

Hello Olivier, Hope you are doing well. As you already know, we are trying to test FF-A, using Cactus, on pre-8.4 Tegra platforms. While doing so, we saw that cactus.dts was missing the following properties 1. maj_ver 2. min_ver 3. spmc_id plat_spm_core_manifest_load() expects these values in the core manifest file. i.e. cactus.dts. What would be the right path forward? Do we add these fields to the dts file? Or modify plat_spmd_manifest.c file? -Varun

5 years, 9 months

2
1
0 0

Re: [TF-A] Fw: Automate generation of Partition's specific configuration

by raghu.ncstate＠icloud.com

Hi, It seems like a good idea to automate it and the approach looks fine to me. Is my understanding correct that the generated *dtsi* files will need to be included in the *dts* files once and the hope is if there is a change, the dts files need not change since the dtsi files will be regenerated every time during build? The other way this could be done is that the tool can generate dts files which have nodes that change at build time, which can then be compiled and added as dtb files, added to the FIP. That way fvp_tb_fw_config.dts and fvp_spmc_manifest.dts will remain the same and not have any dependency on a changing dtsi file. I’d prefer that dts files that change frequently like in this case be autogenerated entirely and as separate files. That _seems_ cleaner but may not work out so in practice. Thanks Raghu From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Joao Alves via TF-A Sent: Monday, August 3, 2020 10:08 AM To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Fw: Automate generation of Partition's specific configuration Hi all, Forwarding email below as the referred work may be useful/relevant for other parts of the TF-A project as well. Best regards, João Alves _____ From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org <mailto:hafnium-bounces@lists.trustedfirmware.org> > on behalf of Joao Alves via Hafnium <hafnium(a)lists.trustedfirmware.org <mailto:hafnium@lists.trustedfirmware.org> > Sent: Monday, August 3, 2020 5:59 PM To: hafnium(a)lists.trustedfirmware.org <mailto:hafnium@lists.trustedfirmware.org> <hafnium(a)lists.trustedfirmware.org <mailto:hafnium@lists.trustedfirmware.org> > Subject: [Hafnium] Automate generation of Partition's specific configuration Hello all, I have been trying to ease the process of adding a Secure Partition to a system using Secure Hafnium. There is no way to automatically generate SP's specific configuration into TF-A's code-base. Considering FVP as the target platform, we need to manually add partition's specific configuration to files "fvp_tb_fw_config.dts" and "fvp_spmc_manifest.dts" (files held in FVP platform specific folder of TF-A codebase). The following snippet shows the hypervisor node from "fvp_spmc_manifest.dts", for the simple case of having in the system two Cactus Secure Partitions: hypervisor { compatible = "hafnium,hafnium"; vm1 { is_ffa_partition; debug_name = "cactus-primary"; load_address = <0x7000000>; }; vm2 { is_ffa_partition; debug_name = "cactus-secondary"; load_address = <0x7100000>; vcpu_count = <2>; mem_size = <1048576>; }; }; Some of the above properties are available in the partition's manifest, for example "debug_name" and "load_address". If changing one of these values in the partition's manifest or adding another SP, we also need to update the referred files. In order to avoid the burden of having to manually update partition's specific configuration and to make whole system more scalable, I started to write a script that is able to generate a specific node structure and fetch any property value from a any dts file. Then, applied it to fetch/generate SPs specific configuration and include it in aforementioned configuration files. Although it is still a Work In Progress, the work can be found in the patch: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/5150. The implementation is divided between two scripts: * "dts_gen.py" - This is a generic solution for the problem. It can fetch/generate/alter any configuration using dts files. * "sp_dts_gen.py" - Uses the previous command to solve the specific problem regarding SPs specific configuration. Although is still Work In Progress, I am looking to obtain feedback/reviews from anyone that could be interested in using this implementation. The above files contain a lot of comments on how to use them, and also describing the implementation. If the obtained feedback is good, I can work on integrating this in TF-A's build-system. Let me know if anyone has questions. Best regards, João Alves -- Hafnium mailing list Hafnium(a)lists.trustedfirmware.org <mailto:Hafnium@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/hafnium

5 years, 9 months

1
0
0 0

[Request for review] Tegra platform changes

by Varun Wadekar

Hi Team, Can you please help review the changes [1] posted for Tegra platforms? These were pushed on 07/09 and I would like to make progress. Several other changes are blocked on this merge. Thanks, Varun [1] https://review.trustedfirmware.org/q/topic:%22tegra-downstream-07092020%22+…

5 years, 9 months

1
0
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 1 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 1 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 361221: (TAINTED_SCALAR) ________________________________________________________________________________________________________ *** CID 361221: (TAINTED_SCALAR) /plat/arm/board/arm_fpga/fpga_bl31_setup.c: 196 in fpga_prepare_dtb() 190 if (err) { 191 ERROR("Could not set command line: %d\n", err); 192 } 193 } 194 } 195 >>> CID 361221: (TAINTED_SCALAR) >>> Passing tainted variable "fdt->size_dt_struct" to a tainted sink. 196 err = fdt_pack(fdt); 197 if (err < 0) { 198 ERROR("Failed to pack Device Tree at %p: error %d\n", fdt, err); 199 } 200 201 clean_dcache_range((uintptr_t)fdt, fdt_blob_size(fdt)); /plat/arm/board/arm_fpga/fpga_bl31_setup.c: 196 in fpga_prepare_dtb() 190 if (err) { 191 ERROR("Could not set command line: %d\n", err); 192 } 193 } 194 } 195 >>> CID 361221: (TAINTED_SCALAR) >>> Passing tainted variable "fdt->size_dt_struct" to a tainted sink. 196 err = fdt_pack(fdt); 197 if (err < 0) { 198 ERROR("Failed to pack Device Tree at %p: error %d\n", fdt, err); 199 } 200 201 clean_dcache_range((uintptr_t)fdt, fdt_blob_size(fdt)); /plat/arm/board/arm_fpga/fpga_bl31_setup.c: 196 in fpga_prepare_dtb() 190 if (err) { 191 ERROR("Could not set command line: %d\n", err); 192 } 193 } 194 } 195 >>> CID 361221: (TAINTED_SCALAR) >>> Passing tainted variable "fdt->size_dt_struct" to a tainted sink. 196 err = fdt_pack(fdt); 197 if (err < 0) { 198 ERROR("Failed to pack Device Tree at %p: error %d\n", fdt, err); 199 } 200 201 clean_dcache_range((uintptr_t)fdt, fdt_blob_size(fdt)); /plat/arm/board/arm_fpga/fpga_bl31_setup.c: 196 in fpga_prepare_dtb() 190 if (err) { 191 ERROR("Could not set command line: %d\n", err); 192 } 193 } 194 } 195 >>> CID 361221: (TAINTED_SCALAR) >>> Passing tainted variable "fdt->size_dt_struct" to a tainted sink. 196 err = fdt_pack(fdt); 197 if (err < 0) { 198 ERROR("Failed to pack Device Tree at %p: error %d\n", fdt, err); 199 } 200 201 clean_dcache_range((uintptr_t)fdt, fdt_blob_size(fdt)); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

5 years, 9 months

1
0
0 0

Re: [TF-A] Erroneous speculative AT workaround

by Varun Wadekar

Hi, I guess I'm late for the party. But I have some questions. Looking at the initial email from Andrew, these two points stood out. --8<-- 1. Whilst looking at the speculative AT workaround in KVM, I compared it against the workaround in TF-A and noticed an inconsistency whereby TF-A **breaks** KVM's workaround. 2. TF-A will also have to be compatible with whatever workaround the EL2 software is using -->8-- Some questions about the unwanted dependency that this fix in TF-A creates. 1. Does KVM team always announce all the dependencies, along with their version numbers, that consumers should use? 2. With the fix in TF-A, are we forcing consumers to upgrade their TF-A blobs? Is this normal practice for consumers? 3. How do we plan to make the upgrade from TF-A side easier? Runtime detection of the feature (similar to the Spectre and Meltdown fixes) comes to mind. -Varun -----Original Message----- From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Manish Badarkhe via TF-A Sent: Thursday, July 30, 2020 10:48 PM To: tf-a(a)lists.trustedfirmware.org Cc: Will Deacon <willdeacon(a)google.com>; android-kvm(a)google.com; Marc Zyngier <mzyngier(a)google.com>; James Morse <James.Morse(a)arm.com>; Andrew Scull <ascull(a)google.com> Subject: Re: [TF-A] Erroneous speculative AT workaround External email: Use caution opening links or attachments Hi All As per discussion over mailing list, we implemented workaround for AT speculative behaviour. If anybody interested they can look into the changes posted here: https://review.trustedfirmware.org/q/topic:%22at_errata_fix%22+(status:open… These changes are currently under review. Thanks Manish Badarkhe On 03/07/2020, 14:43, "TF-A on behalf of Soby Mathew via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: > -----Original Message----- > From: Will Deacon <willdeacon(a)google.com> > Sent: 02 July 2020 15:47 > To: Soby Mathew <Soby.Mathew(a)arm.com> > Cc: Andrew Scull <ascull(a)google.com>; Raghu K > <raghu.ncstate(a)icloud.com>; android-kvm(a)google.com; Marc Zyngier > <mzyngier(a)google.com>; James Morse <James.Morse(a)arm.com>; tf- > a(a)lists.trustedfirmware.org > Subject: Re: [TF-A] Erroneous speculative AT workaround > > On Thu, Jul 02, 2020 at 02:15:47PM +0000, Soby Mathew wrote: > > So the fix as we currently understand would involve the following > > sequence > > : > > > > a. On Entry to EL3, save the incoming SCTLR_EL1.M and TCR_EL1.EPDx > bits and set them (ensure TCR_EL1.EPDx =1 prior to SCTLR_EL1.M =1 using > isb()) > > b. Prior to Exit from EL3, after the target context is restored, restore > the SCTLR_EL1.M and TCR_EL1.EPDx bits. > > > > The above sequence now means that any use of AT instruction targeted > > at lower EL from EL3 that require PTW will fault. So prior to use of > > AT, ensure the PTW are re-enabled and disabled back again after the AT > > instructions. > > > > If the above sequence is agreed upon to resolve the errata, then we > > can work on a patch for the same. I suspect current el1 register save > > and restore sequence in TF-A is a bit unwieldy and we may need to > > analyze all the entry points to EL3 to ensure we cover everything. > > Looks good to me, but there's still one niggle that I don't know how to solve. > If EL2 has been audited not to have any executable AT instructions, it may > not have a software workaround. However, if a secure interrupt is taken > from EL2 to EL3 while EL2 is the middle of a world switch, then there is a > small window where an AT instruction present at EL3 cold be speculatively > executed before you've had a chance to mess with SCTLR_EL1. > > Fun! Maybe it's worth documenting this somewhere? Hi Will, Good point, this effectively means every EL2 software must implement the fix similar to KVM for this workaround to be effective (or else EL3 should also be audited to not to have any executable AT instruction). This needs to be communicated. Since this is crossing TF-A boundary and need wider communication, I can initiate some internal discussion on how to communicate this properly. Best Regards Soby Mathew > > Will -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 9 months

3
4
0 0

Fw: Automate generation of Partition's specific configuration

by Joao Alves

Hi all, Forwarding email below as the referred work may be useful/relevant for other parts of the TF-A project as well. Best regards, João Alves ________________________________ From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> on behalf of Joao Alves via Hafnium <hafnium(a)lists.trustedfirmware.org> Sent: Monday, August 3, 2020 5:59 PM To: hafnium(a)lists.trustedfirmware.org <hafnium(a)lists.trustedfirmware.org> Subject: [Hafnium] Automate generation of Partition's specific configuration Hello all, I have been trying to ease the process of adding a Secure Partition to a system using Secure Hafnium. There is no way to automatically generate SP's specific configuration into TF-A's code-base. Considering FVP as the target platform, we need to manually add partition's specific configuration to files "fvp_tb_fw_config.dts" and "fvp_spmc_manifest.dts" (files held in FVP platform specific folder of TF-A codebase). The following snippet shows the hypervisor node from "fvp_spmc_manifest.dts", for the simple case of having in the system two Cactus Secure Partitions: hypervisor { compatible = "hafnium,hafnium"; vm1 { is_ffa_partition; debug_name = "cactus-primary"; load_address = <0x7000000>; }; vm2 { is_ffa_partition; debug_name = "cactus-secondary"; load_address = <0x7100000>; vcpu_count = <2>; mem_size = <1048576>; }; }; Some of the above properties are available in the partition's manifest, for example "debug_name" and "load_address". If changing one of these values in the partition's manifest or adding another SP, we also need to update the referred files. In order to avoid the burden of having to manually update partition's specific configuration and to make whole system more scalable, I started to write a script that is able to generate a specific node structure and fetch any property value from a any dts file. Then, applied it to fetch/generate SPs specific configuration and include it in aforementioned configuration files. Although it is still a Work In Progress, the work can be found in the patch: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/5150. The implementation is divided between two scripts: * "dts_gen.py" - This is a generic solution for the problem. It can fetch/generate/alter any configuration using dts files. * "sp_dts_gen.py" - Uses the previous command to solve the specific problem regarding SPs specific configuration. Although is still Work In Progress, I am looking to obtain feedback/reviews from anyone that could be interested in using this implementation. The above files contain a lot of comments on how to use them, and also describing the implementation. If the obtained feedback is good, I can work on integrating this in TF-A's build-system. Let me know if anyone has questions. Best regards, João Alves -- Hafnium mailing list Hafnium(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/hafnium

5 years, 9 months

1
0
0 0

Re: [TF-A] cactus and ivy on Tegra194

by Varun Wadekar

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(a)lists.trustedfirmware.org> On Behalf Of Varun Wadekar via TF-A Sent: Tuesday, July 28, 2020 2:27 PM To: Olivier Deprez <Olivier.Deprez(a)arm.com>; Matteo Carlini <Matteo.Carlini(a)arm.com> Cc: tf-a(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(a)arm.com> Sent: Tuesday, July 28, 2020 9:09 AM To: Varun Wadekar <vwadekar(a)nvidia.com>; Matteo Carlini <Matteo.Carlini(a)arm.com> Cc: tf-a(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(a)nvidia.com> Sent: 27 July 2020 18:28 To: Olivier Deprez; tf-a(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(a)arm.com> Sent: Monday, July 27, 2020 1:36 AM To: tf-a(a)lists.trustedfirmware.org; Varun Wadekar <vwadekar(a)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(a)lists.trustedfirmware.org> on behalf of Varun Wadekar via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 27 July 2020 06:46 To: tf-a(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(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 9 months

2
7
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-A