- TF-M - lists.trustedfirmware.org

Re: [TF-M] spi peripheral doesn't work in secure world

by Kevin Peng

Hi Poppy, Mmio_regions is required for Secure Partitions to access peripherals, even though in some cases it would work without mmio_regions declaration. Could you please provide more information such as what's your build configuration and what's the type of your Secure Partition? Have you put the driver codes into the Secure Partition's library in the TF-M build system? Are you seeing any exceptions or errors? Best Regards, Kevin From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edward Yang via TF-M Sent: Wednesday, July 28, 2021 11:23 AM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] spi peripheral doesn't work in secure world Hi experts, We are running Arm TF-M on stm32l562e_dk board, and we add a new secure partition based on TF-M architecture according to our specific application.In this new secure partition ,spi peripheral is used to communicate with a external spi nor flash. [cid:image001.gif@01D783B8.24FD4C40] If we just test the spi driver in non-secure world(without tf-m),it works well. Then we put this driver in secure world,it's a plarform driver used by this new secure partition,and we have configured the spi peripheral as secure peripheral in gtzc_init_cfg() inside tfm_core_init(). We used a logic analyzer to debug, and found there was no spi communication waveform, it seems that this peripheral doesn't work in secure world,. We didn't declare this new partition's dependency on spi peripheral in its manifest files with mmio_regions. And I am not sure whether this is why the spi peripheral doesn't work. Is there anything else that we should pay attention to? Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd http://www.mxic.com.cn<http://www.mxic.com.cn/> CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. =====================================================================

3 years, 8 months

1
0
0 0

spi peripheral doesn't work in secure world

by Edward Yang

Hi experts, We are running Arm TF-M on stm32l562e_dk board, and we add a new secure partition based on TF-M architecture according to our specific application.In this new secure partition ,spi peripheral is used to communicate with a external spi nor flash. If we just test the spi driver in non-secure world(without tf-m),it works well. Then we put this driver in secure world,it's a plarform driver used by this new secure partition,and we have configured the spi peripheral as secure peripheral in gtzc_init_cfg() inside tfm_core_init(). We used a logic analyzer to debug, and found there was no spi communication waveform, it seems that this peripheral doesn't work in secure world,. We didn't declare this new partition's dependency on spi peripheral in its manifest files with mmio_regions. And I am not sure whether this is why the spi peripheral doesn't work. Is there anything else that we should pay attention to? Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd http://www.mxic.com.cn ============================================================================ CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. =====================================================================

3 years, 8 months

1
0
0 0

Re: [TF-M] Failure building Musca B1 SE with armclang on Linux

by Raef Coles

