Add support for the configUSE_TASK_FPU_SUPPORT constant in the GCC/ARM_CR5 port #584
Conversation
This is done almost identically as in the GCC/ARM_CA9 port
Ensure that the task stack initialization is done correctly for the different options of configUSE_TASK_FPU_SUPPORT. This is very similar to the GCC/ARM_CA9 port. The only meaningful difference is, that the FPU of the Cortex-R5 has just sixteen 64-bit floating point registers as it implements the VFPv3-D16 architecture. You may also refer to the ARM documentation
Similar to GCC/ARM_CA9 port
ChristosZosi
changed the title
Codecov ReportBase: 94.30% // Head: 94.30% // No change to project coverage 👍
Additional details and impacted files@@ Coverage Diff @@
## main #584 +/- ##
=======================================
Coverage 94.30% 94.30%
=======================================
Files 6 6
Lines 2370 2370
Branches 579 579
=======================================
Hits 2235 2235
Misses 85 85
Partials 50 50
Flags with carried forward coverage won't be shown. Click here to find out more. Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
| * the floating point hardware must call vPortTaskUsesFPU() before executing | ||
| * any floating point instructions. */ | ||
| *pxTopOfStack = portNO_FLOATING_POINT_CONTEXT; | ||
| #if( configUSE_TASK_FPU_SUPPORT == 1 ) |
There was a problem hiding this comment.
It is possible that this port is being compiled for a target without an FPU, in which case configUSE_TASK_FPU_SUPPORT may not be defined. This is probably an issue in the original Cortex-A port as well. This code as-is does not compile when configUSE_TASK_FPU_SUPPORT is left undefined or set to 0.
It might be preferable to use the configENABLE_FPU option from the ARMv8M ports and make FPU management on by default for each task rather than opt-in.
@RichardBarry and @aggarg Do you have a preference here?
There was a problem hiding this comment.
Oh, I see what you, @paulbartell , mean. I did take a look on the configENABLE_FPU option, and I strongly agree with you. Let me know, if you want the configENABLE_FPU-option implemented on both ports (Cortex-R5 and A9), I would gladly do it.
There was a problem hiding this comment.
I think we should merge this PR as is and then create a separate PR which should allow setting configUSE_TASK_FPU_SUPPORT to 0. The configUSE_TASK_FPU_SUPPORT would then have the following meaning -
0- No FPU support.1- Tasks individually register their intent to have a FPU context.2- All tasks have FPU context.
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
Add support for the
configUSE_TASK_FPU_SUPPORTconstant in the GCC/ARM_CR5 portDescription
In this PR, I have added support for the
configUSE_TASK_FPU_SUPPORTconfiguration constant to the GCC/ARM_CR5 port.The reason for this is, that when one does compile a FreeRTOS application with FPU on for the Cortex-R5 processor with the GCC compiler, then the compiler by default may make code optimizations using the FP-registers. E.g. code that uses standard functions such as
memcpy,memsetand similar ones, the chances are very high, that the compiler will make optimizations using the FPU registers. This will lead certainly to corrupted FP-registers, if these won't be handled accordingly.In the current state of the GCC/ARM_CR5 port, one could use the function
vPortTaskUsesFPU( void )to mark a task that uses the FPU, to also save/restore the FP-registers during context switches. However, this only option, to ensure that the FP-registers get saved/restored, on its own is not ideal. I had an issue with our application using the FreeRTOS-Plus-TCP library, in which the IP-Task would be optimized by the compiler to use the FPU registers, and for this task we were not able to set thevPortTaskUsesFPU( void )mark, without making changes to the library.So, now with the
configUSE_TASK_FPU_SUPPORT, one can set it to2and ensure that every task created in the FreeRTOS application saves/restores the FP-registers.All this, of course, is not something new. The GCC/ARM_CA9 port does it already.
I have also created a topic in the FreeRTOS-Forum, where this issue is being discussed more thoroughly.
FreeRTOS + TCP with hard FPU on Xilinx ZynqMP UltraScale CortexR5
Test Steps
I did test these changes with our application in real hardware and also the FreeRTOS Demo CORTEX_R5_UltraScale_MPSoC, to verify that everything still works as expected and this was the case on both occasions.
Related Issue
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.