VSCode exporter was generating a launch config that contained absolute paths to the
compiler executables. It makes more sense to use the executables that are
installed into the system PATH.
When packing data into multiple regions using the `.ANY` directive,
the linker can accidentally overfill an area.
This doesn't normally happen because it defaults to
`--any_placement=worst_fit`, which puts data in the region with
most space.
When we prioritise regions with `.ANY1`/`.ANY2`, it may totally fill
an area, then fail to leave enough space for linker-generated veneers.
We've just seen this error with the new K64F linker map.
Adding `--any-contingency` makes it lower priority when a region is
98% full, avoiding this error.
The option should not have any effect on targets with scatter files
without prioritised `.ANY` directives.
Due to some historical reasons ARMC 5 compiler behaves very
differently compared to others (GCC, IAR, ARM C 6) as it optimizes
performance rather than size (like the others).
All compilers should behave the same way with the same profile,
thus ARM C 5 should also drive towards size (space).
Lots of target code, STM in particular, uses the `register` keyword, so
it'll take a little while to clean up. In the interim, some builds are
producing a lot of warnings. Suppress the warning for now, as `register`
remains legal C++14 and C11, despite C++14 deprecating it.
C++17 removes `register`, so code will need to be cleaned before any
further C++ version update.
Clang warns about reserved user-defined literals by default. This
warning is not terribly helpful; compilers aren't normally in the
habit of warning about use of reserved identifiers. It can interfere
with, for example, deliberate emulation of a future standard
language feature.
The warning was promoted to an error in an mbed client build, due to a
non-C++11 "%s"name occurring in a macro. But the macro itself was never
invoked, so the misinterpretation as C++11 caused no problems other than
this warning. Killing the warning will let that code build on ARMC6.
The code already built on GCC and IAR.
If that macro ever was used, then a separate error about operator ""
name not being defined would be generated, on all 3 toolchains.
This is limited to ARMC6 because as of µVision V5.27 you can't set C++11
for ARMC5.
Also current µVision does not support gnu++14. We should be able to get
is as `<default>`, as it is the default for ARM Compiler 6.10-6.12,
but this option does not work as documented and actually requests
gnu++89 explicitly. So gnu++14 is mapped to gnu++11.
Musca-A1 is a Cortex-M33 based target with security extension enabled.
- ARM_MUSCA_A1 is the non-secure target running mbed-os.
- ARM_MUSCA_A1_S is the secure target running TF-M.
- TF-M sources were imported and patched in previous commits.
- TF-M secure bootloader (McuBoot) for MUSCA_A1 is submitted by a pre-built binary.
- A post-build hook concatenates The secure and non-secure binaries,
signs it and then concatenates the bootloader with the signed binary.
due to partial implementation. Having FUTURE_SEQUANA_M0 and
FUTURE_SEQUANA PSA targets is misleading.
Signed-off-by: Devaraj Ranganna <devaraj.ranganna@arm.com>
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.