11-29-2016 04:02 AM
To use the neon FPU the compiler flags for application, library and BSP have to be -mcpu=cortex-a9 -mfpu=neon -mfloat-abi=softfp
When I edit the extra_compiler_flags setting the values change, the BSP builds and with sympathetic changes to the application I can build code and use the Ne10 library.
However, should the BSP auto build for some reason things start to go bump in the night : I presume "mangled make" is making the boards squeak.
A simple manifestation of what is going wrong is that, if one manually reopens the .mss and inspects the extra_compiler_flags the default values have reappeared in the values box, concatenated with the user edited value : e.g. -mcpu=cortex-a9 -mfpu=vfpv3 -mfloat-abi=hard -nostartfiles -mcpu=cortex-a9 -mfpu=neon -mfloat-abi=softfp -nostartfiles -DUNDEFINE_FILE_OPS [cut/paste from the SDK]
Strikes me this is SPR territory - solution please [Tools = SDK 2016.3] [Toy Example attached - for Zybo]
12-05-2016 09:31 AM
It looks like this is an kind of issue when regenerating the BSP.
Once you modify the extra_compiler_flags value in the BSP settings wizard it saves the values properly in the MSS file and also it is able to build the libraries properly too. However once BSP is regenerated, either using the particular GUI button or just allowing to regenerate in one of the typical emerging windows, the tool concatenates the default compiler options to the custom ones.
I tested to build again the application using the concatenated argument list and the SDK is able to build it so it's clear that the library and the application have been build using NEON but I cannot detail the implications that may have in the BSP libraries the usage of both configurations.
I'll take notice of this issue.
04-10-2017 02:57 AM
I have the same identical problem: the default extra compiler settings are always concatenated to the user's choice.
Is there any workaorund for this issue?