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.
PSoC 64 secure BSP post-build hook (cysecuretools image signing)
expects the HEX file with start address 0x10000400 (first KB of
internal FLASH is reserved for MCUboot headers area).
In order to get the correct HEX file produced by ARM fromELF tool,
the ELF file should allocate LR_IROM1 starting from address
0x10000400, not 0x10000000. Otherwise the generated HEX file
allocates rows at addresses 0x10000000 ~ 010000400 and the
final application image is not signed correctly.
Fixes https://github.com/ARMmbed/mbed-os/issues/13058.