What version of cmake are you using Chris? I notice it's installed via PIP, so it might be a particularly new one which has some incompatibility Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of chris.brand--- via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 27 July 2021 16:58 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Failure building Musca B1 SE with armclang on Linux This is definitely something wrong with my system. I can’t build other targets with that toolchain either. Chris From: David Hu <David.Hu(a)arm.com> Sent: Tuesday, July 27, 2021 2:02 AM To: Anton Komlev <Anton.Komlev(a)arm.com>; tf-m(a)lists.trustedfirmware.org; Brand Chris (CSCA CSS ICW SW PSW 1) <Chris.Brand(a)infineon.com> Cc: nd <nd(a)arm.com> Subject: RE: Failure building Musca B1 SE with armclang on Linux Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://intranet-content.infineon.com/explore/aboutinfineon/rules/informati…>. Hi Chris, Xinyu helps run a Musca-B1 build on staging CI with Armclang 6.13 and the build succeeds. Please check the build log: https://ci.staging.trustedfirmware.org/view/TF-M/job/tf-m-build-config/2681… Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Anton Komlev via TF-M Sent: Tuesday, July 27, 2021 3:32 PM To: 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] Failure building Musca B1 SE with armclang on Linux Hi Chris, Your command works well also on Windows, Clang v6.16.1, although had to modify -G”Unix Makefiles”. Hope it helps, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of David Hu via TF-M Sent: Tuesday, July 27, 2021 12:59 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; Chris.Brand(a)infineon.com<mailto:Chris.Brand@infineon.com>; Raef Coles <Raef.Coles(a)arm.com<mailto:Raef.Coles@arm.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] Failure building Musca B1 SE with armclang on Linux Hi Chris, Sorry for the trouble. I tried your build command and it worked with Armclang 6.14 on my ubuntu desktop. It looks like CMAKE_C_COMPILER_ID doesn’t receive the correct toolchain ID. Probably @Raef can help? Best regards, Hu Ziji ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of chris.brand--- via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: Tuesday, July 27, 2021 3:08 AM 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] Failure building Musca B1 SE with armclang on Linux My build command is this: cmake -S . -B build_musca_se_ARMCLANG_Debug '-GUnix Makefiles' -DTFM_PLATFORM=arm/musca_b1/secure_enclave -DTFM_TOOLCHAIN_FILE=toolchain_ARMCLANG.cmake -DCMAKE_BUILD_TYPE=Debug -DTFM_ISOLATION_LEVEL=2 -DTFM_PSA_API=ON -DFORWARD_PROT_MSG=ON -DTFM_PROFILE=profile_medium The tree I’m building is hash 76939d7ca9cea03b07d3617fbbdca09947d5cdf9, and the toolchain is version 6.13. I see the same error with version 6.12. The error message I get is this: [100%] Built target tfm_test_repo-populate gmake[1]: Leaving directory '/lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/build_musca_se_ARMCLANG_Debug/lib/ext/tfm_test_repo-subbuild' /lhome/cbrand/.local/lib/python3.6/site-packages/cmake/data/bin/cmake -E cmake_progress_start /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/build_musca_se_ARMCLANG_Debug/lib/ext/tfm_test_repo-subbuild/CMakeFiles 0 CMake Error at lib/ext/CMSIS_5/CMakeLists.txt:25 (message): does not have CMSIS RTX static libraries set up -- Configuring incomplete, errors occurred! I wonder whether it might be a toolchain configuration issue, but I’m pretty sure that I’ve built with this same toolchain on this same machine in the past… Gcc build with the same source and options works fine. Chris Brand Cypress Semiconductor (Canada), Inc. Sr Prin Software Engr CSCA CSS ICW SW PSW 1 Office: +1 778 234 0515 Chris.Brand(a)infineon.com<mailto:Chris.Brand@infineon.com>

3 years, 8 months

2
1
0 0

Re: [TF-M] Failure building Musca B1 SE with armclang on Linux

by David Hu

