- TF-M - lists.trustedfirmware.org

[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

7 years, 2 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.

7 years, 2 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

7 years, 2 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

7 years, 2 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

7 years, 2 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

7 years, 2 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

7 years, 2 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

7 years, 2 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

7 years, 2 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

7 years, 2 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M