- TF-M - lists.trustedfirmware.org

Re: [TF-M] Create another branch for feature development

by David Wang (Arm Technology China)

Hi Edison, It sounds reasonable to evolve the branch management in TF-M because we get more and more contributions in the community. Thanks for raising that. A few comments: >> * Reduce the risk to broke the master branch directly especial when the CI cannot work rightly. This reason of creating dev branch seems like a workaround as CI is not stable. >> * We can use the "master" branch only for release, and in this, we do not need to freeze the patch merging when preparing the release. If we don’t have the feature branches you proposed, then the problem seems to be the same. It's because dev branch is acting as the master branch and the release(master) branch get "git fast-forward" to a point of dev branch when doing the release. Then we still can't stop merging the unnecessary patches in the release unless we do manual rebase which is not what we wanted. For feature branches, I think it's a good idea but we need to make a process/policy about how/when to create the branches, who maintain the branches and the timing of merging this feature. This could align with the roadmap and release plan, e.g. next release will include a few features/bugfixes which are in corresponding branches. Just share my thoughts. Regards, David Wang Arm Electronic Technology (Shanghai) Co., Ltd Phone: +86-21-6154 9142 (ext. 59142) -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edison Ai (Arm Technology China) via TF-M Sent: Wednesday, December 11, 2019 2:16 PM To: Kevin Peng (Arm Technology China) <Kevin.Peng(a)arm.com>; 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Create another branch for feature development Hi Kevin, Yes, you are right. The main point does not break a stable branch, it could be the "master" branch or "release" branch. Your suggest is good for it will not conflict with our current patches(upstream to the master branch). But the users may be more like to fetch code from the master branch for a stable version. We can discuss more about it. For this, I think we should discuss if it is necessary to create another branch for release or the stable version firstly. And for "are we already using feature branches such as feature-twincpu?": Yes, you are right again. But current, only several branches are created for huge features. What I mean it that we should not to merge patch to "master" or "release" branch directly. Or we just merge little change patches to master branch. For others, we can create a dedicated feature branch. For example, PSA FF alignment or even a bug fix. Thanks, Edison -----Original Message----- From: Kevin Peng (Arm Technology China) <Kevin.Peng(a)arm.com> Sent: Wednesday, December 11, 2019 1:43 PM To: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com>; 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: RE: Create another branch for feature development Hi Edison, In your proposal, the new "develop" branch seems to be the current "master" branch and the "master" branch becomes kind of release branch if I'm understand correctly. So why not create a "release" branch instead. And are we already using feature branches such as feature-twincpu? Best Regards, Kevin -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edison Ai (Arm Technology China) via TF-M Sent: Wednesday, December 11, 2019 11:24 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Create another branch for feature development Hi all, I have a proposal to create a "develop"(or something like this) branch in TF-M for our feature development. The reasons for this are: * Reduce the risk to broke the master branch directly especial when the CI cannot work rightly. * We can use the "master" branch only for release, and in this, we do not need to freeze the patch merging when preparing the release. More addition, we can create more branches for big features development, such as "develop/feature_a" or "develop/feature_b". All these new features branch need to be merged to the "develop" branch first and then release to the "master" branch. This is different from the current patch upstream mode, and it needs to spend more time maintaining those branches. But I think it is more convenient for us to develop different features. We do not need to spend more time to fix the conflicts and to do rebase when other patches merge to master branch during patch reviewing. Welcome to comment on this. Thanks, Edison -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 6 months

1
0
0 0

Re: [TF-M] Create another branch for feature development

by Kevin Peng (Arm Technology China)

Hi Edison, In your proposal, the new "develop" branch seems to be the current "master" branch and the "master" branch becomes kind of release branch if I'm understand correctly. So why not create a "release" branch instead. And are we already using feature branches such as feature-twincpu? Best Regards, Kevin -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edison Ai (Arm Technology China) via TF-M Sent: Wednesday, December 11, 2019 11:24 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Create another branch for feature development Hi all, I have a proposal to create a "develop"(or something like this) branch in TF-M for our feature development. The reasons for this are: * Reduce the risk to broke the master branch directly especial when the CI cannot work rightly. * We can use the "master" branch only for release, and in this, we do not need to freeze the patch merging when preparing the release. More addition, we can create more branches for big features development, such as "develop/feature_a" or "develop/feature_b". All these new features branch need to be merged to the "develop" branch first and then release to the "master" branch. This is different from the current patch upstream mode, and it needs to spend more time maintaining those branches. But I think it is more convenient for us to develop different features. We do not need to spend more time to fix the conflicts and to do rebase when other patches merge to master branch during patch reviewing. Welcome to comment on this. Thanks, Edison -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 6 months

