- TF-A - lists.trustedfirmware.org

Re: [TF-A] Erroneous speculative AT workaround

by Manish Badarkhe

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

4 years, 11 months

1
0
0 0

Re: [TF-A] Linker error on integration branch for FVP with ENABLE_PIE

by Lauren Wehrmeister

Hi, I also came across this issue as I'm trying to create test configurations for compiling BL31/TSP/BL2_AT_EL3 as PIEs, the fix suggested by Alexei worked for BL2_AT_EL3, but it did not work for TSP. I am getting the same error message as Raghu: "./build/fvp/debug/bl31/platform_mp_stack.o: relocation R_AARCH64_ABS32 against `a local symbol' can not be used when making a shared object". Any suggestions? Thanks, Lauren

4 years, 11 months

1
0
0 0

Re: [TF-A] Linker error on integration branch for FVP with ENABLE_PIE

by Olivier Deprez

Hi Raghu, On the toolchain question you would normally use CROSS_COMPILE=aarch64-none-elf- as recommended here: https://trustedfirmware-a.readthedocs.io/en/latest/getting_started/initial-… However this does not seem to be the root cause of the problem you report. I reproduce the build issue, however it's not yet clear to me if this platform_normal_stacks variable should be rather placed in a specific section (.data?), rather than embedded in the code. Tbc. Regards, Olivier. ________________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Alexei Fedorov via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 30 July 2020 14:53 To: tf-a(a)lists.trustedfirmware.org Subject: Re: [TF-A] Linker error on integration branch for FVP with ENABLE_PIE Is it a copy/paste typo? CTX_INCLUDE_EL2)REGS Regards. Alexei ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Raghu Krishnamurthy via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 30 July 2020 02:44 To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] Linker error on integration branch for FVP with ENABLE_PIE When I compile TF-A code on the integration branch with the ENABLE_PIE=1 option for FVP, I get a linker error “./build/fvp/debug/bl31/platform_mp_stack.o: relocation R_AARCH64_ABS32 against `a local symbol' can not be used when making a shared object". It appears to be related to line 62(.word platform_normal_stack) of plat/common/aarch64/platform_mp_stack.S that was introduced by https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4301 . It looks like the linker is having trouble resolving this symbol for which I cant find a use for. If I remove line 62 or set ENABLE_PIE=0, the below command line to compile succeeds. What is the use of line 62 in the file? Seems like it may have some use in other configurations that are not obvious. Or is the issue due to the toolchain I’m using? See gcc version below. Command line I’m using: make CROSS_COMPILE=aarch64-none-linux-gnu- TRUSTED_BOARD_BOOT=1 GENERATE_COT=1 DEBUG=1 LOG_LEVEL=40 MBEDTLS_DIR=../mbed-tls PLAT=fvp ARM_ROTPK_LOCATION=regs CTX_INCLUDE_PAUTH_REGS=1 CTX_INCLUDE_EL2)REGS=1 ARM_ARCH_MINOR=5 ENABLE_PIE=1 BRANCH_PROTECTION=1 FVP_HW_CONFIG_DTS=fdts/fvp-base-gicv3-psci-1t.dts BL33=<path_to_bl33> all fip Compiler version: aarch64-none-linux-gnu-gcc (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) 9.2.1 20191025 Thanks Raghu

4 years, 11 months

2
1
0 0

Re: [TF-A] Linker error on integration branch for FVP with ENABLE_PIE

by Alexei Fedorov

