On Wed, 9 Feb 2022 18:07:24 +0000
Joakim Tjernlund <joakim.tjernl...@infinera.com> wrote:
Hi,
> On Wed, 2022-02-09 at 13:13 +0000, Andre Przywara wrote:
> > On Wed, 9 Feb 2022 14:05:57 +0100
> > Michael Walle <mich...@walle.cc> wrote:
> >
> > Hi,
> >
> > > > > The problem I have is that I boot a custom SOC into u-boot and when
> > > > > u-boot tries
> > > > > to boot linux I get an error exception when u-boot calls
> > > > > armv8_switch_to_el2 to enter linux.
> > > >
> > > > So that means that U-Boot runs in EL3, is that the first and only
> > > > firmware
> > > > that you run? I think the EL3 part of U-Boot is not widely used and
> > > > tested
> > > > beyond the very few platforms that use it.
> > >
> > > FWIW, the u-boot on the kontron_sl28 (which is a A72 core) is running
> > > in EL3. But it's a layerscape so it might be worth looking in
> > > arch/arm/cpu/armv8/fsl-layerscale/ if there is anything special.
> >
> > Thanks Michael, that's what I meant: the generic EL3 code in
> > arch/arm/cpu/armv8 might depend on more platform specific code to make it
> > work.
>
> Thanks guys, will look at these boards.
> I have learnt that EL2 state in our design may be broken
How so? The exception levels itself are completely capsuled in the CPU
core, so Arm Cortex-A53, in your case. And EL2 surely runs happily there. I
wouldn't know of any peripherals being affected by the EL the core is
running in (ignoring secure state for now).
So what is the problem, exactly? The only EL2 problems I heard of were
firmware related (not setting up EL2 correctly), but we are looking
at the firmware here.
> so I started to look at going directly to EL1
> instead, is that a bad idea?
Please don't do this. For a start, I don't think it's necessary, and also
you are leaving the architectural trails here. In particular you are
getting into trouble with PSCI. Sure, you can somehow hack this up, but it
will stay a hack and it will come back and bite you later. Promised ;-)
> In u-boot I find:
>
> #ifdef CONFIG_ARMV8_SWITCH_TO_EL1
> static void switch_to_el1(void)
> {
> if ((IH_ARCH_DEFAULT == IH_ARCH_ARM64) &&
> (images.os.arch == IH_ARCH_ARM))
> armv8_switch_to_el1(0, (u64)gd->bd->bi_arch_number,
> (u64)images.ft_addr, 0,
> (u64)images.ep,
> ES_TO_AARCH32);
Last time I tried this, for an experiment, this part was broken, it sets up
SCTLR wrongly, making the Linux kernel decompressor hang. I am tempted to
ask for removal, since it has architectural problems with PSCI anyway.
> else
> armv8_switch_to_el1((u64)images.ft_addr, 0, 0, 0,
> images.ep,
> ES_TO_AARCH64);
And this has issues with PSCI as well, since we now skip one EL, which the
spec does not allow.
Cheers,
Andre
> }
> #endif
> ....
> #ifdef CONFIG_ARMV8_SWITCH_TO_EL1
> armv8_switch_to_el2((u64)images->ft_addr, 0, 0, 0,
> (u64)switch_to_el1, ES_TO_AARCH64);
> #else
> .....
>
> which looks promising but when I look closer I see that this seems to do:
> EL3 -> EL1 -> EL2
> Really? What is the point ? Looks like I need to hack something myself to go
> EL3->EL1
> or am I missing something ?
>
> Jocke
>