Hi Chris, Xinyu helps run a Musca-B1 build on staging CI with Armclang 6.13 and the build succeeds. Please check the build log: https://ci.staging.trustedfirmware.org/view/TF-M/job/tf-m-build-config/2681… Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Tuesday, July 27, 2021 3:32 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Failure building Musca B1 SE with armclang on Linux Hi Chris, Your command works well also on Windows, Clang v6.16.1, although had to modify -G"Unix Makefiles". Hope it helps, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of David Hu via TF-M Sent: Tuesday, July 27, 2021 12:59 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; Chris.Brand(a)infineon.com<mailto:Chris.Brand@infineon.com>; Raef Coles <Raef.Coles(a)arm.com<mailto:Raef.Coles@arm.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] Failure building Musca B1 SE with armclang on Linux Hi Chris, Sorry for the trouble. I tried your build command and it worked with Armclang 6.14 on my ubuntu desktop. It looks like CMAKE_C_COMPILER_ID doesn't receive the correct toolchain ID. Probably @Raef can help? Best regards, Hu Ziji ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of chris.brand--- via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: Tuesday, July 27, 2021 3:08 AM 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] Failure building Musca B1 SE with armclang on Linux My build command is this: cmake -S . -B build_musca_se_ARMCLANG_Debug '-GUnix Makefiles' -DTFM_PLATFORM=arm/musca_b1/secure_enclave -DTFM_TOOLCHAIN_FILE=toolchain_ARMCLANG.cmake -DCMAKE_BUILD_TYPE=Debug -DTFM_ISOLATION_LEVEL=2 -DTFM_PSA_API=ON -DFORWARD_PROT_MSG=ON -DTFM_PROFILE=profile_medium The tree I'm building is hash 76939d7ca9cea03b07d3617fbbdca09947d5cdf9, and the toolchain is version 6.13. I see the same error with version 6.12. The error message I get is this: [100%] Built target tfm_test_repo-populate gmake[1]: Leaving directory '/lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/build_musca_se_ARMCLANG_Debug/lib/ext/tfm_test_repo-subbuild' /lhome/cbrand/.local/lib/python3.6/site-packages/cmake/data/bin/cmake -E cmake_progress_start /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/build_musca_se_ARMCLANG_Debug/lib/ext/tfm_test_repo-subbuild/CMakeFiles 0 CMake Error at lib/ext/CMSIS_5/CMakeLists.txt:25 (message): does not have CMSIS RTX static libraries set up -- Configuring incomplete, errors occurred! I wonder whether it might be a toolchain configuration issue, but I'm pretty sure that I've built with this same toolchain on this same machine in the past... Gcc build with the same source and options works fine. Chris Brand Cypress Semiconductor (Canada), Inc. Sr Prin Software Engr CSCA CSS ICW SW PSW 1 Office: +1 778 234 0515 Chris.Brand(a)infineon.com<mailto:Chris.Brand@infineon.com>

3 years, 8 months

2
1
0 0

Re: [TF-M] TF-M v1.4.0 release started

by Chris.Brand＠infineon.com

We ran the regression test suite on PSoC64. We did see some failures in the PSA Arch crypto tests: TEST: 226 | DESCRIPTION: Testing crypto MAC APIs | UT: psa_mac_sign_setup TEST: 227 | DESCRIPTION: Testing crypto MAC APIs | UT: psa_mac_update TEST: 228 | DESCRIPTION: Testing crypto MAC APIs | UT: psa_mac_sign_finish TEST: 229 | DESCRIPTION: Testing crypto MAC APIs | UT: psa_mac_verify_setup TEST: 230 | DESCRIPTION: Testing crypto MAC APIs | UT: psa_mac_verify_finish TEST: 262 | DESCRIPTION: Testing crypto hash functions APIs | UT: psa_hash_suspend TEST: 263 | DESCRIPTION: Testing crypto hash functions APIs | UT: psa_hash_resume This is consistent between Debug/Release and gcc/armclang. Do we know whether the PSA Arch Crypto tests are passing on other platforms? Chris From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Monday, July 26, 2021 1:50 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M v1.4.0 release started Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://intranet-content.infineon.com/explore/aboutinfineon/rules/informati…>. Hi, All TF-M repositories are updated with TF-Mv1.4.0-RC2 tag. The changes are minimal and shall not invalidate the tests, already done. Please use this tag for new tests and report any issues found by the end of July 30. Thanks and good luck, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Anton Komlev via TF-M Sent: Wednesday, July 21, 2021 11:25 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: [TF-M] TF-M v1.4.0 release started Hi, All TF-M repositories are tagged with TF-Mv1.4.0-RC1 tag. Code is frozen now for the release candidate testing. Note that changes to other repositories are still possible during that time. Please use this tag for your tests and report any issues found by the end of July 30. Thanks and good luck, Anton

3 years, 8 months

1
0
0 0

Re: [TF-M] TF-M v1.4.0 release started

by David Hu