Is it a copy/paste typo? CTX_INCLUDE_EL2)REGS Regards. Alexei ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Raghu Krishnamurthy via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 30 July 2020 02:44 To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] Linker error on integration branch for FVP with ENABLE_PIE When I compile TF-A code on the integration branch with the ENABLE_PIE=1 option for FVP, I get a linker error “./build/fvp/debug/bl31/platform_mp_stack.o: relocation R_AARCH64_ABS32 against `a local symbol' can not be used when making a shared object". It appears to be related to line 62(.word platform_normal_stack) of plat/common/aarch64/platform_mp_stack.S that was introduced by https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4301 . It looks like the linker is having trouble resolving this symbol for which I cant find a use for. If I remove line 62 or set ENABLE_PIE=0, the below command line to compile succeeds. What is the use of line 62 in the file? Seems like it may have some use in other configurations that are not obvious. Or is the issue due to the toolchain I’m using? See gcc version below. Command line I’m using: make CROSS_COMPILE=aarch64-none-linux-gnu- TRUSTED_BOARD_BOOT=1 GENERATE_COT=1 DEBUG=1 LOG_LEVEL=40 MBEDTLS_DIR=../mbed-tls PLAT=fvp ARM_ROTPK_LOCATION=regs CTX_INCLUDE_PAUTH_REGS=1 CTX_INCLUDE_EL2)REGS=1 ARM_ARCH_MINOR=5 ENABLE_PIE=1 BRANCH_PROTECTION=1 FVP_HW_CONFIG_DTS=fdts/fvp-base-gicv3-psci-1t.dts BL33=<path_to_bl33> all fip Compiler version: aarch64-none-linux-gnu-gcc (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) 9.2.1 20191025 Thanks Raghu

4 years, 11 months

1
0
0 0

Linker error on integration branch for FVP with ENABLE_PIE

by raghu.ncstate＠icloud.com

When I compile TF-A code on the integration branch with the ENABLE_PIE=1 option for FVP, I get a linker error "./build/fvp/debug/bl31/platform_mp_stack.o: relocation R_AARCH64_ABS32 against `a local symbol' can not be used when making a shared object". It appears to be related to line 62(.word platform_normal_stack) of plat/common/aarch64/platform_mp_stack.S that was introduced by https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4301 . It looks like the linker is having trouble resolving this symbol for which I cant find a use for. If I remove line 62 or set ENABLE_PIE=0, the below command line to compile succeeds. What is the use of line 62 in the file? Seems like it may have some use in other configurations that are not obvious. Or is the issue due to the toolchain I'm using? See gcc version below. Command line I'm using: make CROSS_COMPILE=aarch64-none-linux-gnu- TRUSTED_BOARD_BOOT=1 GENERATE_COT=1 DEBUG=1 LOG_LEVEL=40 MBEDTLS_DIR=../mbed-tls PLAT=fvp ARM_ROTPK_LOCATION=regs CTX_INCLUDE_PAUTH_REGS=1 CTX_INCLUDE_EL2)REGS=1 ARM_ARCH_MINOR=5 ENABLE_PIE=1 BRANCH_PROTECTION=1 FVP_HW_CONFIG_DTS=fdts/fvp-base-gicv3-psci-1t.dts BL33=<path_to_bl33> all fip Compiler version: aarch64-none-linux-gnu-gcc (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) 9.2.1 20191025 Thanks Raghu

4 years, 11 months

1
0
0 0

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

by Olivier Deprez

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.

4 years, 11 months

2
3
0 0

TF-A Tech Forum Agenda @ Thr 30th July 2020 16:00-1700 BST

by Joanna Farley

Hi All, The next TF-A Tech Forum is scheduled for Thu 30th July 2020 16:00 – 17:00 (BST). A reoccurring meeting invite has been sent out to the subscribers of this TF-A mailing list. If you don’t have this please let me know. Agenda: * Detailed Investigation for support for TRNG (True Random Number Generator) * Presented by Jimmy Brisson * Initial Investigation for support for GIC600AE * Presented by Jimmy Brisson * Optional TF-A Mailing List Topic Discussions If TF-A contributors have anything they wish to present at any future TF-A tech forum please contact me to have that scheduled. Previous sessions, both recording and presentation material can be found on the trustedfirmware.org TF-A Technical meeting webpage: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/ A scheduling tracking page is also available to help track sessions suggested and being prepared: https://developer.trustedfirmware.org/w/tf_a/tf-a-tech-forum-scheduling/ Final decisions on what will be presented will be shared a few days before the next meeting and shared on the TF-A mailing list. Thanks Joanna

4 years, 11 months

1
0
0 0

Re: [TF-A] New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by Sandrine Bailleux

