Undefined instruction exceptions due to compiler-generated NEON code in TF-A
We are experiencing issues on STM32MP13 when using TF-A with OP-TEE due to an "Undefined instruction" exception during low-power entry.
When TF-A is built with a standard arm-*-gnueabihf toolchain, the compiler is allowed to generate NEON instructions because the STM32MP1 platform enables:
ARM_WITH_NEON := yes
In our case, GCC generates NEON instructions when compiling lib/compiler-rt/builtins/udivmoddi4.c, which is reached from udelay() during the low-power sequence. At that point, however, the VFP/NEON unit is disabled, so execution aborts with an "Undefined instruction" exception.
Relevant TF-A build settings:
- ARM_CORTEX_A7 := yes (from STM32MP1 platform settings)
- ARM_WITH_NEON := yes (from STM32MP1 platform settings)
- AARCH32_SP := optee
- CTX_INCLUDE_FPREGS=0
Relevant compiler options:
- -mcpu=cortex-a7 (generated by TF-A from ARM_CORTEX_A7 := yes)
- -mfpu=neon (generated by TF-A from ARM_WITH_NEON := yes)
- -ffreestanding
- -fno-builtin
- -Os
We have verified that replacing udelay() with a simple NOP loop (for testing purposes) is enough to work around the problem.
Building TF-A with options that prevent compiler-generated NEON instructions (such as -mfloat-abi=soft) also avoids the exception.
Interestingly, the STM32MP1 platform already contains a special case for sp_min:
ifeq ($(AARCH32_SP),sp_min)
# Disable Neon support: sp_min runtime may conflict with non-secure world
TF_CFLAGS += -mfloat-abi=soft
endifWe are wondering whether a similar approach should also be considered when AARCH32_SP=optee, or whether there is another recommended way to avoid executing compiler-generated NEON instructions in this code path.
Any feedback is welcome.
Regards,
Guillermo
