Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add ARM_MUSCA_A1 target #9221

Merged
merged 21 commits into from May 23, 2019

Conversation

@mikisch81
Copy link
Contributor

commented Jan 2, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Jan 2, 2019

@ciarmcom

This comment has been minimized.

@ciarmcom ciarmcom requested review from theotherjimmy and ARMmbed/mbed-os-maintainers Jan 2, 2019

@mikisch81 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

@theotherjimmy

This comment has been minimized.

Copy link
Contributor

commented Jan 2, 2019

@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

This comment has been minimized.

Copy link
Contributor

commented Jan 2, 2019

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

@mikisch81

This comment has been minimized.

Copy link
Contributor Author

commented Jan 2, 2019

@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:

  1. 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?).
  2. For ARMC6 TF-M use -std=c99 and mbed-os use -std=gnu99.
@mikisch81

This comment has been minimized.

Copy link
Contributor Author

commented Jan 2, 2019

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

#include "../cmsis_nvic.h"

LR_CODE NS_CODE_START NS_CODE_SIZE {

This comment has been minimized.

Copy link
@deepikabhavnani

deepikabhavnani Jan 2, 2019

Contributor

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

This comment has been minimized.

Copy link
@mikisch81

mikisch81 Jan 3, 2019

Author Contributor

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 😄)

This comment has been minimized.

Copy link
@mikisch81

mikisch81 Jan 3, 2019

Author Contributor

Done

This comment has been minimized.

Copy link
@deepikabhavnani

deepikabhavnani Jan 3, 2019

Contributor

@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

This comment has been minimized.

Copy link
@mikisch81

mikisch81 Jan 3, 2019

Author Contributor

@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.

This comment has been minimized.

Copy link
@deepikabhavnani

deepikabhavnani Jan 3, 2019

Contributor

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.

This comment has been minimized.

Copy link
@mikisch81

mikisch81 Jan 3, 2019

Author Contributor

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

This comment has been minimized.

Copy link
@deepikabhavnani

deepikabhavnani Jan 3, 2019

Contributor

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

image

targets/TARGET_ARM_SSG/TARGET_MUSCA_A1/device/COMPONENT_SPE/TOOLCHAIN_ARMC6/musca_s.sct Outdated
LR_CODE S_CODE_START {

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

This comment has been minimized.

Copy link
@deepikabhavnani

deepikabhavnani Jan 2, 2019

Contributor

S_CODE_START and S_CODE_SIZE - From where are these values parsed?

This comment has been minimized.

Copy link
@mikisch81

mikisch81 Jan 3, 2019

Author Contributor

This comment has been minimized.

Copy link
@jeromecoutant

jeromecoutant Feb 6, 2019

Contributor

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"
}

This comment has been minimized.

Copy link
@mikisch81

mikisch81 Feb 6, 2019

Author Contributor

@jeromecoutant This comment is outdated and not relevant anymore.

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

}

LR_VENEER CMSE_VENEER_REGION_START {

This comment has been minimized.

Copy link
@deepikabhavnani

deepikabhavnani Jan 2, 2019

Contributor

Where is CMSE_VENEER_REGION_START defined?

This comment has been minimized.

Copy link
@mikisch81

mikisch81 Jan 3, 2019

Author Contributor
@deepikabhavnani

This comment has been minimized.

Copy link
Contributor

commented Jan 2, 2019

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

@cmonr cmonr requested a review from bulislaw Jan 3, 2019

@mikisch81

This comment has been minimized.

Copy link
Contributor Author

commented Jan 3, 2019

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 mikisch81 force-pushed the kfnta:tfm_musca_a1 branch Jan 3, 2019

@mikisch81

This comment has been minimized.

Copy link
Contributor Author

commented Jan 3, 2019

@deepikabhavnani

This comment has been minimized.

Copy link
Contributor

commented Jan 3, 2019

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

This comment has been minimized.

Copy link
Member

commented Jan 3, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Jan 3, 2019

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

This comment has been minimized.

Copy link
Contributor Author

commented Jan 3, 2019

@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.

mikisch81 and others added some commits Mar 20, 2019

Increase Secure RAM by 4K
- 68KB Secure
- 60KB Non-secure
Fix last issues
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
Use build directory instead of temp directory for for
intermediate files during binaries merge.

@orenc17 orenc17 force-pushed the kfnta:tfm_musca_a1 branch from 4ad26c4 to ed29d64 May 22, 2019

@orenc17

This comment has been minimized.

Copy link
Contributor

commented May 22, 2019

@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

@devran01

This comment has been minimized.

Copy link
Contributor

commented May 22, 2019

@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

This comment has been minimized.

Copy link
Contributor

commented May 23, 2019

@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

This comment has been minimized.

Copy link
Member

commented May 23, 2019

CI started

@devran01

This comment has been minimized.

Copy link
Contributor

commented May 23, 2019

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

@mbed-ci

This comment has been minimized.

Copy link

commented May 23, 2019

Test run: SUCCESS

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

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

@0xc0170

This comment has been minimized.

Copy link
Member

commented May 23, 2019

This is now ready for integration

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

26 checks passed

continuous-integration/jenkins/pr-head This commit looks good
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
jenkins-ci/build-ARM Success
Details
jenkins-ci/build-GCC_ARM Success
Details
jenkins-ci/build-IAR Success
Details
jenkins-ci/cloud-client-test Success
Details
jenkins-ci/dynamic-memory-usage Success
Details
jenkins-ci/exporter Success
Details
jenkins-ci/greentea-test Success
Details
jenkins-ci/mbed2-build-ARM Success
Details
jenkins-ci/mbed2-build-GCC_ARM Success
Details
jenkins-ci/mbed2-build-IAR Success
Details
jenkins-ci/unittests Success
Details
travis-ci/astyle Success!
Details
travis-ci/docs Success!
Details
travis-ci/doxy-spellcheck Success!
Details
travis-ci/events Success! Runtime is 8620 cycles.
Details
travis-ci/gitattributestest Success!
Details
travis-ci/include_check Success!
Details
travis-ci/licence_check Success!
Details
travis-ci/littlefs Success! Code size is 8448B.
Details
travis-ci/psa-autogen Success!
Details
travis-ci/tools-py2.7 Success!
Details
travis-ci/tools-py3.5 Success!
Details
travis-ci/tools-py3.6 Success!
Details
travis-ci/tools-py3.7 Success!
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.