- User Since
- Dec 4 2019, 9:44 AM (133 w, 3 d)
Fri, Jun 10
on systems that don't support S-EL2, SPMC functionality mostly, if not all, resides in EL3
This is an implementation choice. E.g. OP-TEE implements an S-EL1 SPMC without needing SPMC logic at EL3 (beyond the SPMD as FF-A relayer).
If you consider the EL3 FF-A SPMC just recently added, yes most of the SPMC logic resides at EL3.
May 24 2022
Today SEL2 unconditionally saves/restores FP/SIMD/SVE NS context on any SEL2 entry/exit.
I believe it could be optimized the way Soby is describing it by bullets 1,2,3,4.
It is worth noting that when SEL2 is not present (e.g. using the EL3 FF-A SPMC and a SEL1 TOS), the same lazy NS and TA contexts save/restore mechanism can be used by a SEL1 TOS and EL3 doesn't have to bother.
Apr 27 2022
So far this has been a deliberate design choice to avoid saving/restoring SVE state from EL3 mainly for BL31 footprint reasons (and performance if unconditionally done on each and every world switch). The vector register file ranges from 2KB to 8KB with 8 cores, and linearly scales to as many cores in the system (which can be hundreds in a server chipset). Apart from specific cases under discussion (SPM-MM or EL3 FF-A SPM), it is preferable to do this at lower EL e.g. a TOS at SEL1 (or Hafnium at SEL2). Do you have specific reasons why it cannot be done at lower EL?
You may also want to take a look at those options: ENABLE_SVE_FOR_NS and ENABLE_SVE_FOR_SWD
Apr 20 2022
Jan 19 2022
Hi Ross, following changes were merged which help building on Arm and integrating to Yocto. Let us know how it goes. Thanks.
Sep 15 2021
May 5 2021
Is this building natively on arm64 host?
Can you please provide the link to the gcc11 toolchain you use?
AFAIK latest public Arm release of the cross compiler toolchains is 10.2 (https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-a/downloads)
Mar 26 2021
Raghu as you are originator for this ask; can you state more about the requirements as to the why we'd really need to do so?
Mar 22 2021
In particular this is about specifying the offset field in the endpoint memory access descriptor.
The possible envisioned scenario is related to booting TF-A+UEFI and support for authenticated variables.
Feb 15 2021
Sep 22 2020
SMMUv3.2 supports secure Stage-2 translations and that's the feature we intend to enable as a first step.
The IP also supports "nested translations" aka S-EL1 SMMU paravirtualization although we're not looking at this option immediately.
Sep 9 2020
We're considering the SMMUv3.2 support which covers the Secure Stage-2 mappings (https://developer.arm.com/documentation/ihi0070/latest).
This is still in initial investigation phases, but we hope to share design details and early patches by end of Q4'20.
Jun 29 2020
Pursuing Jose's early work through Google's gerrit interface.
We'll provide more design details in the shared SPM doc.
Jun 25 2020
May 1 2020
Apr 9 2020
Jan 14 2020
Nerver mind :) Glad if it works now. Cheers, Olivier.
Jan 13 2020
The log seems to show additional options versus the regular TF-A build:
-march=armv8-a -O2 -pipe -fstack-protector-strong -fno-plt
Jan 9 2020
I installed manjaro-arm on an rpi3 and cloned TF-A commit 0348ee49135c
Jan 8 2020
Unfortunately the option won't show on asm files, but only on C files.
Jan 7 2020
I tried on an arm64 machine (using gcc8.3) but did not reproduce the issue.
Jan 6 2020
I suspect this problem arises because of building natively (although I agree this should normally work).
Dec 24 2019
I'm not too much versed into RAS error handling, so please take my explanation below with care.
I suggest you send the question to the TF-A ML to get more sensible insights.