-
-
Notifications
You must be signed in to change notification settings - Fork 8.3k
qemu/arm: Extend CI testing to include ArmV7-M hardfp targets. #17757
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
agatti
wants to merge
4
commits into
micropython:master
Choose a base branch
from
agatti:natmod-test-arm-hardfp
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
+97
−13
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This commit lets board use a different floating point mode rather than the usual soft-float that was the original default for all QEMU-based boards. The configuration options are the same available in the "stm32" port. Boards can set "MICROPY_FLOAT_IMPL" to either "float", "double", or "none" to indicate which floating point mode they want, and optionally "SUPPORTS_HARDWARE_FP_SINGLE" or "SUPPORTS_HARDWARE_FP_DOUBLE" can be set to 1 to further indicate the hardware capabilities of the hardware floating point unit, if present. Signed-off-by: Alessandro Gatti <a.gatti@frob.it>
This commit introduces a new target for the QEMU port called "MPS2_AN500", an ARMv7-M machine with a Cortex-M7 CPU and single-/double-precision floating point unit. Signed-off-by: Alessandro Gatti <a.gatti@frob.it>
This commit extends the QEMU port's CPU error handler for the Arm target by printing out in detail the ARMv7-M debug registers if the firmware is compiled for such a target. Signed-off-by: Alessandro Gatti <a.gatti@frob.it>
This commit lets CI extend the testing scope of the QEMU Arm target, by letting it perform the usual battery of tests (interpreter and natmods) also on hardfp targets. The default board for Arm testing lacks hardware floating point support, so natmods weren't tested in that specific configuration. With the introduction of the "MPS_AN500" QEMU target, now this is made possible as said board emulates a Cortex-M7 machine with a single- and double-precision floating point unit. To reduce the impact on build times, the "ci_qemu_build_arm_thumb" CI step was split in two: "ci_qemu_build_arm_thumb_softfp" and "ci_qemu_build_arm_thumb_hardfp" - so hopefully those can run in parallel whenever possible. Signed-off-by: Alessandro Gatti <a.gatti@frob.it>
Code size report:
|
e703b1e
to
cd829f2
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #17757 +/- ##
=======================================
Coverage 98.38% 98.38%
=======================================
Files 171 171
Lines 22239 22239
=======================================
Hits 21880 21880
Misses 359 359 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.