Hi Manish,
The new STM32MP2 platform (based on a Cortex-A35) that I've just started
to upstream is in this case.
In our downstream code, we run BL33 (U-Boot in our case) at NS-EL1.
So we will use the flag INIT_UNUSED_NS_EL2 if required.
I've seen that several platforms use ID-AA64PFR0-EL1 register to check
EL2 is implemented, and then choose to run BL33 at EL2 if this is the
case. We have the EL2 bits on STM32MP2.
As you intend to remove this code in future releases, we should then run
U-Boot at EL2? I've tested that U-Boot can handle this.
But is that something recommended to do so?
I've seen no documentation / recommendation about that.
Do you have any?
I haven't checked, but will U-Boot switch to EL1 when running Linux?
Best regards,
Yann
On 9/27/23 16:18, Manish Pandey2 via TF-A wrote:
> Hi,
>
> I am writing this email to find out any legacy platforms supports in
> TF-A (upstream or downstream) which does not have any NS-EL2 component
> running.
>
> Because NS-EL2 is present but unused EL3 also need to do a minimal
> initialization of EL2. The side effect of this is, TF-A currently has
> extra code in generic path (e.g. cm_prepare_el3_exit() ) to cater for
> these platforms which is not required for most others.
>
> The most likely reason why TF-A introduced support for systems without
> NS-EL2 was because of UEFI implementation for Windows which didn't
> initialize NS-EL2 properly. Given that the UEFI spec has said "Use the
> highest 64 bit non secure privilege level available" for a long time now
> we are safe to assume that any UEFI implementation will handover to
> windows at NS-EL2. (similar to Linux)
>
> Considering that there are very few platforms which need this code and
> to keep backward compatibility, we propose to introduce a macro like
> "INIT_UNUSED_NS_EL2" and guard the code under this[1]. Keep this flag
> default disabled and get rid of it( along with code) altogether in next
> couple of releases, if we are certain that none of the platforms using it.
>
> Please let me know if you are aware of any such platform configuration.
>
> [1]
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/22716
> <
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/22716>
>
> Thanks
> Manish
>
>