- TF-M - lists.trustedfirmware.org

by Shebu Varghese Kuriakose

Hi All, Not sure if everyone knows that there is an initial deployment of TF-M CI (Continuous Integration) system. It tests every patch that gets submitted in TF-M gerrit. Read about the CI system and find the relevant links in this blog - https://www.trustedfirmware.org/blog/trusted-firmware-open-ci-update/ Thanks, Shebu

7 years, 4 months

1
0
0 0

Please help review the patches of architecture abstraction in TF-M

by David Hu (Arm Technology China)

Hi all, Could you please review the following patches to abstract architecture specific code? https://review.trustedfirmware.org/c/trusted-firmware-m/+/1157/<https://review.trustedfirmware.org/c/trusted-firmware-m/+/1157> https://review.trustedfirmware.org/c/trusted-firmware-m/+/1158 https://review.trustedfirmware.org/c/trusted-firmware-m/+/1390/ https://review.trustedfirmware.org/c/trusted-firmware-m/+/1251/ https://review.trustedfirmware.org/c/trusted-firmware-m/+/1252/ The above patches abstract architecture specific code to decouple TF-M core to specific architecture details. It can help enable TF-M running on diverse Arm M-profile architectures. Other Arm M-profile architecture implementation will be added later. Suggestions are welcome. Thank you. Best regards, Hu Ziji

7 years, 4 months

1
0
0 0

Align manifest to PSA FF

by Edison Ai (Arm Technology China)

Hi, I had create patches related to manifest. There are two topics for it: * Align manifest to PSA FF: https://review.trustedfirmware.org/#/q/topic:Align_manifest_to_PSA_FF+(stat… * Generate SID and signal header files according to manifest: https://review.trustedfirmware.org/#/q/topic:generate_SID_signal_header_fil… I had added some reviewers to help to review them. Please feel free to give any comment even you are not in reviewer list(Sorry maybe skip someone by mistake). There are some important patches I think and please pay your attention to them: * Remove "tfm_symbol" from manifest: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1243/ * Change the value of SID: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1246/ * Rename the manifest file: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1247/ * Generate manifest file name header file: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1354/ * Assign signal value to SPM: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1356/ * Generate service ID header file: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1353/ Thanks, Edison

7 years, 4 months

1
0
0 0

Re: [TF-M] T398: Initial support for IAR Embedded Workbench for Arm tool chain

by Christian Daudt

If the objective of assigning it to TEST_PASSED before the test is that it becomes the default final answer (i.e. unless it gets reassigned to TEST_FAILED the final result remains this assignment) then it should absolutely be set to TEST_PASSED at startup. thanks, Christian. ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Jamie Fox via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Wednesday, June 19, 2019 6:00 AM To: Thomas Törnblom; tf-m(a)lists.trustedfirmware.org Cc: nd Subject: Re: [TF-M] T398: Initial support for IAR Embedded Workbench for Arm tool chain Hi Thomas, Personally I would avoid the type cast too. But to turn your dilemma into a trilemma, there is a third possible solution too -- you could remove the `{0}` initialiser from the initialiser list. Then the last member of the struct will be initialised implicitly the same way as a static object (i.e. to zero). Best wishes, Jamie -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: 19 June 2019 13:05 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] T398: Initial support for IAR Embedded Workbench for Arm tool chain I get lots of warnings about type mismatch for enums. I have fixed some of them where it seems natural, but I need to discuss the approach for fixing these: --- [ 37%] Building C object test/CMakeFiles/tfm_secure_tests.dir/suites/invert/secure/invert_s_interface_testsuite.o "Invert with valid buffer", {0} }, ^ "C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\test\suites\invert\secure\invert_s_interface_testsuite.c",20 Warning[Pe188]: enumerated type mixed with another type "Invert with invalid buffer", {0} }, ^ "C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\test\suites\invert\secure\invert_s_interface_testsuite.c",22 Warning[Pe188]: enumerated type mixed with another type --- The issue is that the "{0}" is the initializer for the enum test_status_t "val" below: --- enum test_status_t { TEST_PASSED = 0, /*!< Test has passed */ TEST_FAILED = 1, /*!< Test has failed */ }; struct test_result_t { enum test_status_t val; /*!< Test result \ref test_status_t */ const char *info_msg; /*!< Information message to show in case of * failure */ const char *filename; /*!< Filename where the failure has occured */ uint32_t line; /*!< Line where the failure has occured */ }; --- I can eliminate the warnings by either casting the "0" to enum test_status_t, or replace the 0 with "TEST_PASSED". Personally I would prefer to avoid having a type cast, but initializing the value to "TEST_PASSED" may seem to indicate that the test has passed even before having been run. Comments? /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> Website: 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> -- 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 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.

