CMake versions 3.20 and below always add compiler and linker flags
based on `CMAKE_SYSTEM_PROCESSOR`, for example `--cpu=Cortex-M33`.
This sometimes overrides flags we set in tools/cmake/cores/*.cmake
and results in link failure or unbootable binaries. To workaround
this, we added more linker flags to "counter" what CMake automatically
adds.
From CMake 3.21 onwards, CMake by default does not add flags to
armclang anymore, and it fully relies on projects to set all flags.
In this case we do not need to set `CMAKE_SYSTEM_PROCESSOR` or use
workarounds anymore. We still turn on workarounds when an older
version of CMake (3.19 and 3.20) is used, but in the future we might
require users to have at least CMake 3.21.
As we're moving away from the use of CMAKE_SYSTEM_PROCESSOR, use
MBED_CPU_CORE instead. They differ in cases, but both GCC and Arm
toolchains support case-insensitive CPU names.
We use armclang with `-masm=auto` to auto-select which assembler to use
based on the syntax of the file. Cortex-M55 isn't supported by armasm,
but we don't yet have GCC-syntax asm files for ARM compiler
(1dd090bd1c/CMSIS/RTOS2/RTX/Source/ARM/irq_armv8mml.s).
$ armclang --target=arm-arm-none-eabi -mcpu=cortex-m55 -mfpu=none -masm=auto -c cmsis/CMSIS_5/CMSIS/RTOS2/RTX/Source/TOOLCHAIN_ARM/TARGET_M33/irq_armv8mml.S
armclang: error: armasm does not support CPU 'cortex-m55'
In the mean time, we can build C and C++ files using the
`-mcpu=cortex-m55` option, and for armasm, cancel out that choice of CPU
with a known-supported CPU type, Cortex-R7, and provide the legacy
assembler-specific option `-Wa,armasm,--cpu=cortex-m55`.
After these changes, this works:
$ armclang --target=arm-arm-none-eabi -mcpu=cortex-m55 -mcpu=cortex-r7 -Wa,--cpu=cortex-m55 -mfpu=none -masm=auto -c cmsis/CMSIS_5/CMSIS/RTOS2/RTX/Source/TOOLCHAIN_ARM/TARGET_M33/irq_armv8mml.S
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.
Lingkai Dong
Meano
Werner Lewis
Jaeden Amero
Hugues Kamba
Martin Kojtal
reme
jeromecoutant
Jamie Smith
Rajkumar Kanagaraj