On Sat, 21 Aug 2021 19:54:02 -0500 Samuel Holland samuel@sholland.org wrote:
Hi Samuel,
thanks for the update.
For ARMv8-A, NEON is standard, so the compiler can use it even when no special target flags are provided.
That is not entirely true, NEON is architecturally an optional feature, it's just so prevalent that GCC decided to include it in the default "armv8-a" arch definition: https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html -march=name
For example, it can use stores from NEON registers to zero-initialize large structures. GCC 11 decides to do this inside the DRAM init code for the Allwinner H6.
However, GCC 11 has a bug where it generates misaligned NEON register stores even with -mstrict-align. Since the MMU is not enabled this early in SPL, the misaligned store causes an exception and breaks booting.
For the records: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101934
Work around this issue by restricting the compiler to using GPRs only, not vector registers. This prevents any future surprises relating to NEON use as well.
While one could argue that this is papering over a compiler bug, we actually have no guarantee that *every* ARMv8 target core we compile for has NEON support. Cortex-A53 (and even A55) for instance allow to not include NEON during the integration process, so any access to NEON registers would crash there already.
Signed-off-by: Samuel Holland samuel@sholland.org
Acked-by: Andre Przywara andre.przywara@arm.com
Cheers, Andre
Changes in v2:
- Updated commit message to describe problem more precisely
arch/arm/config.mk | 1 + 1 file changed, 1 insertion(+)
diff --git a/arch/arm/config.mk b/arch/arm/config.mk index 16c63e12667..964c6b026ec 100644 --- a/arch/arm/config.mk +++ b/arch/arm/config.mk @@ -25,6 +25,7 @@ endif
PLATFORM_RELFLAGS += -fno-common -ffixed-r9 PLATFORM_RELFLAGS += $(call cc-option, -msoft-float) \
$(call cc-option,-mgeneral-regs-only) \# LLVM support