Hi Jamie, Can I ask about your toolchain in use? GNUARM 10-2020-q4-major will cause a similar issue. TF-M suggests to avoid using this version: https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/getti…. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M Sent: Tuesday, July 27, 2021 4:48 PM To: Jamie Mccrae <Jamie.Mccrae(a)lairdconnect.com>; Anton Komlev <Anton.Komlev(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] FW: TF-M v1.4.0 release started Hi Jamie, Sorry for the trouble. According to your description, the violation error is caused by non-secure test cases. is it correct? The error message is dumped by tfm_secure_api_error_handler(). It is called multiple times in Library model routine. Can you please help narrow the step in which tfm_secure_api_error_handler() is called? Besides, do you mind trying if IPC model can work on your board? Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Jamie Mccrae via TF-M Sent: Tuesday, July 27, 2021 3:43 PM To: Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@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] TF-M v1.4.0 release started Hi, I have tried the RC1 and RC2 on our platform, the BL5340 (nRF5340-based), which I am testing by building with the following: cmake -DTFM_PLATFORM=lairdconnectivity/bl5340_dvk_cpuapp -GNinja -DTFM_TOOLCHAIN_FILE=../toolchain_GNUARM.cmake -DTEST_S=on -DTEST_NS=on -DCMAKE_BUILD_TYPE=debug -DPS_TEST_NV_COUNTERS=on .. And upon starting the non-secure tests, a security violation occurs which reboots the module. Output from secure core: Test suite 'Crypto secure interface tests (TFM_S_CRYPTO_TEST_1XXX)' has PASSED Test suite 'Initial Attestation Service secure interface tests(TFM_S_ATTEST_TEST_1XXX)' has PASSED Test suite 'Platform Service Secure interface tests(TFM_S_PLATFORM_TEST_1XXX)' has PASSED Test suite 'Audit Logging secure interface test (TFM_S_AUDIT_TEST_1XXX)' has PASSED *** End of Secure test suites *** Security violation when calling secure API [INF] Starting bootloader [INF] Primary image: magic=good, swap_type=0x1, copy_done=0x3, image_ok=0x3 [INF] Scratch: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3 [INF] Boot source: primary slot Output from non-secure core: Non-Secure system starting... #### Execute test suites for the Non-secure area #### Running Test Suite PSA protected storage NS interface tests (TFM_NS_PS_TEST_1XXX)... > Executing 'TFM_NS_PS_TEST_1001' Description: 'Set interface' Non-Secure system starting... So something that has changed from 1.3 to 1.4 seems to have broken our platform. Thanks, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Anton Komlev via TF-M Sent: 26 July 2021 09:50 To: 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] TF-M v1.4.0 release started EXTERNAL EMAIL: Be careful with attachments and links. Hi, All TF-M repositories are updated with TF-Mv1.4.0-RC2 tag. The changes are minimal and shall not invalidate the tests, already done. Please use this tag for new tests and report any issues found by the end of July 30. Thanks and good luck, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Anton Komlev via TF-M Sent: Wednesday, July 21, 2021 11:25 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: [TF-M] TF-M v1.4.0 release started Hi, All TF-M repositories are tagged with TF-Mv1.4.0-RC1 tag. Code is frozen now for the release candidate testing. Note that changes to other repositories are still possible during that time. Please use this tag for your tests and report any issues found by the end of July 30. Thanks and good luck, Anton THIS MESSAGE, ANY ATTACHMENT(S), AND THE INFORMATION CONTAINED HEREIN MAY BE PROPRIETARY TO LAIRD CONNECTIVITY, INC. AND/OR ANOTHER PARTY, AND MAY FURTHER BE INTENDED TO BE KEPT CONFIDENTIAL. IF YOU ARE NOT THE INTENDED RECIPIENT, PLEASE DELETE THE EMAIL AND ANY ATTACHMENTS, AND IMMEDIATELY NOTIFY THE SENDER BY RETURN EMAIL. THIS MESSAGE AND ITS CONTENTS ARE THE PROPERTY OF LAIRD CONNECTIVITY, INC. AND MAY NOT BE REPRODUCED OR USED WITHOUT THE EXPRESS WRITTEN CONSENT OF LAIRD CONNECTIVITY, INC.

3 years, 8 months

2
1
0 0

FW: TF-M v1.4.0 release started

by David Hu