2
1
0 0

Create another branch for feature development

by Edison Ai (Arm Technology China)

Hi all, I have a proposal to create a "develop"(or something like this) branch in TF-M for our feature development. The reasons for this are: * Reduce the risk to broke the master branch directly especial when the CI cannot work rightly. * We can use the "master" branch only for release, and in this, we do not need to freeze the patch merging when preparing the release. More addition, we can create more branches for big features development, such as "develop/feature_a" or "develop/feature_b". All these new features branch need to be merged to the "develop" branch first and then release to the "master" branch. This is different from the current patch upstream mode, and it needs to spend more time maintaining those branches. But I think it is more convenient for us to develop different features. We do not need to spend more time to fix the conflicts and to do rebase when other patches merge to master branch during patch reviewing. Welcome to comment on this. Thanks, Edison

5 years, 6 months

1
0
0 0

Secure Interrupt handling - RE: TF-M technical Forum slides and recording

by Ken Liu (Arm Technology China)

Thank Bill for updating this. I want to use this thread to follow up on the topic 'secure interrupt' given in the 1st tech forum. That is a prologue of the scheduler and interrupt designs. And I do see there are some use cases that I did not focus on, so I want to collect more user scenarios first, and then try to enhance the drafting design (will be published after I updated it base on your inputs). About the secure interrupt usage: - A secure interrupt would be introduced by a secure service call in general; is there any scenarios that there would be an interval secure interrupt since secure service want to do something? For example, a secure timer triggers to let secure service has the chance to do things in the background (not for an ongoing secure call from NSPE) after a period of time? And the question about the system Alan mentioned, just want to confirm if it is a pure thread mode scheduling system? How does the system handle interrupts? Thanks. -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Bill Fletcher via TF-M Sent: Monday, December 9, 2019 7:57 PM To: TF-M mailing list <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] TF-M technical Forum slides and recording Hi all, I've posted links to the (updated) slide deck and a recording of the call on the meetings page of the Trusted Firmware website: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Regards Bill -- [image: Linaro] <http://www.linaro.org/> *Bill Fletcher* | *Field Engineering* T: +44 7833 498336 <+44+7833+498336> bill.fletcher(a)linaro.org | Skype: billfletcher2020 -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 6 months

1
0
0 0

Support for optional build for secure partitions and test suites

by Kevin Peng (Arm Technology China)

Hi, I've made some patches to support optional build for secure partitions and test suites: https://review.trustedfirmware.org/q/topic:%22optional_build_sp_and_tests%2… With this patch set, you can optionally build secure partitions by setting the TFM_PARTITION_XXX in CommonConfig.cmake around line 152 - 162. And for test suites, by setting ENABLE_XXX_TESTS in test/TestConfig.cmake. I'm collecting for review comments. Thanks. Best Regards, Kevin

5 years, 6 months

1
0
0 0

TF-M technical Forum slides and recording

by Bill Fletcher

Hi all, I've posted links to the (updated) slide deck and a recording of the call on the meetings page of the Trusted Firmware website: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Regards Bill -- [image: Linaro] <http://www.linaro.org/> *Bill Fletcher* | *Field Engineering* T: +44 7833 498336 <+44+7833+498336> bill.fletcher(a)linaro.org | Skype: billfletcher2020

5 years, 6 months

1
0
0 0

Adding Cypress PSoC64 platform support

by Christopher Brand

Hi, I recently pushed patches to add support for a platform based on Cypress' PSoC64 SoC to gerrit. Given that this is the first non-Arm platform to be posted, it seems worth drawing attention to. Comments very much appreciated. I do anticipate a few small updates to the patchset, even in the absence of comments. In particular, there are some documentation improvements to come. There are four patches in total, ending with https://review.trustedfirmware.org/c/trusted-firmware-m/+/2728 https://review.trustedfirmware.org/c/trusted-firmware-m/+/2725/1 adds files to the platform/ext/cmsis directory, and so will affect/be affected by https://review.trustedfirmware.org/c/trusted-firmware-m/+/2578 Thanks, Chris This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

