This needs to be removed as there should not be a
name requirement for application CMake variable name.
Furthermore, in certain uses cases it prevents
successful builds for some Mbed targets. For instance
when building Greentea test applications for Mbed
targets that require post build operations as they do
not define APP_TARGET.
Raise an exception in case of a failure to find an image to use
for the binary signature. This prevents the method from assuming
the image is always successfully retrieved and crash when
attempting to print a message
The CMake custom target must be unique to avoid more than one
Mbed target adding the same. Only the CMake custom command added for the
Mbed target being built is run as the custom CMake target now includes
the Mbed target name.
Refactor all Cypress targets to be CMake buildsystem targets. This removes
the need for checking MBED_TARGET_LABELS repeatedly and allows us to be
more flexible in the way we include MBED_TARGET source in the build.
A side effect of this is it will allow us to support custom targets
without breaking the build for 'standard' targets, as we use CMake's
standard mechanism for adding build rules to the build system, rather
than implementing our own layer of logic to exclude files not needed for
the target being built. Using this approach, if an MBED_TARGET is not
linked to using target_link_libraries its source files will not be
added to the build. This means custom target source can be added to the
user's application CMakeLists.txt without polluting the build system
when trying to compile for a standard MBED_TARGET.
A CMake custom target, mbed-post-build, is added as a dependency of the
application CMake target if a Mbed target adds a CMake custom target
named mbed-post-build-bin. mbed-post-build-bin is added as a dependency
of mbed-post-build. mbed-post-build-bin depends on the application binary.
This is done so a CMake custom command that executes post-build can be added.
The Python scripts that implement the operations have been modified to add
CLI entry points so they can be called from CMake. Dependency on the old
tool has been removed on those scripts by passing them exactly what they
require instead of passing old tool Python objects. A consequence of that
was to slightly amend how the old tool calls some of those Python modules.
Support has only been added for Mbed targets that currently have a requirement
for post build operations. This includes: LPC1114, LPC1768, ARCH_PRO, LPC54114,
LPC546XX, FF_LPC546XX, CY8CKIT064B0S2_4343W, CYTFM_064B0S2_4343W, CYSBSYSKIT_01
The following targets are not supported as TFM support is not yet included:
ARM_MUSCA_B1, ARM_MUSCA_B1_NS, ARM_MUSCA_S1, ARM_MUSCA_S1_NS.
This change allows external memory to be used for other purposes while
the WiFi firmware is stored in it by interacting with it via the
reserved region block device.
Given an underlying block device and the size of the reserved region, a
CyReservedRegionBlockDevice will act as the underlying block device but
operating only outside of the reserved region. It also allows reading
from the reserved region. The reserved region is assumed to start at
address 0 in the underlying block device.
In some toolchains, in order to use linker symbols referring to the
start and end of a region, the region name must not contain a '.'
character. These changes allow those symbols to be used for the cy_xip
region by renaming it. They also create explicit start and end symbols
for GCC.
Add license identifier to files which Arm owns the copyright to,
and contain either BSD-3 or Apache-2.0 licenses. This is to address
license errors raised by scancode analysis.
Workaround a bug where the boot stack size configuration option is not
passed on to armlink, the Arm Compiler's linker. Prefer
MBED_CONF_TARGET_BOOT_STACK_SIZE if present, as this is what the
configuration system should provide. Fall back to MBED_BOOT_STACK_SIZE
if MBED_CONF_TARGET_BOOT_STACK_SIZE is not defined, as in the case of
buggy tools. If both MBED_CONF_TARGET_BOOT_STACK_SIZE and
MBED_BOOT_STACK_SIZE are not defined, then we fall back to a hard-coded
value provided by the linkerscript. See
https://github.com/ARMmbed/mbed-os/issues/13474 for more information.
To allow overriding of the boot stack size from the Mbed configuration
system, consistently use MBED_CONF_TARGET_BOOT_STACK_SIZE rather than
MBED_BOOT_STACK_SIZE.
Fixes#10319
Add TF-M to Mbed OS, replacing the previous PSA implementation for
TF-M-capable targets. This commit adds files imported from TF-M, without
modification. The version of TF-M imported can be found in
`features/FEATURE_PSA/TARGET_TFM/VERSION.txt`.
These changes switch to TF-M as the sole PSA implementation for v8-M and
dual core targets, with TF-M running on the secure side and Mbed OS
running on the non-secure side. Single core v7-M targets will continue
to have PSA implemented via PSA emulation, implemented by Mbed OS.
Move or remove many PSA-implementing files, as PSA will be provided by
TF-M on non-single-v7-M targets. Delete any files that are not relevant
for PSA emulation mode.
- Remove imported TF-M SPM
- Remove Mbed SPM and tests
- Remove Mbed-implemented PSA services and tests
- Remove PSA_SRV_IMPL, PSA_SRV_IPC, PSA_SRV_EMUL and NSPE.
- Replace PSA_SRV_EMUL and PSA_SRV_IMPL with MBED_PSA_SRV
- Remove any files autogenerated by
"tools/psa/generate_partition_code.py", which no longer exists.
Add new feature `PSA` to support PSA in Mbed OS.
Move the Mbed OS implementation of PSA services for v7-M targets (which
employ PSA emulation, and don't yet use TF-M) to
features/FEATURE_PSA/TARGET_MBED_PSA_SRV. Update the `requires`
attribute in TESTS/configs/baremetal.json to avoid breaking baremetal
testing builds.
Update .astyleignore to match new directory structure
Update Mbed TLS importer to place files into FEATURE_PSA
Create the following generic PSA targets:
* `PSA_Target` (Root level PSA generic target)
* `PSA_V7_M` (Single v7-M PSA generic target)
* `PSA_DUAL_CORE` (Dual-core PSA generic target)
* `PSA_V8_M` (v8-M PSA generic target)
Flatten MUSCA_NS and private MUSCA targets into public MUSCA targets.
Move mcuboot.bin to flat location (removing prebuilt folder)
Signed-off-by: Devaraj Ranganna <devaraj.ranganna@arm.com>
Signed-off-by: Jaeden Amero <jaeden.amero@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>
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.