Hello Joanna, Varun, Regarding the idea of looping in Coverity Scan Online in the patch submission process, that is not possible because this free service from Synopsys only allows for a dozen of analyses to be requested per week per open-source project. If we were to request analyses for every patch submission, we would hit the limit very quickly. That is the reason why this is setup to run on the integration branch once per work week day at the moment. I appreciate this is not ideal (as pointed out by both of you) as we get defects reports after patches have been merged but I can't see another way out of this. Regards, Sandrine On 7/27/20 9:08 AM, Joanna Farley via TF-A wrote: > Hi Varun, > > At this time not that I know of which is why we have the solution we have. I'm sure with enough investment of effort something can be done. If we were going to do that though I would personally prefer investigating integrating this tighter into the patch review tooling and report there before patch submitting but there too lies challenges interfacing to the online Coverity server offered as a free service to opensource projects. > > Cheers > > Joanna > > > On 22/07/2020, 18:09, "TF-A on behalf of Varun Wadekar via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: > > Hi, > > Is there a way to create a ticket and assign Coverity flagged issues to the code owner automatically? > > -Varun > > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of scan-admin--- via TF-A > Sent: Wednesday, July 22, 2020 8:17 AM > To: tf-a(a)lists.trustedfirmware.org > Subject: [TF-A] New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware > > External email: Use caution opening links or attachments > > > Hi, > > Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. > > 3 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. > > > New defect(s) Reported-by: Coverity Scan Showing 3 of 3 defect(s) > > > ** CID 360935: Integer handling issues (CONSTANT_EXPRESSION_RESULT) > /drivers/st/scmi-msg/clock.c: 273 in write_rate_desc_array_in_buffer() > > > ________________________________________________________________________________________________________ > *** CID 360935: Integer handling issues (CONSTANT_EXPRESSION_RESULT) > /drivers/st/scmi-msg/clock.c: 273 in write_rate_desc_array_in_buffer() > 267 size_t n; > 268 > 269 ASSERT_SYM_PTR_ALIGN(out); > 270 > 271 for (n = 0U; n < nb_elt; n++) { > 272 out[2 * n] = (uint32_t)rates[n]; > >>> CID 360935: Integer handling issues (CONSTANT_EXPRESSION_RESULT) > >>> "(uint64_t)rates[n] >> 32" is 0 regardless of the values of its operands. This occurs as the operand of assignment. > 273 out[2 * n + 1] = (uint32_t)((uint64_t)rates[n] >> 32); > 274 } > 275 } > 276 > 277 static void scmi_clock_describe_rates(struct scmi_msg *msg) > 278 { > > ** CID 360934: Integer handling issues (BAD_SHIFT) > /drivers/st/scmi-msg/clock.c: 273 in write_rate_desc_array_in_buffer() > > > ________________________________________________________________________________________________________ > *** CID 360934: Integer handling issues (BAD_SHIFT) > /drivers/st/scmi-msg/clock.c: 273 in write_rate_desc_array_in_buffer() > 267 size_t n; > 268 > 269 ASSERT_SYM_PTR_ALIGN(out); > 270 > 271 for (n = 0U; n < nb_elt; n++) { > 272 out[2 * n] = (uint32_t)rates[n]; > >>> CID 360934: Integer handling issues (BAD_SHIFT) > >>> In expression "(uint64_t)rates[n] >> 32", right shifting "rates[n]" by more than 31 bits always yields zero. The shift amount is 32. > 273 out[2 * n + 1] = (uint32_t)((uint64_t)rates[n] >> 32); > 274 } > 275 } > 276 > 277 static void scmi_clock_describe_rates(struct scmi_msg *msg) > 278 { > > ** CID 360933: Integer handling issues (CONSTANT_EXPRESSION_RESULT) > /drivers/st/scmi-msg/clock.c: 191 in scmi_clock_rate_get() > > > ________________________________________________________________________________________________________ > *** CID 360933: Integer handling issues (CONSTANT_EXPRESSION_RESULT) > /drivers/st/scmi-msg/clock.c: 191 in scmi_clock_rate_get() > 185 return; > 186 } > 187 > 188 rate = plat_scmi_clock_get_rate(msg->agent_id, clock_id); > 189 > 190 return_values.rate[0] = (uint32_t)rate; > >>> CID 360933: Integer handling issues (CONSTANT_EXPRESSION_RESULT) > >>> "(uint64_t)rate >> 32" is 0 regardless of the values of its operands. This occurs as the operand of assignment. > 191 return_values.rate[1] = (uint32_t)((uint64_t)rate >> 32); > 192 > 193 scmi_write_response(msg, &return_values, sizeof(return_values)); > 194 } > 195 > 196 static void scmi_clock_rate_set(struct scmi_msg *msg) > > > ________________________________________________________________________________________________________ > To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P… > > -- > 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 >

