[bootwrapper PATCH v2 06/13] aarch64: initialize SCTLR_ELx for the boot-wrapper

[Mark Rutland]

On Mon, Jan 17, 2022 at 12:15:57PM +0000, Mark Rutland wrote:
> On Fri, Jan 14, 2022 at 06:12:47PM +0000, Andre Przywara wrote:
> > On Fri, 14 Jan 2022 10:56:46 +0000
> > Mark Rutland <mark.rutland at arm.com> wrote:
> > 
> > Hi Mark,
> 
> Hi Andre,
 
> > > +
> > > +#define SCTLR_EL1_RES1		(BIT(29) | BIT(28) | BIT(23) | BIT(22) | \
> > > +				 BIT(11) | BIT(8) | BIT(7) | BIT(4))

> > > -#define SCTLR_EL1_RES1		(3 << 28 | 3 << 22 | 1 << 11)
> > >  
> > >  #ifdef KERNEL_32
> > >  /* 32-bit kernel decompressor uses CP15 barriers */
> > > #define SCTLR_EL1_KERNEL        (SCTLR_EL1_RES1 | SCTLR_EL1_CP15BEN)
> > 
> > So I wonder if this actually works? The ARMv7 version of SCTLR
> > differs in some bits from both the ARMv8 AArch32 version and more
> > importantly the AArch64 version.

> > I had troubles the other day running the
> > arm32 Linux kernel decompressor with some ARMv8 SCTLR_EL1 reset value. The
> > decompressor code does only read-modify-write of SCTLR (probably to
> > cover multiple architecture revisions), so some bits might stay wrong. In
> > particular I think having bits 28 and 29 set caused problems.
> > By looking at the ARMv7 ARM and with experimentation I came up
> > with 0x00c00878 as a safe and working value.

Having re-read all of this, I believe you're right; I'll rework the
AArch32-kernel SCTLR_EL1_KERNEL to not use the AArch64 bit definitions,
and I'll add some commentary explaining that we're writing to the AArch32
format.

> > Shall we have a separate reset value for 32bit?

Assuming you meant to alter the SCTLR_ELx_KERNEL definition, yes.

The idea of splitting the SCTLR_ELx_RESET and SCTLR_ELx_KERNEL
definitions was that the former would be whatever the boot-wrapper
needed to run at ELx, and the latter was whatever we must initialize for
the kernel to run at ELx, so I don't want to put the AArch32 kernel bits
into SCTLR_EL1_RESET.

My only remaining concern is exactly what we must initialize. If there's
any documentation we can refer to, that'd be great, otherwise I'll dig
through your prior suggestion.

Thanks,
Mark.