- TF-M - lists.trustedfirmware.org

psa_invec type mismatch in tfm_psa_call_veneer?

by DeMars, Alan

It seems to me that the 'psa_invec' type is incorrectly being used where the 'psa_outvec' type should be used everywhere tfm_psa_call_veneer() is used. In tfm_api.h, I think this: psa_status_t tfm_psa_call_veneer(psa_handle_t handle, const psa_invec *in_vecs, const psa_invec *out_vecs); should be this: psa_status_t tfm_psa_call_veneer(psa_handle_t handle, const psa_invec *in_vecs, const psa_outvec *out_vecs); And, in the implementation of the tfm_psa_call_veneer within tfm_psa_api_client.c, I think this: __tfm_secure_gateway_attributes__ psa_status_t tfm_psa_call_veneer(psa_handle_t handle, const psa_invec *in_vecs, const psa_invec *out_vecs) should be this: __tfm_secure_gateway_attributes__ psa_status_t tfm_psa_call_veneer(psa_handle_t handle, const psa_invec *in_vecs, const psa_outvec *out_vecs) And, in the NS implementation of psa_call() within tfm_psa_ns_api.c, I think this: psa_invec in_vecs, out_vecs; should be this: psa_invec in_vecs; psa_outvec out_vecs; Alan

6 years, 6 months

1
0
0 0

Platform: Create platform service for pin functions

by Michel JAOUEN

Hello, I noticed the merge of this api, which seems require only for platform Musca_a. This create the need to implement dummy functions for the other platform. would it be better to make this configurable for each platform ? I think for the interface connected to platform partition, it is important to have a flexibility. As example some platform , may require an API requesting a pin to be configureable from non secure . Best regards

6 years, 6 months

1
0
0 0

[RFC] Core: Set PendSV priority to lowest

by Ken Liu (Arm Technology China)

Hi, I have created a patch to set PenSV priority as lowest, which makes more sense that other high priority interrupts may preempt scheduling and affect the scheduling result. The issue is created here and you can find gerrit link in comment: https://developer.trustedfirmware.org/T310 Please publish your comments under this issue if you have. Thanks -Ken

6 years, 6 months

1
0
0 0

Re: [TF-M] Trusted boot - rollback protection

by Michel JAOUEN

For the platform without hardware for NV counter, but having trusted memory It is mentioned that the support is possible as follow : "an active image and related manifest data is stored in trusted memory then the included security counter cannot be compromised." the impact for this implementation in mcu-boot is limited to : * The test of the version (security counter is ih_ver from mcuboot header) * The placement of active image and related manifest data in a trusted memory. Is my understanding correct ? As the placement of full image in a trusted memory is a constraint. Can we limit the information placed in a trusted memory to : * image header, * TLV sections. This seems sufficient to support anti roll back. Of course additional impact on mcu-boot must be planned but as multi image support is also targeted , the placement of all images in a trusted memory is likely to be unachievable for all configurations.

6 years, 6 months

1
0
0 0

Support SST_FLASH_PROGRAM_UNIT=8

by Michel JAOUEN

Hello, For this support , I created https://developer.trustedfirmware.org/T305 Best regards

6 years, 7 months

1
0
0 0

Re: [TF-M] build of NSPE with flag __ARM_FEATURE_CMSE=3

by Gyorgy Szing

