Hi Mark,
On 2021-02-11 10:22, Mark Kettenis wrote:
Date: Thu, 11 Feb 2021 09:58:49 +0000
From: Marc Zyngier <m...@kernel.org>
On 2021-02-10 19:14, Mark Kettenis wrote:
> On implementations that support VHE, the layout of the CPTR_EL2
> register depends on whether HCR_EL2.E2H is set. If the bit is
> set, CPTR_EL2 uses the same layout as CPACR_EL1 and can in fact
> be accessed through that register. In that case, jump to the
> EL1 code to enable access to the FP/SIMD registers. This allows
> U-Boot to run on systems that pass control to U-Boot in EL2 with
> EL2 Host mode enabled such as machines using Apple's M1 SoC.
>
> Signed-off-by: Mark Kettenis <kette...@openbsd.org>
> ---
>
> v4: use EL1 codepath when HCR_EL2.E2H is set
> suggested by Marc Zyngier <m...@kernel.org>
>
> v2: rename label
>
> arch/arm/cpu/armv8/start.S | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S
> index 662449156b..9e9c6140cd 100644
> --- a/arch/arm/cpu/armv8/start.S
> +++ b/arch/arm/cpu/armv8/start.S
> @@ -132,11 +132,13 @@ pie_fixup_done:
> msr cntfrq_el0, x0 /* Initialize CNTFRQ */
> #endif
This seems to skip the CNTFRQ_EL0 setup. However, this should
probably also be done on CPUs that do not have EL3, such as M1.
Unless the lower level FW already deals with it? Doesn't have to
be part of this patch though.
Hi Marc,
I think the basic assumption that U-Boot makes is that if you enter in
EL2 or EL1 there is firmware (e.g. TF-A) that does the CNTFRQ_EL0
setup.
On the M1 there is defenitely lower level FW that deals with this, so
this assumption is still fine.
Right. As long as CNTFRQ_EL0 gets set to the correct value on all CPUs,
I'm happy!
Thanks,
M.
--
Jazz is not dead. It just smells funny...