7 years, 4 months

1
0
0 0

Re: [TF-M] T398: Initial support for IAR Embedded Workbench for Arm tool chain

by Jamie Fox

Hi Thomas, Personally I would avoid the type cast too. But to turn your dilemma into a trilemma, there is a third possible solution too -- you could remove the `{0}` initialiser from the initialiser list. Then the last member of the struct will be initialised implicitly the same way as a static object (i.e. to zero). Best wishes, Jamie -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: 19 June 2019 13:05 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] T398: Initial support for IAR Embedded Workbench for Arm tool chain I get lots of warnings about type mismatch for enums. I have fixed some of them where it seems natural, but I need to discuss the approach for fixing these: --- [ 37%] Building C object test/CMakeFiles/tfm_secure_tests.dir/suites/invert/secure/invert_s_interface_testsuite.o "Invert with valid buffer", {0} }, ^ "C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\test\suites\invert\secure\invert_s_interface_testsuite.c",20 Warning[Pe188]: enumerated type mixed with another type "Invert with invalid buffer", {0} }, ^ "C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\test\suites\invert\secure\invert_s_interface_testsuite.c",22 Warning[Pe188]: enumerated type mixed with another type --- The issue is that the "{0}" is the initializer for the enum test_status_t "val" below: --- enum test_status_t { TEST_PASSED = 0, /*!< Test has passed */ TEST_FAILED = 1, /*!< Test has failed */ }; struct test_result_t { enum test_status_t val; /*!< Test result \ref test_status_t */ const char *info_msg; /*!< Information message to show in case of * failure */ const char *filename; /*!< Filename where the failure has occured */ uint32_t line; /*!< Line where the failure has occured */ }; --- I can eliminate the warnings by either casting the "0" to enum test_status_t, or replace the 0 with "TEST_PASSED". Personally I would prefer to avoid having a type cast, but initializing the value to "TEST_PASSED" may seem to indicate that the test has passed even before having been run. Comments? /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> Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems> -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

7 years, 4 months

1
0
0 0

Re: [TF-M] T398: Initial support for IAR Embedded Workbench for Arm tool chain

by Thomas Törnblom

I get lots of warnings about type mismatch for enums. I have fixed some of them where it seems natural, but I need to discuss the approach for fixing these: --- [ 37%] Building C object test/CMakeFiles/tfm_secure_tests.dir/suites/invert/secure/invert_s_interface_testsuite.o "Invert with valid buffer", {0} }, ^ "C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\test\suites\invert\secure\invert_s_interface_testsuite.c",20 Warning[Pe188]: enumerated type mixed with another type "Invert with invalid buffer", {0} }, ^ "C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\test\suites\invert\secure\invert_s_interface_testsuite.c",22 Warning[Pe188]: enumerated type mixed with another type --- The issue is that the "{0}" is the initializer for the enum test_status_t "val" below: --- enum test_status_t { TEST_PASSED = 0, /*!< Test has passed */ TEST_FAILED = 1, /*!< Test has failed */ }; struct test_result_t { enum test_status_t val; /*!< Test result \ref test_status_t */ const char *info_msg; /*!< Information message to show in case of * failure */ const char *filename; /*!< Filename where the failure has occured */ uint32_t line; /*!< Line where the failure has occured */ }; --- I can eliminate the warnings by either casting the "0" to enum test_status_t, or replace the 0 with "TEST_PASSED". Personally I would prefer to avoid having a type cast, but initializing the value to "TEST_PASSED" may seem to indicate that the test has passed even before having been run. Comments? /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> Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>

7 years, 4 months

1
0
0 0

Re: [TF-M] Is TFM_PSA_API broken?

by Andrej Butok

