You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Commit disabling DSP instructions for M-33 suggests creating a custom compiler package for BSPs that need it: bafc7e0.
Given that nRF5340 appcore and netcore BSPs are in-tree, and appcore supports DSP instruction set while the netcore does not, I think the two compiler packages themselves should be in the tree: arm-none-eabi-m33 and arm-none-eabi-m33-nodsp, so that the corresponding Nordic BSPs can be used directly from the repo.
The text was updated successfully, but these errors were encountered:
So, this can be solved by specifying pkg.cflags: for the respective BSP. apps, BSPs, targets and compiler packages when provided with pkg.cflags get applied to the entire build. cc: @ccollins476ad@vikrant-proxy
Yes, although I am not sure what the result of specifying multiple -mcpu options is. Would this prevent the compiler package from specifying a default?
I have not tested this with cflags, but with lflags the order of options is also not preserved currently, which could make this trickier (apache/mynewt-newt#429).
Commit disabling DSP instructions for M-33 suggests creating a custom compiler package for BSPs that need it: bafc7e0.
Given that nRF5340 appcore and netcore BSPs are in-tree, and appcore supports DSP instruction set while the netcore does not, I think the two compiler packages themselves should be in the tree:
arm-none-eabi-m33
andarm-none-eabi-m33-nodsp
, so that the corresponding Nordic BSPs can be used directly from the repo.The text was updated successfully, but these errors were encountered: