On 05.06.20 16:57, Ard Biesheuvel wrote: > On Fri, 5 Jun 2020 at 16:54, Heinrich Schuchardt <xypron.glpk@xxxxxx> wrote: >> >> On 05.06.20 14:39, Ard Biesheuvel wrote: >>> On Fri, 5 Jun 2020 at 14:20, Heinrich Schuchardt <xypron.glpk@xxxxxx> wrote: >>>> >>>> On 05.06.20 13:52, Ard Biesheuvel wrote: >>>>> EFI on ARM only supports short descriptors, and given that it mandates >>>>> that the MMU and caches are on, it is implied that booting in HYP mode >>>>> is not supported. >>>>> >>>>> However, implementations of EFI exist (i.e., U-Boot) that ignore this >>>>> requirement, which is not entirely unreasonable, given that it does >>>>> not make a lot of sense to begin with. >>>> >>>> Hello Ard, >>>> >>>> thanks for investigating the differences between EDK2 and U-Boot. >>>> >>>> What I still do not understand is if there is a bug in U-Boot where >>>> U-Boot does not conform to the UEFI specification? In this case I would >>>> expect a fix in U-Boot. >>>> >>> >>> U-Boot violates the EFI spec, yes. The spec is very clear on how the >>> MMU is configured, and this rules out booting with the caches off, or >>> booting in HYP mode. >>> >>> However, given that this is the situation today, we still need to deal >>> with it on the Linux side. >>> In parallel, fixing it in U-boot may be appropriate. However, I think >>> the EFI spec is too detailed here - instead of 'booting at the highest >>> non-secure privilege mode', it tells you which exact bits to set in >>> SCTLR, which seems overzealous to me. In other words, even though it >>> violates the letter of the spec, I don't mind dealing with this >>> exception in the Linux side, since the requirement is somewhat >>> unreasonable to begin with. >>> >>>> Or is it simply a deficiency of Linux that it does not properly support >>>> HYP/EL2 mode on 32-bit ARM? >>>> >>> >>> No, this is definitely not the fault of Linux. >>> >>>> Up to now I never experience a problem booting a 32bit board via U-Boot >>>> -> GRUB-EFI -> Linux. Where did you have a problem when booting via >>>> U-Boot's UEFI implementation and the current Linux kernel? >>>> >>> >>> I haven't managed to make it fail, but my only 32-bit HYP capable >>> platform is QEMU. I am not 100% convinced that the EFI+HYP+U-Boot case >>> is rock solid, and I may have gotten lucky with QEMU (which uses >>> emulation not virtualization when running at HYP) >>> >>> Do you have any A7/A15 based boards that don't print 'WARNING: Caches >>> not enabled' at boot? >> >> Hello Ard, >> >> I have no board that prints this. Where did you actually see this output? >> > > In U-boot > > arch/arm/lib/cache.c: * Default implementation of enable_caches() > arch/arm/lib/cache.c- * Real implementation should be in platform code > arch/arm/lib/cache.c- */ > arch/arm/lib/cache.c:__weak void enable_caches(void) > arch/arm/lib/cache.c-{ > arch/arm/lib/cache.c- puts("WARNING: Caches not enabled\n"); > arch/arm/lib/cache.c-} > arch/arm/lib/cache.c- > > The QEMU port does not override that routine. This may be the reason > it doesn't work for me under KVM, but only under emulation. > >> The string "Caches not enabled" does not exist in Linux next-20200505 >> according to "git grep -n 'ache not enabled'". >> >> Here is some sample output for an Orange Pi PC with a quad core >> Allwinner H3 Soc. "ARMv7 Processor rev 5 (v7l)" according to >> /proc/cpuinfo, compatible to "arm,cortex-a7" according to the device tree. >> >> $ uname -m >> Linux orangepi-pc 5.6.0-2-armmp-lpae #1 SMP Debian 5.6.14-1 (2020-05-23) >> armv7l GNU/Linux >> > > Could you check whether it boots in HYP mode? > > [ 0.381460] CPU: All CPU(s) started in SVC mode. > > vs > > [ 0.135626] CPU: All CPU(s) started in HYP mode. > > > ? > Booted via GRUB-EFI: sudo dmesg -H | grep 'started in' [ +0.000017] CPU: All CPU(s) started in HYP mode. Booted via Linux stub: $ sudo dmesg -H | grep 'started in' [ +0.000016] CPU: All CPU(s) started in HYP mode. Best regards Heinrich