5 years, 6 months

1
0
0 0

Re: [TF-M] Regression test issues with IAR port

by Jamie Fox

Hi Thomas, Looks to me like the call to psa_ps_get() is retrieving the data set by psa_ps_set() in tfm_sst_test_1018_task_1(). This shouldn’t happen, because the two task functions are run in two different threads, which should have different client IDs. Can you check the client ID returned by tfm_core_get_caller_client_id() in tfm_sst_set_req() and tfm_sst_get_req() in each case? They should be different. Kind regards, Jamie From: Thomas Törnblom <thomas.tornblom(a)iar.com> Sent: 02 December 2019 22:50 To: Jamie Fox <Jamie.Fox(a)arm.com>; Minos Galanakis <Minos.Galanakis(a)arm.com> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Regression test issues with IAR port Hi Jamie, From tfm_sst_test_1018_task_2(): --- ... uint8_t read_data[] = READ_DATA; status = psa_ps_get(uid, offset, data_len, read_data); if (status != PSA_PS_ERROR_UID_NOT_FOUND) { TEST_FAIL("Get should not succeed with invalid thread name"); return; } /* Check that read data has not been modified */ if (memcmp(read_data, READ_DATA, sizeof(read_data)) != 0) { TEST_FAIL("Read data should not have changed"); return; } ... --- The call to psa_ps_get() returns 0, which is a failure in this test. Out of curiosity I stopped right after this call and I notice that the read_data array had been clobbered and now starts with the string "THEQUICKBROWNFOX". This appears to happen in the following call chain: sst_object_read() -> sst_req_mngr_write_asset_data() -> memcpy() As there is a test that the data has not been clobbered after the return, I suspect that the two issues are related. sst_req_mngr_write_asset_data() uses a global variable p_data as the destination for the memcpy() call, and this variable gets set in the call chain tfm_core_sfn_request() -> tfm_sst_get_req() I see that the "info" argument in tfm_sst_test_1019_task_2() is also clobbered after the call to psa_ps_get(). It appears that it is only the tests with invalid thread names that fails, 1018, 1019 and 1020. I'll continue debugging this... Cheers, Thomas Den 2019-11-28 kl. 17:37, skrev Jamie Fox: Hi Thomas, We use prebuilt RTX binaries from the CMSIS_5 repo, which does make debugging RTX code more difficult. Before we go down that route, it's worth checking that the error isn't in TF-M I think. Just looking at the errors you are getting, the most likely explanation to me is that something has gone wrong with registering the mapping from RTX thread name to NS client ID. Your first failure is on line 936 of test/suites/sst/non_secure/psa_ps_ns_interface_testsuite.c for example, which checks that one thread cannot access the uid belonging to a different thread. This could happen, for example, if the two threads ended up with the same client_id due to some error in the mapping. The mapping is done by tfm_nspm_register_client_id() in interface/src/tfm_nspm_api.c, which is called by test_task_runner() in test/suites/sst/non_secure/ns_test_helpers.c at the start of the execution of each SST test thread. Could you check that tfm_nspm_register_client_id() is getting the correct client ID for each test thread? Also, it calls a function with the " __attribute__ ((naked))" attribute. As this is a compiler extension could there be some problem there? Kind regards, Jamie -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org><mailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: 28 November 2019 15:45 To: Minos Galanakis <Minos.Galanakis(a)arm.com><mailto:Minos.Galanakis@arm.com>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com><mailto:nd@arm.com> Subject: Re: [TF-M] Regression test issues with IAR port Sorry, I was being unclear. I know where the tests start and ends, but the work appears to be handed off to the OS so that I can't (easily) step through the code and find what function is being used to look up the thread. The call to psa_ps_get() is used by the test and I assume it ends up using an RTX call and I would like to check what happens there. Cheers, Thomas Den 2019-11-28 kl. 16:00, skrev Minos Galanakis: Thomas, Tests are placed under the test -> suites -> service name directory. In your case you are looking at the Secure Storage Service non secure suite. For SST The logic is located at : * Non Secure side tests: test/suites/sst/non_secure/psa_ps_ns_interface_testsuite.c * Secure side tests: test/suites/sst/secure/psa_ps_s_interface_testsuite.c Hope that helps Minos ---------------------------------------------------------------------- -- *From:* TF-M <tf-m-bounces(a)lists.trustedfirmware.org><mailto:tf-m-bounces@lists.trustedfirmware.org> on behalf of Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org><mailto:tf-m@lists.trustedfirmware.org> *Sent:* 28 November 2019 14:49 *To:* tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org><mailto:tf-m@lists.trustedfirmware.org> *Subject:* [TF-M] Regression test issues with IAR port In my quest to port TF-M to the IAR toolchain I've run into issues with a few of the tests, and I need some hints where to look. The cmake build command line: --- cmake .. -G"Unix Makefiles" -DPROJ_CONFIG=C:\Users\thomasto\Projects\tf-m16\trusted-firmware-m\con figs\ConfigRegression.cmake -DTARGET_PLATFORM=MUSCA_A -DCOMPILER=IARARM -DCMAKE_BUILD_TYPE=RelWithDebInfo --- This results in three similar tests that fails: --- > Executing 'TFM_SST_TEST_1018' Description: 'Get interface with invalid thread name' Get should not succeed with invalid thread name (Failed at C:/Users/thomasto/Projects/tf-m16/trusted-firmware-m/test/suites/sst/n on_secure/psa_ps_ns_interface_testsuite.c:936) TEST FAILED! > Executing 'TFM_SST_TEST_1019' Description: 'Get info interface with invalid thread name' Get info should not succeed with invalid thread name (Failed at C:/Users/thomasto/Projects/tf-m16/trusted-firmware-m/test/suites/sst/n on_secure/psa_ps_ns_interface_testsuite.c:1015) TEST FAILED! > Executing 'TFM_SST_TEST_1020' Description: 'Remove interface with invalid thread name' Remove should not succeed with invalid thread name (Failed at C:/Users/thomasto/Projects/tf-m16/trusted-firmware-m/test/suites/sst/n on_secure/psa_ps_ns_interface_testsuite.c:1093) TEST FAILED! --- Where do I find the logic that determines if these tests succeed or fails? Cheers, Thomas -- *Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com<mailto:thomas.tornblom@iar.com> <mailto:thomas.tornblom@iar.com><mailto:thomas.tornblom@iar.com> Website: www.iar.com<http://www.iar.com> <http://www.iar.com><http://www.iar.com> <http://www.iar.com><http://www.iar.com> Twitter: www.twitter.com/iarsystems<http://www.twitter.com/iarsystems> <http://www.twitter.com/iarsystems><http://www.twitter.com/iarsystems> <http://www.twitter.com/iarsystems><http://www.twitter.com/iarsystems> -- TF-M mailing list TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- Thomas Törnblom, Product Engineer IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com<mailto:thomas.tornblom@iar.com> Website: www.iar.com<http://www.iar.com> Twitter: www.twitter.com/iarsystems<http://www.twitter.com/iarsystems>