4 years, 11 months

2
2
0 0

Re: [TF-A] New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by Joanna Farley

Hi Varun, At this time not that I know of which is why we have the solution we have. I'm sure with enough investment of effort something can be done. If we were going to do that though I would personally prefer investigating integrating this tighter into the patch review tooling and report there before patch submitting but there too lies challenges interfacing to the online Coverity server offered as a free service to opensource projects. Cheers Joanna On 22/07/2020, 18:09, "TF-A on behalf of Varun Wadekar via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: Hi, Is there a way to create a ticket and assign Coverity flagged issues to the code owner automatically? -Varun -----Original Message----- From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of scan-admin--- via TF-A Sent: Wednesday, July 22, 2020 8:17 AM To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware External email: Use caution opening links or attachments Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 3 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 3 of 3 defect(s) ** CID 360935: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /drivers/st/scmi-msg/clock.c: 273 in write_rate_desc_array_in_buffer() ________________________________________________________________________________________________________ *** CID 360935: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /drivers/st/scmi-msg/clock.c: 273 in write_rate_desc_array_in_buffer() 267 size_t n; 268 269 ASSERT_SYM_PTR_ALIGN(out); 270 271 for (n = 0U; n < nb_elt; n++) { 272 out[2 * n] = (uint32_t)rates[n]; >>> CID 360935: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "(uint64_t)rates[n] >> 32" is 0 regardless of the values of its operands. This occurs as the operand of assignment. 273 out[2 * n + 1] = (uint32_t)((uint64_t)rates[n] >> 32); 274 } 275 } 276 277 static void scmi_clock_describe_rates(struct scmi_msg *msg) 278 { ** CID 360934: Integer handling issues (BAD_SHIFT) /drivers/st/scmi-msg/clock.c: 273 in write_rate_desc_array_in_buffer() ________________________________________________________________________________________________________ *** CID 360934: Integer handling issues (BAD_SHIFT) /drivers/st/scmi-msg/clock.c: 273 in write_rate_desc_array_in_buffer() 267 size_t n; 268 269 ASSERT_SYM_PTR_ALIGN(out); 270 271 for (n = 0U; n < nb_elt; n++) { 272 out[2 * n] = (uint32_t)rates[n]; >>> CID 360934: Integer handling issues (BAD_SHIFT) >>> In expression "(uint64_t)rates[n] >> 32", right shifting "rates[n]" by more than 31 bits always yields zero. The shift amount is 32. 273 out[2 * n + 1] = (uint32_t)((uint64_t)rates[n] >> 32); 274 } 275 } 276 277 static void scmi_clock_describe_rates(struct scmi_msg *msg) 278 { ** CID 360933: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /drivers/st/scmi-msg/clock.c: 191 in scmi_clock_rate_get() ________________________________________________________________________________________________________ *** CID 360933: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /drivers/st/scmi-msg/clock.c: 191 in scmi_clock_rate_get() 185 return; 186 } 187 188 rate = plat_scmi_clock_get_rate(msg->agent_id, clock_id); 189 190 return_values.rate[0] = (uint32_t)rate; >>> CID 360933: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "(uint64_t)rate >> 32" is 0 regardless of the values of its operands. This occurs as the operand of assignment. 191 return_values.rate[1] = (uint32_t)((uint64_t)rate >> 32); 192 193 scmi_write_response(msg, &return_values, sizeof(return_values)); 194 } 195 196 static void scmi_clock_rate_set(struct scmi_msg *msg) ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P… -- 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

4 years, 11 months

1
0
0 0

cactus and ivy on Tegra194

by Varun Wadekar

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.

4 years, 11 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-A