Hi Michel, Apologies, somehow my response yesterday got lost, so here it goes again: I re-read the documentation and the way you use this macro seems to be valid when targeting v8-M based chips. I see two solutions for your problem: 1. I created a ticket to remove the --mcmse compile flag for non-secure projects. See: https://developer.trustedfirmware.org/T304 After this is fixed, your current code will work as expected. 2. Currently TF-M uses the __DOMAIN_NS macro to define the target domain for the source-code. It is an option to change your code to use this macro. I suggest going for this option if your code is not v8-M specific, and may need to support other architectures in the future. /George -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M Sent: 03 April 2019 17:40 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] build of NSPE with flag __ARM_FEATURE_CMSE=3 Hi Michel, A ticket has been raised by Gyorgy to track this: https://developer.trustedfirmware.org/T304 Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Michel JAOUEN via TF-M Sent: 03 April 2019 03:03 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] build of NSPE with flag __ARM_FEATURE_CMSE=3 Hello, The flag is defined to __ARM_FEATURE_CMSE == 3U. In documentation, I can read : __ARM_FEATURE_CMSE == 3U when Toolchain targets the secure state of CMSE (implies the availability of the TT instruction). My soc files relies on this flag to select by default a secure peripheral register address or a non secure peripheral address. With the non secure compiled with __ARM_FEATURE_CMSE == 3U , by default secure peripheral address are selected. Is it a correct usage to build NSPE with __ARM_FEATURE_CMSE == 3U ? Best regards -- 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

6 years, 7 months

1
0
0 0

Re: [TF-M] build with GNUARM with option -Os

by Edison Ai (Arm Technology China)

Hi Michel, We will pick up this and try to push a patch to fix it soon. Hi Alan, Thanks for your workaround, and it is very helpful. We will update the T234 as soon as possible after the patch ready. Thanks, Edison -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: Wednesday, April 3, 2019 9:32 PM To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] build with GNUARM with option -Os I assumed there was an outstanding pull request for this ticket: https://developer.trustedfirmware.org/T234 Alan -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Tuesday, April 02, 2019 6:59 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd Subject: [EXTERNAL] Re: [TF-M] build with GNUARM with option -Os Hi Alan, Is it OK for you to commit this change? -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of > DeMars, Alan via TF-M > Sent: Wednesday, April 3, 2019 5:50 AM > To: Michel JAOUEN <michel.jaouen(a)st.com> > Cc: tf-m(a)lists.trustedfirmware.org > Subject: Re: [TF-M] build with GNUARM with option -Os > > I had a similar problem. Upon advice in this email list, I fixed it by > changing the implementation of "tfm_core_ns_ipc_request()" in > secure_fw/core/tfm_psa_api_client.c. > > Add 'volatile' to the declaration of these variables: > > struct tfm_sfn_req_s desc, *desc_ptr = &desc; > > change to: > > volatile struct tfm_sfn_req_s desc, *desc_ptr = &desc; > > After this change, I am able to build and run with -O3 as well as -Os. > > I don't know why this fix hasn't been added to the master branch as > this problem has already been identified. > > Alan > > -----Original Message----- > From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf > Of Michel JAOUEN via TF-M > Sent: Tuesday, April 02, 2019 4:11 AM > To: tf-m(a)lists.trustedfirmware.org > Subject: [EXTERNAL] [TF-M] build with GNUARM with option -Os > > Hello, > I tested my board port on top of > 1c266ae74bd93c2ef290e9aac0caecf92b06b93d > Without option -Os , the tests with ConfigCoreIPC.cmake are passed . > When I put the option -Os , 1st test is failing in Hardware Fault. > > For info, the test with ConfigRegression.cmake and option -Os is passed . > > With the configuration -Os , code footprint is much better. > > Is it plan to activate this option in master ? Is the same issue > reproduced on another board ? > > Best regards > > -- > 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 -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 7 months

1
0
0 0

Re: [TF-M] build of NSPE with flag __ARM_FEATURE_CMSE=3

by Antonio De Angelis

Hi Michel, A ticket has been raised by Gyorgy to track this: https://developer.trustedfirmware.org/T304 Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Michel JAOUEN via TF-M Sent: 03 April 2019 03:03 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] build of NSPE with flag __ARM_FEATURE_CMSE=3 Hello, The flag is defined to __ARM_FEATURE_CMSE == 3U. In documentation, I can read : __ARM_FEATURE_CMSE == 3U when Toolchain targets the secure state of CMSE (implies the availability of the TT instruction). My soc files relies on this flag to select by default a secure peripheral register address or a non secure peripheral address. With the non secure compiled with __ARM_FEATURE_CMSE == 3U , by default secure peripheral address are selected. Is it a correct usage to build NSPE with __ARM_FEATURE_CMSE == 3U ? Best regards -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 7 months