Hi Jamie, Sorry for the trouble. According to your description, the violation error is caused by non-secure test cases. is it correct? The error message is dumped by tfm_secure_api_error_handler(). It is called multiple times in Library model routine. Can you please help narrow the step in which tfm_secure_api_error_handler() is called? Besides, do you mind trying if IPC model can work on your board? Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Jamie Mccrae via TF-M Sent: Tuesday, July 27, 2021 3:43 PM To: Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@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] TF-M v1.4.0 release started Hi, I have tried the RC1 and RC2 on our platform, the BL5340 (nRF5340-based), which I am testing by building with the following: cmake -DTFM_PLATFORM=lairdconnectivity/bl5340_dvk_cpuapp -GNinja -DTFM_TOOLCHAIN_FILE=../toolchain_GNUARM.cmake -DTEST_S=on -DTEST_NS=on -DCMAKE_BUILD_TYPE=debug -DPS_TEST_NV_COUNTERS=on .. And upon starting the non-secure tests, a security violation occurs which reboots the module. Output from secure core: Test suite 'Crypto secure interface tests (TFM_S_CRYPTO_TEST_1XXX)' has PASSED Test suite 'Initial Attestation Service secure interface tests(TFM_S_ATTEST_TEST_1XXX)' has PASSED Test suite 'Platform Service Secure interface tests(TFM_S_PLATFORM_TEST_1XXX)' has PASSED Test suite 'Audit Logging secure interface test (TFM_S_AUDIT_TEST_1XXX)' has PASSED *** End of Secure test suites *** Security violation when calling secure API [INF] Starting bootloader [INF] Primary image: magic=good, swap_type=0x1, copy_done=0x3, image_ok=0x3 [INF] Scratch: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3 [INF] Boot source: primary slot Output from non-secure core: Non-Secure system starting... #### Execute test suites for the Non-secure area #### Running Test Suite PSA protected storage NS interface tests (TFM_NS_PS_TEST_1XXX)... > Executing 'TFM_NS_PS_TEST_1001' Description: 'Set interface' Non-Secure system starting... So something that has changed from 1.3 to 1.4 seems to have broken our platform. Thanks, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Anton Komlev via TF-M Sent: 26 July 2021 09:50 To: 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] TF-M v1.4.0 release started EXTERNAL EMAIL: Be careful with attachments and links. Hi, All TF-M repositories are updated with TF-Mv1.4.0-RC2 tag. The changes are minimal and shall not invalidate the tests, already done. Please use this tag for new tests and report any issues found by the end of July 30. Thanks and good luck, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Anton Komlev via TF-M Sent: Wednesday, July 21, 2021 11:25 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: [TF-M] TF-M v1.4.0 release started Hi, All TF-M repositories are tagged with TF-Mv1.4.0-RC1 tag. Code is frozen now for the release candidate testing. Note that changes to other repositories are still possible during that time. Please use this tag for your tests and report any issues found by the end of July 30. Thanks and good luck, Anton THIS MESSAGE, ANY ATTACHMENT(S), AND THE INFORMATION CONTAINED HEREIN MAY BE PROPRIETARY TO LAIRD CONNECTIVITY, INC. AND/OR ANOTHER PARTY, AND MAY FURTHER BE INTENDED TO BE KEPT CONFIDENTIAL. IF YOU ARE NOT THE INTENDED RECIPIENT, PLEASE DELETE THE EMAIL AND ANY ATTACHMENTS, AND IMMEDIATELY NOTIFY THE SENDER BY RETURN EMAIL. THIS MESSAGE AND ITS CONTENTS ARE THE PROPERTY OF LAIRD CONNECTIVITY, INC. AND MAY NOT BE REPRODUCED OR USED WITHOUT THE EXPRESS WRITTEN CONSENT OF LAIRD CONNECTIVITY, INC.

3 years, 8 months

1
0
0 0

Re: [TF-M] TF-M v1.4.0 release started

by Jamie Mccrae