5 years, 6 months

2
3
0 0

X.509 Certificate Chain Support in TF-M

by Kevin Townsend

Hi, As part of some of our work on TF-M, specifically around attestation, device provisioning and firmware management, we've been reviewing some of what various companies are currently doing or requiring during the provisioning process (whether provisioning at the manufacturing phase, or provisioning devices into cloud or similar services post manufacturing). The common thread in almost all of these scenarios is the use of X.509 certification chains when working with the public key(s) held on the end device. At Linaro, we've been thinking through some of the benefits and tradeoffs of migrating from the current approach of exposing unsigned public keys for things like initial attestation and signing firmware, and what would be required to allow the signing of the attestation/firmware keys on devices, and generating new keys such as provisioning a device onto an Amazon/Google/Microsoft cloud service which would require creating a new private key held in secure storage, and storing the signed certificate chain associated with that new private key for on-demand retrieval. - Some of the initial thinking and imagined benefits of migrating to X.509 certificate chains are described here: https://github.com/microbuilder/certificate_chains/blob/master/rfc_tfm.md - Some general notes on X.509 certificates are available here: https://github.com/microbuilder/certificate_chains/blob/master/README.md - And here are two scripts showing how to create 2 and 3 level certificate chains, just as a proof of concept to better understand how this might work with something like TF-M: - https://github.com/microbuilder/certificate_chains/blob/master/2lev_cert_cr… - https://github.com/microbuilder/certificate_chains/blob/master/3lev_cert_cr… Specifically, they key missing aspects to enable the use of standard X.509 certificates are: - Update mcuboot to understand a certificate chain -- rather than the raw public key -- when verifying firmware images - Generating PKSC#10 (RFC2986) certificate signing requests on the secure side, using a securely held private key during the request generation process - Generate new private keys and store them in secure storage for non-attestation uses like cloud services, and retrieve the associated and signed cert chains for that key on demand A proposal of how this might work in the real world is shown here, with the TF-M secure code requrements in the 'opt' box of the sequence diagram: https://github.com/microbuilder/certificate_chains/blob/master/rfc_tfm.md#c… We don't have a full TF-M proof of concept ready yet, but wanted to put the idea on the table of migrating to X.509 certificate chains while we work on a proof of concept, and continue analysis of how provision at manufacturing and in the field (to cloud services, etc.) can be improved. Any feedback/concerns is welcome here or perhaps in the Github repo above until a specific change request can be prepared for TF-M. Best regards, Kevin Townsend

