Use instead the general TF-M v8-M virtual NVIC which will be added in
the commit that replaces Mbed PSA with TF-M PSA:
features/FEATURE_PSA/TARGET_TFM/TARGET_TFM_V8M/src/cmsis_nvic_virtual.c
When python3 is enforced to build the ARM_MUSCA_A1 or ARM_MUSCA_B1
targets, it is unable to find binary utility tool scripts which are
imported from TF-M.
The reason to use the python3 environment is as follows: Mbed OS + TFM
contained a faulty boot record TLV, which failed the attestation test
(TF-M regression). The data in the boot record TLV will be included in
the generated attestation token as 1 item in the SW_COMPONENTS claim.
This data (in the boot record TLV) is pre-encoded in CBOR format at
build time and appended to the image during the image signing process
(done by the imgtool Python3 script).
Signed-off-by: Vikas Katariya <vikas.katariya@arm.com>
Partially revert f38e21fa6c ("Update PSoC 6 BSPs to verion 1.2") to
restore TF-M compatibility.
Make the CY8CKIT_064S2_4343W target TF-M compatible by addding flash and
region definitions from TF-M (at c4f37c18c4a0) and by updating the
CY8CKIT_064S2_4343W linker script to create a flash image compatible
with TF-M.
Fixes: f38e21fa6c ("Update PSoC 6 BSPs to verion 1.2")
Signed-off-by: Jaeden Amero <jaeden.amero@arm.com>
Since Mbed OS 6.0, secure build is not supported yet. Remove it from master temporarily.
For non-TF-M support (NU_PFM_M2351_NPSA_S/NS), go to mbed-os-5.15 branch and Mbed OS 5.15 release.
For TF-M support (NU_PFM_M2351_S/NS), this needs M2351 integrated into TF-M repo first.
Expect M2351 TF-M support can come back into master after integration with TF-M is finished.
Having Freescale and NXP macro causes compile from both
TARGET_Freescale and TARGET_NXP HAL folders.
Signed-off-by: Mahesh Mahadevan <mahesh.mahadevan@nxp.com>
This allows the application to inject its own resource reservations
immmediately after the BSP (and therefore HAL) is initialized,
ensuring that they can claim require resources before mbed tries
to use them for more flexible purposes. For example, the application
might want to claim a particular timer to make sure that it doesn't
get picked for us_ticker (which can use any arbitrary timer instance).
A running timer will block DeepSleep, which would normally be
good because we don't want the timer to accidentally lose counts.
We don't care about that for us_ticker (If we're requesting deepsleep
the upper layers already determined that they are okay with that),
so explicitly stop the us_ticker timer before we go to sleep and
start it back up afterwards.
Fixes: #13109
Prior to this commit, target implementations of NanostackRfPhy
are not guarded by any mbed_lib.json - they are always visible
to the build even if the interface itself is not enabled
(e.g. when using the "requires" attribute of mbed_app.json).
It causes build errors.
To resolve this, this commit move target code into
nanostack-interface, similar to what we do with BLE targets.