Hi Yann,

Please find my answers [MP]

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.
[MP] : Sounds good

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.
[MP]: ID register should be constant for a given CPU and the logic written in the code expects that if CPU has EL2 extension present then BL33 would start at  EL2.
mode = (el_status) ? MODE_EL2 : MODE_EL1

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?
[MP] : Its not confirmed at this point that we will remove this code all together (need to wait for the feedback). The most common use cases where U-boot is used as bootloader it is recommended it to run at EL2. There is some guidelines here 
https://u-boot.readthedocs.io/en/latest/arch/arm64.html#:~:text=U%2DBoot%20can%20run%20at,that%20of%20a%20boot%20loader. 

I haven't checked, but will U-Boot switch to EL1 when running Linux?
[MP]: In the most common scenarios, U-boot would hand over to Linux at EL2 (so no switching of EL in U-boot)

Thanks 
Manish
 
From: Yann Gautier <yann.gautier@foss.st.com>
Sent: 03 October 2023 09:11
To: Manish Pandey2 <Manish.Pandey2@arm.com>; tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.org>
Cc: Arvind Ram Prakash <Arvind.RamPrakash@arm.com>
Subject: Re: [TF-A] Platforms without NS-EL2 component
 
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
>
>