Hi, I have tried the RC1 and RC2 on our platform, the BL5340 (nRF5340-based), which I am testing by building with the following: cmake -DTFM_PLATFORM=lairdconnectivity/bl5340_dvk_cpuapp -GNinja -DTFM_TOOLCHAIN_FILE=../toolchain_GNUARM.cmake -DTEST_S=on -DTEST_NS=on -DCMAKE_BUILD_TYPE=debug -DPS_TEST_NV_COUNTERS=on .. And upon starting the non-secure tests, a security violation occurs which reboots the module. Output from secure core: Test suite 'Crypto secure interface tests (TFM_S_CRYPTO_TEST_1XXX)' has PASSED Test suite 'Initial Attestation Service secure interface tests(TFM_S_ATTEST_TEST_1XXX)' has PASSED Test suite 'Platform Service Secure interface tests(TFM_S_PLATFORM_TEST_1XXX)' has PASSED Test suite 'Audit Logging secure interface test (TFM_S_AUDIT_TEST_1XXX)' has PASSED *** End of Secure test suites *** Security violation when calling secure API [INF] Starting bootloader [INF] Primary image: magic=good, swap_type=0x1, copy_done=0x3, image_ok=0x3 [INF] Scratch: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3 [INF] Boot source: primary slot Output from non-secure core: Non-Secure system starting... #### Execute test suites for the Non-secure area #### Running Test Suite PSA protected storage NS interface tests (TFM_NS_PS_TEST_1XXX)... > Executing 'TFM_NS_PS_TEST_1001' Description: 'Set interface' Non-Secure system starting... So something that has changed from 1.3 to 1.4 seems to have broken our platform. Thanks, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: 26 July 2021 09:50 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M v1.4.0 release started EXTERNAL EMAIL: Be careful with attachments and links. Hi, All TF-M repositories are updated with TF-Mv1.4.0-RC2 tag. The changes are minimal and shall not invalidate the tests, already done. Please use this tag for new tests and report any issues found by the end of July 30. Thanks and good luck, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Anton Komlev via TF-M Sent: Wednesday, July 21, 2021 11:25 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: [TF-M] TF-M v1.4.0 release started Hi, All TF-M repositories are tagged with TF-Mv1.4.0-RC1 tag. Code is frozen now for the release candidate testing. Note that changes to other repositories are still possible during that time. Please use this tag for your tests and report any issues found by the end of July 30. Thanks and good luck, Anton THIS MESSAGE, ANY ATTACHMENT(S), AND THE INFORMATION CONTAINED HEREIN MAY BE PROPRIETARY TO LAIRD CONNECTIVITY, INC. AND/OR ANOTHER PARTY, AND MAY FURTHER BE INTENDED TO BE KEPT CONFIDENTIAL. IF YOU ARE NOT THE INTENDED RECIPIENT, PLEASE DELETE THE EMAIL AND ANY ATTACHMENTS, AND IMMEDIATELY NOTIFY THE SENDER BY RETURN EMAIL. THIS MESSAGE AND ITS CONTENTS ARE THE PROPERTY OF LAIRD CONNECTIVITY, INC. AND MAY NOT BE REPRODUCED OR USED WITHOUT THE EXPRESS WRITTEN CONSENT OF LAIRD CONNECTIVITY, INC.

3 years, 8 months

1
0
0 0

Re: [TF-M] Failure building Musca B1 SE with armclang on Linux

by Anton Komlev