5 years, 6 months

1
0
0 0

Re: [TF-M] [EXTERNAL] Re: out of tree build

by DeMars, Alan

In our use case, we added complete paths to the build area's corresponding directory to the embedded include paths and removed the default generated content from our git repo. Consequently only the newly generated content is found, wherever it happens to be placed. Alan -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Kevin Peng (Arm Technology China) via TF-M Sent: Friday, November 22, 2019 2:15 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd Subject: Re: [TF-M] [EXTERNAL] Re: out of tree build Hi all, I'm having issues on supporting the out of tree build. So I'd like to propose some additional changes. What does the out of tree build currently support is that: The user uses the tfm_parse_manifest_list.py with the custom manifests to generate the customized files to a directory out of TF-M. And the TF-M build system uses the customized files rather than the pre-generated ones in the TF-M for building. The problem is that some of the source files include the generated headers using the relative path to where the source itself is. And the directory of the source file is always searched first. This makes it impossible to use the generated files outside TF-M even the custom output directory is added to searching list. So I suggest to put the generated files to a dedicated directory in TF-M. Then for the default build, add the directory and its subdirectories to the search list for headers. For out of tree build, use the specified directory and its subdirectories instead. Then there would only one header file with the same name in all the directories for searching headers. Any concerns, thoughts or suggestions? Best Regards, Kevin -----Original Message----- From: Kevin Peng (Arm Technology China) Sent: Friday, November 22, 2019 3:45 PM To: DeMars, Alan <ademars(a)ti.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: RE: [EXTERNAL] Re: [TF-M] out of tree build Hi Alan, I've created a patch for the tfm_parse_manifest_list.py as the first step for the out of tree build support: https://review.trustedfirmware.org/c/trusted-firmware-m/+/2606 The changes for build system is ongoing. The functionality changes for the tfm_parse_manifest_list.py is the same as your version. Please have a review and help verify it if possible. Comments from anyone else are also welcome. Best Regards, Kevin -----Original Message----- From: Kevin Peng (Arm Technology China) Sent: Thursday, November 14, 2019 3:31 PM To: DeMars, Alan <ademars(a)ti.com> Cc: tf-m(a)lists.trustedfirmware.org; nd <nd(a)arm.com> Subject: RE: [EXTERNAL] Re: [TF-M] out of tree build OK. It's much clearer for me now. Thanks. Best Regards, Kevin -----Original Message----- From: DeMars, Alan <ademars(a)ti.com> Sent: Thursday, November 14, 2019 10:34 AM To: Kevin Peng (Arm Technology China) <Kevin.Peng(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org; nd <nd(a)arm.com> Subject: Re: [EXTERNAL] Re: [TF-M] out of tree build 1) I verified the tfm_parse_manifest.py script changes using the master branch’s version of the tfm_manifest_list.yaml and tfm_generated_file_list.yaml files. 2) Yes, I’m building using the unmodified master branch’s cmake build system. 3) Just as all other build artifacts are placed in the user’s build directory and NOT in the source tree, the generated files should also. Otherwise, the user is required to update the source tree’s tfm_manifest_list.yaml and tfm_generated_file_list.yaml files to build a custom SPE, with the generated files also ending up in the source tree. The files necessary to create a custom SPE should not be kept in the source tree. Nor should the generated content be inserted in the source tree. This creates headaches for maintaining the original source tree. Alan > On Nov 13, 2019, at 1:57 AM, Kevin Peng (Arm Technology China) via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi Alan, > > I checked your modified tfm_parse_manifest_list.py. > It basically uses the input tfm_manifest_list.yaml and tfm_generated_file_list.yaml to generate the TF-M auto generated files to the third input. > > I'm sorry I was not in the workshop. So I have some questions. > 1. Do you have your own tfm_manifest_list.yaml and tfm_generated_file_list.yaml that is not upstreamed in TF-M? > 2. Are you using the TF-M provided CMake build system? > 3. Do you only need the files generated by tfm_parse_manifest_list.py to be out of the TF-M source directory? > > Could you provide some details about your requirements. Thanks. > > Best Regards, > Kevin > > -----Original Message----- > From: Kevin Peng (Arm Technology China) > Sent: Wednesday, November 13, 2019 10:27 AM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: RE: out of tree build > > Hi Alan, > > I'm following on this and will get you updated on any progress. > > Best Regards, > Kevin > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M > Sent: Thursday, November 7, 2019 12:42 PM > To: Abhishek Pandit <Abhishek.Pandit(a)arm.com> > Cc: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> > Subject: Re: [TF-M] out of tree build > > Trying again after renaming tfm_parse_manifest_list.py to tfm_parse_manifest_list.txt so it wouldn't get deleted. > --- > > With the attached modified secure_fw/CMakeLists.txt and tools/tfm_parse_manifest_list.py files, I am able to redirect the generated files using the following command line: > > python3 <full_path_to_your>/tfm_parse_manifest_list.py <full_path_to_your>/tfm_manifest_list.yaml <full_path_to_your>/tfm_generated_file_list.yaml <full_path_to_your>/<build_dir> > > And then build the ConfigCoreIPC artifacts within <your_build_dir> using the following cmake line: > > cmake -G"Unix Makefiles" -DPROJ_CONFIG=`readlink -f ../configs/ConfigCoreIPC.cmake` -DREMOTE_GEN_DIR=<full_path_to_your><build_dir> -DTARGET_PLATFORM=AN521 -DCOMPILER=GNUARM ../ > > The changes to tfm_parse_manifest_list.py are backward compatible with the standard usage. > > Alan > > > -----Original Message----- > From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of DeMars, Alan via TF-M > Sent: Monday, November 4, 2019 4:36 PM > To: Abhishek Pandit; tf-m(a)lists.trustedfirmware.org > Subject: [EXTERNAL] Re: [TF-M] out of tree build > > Abishek, > > Yes, we have modified tfm_gen.py and tfm_parse_manifest_list.py to support redirecting the destination of the generated template files into a command line provided destination build directory. > A corresponding change to our platform's platform/ext/xyz.cmake file was also required to add the path to the root of the build directory to the embedded_include_directories() list as well as the paths to the generated linker command files. > > I was not planning to provide these changes as a patch for review as I am very unsure of the applicability of this to other platforms. Also, I was fairly certain that given my very poor understanding of the CMake build system, my approach to the problem was not utilizing features present in CMake that would make the job simpler and more extensible. > > Since the topic came up at the conference and you already seemed willing to address the out-of-tree build problem that the templates lead to, I assumed you folks would find a simple and elegant solution that would save me the embarrassment of exposing my lack of CMake expertise. > > Alan > > -----Original Message----- > From: Abhishek Pandit [mailto:Abhishek.Pandit@arm.com] > Sent: Monday, November 4, 2019 3:08 PM > To: DeMars, Alan; tf-m(a)lists.trustedfirmware.org > Subject: [EXTERNAL] RE: out of tree build > > Hi Alan, > Not sure if I remember the exact detail from the workshop last week, but did you mention that you have a prototype for this? If so, are you planning to push a patch for review? > Thanks, > Abhishek > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M > Sent: 01 November 2019 16:29 > To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> > Subject: [TF-M] out of tree build > > Please modify the template generators to support out of tree build, and modify the CMake files to add the necessary include paths so that the files that include the template-generated files can find them. > > Alan > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 6 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M