Just FYI The problem has been solved. The main issue was caused by not correct integration of mbedCrypto on our side. -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Friday, June 14, 2019 5:12 PM To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Is TFM_PSA_API broken? Just FYI: Downgraded to commit SHA-1: 25e2b2dba5d7eb3ba0da14384a6c8240278f5c15 (Crypto: Implement additional PSA Crypto APIs). It becomes much better, but finally goes to the assert in some time (tfm_thrd_context_switch:170). Will continue next week. The terminal log: Sec Thread] Secure image initializing! [Sec Thread] hello! this is ipc client test sp! [Sec Thread] Connect success! [Sec Thread] Call success! #### Execute test suites for the Secure area #### Running Test Suite PSA protected storage S interface tests (TFM_SST_TEST_2XXX)... > Executing 'TFM_SST_TEST_2001' Description: 'Set interface' TEST PASSED! > Executing 'TFM_SST_TEST_2002' Description: 'Set interface with create flags' TEST PASSED! > Executing 'TFM_SST_TEST_2003' Description: 'Set interface with NULL data pointer' TEST PASSED! > Executing 'TFM_SST_TEST_2004' Description: 'Set interface with invalid data length' TEST PASSED! > Executing 'TFM_SST_TEST_2005' Description: 'Set interface with write once UID' TEST PASSED! > Executing 'TFM_SST_TEST_2006' Description: 'Get interface with valid data' TEST PASSED! > Executing 'TFM_SST_TEST_2007' Description: 'Get interface with zero data length' TEST PASSED! > Executing 'TFM_SST_TEST_2008' Description: 'Get interface with invalid UIDs' TEST PASSED! > Executing 'TFM_SST_TEST_2009' Description: 'Get interface with invalid data lengths and offsets' TEST PASSED! > Executing 'TFM_SST_TEST_2010' Description: 'Get interface with NULL data pointer' TEST PASSED! > Executing 'TFM_SST_TEST_2011' Description: 'Get info interface with write once UID' TEST PASSED! > Executing 'TFM_SST_TEST_2012' Description: 'Get info interface with valid UID' TEST PASSED! > Executing 'TFM_SST_TEST_2013' Description: 'Get info interface with invalid UIDs' TEST PASSED! > Executing 'TFM_SST_TEST_2014' Description: 'Get info interface with NULL info pointer' TEST PASSED! > Executing 'TFM_SST_TEST_2015' Description: 'Remove interface with valid UID' TEST PASSED! > Executing 'TFM_SST_TEST_2016' Description: 'Remove interface with write once UID' TEST PASSED! > Executing 'TFM_SST_TEST_2017' Description: 'Remove interface with invalid UID' TEST PASSED! > Executing 'TFM_SST_TEST_2018' Description: 'Block compaction after remove' TEST PASSED! > Executing 'TFM_SST_TEST_2019' Description: 'Multiple partial gets' TEST PASSED! > Executing 'TFM_SST_TEST_2020' Description: 'Multiple sets to same UID from same thread' TEST PASSED! > Executing 'TFM_SST_TEST_2021' Description: 'Get support interface' TEST PASSED! TESTSUITE PASSED! Running Test Suite SST reliability tests (TFM_SST_TEST_3XXX)... > Executing 'TFM_SST_TEST_3001' Description: 'repetitive sets and gets in/from an asset' > Iteration 15 of 15 TEST PASSED! > Executing 'TFM_SST_TEST_3002' Description: 'repetitive sets, gets and removes' > Iteration 15 of 15 TEST PASSED! TESTSUITE PASSED! Running Test Suite Crypto secure interface tests (TFM_CRYPTO_TEST_5XXX)... > Executing 'TFM_CRYPTO_TEST_5001' Description: 'Secure Key management interface' Assert:tfm_thrd_context_switch:170 From: Andrej Butok Sent: Friday, June 14, 2019 4:14 PM To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: RE: Is TFM_PSA_API broken? Hi Ken, > Please check your modification in SST partition No modifications from my side. As it becomes wasting of time, a debugging is not consistent and looks like uninitialized variable, stack or something else. I have decided to find a TFM commit which caused this abnormal behavior. So far, it occurs in a commit between: NOT WORKING: SHA-1: 122360ffb1e7278406183714249afefcb2184488 * Attest: Replace example asymmetric key-pair WORKING: SHA-1: 4743e6731b0fe8a00ceebfd74da098c7676ac6e0 * Crypto: Add IPC compatibility Thanks, Andrej From: Ken Liu (Arm Technology China) <mailto:Ken.Liu@arm.com> Sent: Friday, June 14, 2019 4:00 PM To: Andrej Butok <mailto:andrey.butok@nxp.com> Cc: mailto:tf-m@lists.trustedfirmware.org; nd <mailto:nd@arm.com> Subject: Re: Is TFM_PSA_API broken? Hi Andrej, As I said, that workaround only works for specified case. Debugging these failed cases with this patch applied will lead you into heavy core debugging. We need to find out the root cause, why the assert is triggered? There is no reason that all partitions go into block state, unless there are some improper modification in core or secure partitions. Please check your modification in SST partition, try to print something in your SST thread, to see why the thread keeps in block state. If a client calls psa_connect/psa_all, SPM would activate the partition into running state with function tfm_spm_send_event(). The correct call routine should be (psa_call has the similar routine): tfm_sst_test_2001->psa_connect->...->SVC_Handler->tfm_svcall_psa_connect->tfm_spm_send_event->....-> (your partition thread). Please remove the workaround patch, and try to debug to see if the call routine is correct. Thanks. -Ken ________________________________________ From: Andrej Butok <mailto:andrey.butok@nxp.com> Sent: Friday, June 14, 2019 8:13 PM To: Ken Liu (Arm Technology China) Cc: mailto:tf-m@lists.trustedfirmware.org Subject: RE: Is TFM_PSA_API broken? Hi Ken, Your patch/fix helped, so now there is no stuck in assert. But all regression tests are failed: #### Execute test suites for the Secure area #### Running Test Suite PSA protected storage S interface tests (TFM_SST_TEST_2XXX)... > Executing 'TFM_SST_TEST_2001' Description: 'Set interface' Set should not fail with valid UID (Failed at ../../../../../../../middleware/tfm/test/suites/sst/secure/psa_ps_s_interface_testsuite.c:153) TEST FAILED! > Executing 'TFM_SST_TEST_2002' Description: 'Set interface with create flags' Set should not fail with no flags (Failed at ../../../../../../../middleware/tfm/test/suites/sst/secure/psa_ps_s_interface_testsuite.c:199) TEST FAILED! > Executing 'TFM_SST_TEST_2003' Description: 'Set interface with NULL data pointer' Set should succeed with NULL data pointer and zero length (Failed at ../../../../../../../middleware/tfm/test/suites/sst/secure/psa_ps_s_interface_testsuite.c:243) TEST FAILED! Will try to investigate... -----Original Message----- From: TF-M <mailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Friday, June 14, 2019 10:32 AM To: mailto:TF-M@lists.trustedfirmware.org Cc: nd <mailto:nd@arm.com> Subject: Re: [TF-M] Is TFM_PSA_API broken? Hi Andrej, tfm_thrd_context_switch() does not want to thread to be running is NULL. And actually it should never happen in existing implement unless IRQ is involved. Here is a patch for fixing this, but I am not sure if you are under the same case we met: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr… I am curious about your environment, at least one partition will be running in latest master branch. Can you share me your changes? Are your using original TF-M and which configuration file you are using? Thanks. -Ken > -----Original Message----- > From: TF-M <mailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf > Of Andrej Butok via TF-M > Sent: Friday, June 14, 2019 4:15 PM > To: Antonio De Angelis <mailto:Antonio.DeAngelis@arm.com> > Cc: mailto:tf-m@lists.trustedfirmware.org > Subject: Re: [TF-M] Is TFM_PSA_API broken? > > Hi Antonio, > > > > So, I have disabled Platform and Log services. > > Also, TFM_NS_CLIENT_IDENTIFICATION have to be undefined for IPC. Is > this correct? > > After that it becomes compliable. > > > > But when starting the regression tests, I am getting assert in > tfm_thrd_conext_switch(). Terminal log: > > > > [Sec Thread] Secure image initializing! > > > > NS code is running... > > > > #### Execute test suites for the Secure area #### > > Running Test Suite PSA protected storage S interface tests > (TFM_SST_TEST_2XXX)... > > > Executing 'TFM_SST_TEST_2001' > > Description: 'Set interface' > > Assert:tfm_thrd_context_switch:170 > > > > So I am stuck now, and no matter what to use the IPC or the Function > API approach. > > Probably, something serious happened during last two weeks (before it > worked), may be in platform dependent code. > > NOTE: I am using a different platform LPC55S69 and IDE approach (not cmake). > > > > Any tips? > > > > Thanks, > > Andrej > > > > > > -----Original Message----- > From: TF-M <mailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf > Of Antonio De Angelis via TF-M > Sent: Thursday, June 13, 2019 5:00 PM > To: mailto:tf-m@lists.trustedfirmware.org > Cc: nd <mailto:nd@arm.com> > Subject: Re: [TF-M] Is TFM_PSA_API broken? > > > > Hi Andrej, > > > > "Should the Log and Platform services be disabled for IPC?" > > > > Yes, platform service and Audit Log service do not support IPC. You > can see from existing IPC - specific build configurations which flags > need to be set to make sure these two services are not built when IPC builds are selected. > > > > Thanks, > > Antonio > > > > -----Original Message----- > > From: TF-M > <mailto:tf-m-bounces@lists.trustedfirmware.org%3cmailto:tf-m-%0b> > mailto:bounces@lists.trustedfirmware.org>> On Behalf Of Andrej Butok > via TF-M > > Sent: 13 June 2019 15:46 > > To: > mailto:tf-m@lists.trustedfirmware.org%3cmailto:tf-m@lists.trustedfirmw > are.org> > > Subject: [TF-M] Is TFM_PSA_API broken? > > > > Hello, > > > > I use absolutely the latest TF-M (SHA-1: > 81fb08cd66c1037a5e6c57e46ad5946bfc8a0d0e) > > > > I am trying to run the regression-test application using IPC API > (TFM_PSA_API is > defined) The application is compliable with errors: > > Error: L6218E: Undefined symbol tfm_spm_request_reset_vote (referred > from platform_sp.o). > > Error: L6218E: Undefined symbol tfm_core_get_caller_client_id > (referred from audit_core.o). > > Not enough information to list image symbols. > > > > It is caused by the fact that the platform and audit log services are > using the functions (printed in the log) which are not > available/disabled when TFM_PSA_API is defined. > > Is it known issue? > > Any suggestions? > > Should the Log and Platform services be disabled for IPC? > > > > Thanks, > > Andrej > > -- > > TF-M mailing list > > mailto:TF-M@lists.trustedfirmware.org%3cmailto:TF-M@lists.trustedfirmw > are.org> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > s.trust > edfirmware.org%2Fmailman%2Flistinfo%2Ftf- > m&data=02%7C01%7Candrey.butok%40nxp.com%7C4416c02536e54d420 > bdc08d6f00fc1ff%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6369 > 60347799555976&sdata=1zhWkIyBjqiiTqtf0tYdtxRACLofQ%2B5Po6tC3cqW > Fis%3D&reserved=0 > > -- > > TF-M mailing list > > mailto:TF-M@lists.trustedfirmware.org%3cmailto:TF-M@lists.trustedfirmw > are.org> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > s.trust > edfirmware.org%2Fmailman%2Flistinfo%2Ftf- > m&data=02%7C01%7Candrey.butok%40nxp.com%7C4416c02536e54d420 > bdc08d6f00fc1ff%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6369 > 60347799555976&sdata=1zhWkIyBjqiiTqtf0tYdtxRACLofQ%2B5Po6tC3cqW > Fis%3D&reserved=0 > -- > TF-M mailing list > mailto:TF-M@lists.trustedfirmware.org > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > s.trustedfirmware.org%2Fmailman%2Flistinfo%2Ftf-m&data=02%7C01%7Ca > ndrey.butok%40nxp.com%7C441c81dc90a44fb5418408d6f0a2b68a%7C686ea1d3bc2 > b4c6fa92cd99c5c301635%7C0%7C0%7C636960978972859087&sdata=weHHf8wG3 > nlnTsI1JEA5Ww0D9sXSf4oJKyLkImmaCi8%3D&reserved=0 -- TF-M mailing list mailto:TF-M@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…

