RE: Big endian modifications

[Rory Bolt <Rory.Bolt@kioxia.com>]

Wow. I am unfamiliar with booti - I will investigate. Thank you for the pointer! Believe me when I say the detour through EFI was interesting...

-Rory

-----Original Message-----
From: Robin Murphy <robin.murphy@arm.com> 
Sent: Thursday, February 3, 2022 12:46 PM
To: Rory Bolt <Rory.Bolt@kioxia.com>; linux-arm-kernel@lists.infradead.org
Subject: Re: Big endian modifications

Hi Rory,

On 2022-02-03 18:48, Rory Bolt wrote:
> Hello,
> 
> I have been modifying GRUB on Das U-boot to allow it to boot aarch64_be big endian kernels on the RockPro64 board. Since the RockPro64 has a PCIe (albeit 2.0) slot, it provides a low cost/reasonable performance (vs QEMU) system to test our devices, drivers and software stack on a big endian system. I am in the process of publishing the required changes to GRUB, however there are two minor changes made to the kernel itself. Arguably the modification to head.S could be moved to grub itself, however it is in the defensive spirit of not assuming the boot loader has set up everything correctly and is very similar to the startup of NetBSD which contains similar code in its startup. The second change to Kconfig allows a EFI/PE/COFF header to be added to a big endian kernel (although unfortunately it also adds a useless big endian efistub to the kernel too). With the following two changes the modified GRUB can boot either big endian or little endian Arm64 images.

FWIW I believe the previous thinking was that teaching GRUB to boot non-EFI images via the original arm64 boot protocol would be the most useful thing to do, since that would increase coverage and flexibility regardless of endianness.

However if you're using U-Boot, then booti ought to do exactly that with a standard BE image already, so the pragmatic option might be to just avoid the detour through EFI altogether.

> Please consider the following two modifications for inclusion:
> 
> diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S index 
> 6a98f1a38c29..40a18d767d15 100644
> --- a/arch/arm64/kernel/head.S
> +++ b/arch/arm64/kernel/head.S
> @@ -89,6 +89,24 @@
>           *  x24        __primary_switch() .. relocate_kernel()  current RELR displacement
>           */
>   SYM_CODE_START(primary_entry)
> +#ifdef CONFIG_CPU_BIG_ENDIAN
> +        mrs     x21, CurrentEL
> +        lsr     x21, x21, #2
> +        cmp     x21, #0x2
> +        b.lo    1f
> +
> +        mrs     x21, sctlr_el2
> +        orr     x21, x21, #SCTLR_ELx_EE /* set: Big Endian */
> +        msr     sctlr_el2, x21
> +        isb
> +
> +1:
> +        mrs     x21, sctlr_el1
> +        orr     x21, x21, #(SCTLR_ELx_EE | SCTLR_EL1_E0E)       /* set: Big Endian */
> +        msr     sctlr_el1, x21
> +        isb
> +
> +#endif
>          bl      preserve_boot_args
>          bl      init_kernel_el                  // w0=cpu_boot_mode

Pretty much the first thing that init_kernel_el does is to install the appropriate INIT_SCTLR_EL[12]_MMU_OFF value which already contains the relevant ENDIAN_SET_EL* combinations, therefore this change looks like it shouldn't be needed. Have you seen an actual issue here, other than anything stemming from the completely broken and illegal-per-the-UEFI-spec big-endian EFI config?

It's been a while since I last tried booting a BE kernel (especially in bare-metal EL2 rather than a VM), but it definitely used to work fine.

Robin.

>          adrp    x23, __PHYS_OFFSET
> 
> 
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 
> c4207cf9bb17..a9ccbeb75ea7 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -1997,7 +1997,7 @@ config EFI_STUB
> 
>   config EFI
>          bool "UEFI runtime support"
> -       depends on OF && !CPU_BIG_ENDIAN
> +       depends on OF
>          depends on KERNEL_MODE_NEON
>          select ARCH_SUPPORTS_ACPI
>          select LIBFDT
> 
> Rory Bolt
> 
> KIOXIA America, Inc. | formerly Toshiba Memory America, Inc.
> 
> 
> 
> 
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel