Add PSA build components to build configuration for non-PSA targets

[orenc17]

Description

• Added PSA components to base Target in targets.json
• This is the first PR in a series of PSA related PR's
• The main purpose of this PR is to allow integration with PSA-Crypto

Full list of components and assignment to targets is listed below:

Label \ Core	V7-single [Target]	V7-dual NSPE [NSPE_Target]	V7-dual SPE [SPE_Target]	V8-NS [NSPE_Target]	V8-S [SPE_Target]
PSA_SRV_IMPL	V		V		V
PSA_SRV_EMUL	V
PSA_SRV_IPC		V	V	V	V
SPE			V		V
NSPE	V	V		V
SPM_MAILBOX		V	V
SPM_MAILBOX/NSPE		V
SPM_MAILBOX/SPE			V

• PSA_SRV_IMPL - include secure service business logic implementation code. For example mbedCrytpo or secure time core logic
• PSA_SRV_EMUL - include a wrapper code for non-PSA platforms, that provides PSA API compliance, by directly invoking code from PSA_SRV_IMPL
• PSA_SRV_IPC - include a wrapper code for PSA platforms that calls IPC PSA API for invoking PSA_SRV_IMPL in SPE
• SPE - include code that compiles ONLY to secure image and never compiles to non-secure image
• NSPE - include code that compiles ONLY to snon-secure image and never compiles to secure image
• SPM_MAILBOX - include mailbox driver implementation code for multicore targets

Pull request type

[ ] Fix
[ ] Refactor
[X] Target update
[ ] Functionality change
[ ] Docs update
[ ] Test update
[ ] Breaking change

@theotherjimmy @Patater @alzix

[Patater]

Code looks okay, but the commit message should explain how this works and why the default target gets the values it does.

Are any tests needed to check this is working as expected? What if someone adds a new target and they use "components" instead of "components_add"? It seems a bit fragile in that regard.

[alzix]

@Patater, components_add is the best we came up with with current configuration system. If onyobe have better ideas, please do share, we are open for suggestions.

Regarding tests, it was tested manually. I do not see how you can we test configuration changes automatically. The changes are in configuration and not in the parser code.

Regarding the commit message, @orenc17, can you please reword commit message.

[alzix]

LGTM

[mikisch81]

@Patater, the problem you raise can already happen with this inheritance scheme, take for example the FAMILY_STM32 target, it defines 'extra_labels': ["STM'], any target which inherits FAMILY_STM32 might override it if it does 'extra_labels' instead of'extra_labels_add'. So as Alex pointed out this is the best (and least invasive) solution we found for integrating PSA with the mbed black-list approach.

[theotherjimmy]

Seems fine to me.

[Patater]

My testing concern is not about testing this as-is, but testing for regressions introduced by new targets that don't know they shouldn't use "components".

As @mikisch81 points out, it seems we also need a test for extra_labels regressions as well, but that's out of scope of this PR.

Another issue is that the commit message isn't up to our standards (https://os.mbed.com/docs/latest/reference/workflow.html#guidelines-for-github-pull-requests)

[cmonr]

I too am confused by the difference between components vs ``components_add`.

Would it be possible to clarify?

[alzix]

@cmonr,
We have sort of inheritance of configurations in our targets.json
Descendents can either override parent values or extend it.

• "components" are the property name. Thus using it will override the set specified by parent.
• "components_add" used to extend the list specified by parent by appending new values to it.

[alzix]

I want to emphasize that the PR only configures targets slightly different ba adding PSA related components to default target. This may seem unclear for now, as this is a initial commit for allowing integration with other modules. You can take a look at https://github.com/kfnta/mbed-os/tree/feature-psa for more details.
The idea to provide an infrastructure for partitioning mbed-os sources for building different set of sources for secure and non-secure core images.

[NirSonnenschein]

Work seems to have been addressed:
/morph build

[mbed-ci]

Build : SUCCESS

Build number : 3597
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/8680/

Triggering tests

/morph test
/morph export-build
/morph mbed2-build

[mbed-ci]

Exporter Build : SUCCESS

Build number : 3202
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/exporter/8680/

[mbed-ci]

Test : FAILURE

Build number : 3374
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/8680/3374

[NirSonnenschein]

re-try for seemingly unrelated network issue:
/morph build

[mikisch81]

re-try for seemingly unrelated network issue:

I checked locally and network-interface test also fails on mbed-os master branch.

[0xc0170]

restarting the build

/morph build

[mbed-ci]

Build : SUCCESS

Build number : 3600
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/8680/

Triggering tests

/morph test
/morph export-build
/morph mbed2-build

[mbed-ci]

Test : FAILURE

Build number : 3377
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/8680/3377

[mikisch81]

@0xc0170 @NirSonnenschein guys is it safe now to re-trigger the tests?

[NirSonnenschein]

@mikisch81 unfortunately CI is still not stable yet, we will try to re-run as soon as it is working as expected.

[cmonr]

/morph build

[cmonr]

@Patater

As @mikisch81 points out, it seems we also need a test for extra_labels regressions as well, but that's out of scope of this PR.

This would make for a good issue topic so that we can track and assign work to it.
Also, if that's you're last witholding, could you mark your review as good?

@alzix Thanks for the clarification on the difference between labels. Should we expect any kind of documentation around the new label?

[mbed-ci]

Build : SUCCESS

Build number : 3614
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/8680/

Triggering tests

/morph test
/morph export-build
/morph mbed2-build

[mbed-ci]

Exporter Build : FAILURE

Build number : 3218
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/exporter/8680/

[cmonr]

/morph export-build

[mbed-ci]

Test : FAILURE

Build number : 3393
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/8680/3393

[mbed-ci]

Exporter Build : SUCCESS

Build number : 3220
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/exporter/8680/

[mikisch81]

Rebased on top of master branch

[NirSonnenschein]

/morph build

[mbed-ci]

Build : SUCCESS

Build number : 3617
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/8680/

Triggering tests

/morph test
/morph export-build
/morph mbed2-build

[adbridge]

@Patater Could you please check if you are now happy with these changes ?

[mbed-ci]

Exporter Build : SUCCESS

Build number : 3225
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/exporter/8680/

[mbed-ci]

Test : SUCCESS

Build number : 3399
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/8680/3399

[mikisch81]

@cmonr So it can be merged, there are a couple of PRs dependent on this PR.

[alzix]

LGTM

[cmonr]

#8730 (comment)

@ARMmbed/mbed-os-maintainers According to this description, this appears like it came in too soon?

Fingers crossed that's not the case.

[mikisch81]

#8730 (comment)

@ARMmbed/mbed-os-maintainers According to this description, this appears like it came in too soon?

Fingers crossed that's not the case.

That's not the case, the 2 PRs are not dependent, the kvstore PR has nothing to do with this PR.