The PSA-implementing secure binary is not built using Mbed OS build
tools anymore. Instead, the TrustedFirmware-M (TF-M) build system is
used to produce the secure binary. As such, we remove PSA related hooks
from the build system, remove PSA related scripts from tools/test
folder, and also remove the psa-autogen job from travis which was
running the now unecessary and removed generate_partition_code.py.
Remove the ability to generate new PSA binaries in the old manner, where
Mbed OS implements PSA. We don't yet remove any PSA binaries or break
the currently checked-in Mbed-implemented PSA support. PSA targets
integrated in the old manner will continue working at this point.
Signed-off-by: Devaraj Ranganna <devaraj.ranganna@arm.com>
Signed-off-by: Jaeden Amero <jaeden.amero@arm.com>
Since the offline build is made to auto-generate PSA related components
and services for Secure targets, we can change the output directory to
update the files in the respective locations.
TARGET_PSA
--TARGET_MBED_SPM
--COMPONENT_SPE
psa_setup.c
--TARGET_TFM
--COMPONENT_SPE
--inc
tfm_partition_defs.inc
tfm_partition_list.inc
tfm_service_list.inc
tfm_spm_signal_defs.h
--services
--inc
autogen_sid.h
mbed_spm_partitions.h
The release script is been modified to commit these files if there are
any changes detected when `--commit` argument is passed.
Cleaning of auto-generated is been removed as it uses the main directory
for its operations, but PSA auto-generation will work if any of the
service and application-based manifests are updated.
Signed-off-by: Vikas Katariya <Vikas.Katariya@arm.com>
Only generate PSA headers/source related to components and services
when Secure build is initiated during compile time of PSA targets.
Let the Non-secure build rely on the checked-in files already present.
Signed-off-by: Vikas Katariya <Vikas.Katariya@arm.com>
PSA code generation will be called automatically upon mbed invocation.
The autogenerated files will be created under <mbed-os-root>/PSA_AUTOGEN directory.
The compiler used for the ARM toolchain changes depending on the target.
This changes the front end scripts to do the proper toolchain look up
before checking the system PATH for the compiler executable. The tools
were always checking for the ARMC5 compiler, now it should check for the
right version.
When building secure targets, we would like compile only files that are in the the mbe-os root folder.
This Fixes an issue when sending multiple --source parameters that are all inside the mbed-os tree
Prior to this changeset, applications were all compiled as test #0. This
can lead to unexpected behavoir. In particluar, it's weirdly impossible
to use a `.mbedignore` file to ignore
`mbed-os/features/unsupported/tests/mbed/env/test_env.cpp`.
This PR stops treating applications like tests.
[x] Fix
[ ] Refactor
[ ] Target update
[ ] Functionality change
[ ] Docs update
[ ] Test update
[ ] Breaking change
Some toolchains (GCC) may emit error messages with unicode symbols based on
the your localization settings. Instead of being passed to the user as is,
the unicode causes an exception.
Looks like this:
Building project mbed-os-prettyoutput (ARCH_PRO, GCC_ARM)
Scan: .
Scan: env
Scan: mbed
Scan: FEATURE_LWIP
Text 70.5KB Data 2.72KB BSS 7.43KB ROM 73.2KB RAM 10.1KB
ROM [||||||| ] 73.2KB/512KB
RAM [|||||||||||||||| ] 10.1KB/32KB
Image: BUILD/ARCH_PRO/GCC_ARM/mbed-os-prettyoutput.bin
If you build a target without a cmsis-pack it looks like this:
Building project mbed-os-prettyoutput (ARM_BEETLE_SOC, GCC_ARM)
Scan: .
Scan: env
Scan: mbed
Scan: FEATURE_BLE
Text 99KB Data 2.84KB BSS 13KB ROM 102KB RAM 15.8KB
Image: BUILD/ARM_BEETLE_SOC/GCC_ARM/mbed-os-prettyoutput.bin
And the old behaviour of displaying the memap table can be brought back
by passing the --stats-depth parameter
Removed heap/stack from report
Add --stats-depth option to mbed compile
Fix minor issues identified in review
Fix bug when parsing armcc libs
Fix code style
Fix minor issues on existing tests
Fix memap for automated TESTS
Fix stats-depth parameter for tests
The prior patch in this series makes the assumption that any building
will go through `build_api.prepare_toolchain`. This was not a valid
assumption for the mbed2 build process. So, instead of maintaining 2
ways of using the toolchain classes, I elected to unify on
`prepare_toolchain`.