> From: Ilias Apalodimas <ilias.apalodi...@linaro.org>
> Date: Sat, 12 Jul 2025 09:28:07 +0300
Hi Ilias, Heinrich and Tom,
As you probably know, OpenBSD/armv7 relies on EFI_LOAD, so disabling
EFI_LOADER on a platform means you can't boot OpenBSD on it. Ilias
and I talked about this a while ago. We talked about telling QEMU to
use an older version of the architecture that didn't do this alignment
check, but that may have been based on a misunderstanding of the
changes in QEMU.
At the time I didn't look any further into this, but I did now. And
I'm confused because...
> Hi Heinrich
>
> On Fri, 11 Jul 2025 at 22:35, Heinrich Schuchardt <xypron.g...@gmx.de> wrote:
> >
> > Am 11. Juli 2025 20:55:12 MESZ schrieb Tom Rini <tr...@konsulko.com>:
> > >As part of upgrading to QEMU 10.0.0 we discovered that the EFI loader
> > >tests would no longer pass CI, on this specific platform, while still
> > >passing on real hardware. Upon further investigation it turns out that
> > >on ARMv7 we rely on some undefined behavior with respect to enabling
> > >unaligned access. And while this is seemingly fine on real hardware,
> > >QEMU is now correct enough in implementation to no longer allow this. In
> > >order to not rely on this undefined behavior we would need to implement
> > >some MMU configuration (and then ensure proper tear-down possibly).
> > >
> > >At the moment, the most reasonable path forward seems to be to document
> > >this and disable the support here.
> >
> > Where will we document the issue?
>
> I think we can add it on the EFI documentation? IIRC we only enable
> the i-cache not the mmu + d-cache. I can double check and send a
> patch.
There is code in U-Boot to enable the MMU and the D-cache. The code
turns on the MMU gets turned on when we turn on the D-cache, which
happens when we call dcache_enable(). That function typically gets
called from the board.c file and the one used by vexpress_ca9x4
doesn't seem to do that. But other ARMv7 targets do. For example in
arch/arm/mach-sunxi/board.c we have:
#if !CONFIG_IS_ENABLED(SYS_DCACHE_OFF) && defined(CONFIG_CPU_V7A)
void enable_caches(void)
{
/* Enable D-cache. I-cache is already enabled in start.S */
dcache_enable();
}
#endif
Note the CONFIG_CPU_V7A there. This means that for the Allwinner
ARMv7 SoCs, which typically use Cortex-A7 cores that do include the
virtualization extensions and therefore should implement the stricter
unaligned access checks, we do enable the MMU.
> > Does it imply that we should discourage EFI use on all ARMv7 systems?
So no, it does *not* imply we should discourage EFI use on all ARMv7
systems.
> The spec says the MMU must be enabled, so I think yes. I thought about
> disabling it, but that's too strict.
> Perhaps someone that uses v7 and *needs* EFI can look at enabling the
> MMU with a simple identity mapping.
That should be as simple the diff below. I've not verified if that
fixes the QEMU issue, but I strongly suspect it will. Whether this
works on actual vexpress hardware is a different issue though.
diff --git a/board/armltd/vexpress/vexpress_common.c
b/board/armltd/vexpress/vexpress_common.c
index 6c374e25e32..3833af59b09 100644
--- a/board/armltd/vexpress/vexpress_common.c
+++ b/board/armltd/vexpress/vexpress_common.c
@@ -165,3 +165,11 @@ void smp_set_core_boot_addr(unsigned long addr, int corenr)
writel(addr, CONFIG_SYSFLAGS_ADDR);
}
#endif
+
+#if !CONFIG_IS_ENABLED(SYS_DCACHE_OFF)
+void enable_caches(void)
+{
+ /* Enable D-cache. I-cache is already enabled in start.S */
+ dcache_enable();
+}
+#endif
