Add ARM_MUSCA_A1 target #9221

mikisch81 · 2019-01-02T10:14:48Z

Description

This PR replaces #8845 as the proting PR of ARM Musca A1.

These targets are defined:

ARM_MUSCA_A1 as the base target with common code for Secure/Non-secure worlds.
ARM_MUSCA_A1_NS as the non-secure target.
ARM_MUSCA_A1_S as the secure target.
- This target is built using the bare-metal profile as described in ISGDEVPREQ-1003.
So to build an overall Musca_a1 image containing secure and non-secure with a pre-compiled bootloader just run these commands:

> mbed compile -t $TOOLCHAIN -m ARM_MUSCA_A1_S --app-config $MBED_OS_ROOT/tools/psa/tfm/mbed_app.json
> mbed compile -t $TOOLCHAIN -m ARM_MUSCA_A1_NS

To build special SPM IPC tests do as follows:

mbed test --compile -t GCC_ARM -m ARM_MUSCA_A1_S --app-config mbed-os/tools/psa/tfm/mbed_app.json -n mbed-os-tests-psa-spm_smoke -DUSE_PSA_TEST_PARTITIONS -DUSE_SMOKE_TESTS_PART1
cd mbed-os/targets/TARGET_ARM_SSG/TARGET_MUSCA_A1/TARGET_MUSCA_A1_NS/device && cp spm_smoke.bin tfm.bin && cd -
mbed test --compile -t GCC_ARM -m ARM_MUSCA_A1_NS -n mbed-os-tests-psa-spm_smoke -DNO_GREENTEA

mbed test --compile -t GCC_ARM -m ARM_MUSCA_A1_S --app-config mbed-os/tools/psa/tfm/mbed_app.json -n mbed-os-tests-psa-spm_client -DUSE_PSA_TEST_PARTITIONS -DUSE_CLIENT_TESTS_PART1
cd mbed-os/targets/TARGET_ARM_SSG/TARGET_MUSCA_A1/TARGET_MUSCA_A1_NS/device && cp spm_client.bin tfm.bin && cd -
mbed test --compile -t GCC_ARM -m ARM_MUSCA_A1_NS -n mbed-os-tests-psa-spm_client -DNO_GREENTEA

mbed test --compile -t GCC_ARM -m ARM_MUSCA_A1_S --app-config mbed-os/tools/psa/tfm/mbed_app.json -n mbed-os-tests-psa-spm_server -DUSE_PSA_TEST_PARTITIONS -DUSE_SERVER_TESTS_PART1 -DUSE_SERVER_TESTS_PART2 --profile debug
cd mbed-os/targets/TARGET_ARM_SSG/TARGET_MUSCA_A1/TARGET_MUSCA_A1_NS/device && cp spm_server.bin tfm.bin && cd -
mbed test --compile -t GCC_ARM -m ARM_MUSCA_A1_NS -n mbed-os-tests-psa-spm_server -DNO_GREENTEA

Full run of Greentea tests hasn't been run yet, unitesting it by running the mbed-os-tests-psa-its and mbed-os-tests-mbed-crypto-sanity test suites.

Currently IAR is not supported.

TODO list

[ ] Full run of Greentea tests

Pull request type

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

Reviewers

@gaborkertesz @theotherjimmy @ashok-rao @dreemkiller @deepikabhavnani @bridadan @alzix

jeromecoutant · 2019-01-02T10:16:51Z

@jamike

ciarmcom · 2019-01-02T12:00:29Z

@mikisch81, thank you for your changes.
@dreemkiller @ashok-rao @theotherjimmy @bridadan @alzix @deepikabhavnani@ARMmbed/mbed-os-maintainers @ARMmbed/mbed-os-tools please review.

theotherjimmy · 2019-01-02T16:15:14Z

