Support secure/non-secure combined build for non-PSA target:
1. In secure post-build, deliver built secure image to TARGET_NU_PREBUILD_SECURE
directory which is to combine later.
2. In non-secure post-build, merge non-secure image with secure image saved in
TARGET_NU_PREBUILD_SECURE directory.
3. In non-secure post-build, user can also drop pre-built secure image saved in
TARGET_NU_PREBUILD_SECURE directory and provide its own by adding the line below
in mbed_app.json:
"target.extra_labels_remove": ["NU_PREBUILD_SECURE"]
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.
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.
PSA code generation will be called automatically upon mbed invocation.
The autogenerated files will be created under <mbed-os-root>/PSA_AUTOGEN directory.
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.
When the original PSOC6 CM4 hex file contains unalinged text sections
that span through multiple intelhex segments, aligned segments (filled
with zeroes) overlap with the original data segments, resulting in
error thrown by ihex.merge(alignments, overlap='error').
Such hex file can be produced when the ELF is built with ARM MDK Compiler
with --split_sections option:
http://www.keil.com/support/man/docs/armcc/armcc_chr1359124944914.htm
Change the merge strategy to overlap='ignore', so that the overlapping
zero-filled segments are skipped.
DAPLink implementation on Cypress kits cannot handle hex files
with 64 bytes per row: refer to https://github.com/ARMmbed/DAPLink,
source/daplink/drag-n-drop/intelhex.c, hex_line_t struct, data field.
Anna Bridge
Devaraj Ranganna
Rajkumar Kanagaraj
Graham Hammond
jeromecoutant
Chun-Chieh Li
Martin Kojtal
Roman Okhrimenko
Alexander Zilberkant
Michael Schwarcz
Kevin Bracey
Lin Gao
Alexander Zilberkant
Cruz Monrreal
David Saada
Yossi Levy
Jimmy Brisson
Mahesh Mahadevan
Brian Daniels
Senthil Ramakrishnan
Oren Cohen
Volodymyr Medvid
Aleksi Klasila
deepikabhavnani