7 years, 5 months

1
0
0 0

Re: [TF-M] Supported versions of the Armclang compiler in the TF-M build

by Antonio De Angelis

Hi all, As I haven't received any objection to the below, I am going to merge the change which drops support for Armclang 6.7 and Armclang 6.9. Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M Sent: 06 June 2019 11:28 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Supported versions of the Armclang compiler in the TF-M build Dear all, We are considering to drop support for older versions of the Armclang compiler (i.e. 6.7 and 6.9) to focus support on newer releases (thus increasing the requirement on Armclang version to 6.10 or higher). https://developer.trustedfirmware.org/T392 https://review.trustedfirmware.org/c/trusted-firmware-m/+/1223 If you have any specific requirement to use Armclang 6.7 or 6.9, please get in touch here or on the review. Thanks, Antonio -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

7 years, 5 months

1
0
0 0

Re: [TF-M] Feature request

by Andrej Butok

Hi Miklos, One more feature request: 3) Using separate files in TFM without #ifdef is causing issues for IDE projects, and requires creation of separate projects/targets (with different file set) per each feature combination. We are using IDEs (IAR, MCUx, Keil), so we have to add missing #ifdef to the original TFM source code. Please use #if/#ifdef in TFM, everywhere were it is needed. Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Miklos Balint via TF-M Sent: Monday, June 17, 2019 5:31 PM To: Thomas Törnblom <thomas.tornblom(a)iar.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Feature request Hi Thomas, I see no major issue with either suggestion, I think it makes sense to introduce improvements in these matters. For issue #1 it makes very much sense to have a shared header file for all components that rely on these definitions. I don't recall any reason why that should not be possible, it's simply something that hasn't been done due to limited bandwidth for such clean-up of the code. For issue #2 we have had some internal discussions on the best way to handle compiler dependencies, and the suggestion I liked the most is similar to your suggestion below, but instead of having a single header file, having a compiler folder with each supported toolchain as a separate sub-folder, each defining their own version of tfm_compiler.h to provide the definitions required by TF-M. The compiler-specific cmake file can then simply point to the appropriate location for the compiler-specific inclusion, avoiding compiler-specific ifdef:s. Let me know your thoughts on this approach Thanks and kindest regards Miklos -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: 13 June 2019 16:11 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Feature request While working on porting TF-M to the IAR toolchain, I've run into a couple of issues I'd like to discuss. 1) The duplicated REGION/REGION_NAME/REGION_DECLARE macros. Why are these not defined in an include file instead of being defined in eight different c files? I see that they are also defined in spm_db.h, but that is only included in spm related files. 2) I suggest adding a toolchain related include file that should be included in every source file that is part of TF-M. This could be something similar to cmsis_compiler.h, where a toolchain vendor could add stuff that only relates to a specific toolchain. In our case that could include things like: --- #ifdef __ICCARM__ #define $$ZI$$Limit $$Limit #define $$ZI$$Base $$Base #define Image$$ #endif --- Ideas? /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> Website: https://eur01.safelinks.protection.outlook.com/?url=www.iar.com&data=02… <https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.iar.co…> Twitter: https://eur01.safelinks.protection.outlook.com/?url=www.twitter.com%2Fiarsy… <https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.twitte…> -- 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…

