[PATCH] vexpress_ca9x4: Disable EFI_LOADER on this platform

Ilias Apalodimas ilias.apalodimas at linaro.org
Sat Jul 12 08:28:07 CEST 2025


Hi Heinrich

On Fri, 11 Jul 2025 at 22:35, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
>
> Am 11. Juli 2025 20:55:12 MESZ schrieb Tom Rini <trini at 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.

>  Does it imply that 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.

>  It would be good if somebody at ARM could find out if they ever delivered designs that match QEMU's behavior.

I'll ask around and see if I can find something


Reviewed-by: Ilias Apalodimas <ilias.apalodimas at linaro.org>
>
> Best regards
>
> Heinrich
>
>
> >
> >Link: https://gitlab.com/qemu-project/qemu/-/issues/2944
> >Signed-off-by: Tom Rini <trini at konsulko.com>
> >---
> >I believe at one point Norther was using this platform, in QEMU, for a
> >reference platform via EFI for using Mender. As such, this would likely
> >make this platform not useful anymore. I believe Ilias can better
> >explain what needs to be done to fix this properly but there's no one
> >with the available time to take care of this in the community at large,
> >and this is part of what's blocking updating QEMU to a newer version
> >that provides other platform and feature support we do want to use.
> >Alternatively, we could just let this platform go and remove it, if that
> >path makes more sense.
> >
> >Cc: Josef Holzmayr <josef.holzmayr at northern.tech>
> >Cc: Heinrich Schuchardt <xypron.glpk at gmx.de>
> >Cc: Ilias Apalodimas <ilias.apalodimas at linaro.org>
> >---
> > configs/vexpress_ca9x4_defconfig | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> >diff --git a/configs/vexpress_ca9x4_defconfig b/configs/vexpress_ca9x4_defconfig
> >index 67adba437bfc..6ebb37fcf2ec 100644
> >--- a/configs/vexpress_ca9x4_defconfig
> >+++ b/configs/vexpress_ca9x4_defconfig
> >@@ -13,6 +13,7 @@ CONFIG_DEFAULT_DEVICE_TREE="vexpress-v2p-ca9"
> > CONFIG_SYS_LOAD_ADDR=0x90000000
> > CONFIG_ENV_ADDR=0x47F80000
> > CONFIG_SYS_MONITOR_BASE=0x40000000
> >+# CONFIG_EFI_LOADER is not set
> > CONFIG_DISTRO_DEFAULTS=y
> > CONFIG_BOOTCOMMAND="run distro_bootcmd; run bootflash"
> > CONFIG_DEFAULT_FDT_FILE="vexpress-v2p-ca9.dtb"
> >@@ -20,6 +21,7 @@ CONFIG_SYS_CBSIZE=512
> > CONFIG_SYS_PBSIZE=532
> > # CONFIG_DISPLAY_CPUINFO is not set
> > # CONFIG_DISPLAY_BOARDINFO is not set
> >+CONFIG_LAST_STAGE_INIT=y
> > # CONFIG_CMD_CONSOLE is not set
> > # CONFIG_CMD_BOOTD is not set
> > # CONFIG_CMD_XIMG is not set
> >@@ -55,4 +57,6 @@ CONFIG_SMC911X=y
> > CONFIG_SMC911X_32_BIT=y
> > CONFIG_BAUDRATE=38400
> > CONFIG_DM_SERIAL=y
> >+CONFIG_FAT_WRITE=y
> >+CONFIG_FAT_RENAME=y
> > CONFIG_SYS_TIMER_COUNTS_DOWN=y
>


More information about the U-Boot mailing list