1
0
0 0

Re: [TF-M] build with GNUARM with option -Os

by DeMars, Alan

I assumed there was an outstanding pull request for this ticket: https://developer.trustedfirmware.org/T234 Alan -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Tuesday, April 02, 2019 6:59 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd Subject: [EXTERNAL] Re: [TF-M] build with GNUARM with option -Os Hi Alan, Is it OK for you to commit this change? -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, > Alan via TF-M > Sent: Wednesday, April 3, 2019 5:50 AM > To: Michel JAOUEN <michel.jaouen(a)st.com> > Cc: tf-m(a)lists.trustedfirmware.org > Subject: Re: [TF-M] build with GNUARM with option -Os > > I had a similar problem. Upon advice in this email list, I fixed it by changing the > implementation of "tfm_core_ns_ipc_request()" in > secure_fw/core/tfm_psa_api_client.c. > > Add 'volatile' to the declaration of these variables: > > struct tfm_sfn_req_s desc, *desc_ptr = &desc; > > change to: > > volatile struct tfm_sfn_req_s desc, *desc_ptr = &desc; > > After this change, I am able to build and run with -O3 as well as -Os. > > I don't know why this fix hasn't been added to the master branch as this problem > has already been identified. > > Alan > > -----Original Message----- > From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of > Michel JAOUEN via TF-M > Sent: Tuesday, April 02, 2019 4:11 AM > To: tf-m(a)lists.trustedfirmware.org > Subject: [EXTERNAL] [TF-M] build with GNUARM with option -Os > > Hello, > I tested my board port on top of > 1c266ae74bd93c2ef290e9aac0caecf92b06b93d > Without option -Os , the tests with ConfigCoreIPC.cmake are passed . > When I put the option -Os , 1st test is failing in Hardware Fault. > > For info, the test with ConfigRegression.cmake and option -Os is passed . > > With the configuration -Os , code footprint is much better. > > Is it plan to activate this option in master ? Is the same issue reproduced on > another board ? > > Best regards > > -- > 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

6 years, 7 months

1
0
0 0

build of NSPE with flag __ARM_FEATURE_CMSE=3

by Michel JAOUEN

Hello, The flag is defined to __ARM_FEATURE_CMSE == 3U. In documentation, I can read : __ARM_FEATURE_CMSE == 3U when Toolchain targets the secure state of CMSE (implies the availability of the TT instruction). My soc files relies on this flag to select by default a secure peripheral register address or a non secure peripheral address. With the non secure compiled with __ARM_FEATURE_CMSE == 3U , by default secure peripheral address are selected. Is it a correct usage to build NSPE with __ARM_FEATURE_CMSE == 3U ? Best regards

6 years, 7 months

1
0
0 0

Re: [TF-M] build with GNUARM with option -Os

by Ken Liu (Arm Technology China)

Hi Alan, Is it OK for you to commit this change? -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, > Alan via TF-M > Sent: Wednesday, April 3, 2019 5:50 AM > To: Michel JAOUEN <michel.jaouen(a)st.com> > Cc: tf-m(a)lists.trustedfirmware.org > Subject: Re: [TF-M] build with GNUARM with option -Os > > I had a similar problem. Upon advice in this email list, I fixed it by changing the > implementation of "tfm_core_ns_ipc_request()" in > secure_fw/core/tfm_psa_api_client.c. > > Add 'volatile' to the declaration of these variables: > > struct tfm_sfn_req_s desc, *desc_ptr = &desc; > > change to: > > volatile struct tfm_sfn_req_s desc, *desc_ptr = &desc; > > After this change, I am able to build and run with -O3 as well as -Os. > > I don't know why this fix hasn't been added to the master branch as this problem > has already been identified. > > Alan > > -----Original Message----- > From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of > Michel JAOUEN via TF-M > Sent: Tuesday, April 02, 2019 4:11 AM > To: tf-m(a)lists.trustedfirmware.org > Subject: [EXTERNAL] [TF-M] build with GNUARM with option -Os > > Hello, > I tested my board port on top of > 1c266ae74bd93c2ef290e9aac0caecf92b06b93d > Without option -Os , the tests with ConfigCoreIPC.cmake are passed . > When I put the option -Os , 1st test is failing in Hardware Fault. > > For info, the test with ConfigRegression.cmake and option -Os is passed . > > With the configuration -Os , code footprint is much better. > > Is it plan to activate this option in master ? Is the same issue reproduced on > another board ? > > Best regards > > -- > 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

