Re: Big endian modifications

[Robin Murphy <robin.murphy@arm.com>]

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