I want to find a way to clean a memory region in TF-A firmware.

Can you elaborate what you mean by "clean" ?
From the description it seems to be a simple memset, in which case data may remain in caches.
Does the requested operation need to complete to memory e.g. involving cache clean?

fix submitted

Thanks for your reply. Looks like there is a fix under works:

Hi,
From the logs I understand BL31 is started by U-Boot SPL rather than TF-A's BL1/BL2, correct?
Would it be possible to gather more verbose logs (build with DEBUG=1 LOG_LEVEL=50) ?
Can you share the TF-A command line used to build this platform?
In particular what's the state of EL3_EXCEPTION_HANDLING, SPD, SPMD_SPM_AT_SEL2 toggles?
Thanks, Olivier.

Hi,

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.

Hi,
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.

Hi Peter,
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
https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/docs/getting_started/build-options.rst#n409
Regards,
Olivier.

Hi Ross, following changes were merged which help building on Arm and integrating to Yocto. Let us know how it goes. Thanks.

Merged https://review.trustedfirmware.org/c/hafnium/hafnium/+/10759

Ok thanks.

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)

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?

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.

https://review.trustedfirmware.org/c/hafnium/hafnium/+/8243

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.

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.

Pursuing Jose's early work through Google's gerrit interface.
We'll provide more design details in the shared SPM doc.

Nerver mind :) Glad if it works now. Cheers, Olivier.

The log seems to show additional options versus the regular TF-A build:
-march=armv8-a -O2 -pipe -fstack-protector-strong -fno-plt

I installed manjaro-arm on an rpi3 and cloned TF-A commit 0348ee49135c

Unfortunately the option won't show on asm files, but only on C files.

I tried on an arm64 machine (using gcc8.3) but did not reproduce the issue.

I suspect this problem arises because of building natively (although I agree this should normally work).

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.

https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2675/