@mikisch81 Bare metal profile is not planned to handle changing the meaning of build profiles, and I don't think that it's a good idea (it's mixing concerns for 2, currently independent ideas: what code to include and what flags to use).

theotherjimmy · 2019-01-02T16:16:18Z

@mikisch81 could you expand on why you need the build profiles? what is different between matching profiles?

mikisch81 · 2019-01-02T18:37:25Z

@mikisch81 could you expand on why you need the build profiles? what is different between matching profiles?

@theotherjimmy I encountered 2 issues when trying to build TF-M secure code using mbed-os c like:

All the __wrap__xxx which are added to the linker means that a wrapper for main, malloc, etc. are needed. (Is it preferable to add a file which implements dummy wrappers which call the real functions?).
For ARMC6 TF-M use -std=c99 and mbed-os use -std=gnu99.

mikisch81 · 2019-01-02T18:38:24Z

@bulislaw @donatieng

deepikabhavnani · 2019-01-02T19:19:18Z

targets/TARGET_ARM_SSG/TARGET_MUSCA_A1/device/COMPONENT_NSPE/TOOLCHAIN_ARMC6/musca_ns.sct

+
+#include "../cmsis_nvic.h"
+
+LR_CODE NS_CODE_START NS_CODE_SIZE {


NS_CODE_START and NS_CODE_SIZE - Where are these defines set? Are those configurable?

They are defined in region_defs.h, cmsis_nvic.h includes this file.
But to be honest I think I will add an explicit include in the ld/sct files as well (explicit is better than implicit 😄)

@mikisch81 - We have few common defines (RAM / ROM start and size) already available in the tools, which are picked from CMSIS packages and passed as defines. It will be good to use the same instead of adding new ones.

Please check in build of MUSCA if MBED_RAM_START MBED_ROM_START are defined, if yes you can use them

@deepikabhavnani Yes, I know these defines, we use them in PSOC6.
MUSCA build doesn't define them, it takes the values from region_defs.h which is from the TF-M port of Musca.
I can add a block like in PSOC6 which will set these defines accordingly.

Will appreciate if defines in region_defs.h and linker files are updated and used as PSOC6, it will give flexibility to users instead of hard-coded values.

I think it should be relevant only to NS side, as the secure side only runs TF-M on bare-metal.
Something like this in the NS linker scripts:

#if !defined(MBED_ROM_START) #define MBED_ROM_START NS_CODE_START #endif #if !defined(MBED_ROM_SIZE) #define MBED_ROM_SIZE ((TOTAL_CODE_SRAM_SIZE / 2) - BL2_HEADER_SIZE) #endif #if !defined(MBED_RAM_START) #define MBED_RAM_START NVIC_RAM_VECTOR_LIMIT #endif #if !defined(MBED_RAM_SIZE) #define MBED_RAM_SIZE (NS_DATA_SIZE - NVIC_RAM_VECTOR_SIZE) #endif

TF-M though a bare-metal layer, it has linker files https://github.com/ARMmbed/mbed-os/pull/9221/files#diff-477bb268cd4ef63fbe0f6f161bbfeb7cR25

Change is relevant for secure + non-secure side as well. Idea is to have defines at one place, instead of hard-coded in code, so if someone wants to change the size of secure / non-secure RAM / ROM it all should be at one place. Now it looks like it is region_defs.h

I will propose something like this instead

#if !defined(MBED_ROM_START) #define MBED_ROM_START 0x10200000 #endif #if !defined(MBED_ROM1_START) #define MBED_ROM1_START 0x00200000 #endif #define S_ROM_ALIAS_BASE MBED_ROM_START #define NS_ROM_ALIAS_BASE MBED_ROM1_START #define TOTAL_ROM_SIZE (MBED_ROM_SIZE + MBED_ROM1_SIZE)

MBED_ROM_START / MBED_ROM_SIZE - Will map to IROM1
MBED_ROM1_START / MBED_ROM1_SIZE - Will map to IROM2
and same is for RAM

deepikabhavnani · 2019-01-02T19:20:13Z

targets/TARGET_ARM_SSG/TARGET_MUSCA_A1/device/COMPONENT_SPE/TOOLCHAIN_ARMC6/musca_s.sct

+LR_CODE S_CODE_START {
+
+    /****  This initial section contains common code for TEE */
+    ER_TFM_CODE S_CODE_START S_CODE_SIZE {


S_CODE_START and S_CODE_SIZE - From where are these values parsed?

See this answer

Shouldn't we use value from targets.json inherited from PSA_Target:
"overrides": {
"secure-rom-start": "xx",
"secure-rom-size": "xx",
"non-secure-rom-start": "xx",
"non-secure-rom-size": "xx",
"secure-ram-start": "xx",
"secure-ram-size": "xx",
"non-secure-ram-start": "xx",
"non-secure-ram-size": "xx",
"shared-ram-start": "xx",
"shared-ram-size": "xx"
}

@jeromecoutant This comment is outdated and not relevant anymore.

targets/TARGET_ARM_SSG/TARGET_MUSCA_A1/device/COMPONENT_SPE/TOOLCHAIN_ARMC6/musca_s.sct

deepikabhavnani · 2019-01-02T19:22:37Z

targets/TARGET_ARM_SSG/TARGET_MUSCA_A1/device/COMPONENT_SPE/TOOLCHAIN_ARMC6/musca_s.sct

+
+}
+
+LR_VENEER CMSE_VENEER_REGION_START {


Where is CMSE_VENEER_REGION_START defined?

See this answer

deepikabhavnani · 2019-01-02T19:43:54Z

Since TFM source is pulled in as well, do we need tfm.bin and cmse_lib.o? Mcuboot.bin might still be needed.

mikisch81 · 2019-01-03T09:32:46Z

Since TFM source is pulled in as well, do we need tfm.bin and cmse_lib.o? Mcuboot.bin might still be needed.

Eventually we will need some default pre-compiled binaries in the tree (for CI), need to agree on the location.
@theotherjimmy

mikisch81 · 2019-01-03T13:21:11Z

CC @gaborkertesz

deepikabhavnani · 2019-01-03T14:51:35Z

Eventually we will need some default pre-compiled binaries in the tree (for CI), need to agree on the location.

@ARMmbed/mbed-os-maintainers
With pre-compiled binaries maintenance might be a issue, any change in secure side of code will not be tested unless binaries are added with it. Not sure if everyone has agreed to it, just wanted to put it here

bulislaw · 2019-01-03T17:21:21Z

That's a new platform support, we'll need full test result on all 3 compilers. Why do we need the certificate in the sources? What are the changes to the build profiles and how users are supposed to use the new files? I don't want to force everyone to know about and manually pass path to the files.

deepikabhavnani · 2019-01-03T20:15:48Z

That's a new platform support, we'll need full test result on all 3 compilers

@bulislaw - IAR is not supported for ARMv8 devices (IAR 8.x dependency)

mikisch81 · 2019-01-03T20:22:49Z

@bulislaw

Why do we need the certificate in the sources?

Do you mean the private key used by imgtool.py to sign the concatenated binary?

What are the changes to the build profiles and how users are supposed to use the new files? I don't want to force everyone to know about and manually pass path to the files.

I agree, see my answer to @theotherjimmy, bullet 2 is not relevant anymore as I was able today to build TF-M for ARMC6 with -std=gnu99, if there is a more elegant way to deal with bullet 1 I prefer it.

0xc0170 · 2019-01-04T14:21:31Z

For .bin and .o files, please add readme with description (useful to have how it was compiled - version, and what it contains. also the info from above, when it should be precompiled, might not be clear to everyone?) and also license file

- 68KB Secure - 60KB Non-secure

Imports working McuBoot for reset. Updates microsec ticker driver. Default baudrate is set to 115200 to see TF-M boot messages. Stack top is set to scatter file dependent and not hard-coded.

Use build directory instead of temp directory for for intermediate files during binaries merge.

orenc17 · 2019-05-22T14:34:16Z

@Devran01 I;ve rebased on master and fixed one of your issues.
the flash on the board is a QSPI flash, that is why the flash configuration looks a bit weird.

regarding your last comment i dont see the issue

urutva · 2019-05-22T15:04:56Z

@orenc17 Thanks.
@orenc17 and @0xc0170 Surprisingly even I don't see the discussion on extra_labels_add anymore. Strange. Let me try to summarise, the folders TARGET_PSA, TARGET_MBED_SPM and TARGET_TFM should they be renamed to COMPONENT_* respectively or should they be moved under targets folder?

Also, I couldn't see any issue related to this. I'll create an issue.

alzix · 2019-05-23T06:36:57Z

@Devran01,
These folders have semantic meanings. You are free to move them wherever you wish in a separate PR, but IMO such an effort will have negative ROI.
We chosen to use components and labels. Labels force you to use TARGET_ folders.
Nested components is also new concept for embed-os - not sure if it is even respected by the scanning rules.
All these oddly named folders are side effect of using globbing build system and the fact you need to hide some sources from it. Perhaps one day we may have better solution for managing sources included in build.
I would not recommend moving anything under targets folder, as it is used to host the code contributed by silicon partners.

0xc0170 · 2019-05-23T08:55:05Z

CI started

urutva · 2019-05-23T09:25:44Z

@alzix Thanks for your inputs. I'll create a ticket for future reference.

mbed-ci · 2019-05-23T13:30:54Z

Test run: SUCCESS

Summary: 11 of 11 test jobs passed
Build number : 7
Build artifacts

0xc0170 · 2019-05-23T13:47:56Z

This is now ready for integration

ciarmcom requested review from alzix, ashok-rao, bridadan, deepikabhavnani and dreemkiller January 2, 2019 12:00

ciarmcom requested review from theotherjimmy and a team January 2, 2019 12:00

ciarmcom added the needs: review label Jan 2, 2019

mikisch81 changed the title ~~TF-M integration into Mbed-OS using the ARM_MUSCA_A1 platform~~ WIP: TF-M integration into Mbed-OS using the ARM_MUSCA_A1 platform Jan 2, 2019

deepikabhavnani reviewed Jan 2, 2019

View reviewed changes

targets/TARGET_ARM_SSG/TARGET_MUSCA_A1/device/COMPONENT_SPE/TOOLCHAIN_ARMC6/musca_s.sct Outdated Show resolved Hide resolved

deepikabhavnani reviewed Jan 2, 2019

View reviewed changes

cmonr requested a review from bulislaw January 3, 2019 02:46

0xc0170 added the scope: new-target label Jan 4, 2019

Michael Schwarcz and others added 13 commits May 22, 2019 17:17

Fix secure linker script

71683cb

Increase Secure RAM by 4K

84bde31

- 68KB Secure - 60KB Non-secure

Add license files

c83ef8a

Add serial_tx_pinmap() and serial_rx_pinmap() to serial_api.c

1a182df

Fix PinMap_UART_XX

ef9c272

MUSCA_A1_NS: Add IAR support

0fc629c

Update secure binaries for ARM_MUSCA_A1_S

bde2557

Fix last issues

40627a5

Imports working McuBoot for reset. Updates microsec ticker driver. Default baudrate is set to 115200 to see TF-M boot messages. Stack top is set to scatter file dependent and not hard-coded.

Use build directory in postbuild

67905bd

Use build directory instead of temp directory for for intermediate files during binaries merge.

gpio: indent fix

a115c93

ARM_SSG: mbed_rtx remove empty line

fee07dc

CR changes

ed29d64

Update secure binaries

6348753

0xc0170 added needs: CI release-version: 5.13.0-rc1 and removed needs: work labels May 23, 2019

urutva mentioned this pull request May 23, 2019

TARGET_PSA, TARGET_MBED_SPM and TARGET_TFM folders under COMPONENTS folder #10641

Closed

0xc0170 added ready for merge and removed needs: CI labels May 23, 2019

0xc0170 merged commit b735d73 into ARMmbed:master May 23, 2019

0xc0170 removed the ready for merge label May 23, 2019

ccli8 mentioned this pull request Jul 4, 2019

M2351: Support TFM level 1 #10959

Merged

0xc0170 mentioned this pull request Aug 19, 2019

ARM_MUSCA_A1_NS: nightly fails to build with ARMC6 - internal fault #11257

Closed


		#include "../cmsis_nvic.h"

		LR_CODE NS_CODE_START NS_CODE_SIZE {


		}

		LR_VENEER CMSE_VENEER_REGION_START {

Add ARM_MUSCA_A1 target #9221

Add ARM_MUSCA_A1 target #9221

Conversation

mikisch81 commented Jan 2, 2019 • edited Loading

Description

Full run of Greentea tests hasn't been run yet, unitesting it by running the mbed-os-tests-psa-its and mbed-os-tests-mbed-crypto-sanity test suites.

Currently IAR is not supported.

TODO list

Pull request type

Reviewers

jeromecoutant commented Jan 2, 2019

ciarmcom commented Jan 2, 2019

theotherjimmy commented Jan 2, 2019

theotherjimmy commented Jan 2, 2019

mikisch81 commented Jan 2, 2019

mikisch81 commented Jan 2, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

deepikabhavnani Jan 3, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

deepikabhavnani commented Jan 2, 2019

mikisch81 commented Jan 3, 2019

mikisch81 commented Jan 3, 2019

deepikabhavnani commented Jan 3, 2019

bulislaw commented Jan 3, 2019

deepikabhavnani commented Jan 3, 2019

mikisch81 commented Jan 3, 2019

0xc0170 commented Jan 4, 2019

orenc17 commented May 22, 2019

urutva commented May 22, 2019

alzix commented May 23, 2019

0xc0170 commented May 23, 2019

urutva commented May 23, 2019

mbed-ci commented May 23, 2019

0xc0170 commented May 23, 2019

mikisch81 commented Jan 2, 2019 •

edited

Loading

deepikabhavnani Jan 3, 2019 •

edited

Loading