Hi Chris, Your command works well also on Windows, Clang v6.16.1, although had to modify -G"Unix Makefiles". Hope it helps, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M Sent: Tuesday, July 27, 2021 12:59 AM To: tf-m(a)lists.trustedfirmware.org; Chris.Brand(a)infineon.com; Raef Coles <Raef.Coles(a)arm.com> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Failure building Musca B1 SE with armclang on Linux Hi Chris, Sorry for the trouble. I tried your build command and it worked with Armclang 6.14 on my ubuntu desktop. It looks like CMAKE_C_COMPILER_ID doesn't receive the correct toolchain ID. Probably @Raef can help? Best regards, Hu Ziji ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of chris.brand--- via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: Tuesday, July 27, 2021 3:08 AM 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] Failure building Musca B1 SE with armclang on Linux My build command is this: cmake -S . -B build_musca_se_ARMCLANG_Debug '-GUnix Makefiles' -DTFM_PLATFORM=arm/musca_b1/secure_enclave -DTFM_TOOLCHAIN_FILE=toolchain_ARMCLANG.cmake -DCMAKE_BUILD_TYPE=Debug -DTFM_ISOLATION_LEVEL=2 -DTFM_PSA_API=ON -DFORWARD_PROT_MSG=ON -DTFM_PROFILE=profile_medium The tree I'm building is hash 76939d7ca9cea03b07d3617fbbdca09947d5cdf9, and the toolchain is version 6.13. I see the same error with version 6.12. The error message I get is this: [100%] Built target tfm_test_repo-populate gmake[1]: Leaving directory '/lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/build_musca_se_ARMCLANG_Debug/lib/ext/tfm_test_repo-subbuild' /lhome/cbrand/.local/lib/python3.6/site-packages/cmake/data/bin/cmake -E cmake_progress_start /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/build_musca_se_ARMCLANG_Debug/lib/ext/tfm_test_repo-subbuild/CMakeFiles 0 CMake Error at lib/ext/CMSIS_5/CMakeLists.txt:25 (message): does not have CMSIS RTX static libraries set up -- Configuring incomplete, errors occurred! I wonder whether it might be a toolchain configuration issue, but I'm pretty sure that I've built with this same toolchain on this same machine in the past... Gcc build with the same source and options works fine. Chris Brand Cypress Semiconductor (Canada), Inc. Sr Prin Software Engr CSCA CSS ICW SW PSW 1 Office: +1 778 234 0515 Chris.Brand(a)infineon.com<mailto:Chris.Brand@infineon.com>

3 years, 8 months

1
0
0 0

Re: [TF-M] Failure building Musca B1 SE with armclang on Linux

by David Hu

Hi Chris, Sorry for the trouble. I tried your build command and it worked with Armclang 6.14 on my ubuntu desktop. It looks like CMAKE_C_COMPILER_ID doesn't receive the correct toolchain ID. Probably @Raef can help? Best regards, Hu Ziji ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of chris.brand--- via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Tuesday, July 27, 2021 3:08 AM To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] Failure building Musca B1 SE with armclang on Linux My build command is this: cmake -S . -B build_musca_se_ARMCLANG_Debug '-GUnix Makefiles' -DTFM_PLATFORM=arm/musca_b1/secure_enclave -DTFM_TOOLCHAIN_FILE=toolchain_ARMCLANG.cmake -DCMAKE_BUILD_TYPE=Debug -DTFM_ISOLATION_LEVEL=2 -DTFM_PSA_API=ON -DFORWARD_PROT_MSG=ON -DTFM_PROFILE=profile_medium The tree I'm building is hash 76939d7ca9cea03b07d3617fbbdca09947d5cdf9, and the toolchain is version 6.13. I see the same error with version 6.12. The error message I get is this: [100%] Built target tfm_test_repo-populate gmake[1]: Leaving directory '/lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/build_musca_se_ARMCLANG_Debug/lib/ext/tfm_test_repo-subbuild' /lhome/cbrand/.local/lib/python3.6/site-packages/cmake/data/bin/cmake -E cmake_progress_start /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/build_musca_se_ARMCLANG_Debug/lib/ext/tfm_test_repo-subbuild/CMakeFiles 0 CMake Error at lib/ext/CMSIS_5/CMakeLists.txt:25 (message): does not have CMSIS RTX static libraries set up -- Configuring incomplete, errors occurred! I wonder whether it might be a toolchain configuration issue, but I'm pretty sure that I've built with this same toolchain on this same machine in the past... Gcc build with the same source and options works fine. Chris Brand Cypress Semiconductor (Canada), Inc. Sr Prin Software Engr CSCA CSS ICW SW PSW 1 Office: +1 778 234 0515 Chris.Brand(a)infineon.com<mailto:Chris.Brand@infineon.com>

3 years, 8 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M