Re: [PATCH v2 07/14] arm64: head: Force little-endian early during boot

[Will Deacon]

On Tue, Sep 08, 2026 at 07:12:12PM +0200, Ard Biesheuvel wrote:
> On Mon, 7 Sep 2026, at 18:37, Will Deacon wrote:
> > Commit 2ced0f30a426 ("arm64: head: Switch endianness before populating
> > the ID map") configured SCTLR_ELx.EE at boot according to the endianness
> > of the kernel in case the bootloader had entered the image in the wrong
> > endianness. Additionally, if the MMU was enabled in such a case, logic
> > was added to turn it back off to prevent the hardware walker from
> > misinterpreting the idmap page-table.
> >
> > Given that the MMU is only expected to be enabled when booting EFI, EFI
> > only supports little-endian and arm64 kernels cannot be built as
> > big-endian images, we can rip out this handling and simply force
> > SCTLR_ELx.EE to 0 (little-endian).
> >
> > Suggested-by: Ard Biesheuvel <ardb@xxxxxxxxxx>
> > Signed-off-by: Will Deacon <will@xxxxxxxxxx>
> > ---
> >  arch/arm64/kernel/head.S | 20 +-------------------
> >  1 file changed, 1 insertion(+), 19 deletions(-)
> >
> > diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
> > index 8951ce693552..d5c1ea0c5b3c 100644
> > --- a/arch/arm64/kernel/head.S
> > +++ b/arch/arm64/kernel/head.S
> > @@ -138,29 +138,11 @@ SYM_CODE_START_LOCAL(record_mmu_state)
> >  	b.ne	0f
> >  	mrs	x19, sctlr_el2
> >  0:
> > -	tbnz	x19, #SCTLR_ELx_EE_SHIFT, 1f
> > +	bic	x19, x19, #SCTLR_ELx_EE		// Force little-endian
> 
> This bic has no effect here: the 'and' below clears it anyway, but x19
> is not written back to SCTLR.

Oh yes, this is only used to drive the flag to say whether or not the
MMU was enabled on entry and then the other part of the patch removes
the sctlr write.

> When I suggested this, I missed that SCTLR.EE still needs to be cleared
> before populating the ID map, regardless of whether we enter with the
> MMU and caches enabled.
> 
> IOW, we need to retain the SCTLR writeback logic below. The only thing
> we can drop is the clearing of the M bit and the invocations of
> pre_disable_mmu_workaround. But we might as well keep that.
> 
> Apologies for the bad suggestion.

Not to worry, I made an absolutely dog's dinner of implementing it
anyway! I'll just drop this patch for now.

Cheers,

Will