qemu/arm: Extend CI testing to include ArmV7-M hardfp targets. #17757
+97
−13
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
As a followup to #17737, this PR introduces a QEMU Arm target that has a hardware floating point unit (
MPS2_AN500
), and then lets CI use it for selected operations.MPS2_AN500
is a Cortex-M7 with a single- and double-precision floating point unit, but it is otherwise equivalent to theMPS2_AN385
target for MicroPython's needs.To further validate that the FPU is used and initialised correctly, the machine exception handler for ArmV7-M targets was extended to dump the full set of debug registers. If the FPU is used incorrectly (as in, access to the appropriate machine coprocessor was not enabled beforehand) then the
CFSR.NOCP
bit should appear to be set in the exception handler dump.In order to correctly test the hardfp natmods we need to have a validated hardfp interpreter, so we must have a full
MPS2_AN500
build and test cycle as well. To reduce the impact on CI times I've split the original CI step into two discrete units, as in "ci_qemu_build_arm_thumb_softfp" and "ci_qemu_build_arm_thumb_hardfp", so they can run in parallel whenever possible.Manual building and testing of the QEMU port isn't otherwise affected, the default Arm machine is still
MPS2_AN385
and it will retain the same floating point configuration as before (MICROPY_FLOAT_IMPL_FLOAT
).Concidentally, I've made QEMU's Makefile a bit more flexible when it comes to floating point settings. I've replicated the setup from the
stm32
port, so the same flag names apply here as well.Testing
Besides manual testing, CI should (hopefully) run the relevant step without errors; tests passed on my branch.
Trade-offs and Alternatives
There will be a (hopefully) minor increase in CI build times. However, having two separate targets is necessary to catch issues with FPU opcodes being used in softfp contexts for example. Making the hardfp variant the default would still call for a softfp variant to be there anyway.
Things could still be improved though, as in ArmV6-M builds could be tested in an emulated Cortex-M0+ machine to make sure no ArmV7-M opcodes are used by GCC or by viper/native emitters.