6 years, 7 months

1
0
0 0

Re: [TF-M] build with GNUARM with option -Os

by DeMars, Alan

I had a similar problem. Upon advice in this email list, I fixed it by changing the implementation of "tfm_core_ns_ipc_request()" in secure_fw/core/tfm_psa_api_client.c. Add 'volatile' to the declaration of these variables: struct tfm_sfn_req_s desc, *desc_ptr = &desc; change to: volatile struct tfm_sfn_req_s desc, *desc_ptr = &desc; After this change, I am able to build and run with -O3 as well as -Os. I don't know why this fix hasn't been added to the master branch as this problem has already been identified. Alan -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Michel JAOUEN via TF-M Sent: Tuesday, April 02, 2019 4:11 AM To: tf-m(a)lists.trustedfirmware.org Subject: [EXTERNAL] [TF-M] build with GNUARM with option -Os Hello, I tested my board port on top of 1c266ae74bd93c2ef290e9aac0caecf92b06b93d Without option -Os , the tests with ConfigCoreIPC.cmake are passed . When I put the option -Os , 1st test is failing in Hardware Fault. For info, the test with ConfigRegression.cmake and option -Os is passed . With the configuration -Os , code footprint is much better. Is it plan to activate this option in master ? Is the same issue reproduced on another board ? Best regards -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 7 months

1
0
0 0

build with GNUARM with option -Os

by Michel JAOUEN

Hello, I tested my board port on top of 1c266ae74bd93c2ef290e9aac0caecf92b06b93d Without option -Os , the tests with ConfigCoreIPC.cmake are passed . When I put the option -Os , 1st test is failing in Hardware Fault. For info, the test with ConfigRegression.cmake and option -Os is passed . With the configuration -Os , code footprint is much better. Is it plan to activate this option in master ? Is the same issue reproduced on another board ? Best regards

6 years, 7 months

1
0
0 0

Re: [TF-M] PSA Test Suite forum?

by Andrej Butok

Hi Antonio, Ok, so the TFM is using the old API. Hope, it will be updated soon. I prefer do not downgrade the test suite from master, as it contains >50 of new commits. Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M Sent: Monday, April 1, 2019 11:24 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] PSA Test Suite forum? Hi Andrej, I have replied on the GitHub issue as well, copy-pasting my reply below: TF-M uses a version of the API which is marked 0.1.0b. The psa-arch-tests, on the master branch, have moved to use a newer version of the API, while on the branch marked ew_beta0 they use the version of the API compatible with the one TF-M uses, hence TF-M PSA API compliance needs to be tests using the ew_beta0 branch. Work is ongoing on TF-M side to move to newer versions of the API. Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Qixiang Xu (Arm Technology China) via TF-M Sent: 01 April 2019 09:14 To: Andrej Butok <andrey.butok(a)nxp.com> Cc: TF-M(a)lists.trustedfirmware.org Subject: Re: [TF-M] PSA Test Suite forum? Andrej, Yes, the PSA test suite was developed by different team. If it is a common topic, you can report the issue at any of the site, then we will sync it internal. Thanks. Best Regards, Qixiang Xu -----Original Message----- From: Andrej Butok <andrey.butok(a)nxp.com> Sent: Monday, April 1, 2019 3:59 PM To: Qixiang Xu (Arm Technology China) <Qixiang.Xu(a)arm.com> Cc: TF-M(a)lists.trustedfirmware.org Subject: RE: PSA Test Suite forum? Hi Qixiang Xu, I have added https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co… Not sure, what forum to use if it is a common topic related to both TFM and Test-suite. Is the PSA test suite developed by other independent team? Thanks, Andrej -----Original Message----- From: Qixiang Xu (Arm Technology China) <Qixiang.Xu(a)arm.com> Sent: Monday, April 1, 2019 9:41 AM To: Andrej Butok <andrey.butok(a)nxp.com> Cc: TF-M(a)lists.trustedfirmware.org Subject: RE: PSA Test Suite forum? Andrej, You can report any issue or concern at: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co… Best Regards, Qixiang Xu -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Monday, April 1, 2019 3:29 PM To: TF-M(a)lists.trustedfirmware.org Subject: [TF-M] PSA Test Suite forum? Hello, Do you have a forum dedicated to the PSA Test-suite (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co… )? Or we may use this one? Thanks Andrej -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… 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. 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

