Refused the Cortex-R52 VFP option without a hard float ABI

[fdesbiens]

TX_R52_ENABLE_VFP with the default soft float ABI cannot build, and the guard that exists says otherwise.

What happens today

The option defines TX_ENABLE_VFP_SUPPORT, which enables the VMRS, VSTMDB and VLDMIA blocks in the port assembly. -mfloat-abi=soft leaves the assembler with no FPU to accept them, so:

$ cmake -B build -G Ninja -DCMAKE_TOOLCHAIN_FILE=cmake/cortex_r52.cmake \
        -DTX_R52_BUILD_FVP_EXAMPLE=ON -DTX_R52_ENABLE_VFP=ON .
$ cmake --build build
tx_thread_system_return.S:118: Error: selected processor does not support `vmrs r4,FPSCR' in ARM mode
tx_thread_system_return.S:120: Error: selected processor does not support `vstmdb sp!,{D8-D15}' in ARM mode
tx_thread_context_restore.S:194: Error: selected processor does not support `vmrs r2,FPSCR' in ARM mode
... eight in total

None of them mentions the float ABI, so a user has to reason from VMRS back to the option that enabled it.

The port did warn, but the warning described the wrong outcome — "the compiler will not emit floating-point instructions, so the VFP context path will never be exercised", which is a build that succeeds and is merely pointless. Configure then completed, so by the time the assembler errors appeared the warning was a couple of hundred lines up the scrollback.

The change

WARNING becomes FATAL_ERROR, with a message that names the fix.

This is what the same file already does six lines above, for TX_R52_ENABLE_FIQ_NESTING without TX_R52_ENABLE_FIQ — rejected outright for being "meaningless". So the file was treating a merely pointless combination as fatal and an unbuildable one as a warning. The severities were the wrong way round; this makes them consistent. The option's target_compile_definitions also moves below the check so the two blocks read the same way.

The ABI is deliberately not promoted to hard automatically. TX_R52_FLOAT_ABI is a cache variable a user may have set on purpose, and silently overriding an explicit choice is worse than refusing a combination that cannot work.

readme_threadx.txt carried the same wrong claim, and its option list marked the FIQ-nesting dependency inline but not this one. Both corrected.

Verification

Both directions, by hand:

• Soft ABI + VFP now stops at configure with TX_R52_ENABLE_VFP requires TX_R52_FLOAT_ABI=hard, but it is 'soft'. and an explanation of why.
• Hard ABI + VFP + FIQ + IRQ nesting + FIQ nesting builds its eight images with zero warnings and passes ctest 8/8 on the Armv8-R AEM FVP.
• The default configuration and hard without VFP both still configure cleanly.
• scripts/check_gcc.sh passes. Its Cortex-R52 CMake stage configures without TX_R52_ENABLE_VFP, so the new branch is not on its path.

Toolchain GNU Arm 14.3.1.

No regression test, and why

Nothing in the tree asserts a configure-time failure — there is no harness for it, and the sibling FIQ-nesting guard has none either. A test for this one case would have to introduce that mechanism. If a configure-failure harness is wanted, it is worth having for both guards at once rather than bolted on here.

The guard block dates from #579 and is unrelated to any module-manager work.