7 years, 5 months

1
0
0 0

Re: [TF-M] TF-M Cooperative Scheduler Design - Scheduling Rules

by Ken Liu (Arm Technology China)

Hi Ashu, The proposal is good and covers most of the cases while a NS and S communication channel is available. And I think below part is going to be considerate before we create design docs to follow this rules: - Leave the NSPE SPM_IDLE case handling as implementation defined instead of involving IRQ to bring more complexity. NSPE could just yield but SPE needs to support a bit asynchronization -- that is not a big fair compare to IRQ communication. - The rules rely on the NSPE/SPE communication channel but for if NSPE has no use/misuse this channel SPE should detect the problem and panic NSPE, this is also can to be implemented. Most of the interrupt priority related rules can be done with hardware setting. The priority of secure partition with IRQ needs to be considerate while partitions designing since in IPC model scheduler decides who should go based on partition priority. Let's see if we can find more cases while implementing. BR -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ashutosh > Singh via TF-M > Sent: Tuesday, April 30, 2019 7:06 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: [TF-M] TF-M Cooperative Scheduler Design - Scheduling Rules > > Hi, > > This is a proposal that introduces scheduling rules in TF-M. > Introduction: > On ArmV8-M CPUs, NSPE and SPE share the same physical processing > element(PE). A TF-M enabled system need to be able to handle asynchronous > events (interrupts) regardless of current security state of the PE; and that may > lead to scheduling decisions. This introduces significant complexity into TF-M. To > keep the integrity of (NSPE and SPE) schedulers and call paths between NSPE and > SPE, following set of rules are imposed on the TF-M scheduler design. > https://developer.trustedfirmware.org/w/tf_m/design/cooperative_scheduling/ > > Feedback welcome! > > Thanks, > Ashu > > > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

7 years, 5 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M