6 years, 7 months

2
1
0 0

Re: [TF-M] PSA Test Suite forum?

by Antonio De Angelis

Hi Andrej, I have replied on the GitHub issue as well, copy-pasting my reply below: TF-M uses a version of the API which is marked 0.1.0b. The psa-arch-tests, on the master branch, have moved to use a newer version of the API, while on the branch marked ew_beta0 they use the version of the API compatible with the one TF-M uses, hence TF-M PSA API compliance needs to be tests using the ew_beta0 branch. Work is ongoing on TF-M side to move to newer versions of the API. Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Qixiang Xu (Arm Technology China) via TF-M Sent: 01 April 2019 09:14 To: Andrej Butok <andrey.butok(a)nxp.com> Cc: TF-M(a)lists.trustedfirmware.org Subject: Re: [TF-M] PSA Test Suite forum? Andrej, Yes, the PSA test suite was developed by different team. If it is a common topic, you can report the issue at any of the site, then we will sync it internal. Thanks. Best Regards, Qixiang Xu -----Original Message----- From: Andrej Butok <andrey.butok(a)nxp.com> Sent: Monday, April 1, 2019 3:59 PM To: Qixiang Xu (Arm Technology China) <Qixiang.Xu(a)arm.com> Cc: TF-M(a)lists.trustedfirmware.org Subject: RE: PSA Test Suite forum? Hi Qixiang Xu, I have added https://github.com/ARM-software/psa-arch-tests/issues/79 Not sure, what forum to use if it is a common topic related to both TFM and Test-suite. Is the PSA test suite developed by other independent team? Thanks, Andrej -----Original Message----- From: Qixiang Xu (Arm Technology China) <Qixiang.Xu(a)arm.com> Sent: Monday, April 1, 2019 9:41 AM To: Andrej Butok <andrey.butok(a)nxp.com> Cc: TF-M(a)lists.trustedfirmware.org Subject: RE: PSA Test Suite forum? Andrej, You can report any issue or concern at: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co… Best Regards, Qixiang Xu -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Monday, April 1, 2019 3:29 PM To: TF-M(a)lists.trustedfirmware.org Subject: [TF-M] PSA Test Suite forum? Hello, Do you have a forum dedicated to the PSA Test-suite (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co… )? Or we may use this one? Thanks Andrej -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… 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. 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

6 years, 7 months

1
0
0 0

Re: [TF-M] PSA Test Suite forum?

by Qixiang Xu (Arm Technology China)

Andrej, You can report any issue or concern at: https://github.com/ARM-software/psa-arch-tests/issues Best Regards, Qixiang Xu -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Monday, April 1, 2019 3:29 PM To: TF-M(a)lists.trustedfirmware.org Subject: [TF-M] PSA Test Suite forum? Hello, Do you have a forum dedicated to the PSA Test-suite (https://github.com/ARM-software/psa-arch-tests )? Or we may use this one? Thanks Andrej -- 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.

6 years, 7 months

2
2
0 0

PSA Test Suite forum?

by Andrej Butok

