When building greentea tests, each test is an executable with its
own output binary path. This is also the case when a user project
produces multiple executables. But the current implementation of
post-build operations always assumes there's only one executable,
at the root of the build directory.
The post-build command depends on Mbed target, and it always takes
the the executable we build as an input file. To achieve this, we
let each Mbed target (that has a post-build command) define a function
function(mbed_post_build_function target)
which takes a CMake executable target as an argument from which it can
get its binary path using generator expressions. It generates and adds
to the passed executable target a post-build custom command.
Notes:
* The function name needs to be exact, because CMake only supports
literal function calls - CMake can't dereference a function name from
a variable. To avoid multiple definitions of this function, each Mbed
target needs to guard it with a macro to check if the user is
building this Mbed target.
* `mbed_post_build_function()` is a function, but it is usually
defined by another macro rather than a parent function, because
nesting functions would make many variables inaccessible inside the
innermost `mbed_post_build_function()`.
* There's no more need to force regenerate images. Previously, post-
build commands were custom *targets* which always got to run, so we
force regenerated images on every build to avoid patching an image
that's already been patched once on previous build. Now post-build
commands are custom *commands* of the same executable target, and they
are only run if the executable target itself is rebuilt.
The 'post build' functions are made visible by adding the mbed-os
subdirectory. This is not ideal as any components in mbed-os wishing to
call the functions must be added after the functions are defined. To
improve modularity move these functions to a separate CMake script.
We include the post build CMake script in app.cmake for now so we don't
break user's projects.
This helps to allow installation of Mbed OS's Python requirements, when
CMake is used, into the same Python environment as mbed-os-tools. The
versions specified here are aligned with mbed-os-tools;
tools/cmake/requirements.txt depends on the same version of prettytable
as mbed-os-tools's requirements.txt.
The stdio implementation of the standalone greentea-client wasn't
streaming "KiVi protocol" messages through the serial IO. Separate out
the existing implementation for greentea-client that uses
mbed_retarget.h's `read` and `write` functions so greentea tests
continue to work with the standalone client.
The IO fixture is shared between the "legacy" embedded greentea-client
and the newer standalone client.
Currently we have `MBED_TEST_LINK_LIBRARIES` for specifying
* Whether to link `mbed-os` or `mbed-baremetal`
* Any additional libraries we want tests to link
It's not fit for purpose anymore, because
* No flavor of Mbed OS is selected by default, but we should've
really defaulted to `mbed-os`, the full RTOS version. Build doesn't
work unless `-DMBED_TEST_LINK_LIBRARIES=<...>` is passed, which
is redundant.
* A test should never need additional libraries passed via command
line - its `CMakeLists.txt` should specify what it links.
This commit replaces `MBED_TEST_LINK_LIBRARIES` with a new option
`MBED_TEST_BAREMETAL` to build a test with either RTOS (default)
or without it (by passing `-DMBED_TEST_BAREMETAL=ON`).
The mbed_greentea_add_test macro required a greentea test to set an
MBED_PATH variable to the path of the mbed-os root directory, which it
attempts to add as a 'subdirectory' of the test project. We can instead
use CMake's built in CMAKE_CURRENT_LIST_DIR variable to deduce the path
to mbed-os relative to the current list file directory, removing the
need for greentea tests to set MBED_PATH.
Assumption that greentea test file is always named main.cpp is
incorrect. Updated mbed_greentea_add_test() macro to make TEST_SOURCES
parameter compulsory, which is used to specify greentea test
file(s). This allows tests to use C, or have a different name.
Therefore also updated all pre-existing greentea test CMake files to
explicity add main.cpp to TEST_SOURCES.
The mbed_greentea_add_test macro previously set a variable in order to
use the un-prefixed TEST_NAME to refer to the argument in the macro
body. Whilst pair-programming with LDong, this was identified and
determined to be unecessary (maybe it was a failed attempt to fix
something, that was never reversed?) and so it has been removed.
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
Fixes#14494
MBED_TEST_MODE is required for backward compatibilty with CLI1. This
adds a test to ensure that the macro is created when using CLI2 for
testing. This also adds a test in `.travis.yml` that checks whether
CMake defines the macro when BUILD_TESTING is on.
CLI1 Reference: https://os.mbed.com/docs/mbed-os/v6.9/debug-test/greentea-for-testing-applications.html
Also, explicitly create and set the macro BUILD_TESTING to allow for
MBED_TEST_MODE to be defined by CMake. MBED_TEST_MODE is required for
backward compatibilty with CLI1. BUILD_TESTING is used to determine
whether to define MBED_TEST_MODE. Normally, this would be automatically
done by CTest (which we intend to add for test automation) but this
hasn't yet been added to our Greentea tests.
Due to a known issue in Mbed TLS's architecture determination
(ARMmbed/mbedtls#1077), we get the error
error: inline assembly requires more registers than available
when compiling `bignum.c` for Cortex-M0/0+/1/M23 which do not have
the macro `__thumb2__` set by the compiler.
The workaround is to define the macro `MULADDC_CANNOT_USE_R7` which
is already defined by Mbed CLI 1 but missing in our CMake support.
FixesARMmbed/mbed-os-example-lorawan#220
Update CMAKE_MODULE_PATH at once place.
Note, we update also CMAKE_MODULE_PATH in app.cmake. This is temporary until we get a proper way to include
Mbed Os (removing app.cmake need to be included by an application).
To avoid conflicts as we expose our CMake list files via CMAKE_MODULE_PATH. Some files already include it, this
aligns the rest of files.
I leave app.cmake as it is - it's user facing and it would be breaking change. We can clean this one for the next major version.
All files within tools/cmake can now include within tools/cmake. We do not expose
internal folders like core/profiles/toolchains.
They should be included via toolchain file (mbed_toolchain in our case).
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).
- No longer need to create mbed_os.lib and soft link to mbed-os as new
--mbed-os-path command-line removes such dependency and creates mbed_build.cmake
when passing mbed-os path with that command line argument.
In targets.json, ARM_MUSCA_B1 and ARM_MUSCA_S1 have alias target
names suffixed with `_NS`. They are identical to targets without
`_NS` and exist purely for compatibility with the old naming
convention we had. The CI builds them as separate targets and uses
extra resources.
As we are upgrading Musca targets to TF-M v1.2, it's time to clean
up the aliases.
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.
There should not be a reference to APP_TARGET in Mbed OS as end-users
may decide to use a different name for the CMake variable to store their
application name.
The CMake custom target must be unique to avoid more than one
Mbed target adding the same. Only the CMake custom command added for the
Mbed target being built is run as the custom CMake target now includes
the Mbed target name.
We need to generate a "response file" to pass to the C preprocessor
when we preprocess the linker script, because of path length limitations
on Windows. We set the response file and bind the path to a global
property. The MBED_TARGET being built queries this global property when
it sets the linker script.
We must set this global property before the targets subdirectory is
added to the project. This is required because the MBED_TARGET depends
on the response file. If the path to the response file is not defined
when the target requests it the config definitions will not be passed
to CPP.
Lingkai Dong
Robert Walton
Jaeden Amero
Hari Limaye
Meano
Werner Lewis
Martin Kojtal
harmut01
Hugues Kamba
Rajkumar Kanagaraj
Ladislas de Toldi