For backwards compatibility reasons, as the Mbed tools must be able to
build any online-compiler-supported version of Mbed, revert back to
emitting a warning when ARMC5 is used. This will enable ARMC5 to
continue working in the online compiler for Mbed OS 5 and other previous
versions. ARMC5 remains unsupported in Mbed 6.
This reverts commit 03d57b7ba2.
The PSA-implementing secure binary is not built using Mbed OS build
tools anymore. Instead, the TrustedFirmware-M (TF-M) build system is
used to produce the secure binary. As such, we remove PSA related hooks
from the build system, remove PSA related scripts from tools/test
folder, and also remove the psa-autogen job from travis which was
running the now unecessary and removed generate_partition_code.py.
Remove the ability to generate new PSA binaries in the old manner, where
Mbed OS implements PSA. We don't yet remove any PSA binaries or break
the currently checked-in Mbed-implemented PSA support. PSA targets
integrated in the old manner will continue working at this point.
Signed-off-by: Devaraj Ranganna <devaraj.ranganna@arm.com>
Signed-off-by: Jaeden Amero <jaeden.amero@arm.com>
Display a post-build warning indicating to the user that the standard C
library was used instead of the small C library if the former is not
supported.
- By default, Mbed OS build tools use standard C library for all supported toolchains.
It is possible to use smaller C libraries by overriding the "target.default_lib" option
with "small". This option is only currently supported for the GCC_ARM toolchain.
This override config option is now extended in the build tool for ARM toolchain.
- Add configuration option to specify libraries supported for each toolchain per targets.
- Move __aeabi_assert function from rtos to retarget code so it’s available for bare metal.
- Use 2 memory region model for ARM toolchain scatter file for the following targets:
NUCLEO_F207ZG, STM32F411xE, STM32F429xI, NUCLEO_L073RZ, STM32F303xE
- Add a warning message in the build tools to deprecate uARM toolchain.
- NewLib-Nano C library is not supporting floating-point and printf with %hhd,%hhu,%hhX,%lld,%llu,%llX
format specifier so skipping those green tea test cases.
Change the heuristic for selection of CMSE in the tools python, so that
a non-TrustZone ARMv8 build can happen.
Ideally we would have more direct flagging in the targets, but this
refines the heuristic so the necessary behaviour can be easily
achieved.
* DOMAIN_NS=1 is based purely on the `-NS` suffix on the core name.
* Enabling CMSE in the compiler and outputting a secure import library
is now enabled when the core doesn't have an `-NS` suffix by either
the target label `TFM` being present or the flag `trustzone` being set.
This covers the existing ARMv8-M behaviour - TF-M builds have the TFM
label, as per its documentation; M2351 secure builds have no explicit
flagging, so we ensure that the M2351_NS target has the trustzone flag
set, and the out-of-tree secure target inherits that.
* For ARMC6, core types `Cortex-M4` and `Cortex-M7` did not explicitly
add `--fpu=none`, so it defaulted to assuming FPU present. This would
cause a compilation error if the target's cmsis.h had `__FPU_PRESENT`
defined to 0.
* For GCC, `Cortex-M33FE` did not include `+dsp` in the architecture
selection.
* For ARMC5 and ARMC6, `Cortex-M0+` did not pass `M0plus` to the
non-Clang tools.
The sct file path generated in the online compiler
is incorrect. Fix that by changing the correct_scatter_shebang
API to accept a FileRef object instead and use the path.
This change should go with change in online compiler that removes
the override for correct_scatter_shebang.
There are two new functions: get_valid_toolchain_names and
find_valid_toolchain. These functions are used to figure out if a
fallback is possible and necessary. find_valid_toolchain is expected to
be used by the front-end scripts.
get_toolchain_name was updated with some different logic and comments.
On Windows 7 using --preproc option in ARMC6 assembler doesn't work
when -MD option is also specified. Compiler creates incorrect filename for
dependency file and compilation files.
To workaround this issue, this change returns to using a temporary file and
separately calling preprocessor and assembler (as in a case of ARMC5).
The "hook tools" were capable of hooking into many commands run by the build system.
To my knowlage, the only hook is the "post-build-hook". The post build hook could be
easier to reason about if the implementation is specialized for just post-build
hooking.
This commit make it much easier to point out where post build hooks are called by
making the call explicit.