Hello, Do you have a forum dedicated to the PSA Test-suite (https://github.com/ARM-software/psa-arch-tests )? Or we may use this one? Thanks Andrej

6 years, 7 months

1
0
0 0

[twin-cpu]Dual core communication design document for review

by David Hu (Arm Technology China)

Hi all, I've posted a design document for dual core communication in twin cpu project. Could you please review it at https://developer.trustedfirmware.org/w/tf_m/design/twin-cpu/communication_… Any comment is welcome. Thank you. Best regards, Hu Ziji

6 years, 7 months

2
4
0 0

[RFC] Isolation level 2 patches

by Ken Liu (Arm Technology China)

Hi, The isolation level 2 patches are pushed for reviewing; you can find all of them under the issue: https://developer.trustedfirmware.org/T294 The design document was put at: https://developer.trustedfirmware.org/w/tf_m/design/trusted_firmware-m_isol… The first group of patches are working on AN521 with ARMCLANG build. Rest options supporting would come later. With higher isolation level, some functions may not work such as CLIB (malloc/free e.g.). These features need to be supported after dedicated implementation is done. You can check the [RFC] discussion sent in mailing list of the isolation level 2 for details. Isolation level 2 use dedicated config file: "ConfigCoreIPCTfmLevel2.cmake" so the IPC on isolation level 1 is not affected by this change. Please help to comment in documents and patches - current the document has no comment area so you can put comments under the issue link, or just reply in mailing list. Creating issues is another valid options ; ) Thanks! -Ken

6 years, 7 months

1
0
0 0

Re: [TF-M] [EXTERNAL] Re: Please explain tfm_register_client_id() use case

by DeMars, Alan

Yes, that idea would resolve the problem. I’m not sure I understand the use case for multiple updates to a context’s client Id. What is the thought behind that? Alan > On Mar 28, 2019, at 2:23 AM, Miklos Balint via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Alan, > > You are absolutely right that registering client ID should normally be done once, preferably right after AllocModule. > > The current design allows multiple updates to be made, and for this to be possible, we identify the one to be updated by it being the active one. > > I do see an opportunity to extend this so that the last NS context to be Allocated can also be assumed to be the target of a registration in lieu of the active context if there isn't one. > This way we keep the option to update ID when a context is active while also allow an easy and low overhead registration for the context that's latest to have been Allocated. > > Is this an acceptable amendment? > > Regards > Miklos > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M > Sent: 26 March 2019 00:00 > To: tf-m(a)lists.trustedfirmware.org > Subject: [TF-M] Please explain tfm_register_client_id() use case > > As currently specified, I don't see a simple way to invoke the tfm_register_client_id() API ONLY ONCE for each NS client thread. > > It appears that tfm_register_client_id() must be called after TZ_LoadContext_S() because the clientId provided by tfm_register_client_id() is always associated with the CURRENT NS MemoryId. > > However, TZ_LoadContext_S() is designed to be called only when the NS OS actually switches to a new NS thread. This creates pressure for tfm_register_client_id() to be called during a NS thread switch. However, calling tfm_register_client_id() on EVERY NS context switch is redundant and CPU wasteful. Adding code to test whether tfm_register_client_id() has already been called for a particular NS thread also seems wasteful. > > What seems natural to me is to add a MemoryId argument to tfm_register_client_id() so that the clientID can be mapped to the MemoryId provided by TZ_AllocModuleContext_S() right after TZ_AllocModuleContext_S() is called (ie only once). > > Please correct my understanding of how tfm_register_client_id() is intended to be used if the above analysis is off base. > > Alan > > > -- > 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

6 years, 7 months

2
1
0 0

Re: [TF-M] [RFC] twin cpu bootloader design document

by David Hu (Arm Technology China)

Hi Chris, Sorry for the delayed reply. Please check my comments in below. Just about small details. Please correct me if I misunderstand anything. 1. In my own opinion, it can be possible to use IPC to synchronize mailbox services between two cores, during initialization. The synchronization is only trigged when the mailbox mechanism is ready on mailbox server or client. It means that the IPC module should be also configured. Based on the above assumption, using IPC to synchronize the two cores is more generic and convenient than accessing shared memory. If using shared memory to pass status flag, it can be necessary to adjust the address of the shared memory occasionally according to the memory assignment in different applications. 2. I'd like to suggest that we shall discuss more about when the booting HAL APIs are invoked in TF-M. `tfm_core_init()` initializes the TF-M core. Thus in theory, `tfm_core_init()` is irrelevant to the system topology or platform implementations. As a result, IMO, it can be more reasonable to put the HAL APIs outside the `tfm_core_init()`. 3. ` tfm_spm_hal_wait_for_ns_cpu_ready()` can be optional. The secure core acts as a server and it is driven by the request from NS core. The secure core actually doesn't have to wait for an explicit signal to know NS is ready. The synchronization can be guaranteed if NS core starts request via mailbox only after secure core is available. 4. It can be unnecessary to require calling `tfm_spm_hal_wait_for_s_cpu_ready()` in NS `main()`. It might be too early to wait in `main()` and may block other initializations which don't rely on mailbox. This API can be invoked in mailbox functionalities. The whole NS initialization can continue, including enabling application threads, until a NS application requests Secure services via mailbox at the very first time. Thus the whole dual core design can be more generic since the mailbox workflow should be identical on diverse platforms. And we can save the time and effort to hack each RTOS initialization. In other words, I wonder if we can make calling `tfm_spm_hal_wait_for_s_cpu_ready()` in NS `main() as an option and allow other implementations. Thank you. Best regards, Hu Ziji -------------------------------------------------------------------------------------------------------------- Date: Thu, 14 Mar 2019 18:50:56 +0000 From: Christopher Brand <chris.brand(a)cypress.com> To: "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] [RFC] twin cpu bootloader design document Message-ID: <BYAPR06MB5301EBF02F4C0B60A9BB7742FE4B0(a)BYAPR06MB5301.namprd06.prod.outlook.com> Content-Type: text/plain; charset="us-ascii" Hi, I've posted a design document for bootloader changes to support twin cpu at https://developer.trustedfirmware.org/w/tf_m/design/twin-cpu/bootloader/ Comments appreciated! Thanks, Chris

6 years, 7 months

3
7
0 0

proposed change in Musca B1

by Tamas Kaman

Hi All, I'd like to notify everyone about a proposed change in Musca B1 platform in TF-M. Everyone who is using that platform might be affected. The code on Musca B1 is currently running from the external QSPI flash. With the coming change this moves to a much faster internal embedded Flash, so all you might observe is faster code execution. Link to review: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/669/ Also, for loading the image to the a board another version of DAPLink FW will be needed. The eFlash type DAPLink FW can be downloaded from Arm Community page: https://community.arm.com/developer/tools-software/oss-platforms/w/docs/425… A short description of how to update the DAPLink FW can be found here as well. Thanks, Tamas 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.

6 years, 7 months

1
0
0 0

Re: [TF-M] Please explain tfm_register_client_id() use case

by Miklos Balint

Alan, You are absolutely right that registering client ID should normally be done once, preferably right after AllocModule. The current design allows multiple updates to be made, and for this to be possible, we identify the one to be updated by it being the active one. I do see an opportunity to extend this so that the last NS context to be Allocated can also be assumed to be the target of a registration in lieu of the active context if there isn't one. This way we keep the option to update ID when a context is active while also allow an easy and low overhead registration for the context that's latest to have been Allocated. Is this an acceptable amendment? Regards Miklos -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: 26 March 2019 00:00 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Please explain tfm_register_client_id() use case As currently specified, I don't see a simple way to invoke the tfm_register_client_id() API ONLY ONCE for each NS client thread. It appears that tfm_register_client_id() must be called after TZ_LoadContext_S() because the clientId provided by tfm_register_client_id() is always associated with the CURRENT NS MemoryId. However, TZ_LoadContext_S() is designed to be called only when the NS OS actually switches to a new NS thread. This creates pressure for tfm_register_client_id() to be called during a NS thread switch. However, calling tfm_register_client_id() on EVERY NS context switch is redundant and CPU wasteful. Adding code to test whether tfm_register_client_id() has already been called for a particular NS thread also seems wasteful. What seems natural to me is to add a MemoryId argument to tfm_register_client_id() so that the clientID can be mapped to the MemoryId provided by TZ_AllocModuleContext_S() right after TZ_AllocModuleContext_S() is called (ie only once). Please correct my understanding of how tfm_register_client_id() is intended to be used if the above analysis is off base. Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 7 months

1
0
0 0

Re: [TF-M] SYSTICK ownership

by Ken Liu (Arm Technology China)

Hi Alan, Sorry for the late response - the secure IRQ patches are on the way but currently we don't have scenarios for this case. We would create a ticket for tracking this question and let's collect comment there. And, this topic sounds like a timer requirement, so can you tell the actual user scenario? For example, would there still be requirements of using SYSTICK in secure partition if some timer things is available? Thanks. -Ken -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of DeMars, Alan via TF-M Sent: 19 February 2019 02:47 To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com<mailto:Ken.Liu@arm.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] SYSTICK ownership My concern was the value one would provide for the "line_num" field within the manifest. The SYSTICK uses vector 15 which I believe would correspond to "line_num" = -1. I'm not sure the design accommodates negative line_nums. Also, disabling the SYSTICK interrupt while servicing its interrupt can't be handled in the normal way user IRQs are disabled. Special case code would be required in the SPM to support the SYSTICK as a secure partition interrupt. Alan -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Monday, February 18, 2019 5:34 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd Subject: [EXTERNAL] Re: [TF-M] SYSTICK ownership Hi Alan, >From your description, it looks like you want to use secure SYSTICK as an interrupt for Secure Partition, is this correct? In this case, it is similar to the secure interrupt usage. Since the interrupt handling is under developing, I will add a note in the task to remind how we could add SYSTICK as an interrupt in the manifest. BR -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of > DeMars, Alan via TF-M > Sent: Saturday, February 16, 2019 7:02 AM > To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> > Subject: [TF-M] SYSTICK ownership > > If not used anywhere else, can a Secure Partition own the secure > SYSTICK timer and its interrupt? > If so, how is it specified in the SP manifest? > > Alan > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 7 months

