Add Musca B1 target

[GaborAbonyi]

Added Arm Musca B1 as a new target. Prebuilt secure binaries also added.

Summary of changes

These targets are defined:

• ARM_MUSCA_B1 as the base target with common code for Secure/Non-secure worlds.
• ARM_MUSCA_B1_NS as the non-secure target.
• ARM_MUSCA_B1_S as the secure target.

Impact of changes

Now mbed-os can be compiled to Musca B1 target

Migration actions required

Documentation

To build an overall Musca B1 image containing secure and non-secure with a pre-compiled bootloader:

mbed compile -t $TOOLCHAIN -m ARM_MUSCA_B1_S --app-config $MBED_OS_ROOT/tools/psa/tfm/mbed_app.json
mbed compile -t $TOOLCHAIN -m ARM_MUSCA_B1_NS

To rebuild special SPM IPC test secure-side binaries:

mbed test --compile -t GCC_ARM -m ARM_MUSCA_B1_S --app-config tools/psa/tfm/mbed_app.json -n tests-psa-spm_smoke -DUSE_PSA_TEST_PARTITIONS -DUSE_SMOKE_TESTS_PART1 --profile release
mbed test --compile -t GCC_ARM -m ARM_MUSCA_B1_S --app-config tools/psa/tfm/mbed_app.json -n tests-psa-spm_client -DUSE_PSA_TEST_PARTITIONS -DUSE_CLIENT_TESTS_PART1 --profile release
mbed test --compile -t GCC_ARM -m ARM_MUSCA_B1_S --app-config tools/psa/tfm/mbed_app.json -n tests-psa-spm_server -DUSE_PSA_TEST_PARTITIONS -DUSE_SERVER_TESTS_PART1 -DUSE_SERVER_TESTS_PART2 --profile release

---

Pull request type

[X] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

---

Test results

[] No Tests required for this change (E.g docs only update)
[X] Covered by existing mbed-os tests (Greentea or Unittest)
[] Tests / results supplied as part of this PR

Greentea tests run with both GCC_ARM and ARMC6 toolchain:
greentea_musca_B1_profile_release_armc6.log
greentea_musca_B1_profile_release_gcc_arm.log
All tests passed except for tests-mbed_hal-trng, as Musca B1 does not have TRNG support.

---

Reviewers

---

[ciarmcom]

@GaborAbonyi, thank you for your changes.
@ashok-rao @ARMmbed/mbed-os-core @ARMmbed/mbed-os-maintainers @ARMmbed/mbed-os-tools @ARMmbed/mbed-os-storage please review.

[0xc0170]

All tests passed except for tests-mbed_hal-trng, as Musca B1 does not have TRNG support.

Should not fail the test but rather skip so all fine. I can see from the logs it timeouted, why?

[GaborAbonyi]

All tests passed except for tests-mbed_hal-trng, as Musca B1 does not have TRNG support.

Should not fail the test but rather skip so all fine. I can see from the logs it timeouted, why?

The mbed_hal trng test does not have TEST_SKIP or similar conditions, so it is always run if built.
The build has this guard:

#if !DEVICE_TRNG
#error [NOT_SUPPORTED] TRNG API not supported for this target
#else

But in targets.json, NSPE_Target is defined (which is inherited by Musca-B1) to have TRNG, but for Musca-B1 it is not the case.
I believe there is the same issue with Musca-A1 target.

[0xc0170]

If that is the case, you can remove it. Add to targets.json file: device_has_remove

[GaborAbonyi]

If that is the case, you can remove it. Add to targets.json file: device_has_remove

Thanks, it seems to be the right way. I checked and it has some other consequences I also have to rerun the greentea tests. I'll check and get back with the results.

[GaborAbonyi]

If that is the case, you can remove it. Add to targets.json file: device_has_remove

Thanks, it seems to be the right way. I checked and it has some other consequences I also have to rerun the greentea tests. I'll check and get back with the results.

I checked if it is feasible to add device_has_remove: ["TRNG"], but it breaks complicated dependencies in PSA library, so I revisited the TRNG issue.
It turns out to be a host issue. I previously run the test from a WSL shell, but now I see that it had issues to reconnect the serial port after resetting the device (which is a step in TRNG test). Rerunning the test from cygwin passed:
greentea_musca_B1_profile_release_armc6_trng_cygwin.log

[0xc0170]

CI started

[mbed-ci]

Test run: FAILED

Summary: 2 of 4 test jobs failed
Build number : 1
Build artifacts

Failed test jobs:

• jenkins-ci/mbed-os-ci_build-ARM
• jenkins-ci/mbed-os-ci_build-GCC_ARM

[0xc0170]

Please review failures (build logs above)

[GaborAbonyi]

Please review failures (build logs above)

crypto_access_control build failed because the secure partition size on Musca B1 is only 320KB, and this test would need around 500 KB. Is there a way to disable that test for this target?

[0xc0170]

crypto_access_control build failed because the secure partition size on Musca B1 is only 320KB, and this test would need around 500 KB. Is there a way to disable that test for this target?

@Patater is there a reason for the test to require that much ? Is there a way to fix this or the only way to have target skip this test (we often prefer if we test on all targets rather than having specific rules per target)

[GaborAbonyi]

crypto_access_control build failed because the secure partition size on Musca B1 is only 320KB, and this test would need around 500 KB. Is there a way to disable that test for this target?

@Patater is there a reason for the test to require that much ? Is there a way to fix this or the only way to have target skip this test (we often prefer if we test on all targets rather than having specific rules per target)

If I add the secure binary to the prebuilt binaries with this command:
mbed test --compile -t GCC_ARM -m ARM_MUSCA_B1_S --app-config tools/psa/tfm/mbed_app.json -n tests-psa-crypto_access_control -DUSE_PSA_TEST_PARTITIONS -DUSE_CRYPTO_ACL_TEST --profile release
This way it compiles to just below 320KB, I can verify if greentea tests are working in a few hours.
There is another platform that already has this: 'targets/TARGET_NXP/TARGET_MCUXpresso_MCUS/TARGET_LPC55S69/TARGET_M33_NS/prebuilt/README.md' This platform has the same CPU as well.

Pull request has been modified.

[GaborAbonyi]

This way it compiles to just below 320KB, I can verify if greentea tests are working in a few hours.

I run the tests and they passed for both GCC and ARMC6:
greentea_musca_B1_20200221_profile_release_gcc_arm_psa_crypto_access_control.log
greentea_musca_B1_20200221_profile_release_armc6_psa_crypto_access_control.log

I also corrected the format of the targets.json to match the rest of the file.

[0xc0170]

CI restarted

[mbed-ci]

Test run: FAILED

Summary: 1 of 11 test jobs failed
Build number : 2
Build artifacts

Failed test jobs:

• jenkins-ci/mbed-os-ci_cloud-client-pytest

[GaborAbonyi]

It seems there is some environmental issue in the tests. K66F test board is not properly connected.
mbed-os-ci_cloud-client-pytest
It failed for other PRs too. What is the way forward from this?

[0xc0170]

I restarted the test. I already reported this earlier today, we will need to investigate (it affects most of PRs today).