The -mcpu=cortex-a9 flag conflicts with the march=armv7-a flag.
Opted to keep mcpu=cortex-a9 as it is more specific and
allows GCC to perform better optimization.
The compiler is also changed to use soft-float ABI as it
was necessary to successfully build. Without it the application
appears to be built with soft-float ABI and it conflicts with
the previous setting which was built with hard-float ABI.
This may be related to: https://gitlab.kitware.com/cmake/cmake/-/issues/21173
Binaries generated for Cortex-M33 targets (e.g. Musca S1/B1) using
the Arm toolchain + CMake is unable to run, unless we instruct the
linker to not use floating points.
Note: This is a temporary workaround, because
* Ideally, the Arm linker should be able to auto detect the
architecture support from the input object files, but it's not
always the case. We already have a similar workaround for Cortex-M4.
* The full option to use should be `--cpu=Cortex-M33.no_dsp.no_fp`
but `no_dsp` currently conflicts with CMake's compilation tests
(no option to disable DSP in the test objects before linking).
The GCC flag to specify the floating-point hardware (`mfpu`) does not accept
the value `none`. The default value is `auto` which causes the compiler to
select the floating-point and Advanced SIMD instructions based on the
settings of -mcpu and -march. The extension option `+nofp` has been added
to disable floating point instructions.
Move the fpu settings across all cores so they are aligned.
Some cores did not have fpu set for ARMClang. I matched here both toolchains to set up
the fpu the same (Only exception is soft vs hard - that is separate issue I would not like to touch
in this series).
Set DOMAIN_NS=1 only for _NS cores. We had it otherway around.
I verified one non NS target that was failing to build, plus also checked the old tools
that had this definitions:
```
91: "Cortex-M23-NS": ["__CORTEX_M23", "ARM_MATH_ARMV8MBL", "DOMAIN_NS=1",
92 "__CMSIS_RTOS", "__MBED_CMSIS_RTOS_CM"],
93 "Cortex-M23": ["__CORTEX_M23", "ARM_MATH_ARMV8MBL", "__CMSIS_RTOS",
94 "__MBED_CMSIS_RTOS_CM"],
```
Some armasm flags are passed to the ASM whilst we actually use armclang to invoke it. This causes build failures as armclang is not compatible with armasm flags.
This commit passes the same flags to all tools in the chain.
The new function (mbed_set_cpu_core_definitions()) should always be
called as it has defintions needed by Mbed OS to work with that
particular MCU core.
mbed_set_cpu_core_options() should only be called if a third-party
toolchain file has not been used as it has compile options that can
cause conflicts.
mbed-os consists of mbed-core and mbed-rtos
mbed-baremetal consists of mbed-core
The main change is for mbed-core. Changing from object library to be interface. This way it allows us to do the above to have 2 main targets for users to use.
This should be backward compatible change as mbed-os target we used contains the same files/options as previously set.
Hugues Kamba
Lingkai Dong
Martin Kojtal
reme
jeromecoutant
Jamie Smith
Rajkumar Kanagaraj