1
0
0 0

Re: [TF-M] TFM Core regression tests

by Andrej Butok

Hi Mate, OK. It's good to know that this is the known issue. I will wait for a final review and merge. Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Mate Toth-Pal via TF-M Sent: Wednesday, March 27, 2019 2:45 PM To: TF-M(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TFM Core regression tests Hi Andrej, Yes, on the master branch this is a limitation. I already have a few patches on review to fix this: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr… https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr… They are most probably going to be merged with the secure IRQ handling commits. You can also cherry pick those for yourself for testing purposes, there should be no conflict, as it is quite independent from the parent commits on review. Regards, Mate -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 27 March 2019 14:32 To: TF-M(a)lists.trustedfirmware.org Subject: [TF-M] TFM Core regression tests Hello We are trying to enable & compile TFM Core tests. But it looks like they are only for MPS2 platform: 1) tfm_ss_core_test.c: .... #include "smm_mps2.h" ... static psa_status_t test_peripheral_access(void) { struct arm_mps2_fpgaio_t *fpgaio = SEC_MPS2_FPGAIO; ... etc. 2) tfm_partition_list.inc ... #ifdef TFM_PARTITION_TEST_CORE ... PARTITION_ADD_PERIPHERAL(TFM_SP_CORE_TEST, TFM_PERIPHERAL_FPGA_IO); #endif /* TFM_PARTITION_TEST_CORE */ ... What do you suggest ? What is the plan? Should we to skip/ignore the TFM Core regression tests now? Thanks Andrej Butok SW Tech Lead Security & Connectivity, Microcontrollers NXP Semiconductors -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

6 years, 7 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M