- TF-M - lists.trustedfirmware.org

by Anton Komlev

Hello, Let me inform you that release branch "release/1.5.0" is created and tagged with TF-Mv1.5.0-RC1 in these repositories: 1. tf-m-tests<https://git.trustedfirmware.org/TF-M/tf-m-tests.git/> 2. trusted-firmware-m<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/> 3. tf-m-ci-scripts<https://git.trustedfirmware.org/ci/tf-m-ci-scripts.git/> 4. tf-m-job-configs<https://git.trustedfirmware.org/ci/tf-m-job-configs.git/> Normal development can be continued in the main branch as described in the updated release process https://tf-m-user-guide.trustedfirmware.org/docs/releases/release_process.h… Thanks and good luck, Anton

4 years, 7 months

1
2
0 0

Security vulnerability notice - Profile Small Key ID encoding vulnerability

by David Hu

Hi all, This email is a notification of a new security vulnerability reported to TF-M. In TF-M v1.4.0, NSPE may access secure keys stored in TF-M Crypto service in Profile Small with Crypto key ID encoding disabled. This vulnerability impacts Profile Small in TF-M v1.4.0. Please check the details in the security advisory<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/12608/1/docs…>. The advisory has been merged in v1.5.0 release and will be port back to master branch. The fix has been merged on the master branch<https://review.trustedfirmware.org/plugins/gitiles/TF-M/trusted-firmware-m/…> and patch release v1.4.1<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/commit/?h=TF-Mv…>. Thanks. Best regards, Hu Ziji

4 years, 7 months

1
0
0 0

Technical Forum call - Nov-25

by Anton Komlev

Hi, The next Technical Forum is planned on Thursday, Nov 25, 15:00-16:00 UTC (US time zone). This is Thanksgiving day and public holiday in US so we might want to cancel the forum expecting fewer participants unless we have a good topic to discuss. Please reply on this email with your proposals for agenda topics. Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

4 years, 7 months

1
0
0 0

Re: [TF-M] d4dbaa93, "Add FPU support for gnu arm embedded toolchain" causing build errors

by David Hu

Hi Thomas, The tf-m-tests fix is under review and has not been merged yet. Therefore that commit ID is not available in tf-m-tests. I'd suggest to do following to test the fix: * Cherry pick https://review.trustedfirmware.org/c/TF-M/tf-m-tests/+/12563 to your local tf-m-tests repo * Cherry pick https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/12564 to your local trusted-firmware-m repo * Add `-DTFM_TEST_REPO_PATH=<local tf-m-tests folder>` in the build command. After the fix is merged, the commit will be available when fetching the tf-m-tests repo. Best regards, Hu Ziji ________________________________ From: Thomas Törnblom <thomas.tornblom(a)iar.com> Sent: Thursday, November 18, 2021 8:10 PM To: David Hu <David.Hu(a)arm.com>; David Wang <David.Wang(a)arm.com>; Feder Liang <Feder.Liang(a)arm.com> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] d4dbaa93, "Add FPU support for gnu arm embedded toolchain" causing build errors I'm getting another error after cherry picking these: PS D:\Projects\trusted-firmware-m\iar> cmake -GNinja -S .. -B . -DTFM_PLATFORM=arm/musca_s1 "-DTFM_TOOLCHAIN_FILE=..\toolchain_IARARM.cmake" -DTEST_NS=ON -DTEST_S=ON -DCMAKE_BUILD_TYPE=Debug -DBL2=ON -DTEST_NS_QCBOR=OFF -- Populating tfm_test_repo -- Configuring done -- Generating done -- Build files have been written to: D:/Projects/trusted-firmware-m/iar/lib/ext/tfm_test_repo-subbuild [1/9] Creating directories for 'tfm_test_repo-populate' [1/9] Performing download step (git clone) for 'tfm_test_repo-populate' Cloning into 'tfm_test_repo-src'... remote: Enumerating objects: 1094, done. remote: Counting objects: 100% (1094/1094), done. remote: Compressing objects: 100% (613/613), done. remote: Total 2057 (delta 913), reused 511 (delta 481), pack-reused 963 Receiving objects: 100% (2057/2057), 2.05 MiB | 8.43 MiB/s, done. Resolving deltas: 100% (1371/1371), done. fatal: invalid reference: 14ca288 CMake Error at tfm_test_repo-subbuild/tfm_test_repo-populate-prefix/tmp/tfm_test_repo-populate-gitclone.cmake:40 (message): Failed to checkout tag: '14ca288' FAILED: tfm_test_repo-populate-prefix/src/tfm_test_repo-populate-stamp/tfm_test_repo-populate-download cmd.exe /C "cd /D D:\Projects\trusted-firmware-m\iar\lib\ext && "C:\Program Files\CMake\bin\cmake.exe" -P D:/Projects/trusted-firmware-m/iar/lib/ext/tfm_test_repo-subbuild/tfm_test_repo-populate-prefix/tmp/tfm_test_repo-populate-gitclone.cmake && "C:\Program Files\CMake\bin\cmake.exe" -E touch D:/Projects/trusted-firmware-m/iar/lib/ext/tfm_test_repo-subbuild/tfm_test_repo-populate-prefix/src/tfm_test_repo-populate-stamp/tfm_test_repo-populate-download" ninja: build stopped: subcommand failed. CMake Error at C:/Program Files/CMake/share/cmake-3.20/Modules/FetchContent.cmake:1012 (message): Build step for tfm_test_repo failed: 1 Call Stack (most recent call first): C:/Program Files/CMake/share/cmake-3.20/Modules/FetchContent.cmake:1141:EVAL:2 (__FetchContent_directPopulate) C:/Program Files/CMake/share/cmake-3.20/Modules/FetchContent.cmake:1141 (cmake_language) lib/ext/tf-m-tests/fetch_repo.cmake:27 (FetchContent_Populate) lib/ext/tf-m-tests/tf-m-tests.cmake:56 (include) config/set_config.cmake:68 (include) CMakeLists.txt:42 (include) Den 2021-11-18 kl. 13:00, skrev David Hu: Hi Thomas, Sorry for the failure and the trouble. The build logic of QCBOR NS test was adjusted to fit FP feature but the logic has defect when QCBOR NS test = OFF. Please cherry pick the following 2 patches and have a try: https://review.trustedfirmware.org/c/TF-M/tf-m-tests/+/12563 https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/12564 The fix will be port back to master branch when release completes. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org><mailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: Thursday, November 18, 2021 6:57 PM To: David Wang <David.Wang(a)arm.com><mailto:David.Wang@arm.com>; Feder Liang <Feder.Liang(a)arm.com><mailto:Feder.Liang@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] d4dbaa93, "Add FPU support for gnu arm embedded toolchain" causing build errors Oh, and it fails the same on Windows and linux, as well as ARMCLANG and IARARM. /Thomas Den 2021-11-18 kl. 11:56, skrev Thomas Törnblom: commit fd88f7fbde4d23720c3c9be7350e628df51ef964 (HEAD -> master, tag: TF-Mv1.5.0-RC1, origin/master, origin/HEAD, list) Den 2021-11-18 kl. 11:27, skrev David Wang: Hi Thomas, Could you share the SHA of your branch HEAD? Or you can try to fetch the latest tag and code. Regards, David Wang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org><mailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: Thursday, November 18, 2021 6:10 PM To: Feder Liang <Feder.Liang(a)arm.com><mailto:Feder.Liang@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] d4dbaa93, "Add FPU support for gnu arm embedded toolchain" causing build errors Nope, I was using "master", which was 1.5.0 RC1, both fails. /Thomas Den 2021-11-18 kl. 10:56, skrev Feder Liang: Hi, Thomas It seems TF-M and Test repo is not synced. Could you help a try on latest TF-M master branch or tag: TF-Mv1.5.0-RC1? Best Regards Feder From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org><mailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: Thursday, November 18, 2021 5:42 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] d4dbaa93, "Add FPU support for gnu arm embedded toolchain" causing build errors Looks like this patch is causing build errors, at least for Musca S1. cmake line: cmake -GNinja -S .. -B . -DTFM_PLATFORM=arm/musca_s1 "-DTFM_TOOLCHAIN_FILE=..\toolchain_ARMCLANG.cmake" -DTEST_NS=ON -DTEST_S=ON -DCMAKE_BUILD_TYPE=Debug -DBL2=ON -DTEST_NS_QCBOR=OFF [1233/1238] Linking C executable bin\tfm_ns.axf FAILED: bin/tfm_ns.axf cmd.exe /C "cd . && D:\apps\Keil_v5\ARM\ARMCLANG\bin\armlink.exe --cpu=cortex-m33 --info=summarysizes,sizes,totals,unused,veneers --strict --symbols --xref --diag_suppress=6312 --diag_suppress=6314 --diag_suppress=6304 --diag_suppress=6329 --fpu=softvfp --map --scatter=D:/Projects/trusted-firmware-m/armclang/platform/target/CMakeFiles/tfm_ns_scatter.dir/./Device/Source/armclang/musca_ns.o platform\libplatform_ns.a app\libtfm_ns_integration_test.a app\libtfm_api_ns.a ns_log\libtfm_ns_log.a test\suites\core\libtfm_test_suite_core_ns.a app\libtfm_ns_integration_test.a test\suites\core\libtfm_test_suite_core_ns.a test\suites\attestation\libtfm_test_suite_attestation_ns.a test\suites\crypto\libtfm_test_suite_crypto_ns.a test\suites\qcbor\libtfm_test_suite_qcbor_ns.a -ltfm_qcbor_test test\suites\ps\libtfm_test_suite_ps_ns.a test\suites\its\libtfm_test_suite_its_ns.a test\suites\t_cose\libtfm_test_suite_t_cose_ns.a test\suites\t_cose\libtfm_t_cose_test.a test\suites\t_cose\libtfm_t_cose_ns.a test\suites\qcbor\libtfm_qcbor_ns.a test\suites\platform\libtfm_test_suite_platform_ns.a test\suites\ipc\libtfm_test_suite_ipc_ns.a lib\ext\tfm_test_repo-src\CMSIS\RTOS2\RTX\Library\ARM\RTX_V8MMN.lib app\libtfm_api_ns.a secure_fw\libtfm_s_veneers.a ns_log\libtfm_ns_log.a platform\libplatform_ns.a app\CMakeFiles\tfm_ns.dir\main_ns.o app\CMakeFiles\tfm_ns.dir\__\__\platform\ext\target\arm\musca_s1\Device\Source\armclang\startup_cmsdk_musca_ns.o app\CMakeFiles\tfm_ns.dir\__\ns_interface\ns_client_ext\tz_shim_layer.o app\CMakeFiles\tfm_ns.dir\__\CMSIS\RTOS2\RTX\Config\RTX_Config.o app\CMakeFiles\tfm_ns.dir\__\CMSIS\RTOS2\RTX\Source\rtx_lib.o app\CMakeFiles\tfm_ns.dir\os_wrapper_cmsis_rtos_v2.o -o bin\tfm_ns.axf --list=bin\tfm_ns.axf.map && cd ." Fatal error: L3900U: Unrecognized option '-ltfm_qcbor_test'. Finished: 0 information, 0 warning, 0 error and 1 fatal error messages. ninja: build stopped: subcommand failed. -- 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> -- 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> -- 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> -- 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> -- 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>

4 years, 7 months

1
0
0 0

Re: [TF-M] d4dbaa93, "Add FPU support for gnu arm embedded toolchain" causing build errors

by David Hu

The mailing list was lost. From: David Hu Sent: Thursday, November 18, 2021 8:00 PM To: Thomas Törnblom <thomas.tornblom(a)iar.com>; David Wang <David.Wang(a)arm.com>; Feder Liang <Feder.Liang(a)arm.com> Cc: nd <nd(a)arm.com> Subject: RE: [TF-M] d4dbaa93, "Add FPU support for gnu arm embedded toolchain" causing build errors Hi Thomas, Sorry for the failure and the trouble. The build logic of QCBOR NS test was adjusted to fit FP feature but the logic has defect when QCBOR NS test = OFF. Please cherry pick the following 2 patches and have a try: https://review.trustedfirmware.org/c/TF-M/tf-m-tests/+/12563 https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/12564 The fix will be port back to master branch when release completes. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Thomas Törnblom via TF-M Sent: Thursday, November 18, 2021 6:57 PM To: David Wang <David.Wang(a)arm.com<mailto:David.Wang@arm.com>>; Feder Liang <Feder.Liang(a)arm.com<mailto:Feder.Liang@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] d4dbaa93, "Add FPU support for gnu arm embedded toolchain" causing build errors Oh, and it fails the same on Windows and linux, as well as ARMCLANG and IARARM. /Thomas Den 2021-11-18 kl. 11:56, skrev Thomas Törnblom: commit fd88f7fbde4d23720c3c9be7350e628df51ef964 (HEAD -> master, tag: TF-Mv1.5.0-RC1, origin/master, origin/HEAD, list) Den 2021-11-18 kl. 11:27, skrev David Wang: Hi Thomas, Could you share the SHA of your branch HEAD? Or you can try to fetch the latest tag and code. Regards, David Wang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org><mailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: Thursday, November 18, 2021 6:10 PM To: Feder Liang <Feder.Liang(a)arm.com><mailto:Feder.Liang@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] d4dbaa93, "Add FPU support for gnu arm embedded toolchain" causing build errors Nope, I was using "master", which was 1.5.0 RC1, both fails. /Thomas Den 2021-11-18 kl. 10:56, skrev Feder Liang: Hi, Thomas It seems TF-M and Test repo is not synced. Could you help a try on latest TF-M master branch or tag: TF-Mv1.5.0-RC1? Best Regards Feder From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org><mailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: Thursday, November 18, 2021 5:42 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] d4dbaa93, "Add FPU support for gnu arm embedded toolchain" causing build errors Looks like this patch is causing build errors, at least for Musca S1. cmake line: cmake -GNinja -S .. -B . -DTFM_PLATFORM=arm/musca_s1 "-DTFM_TOOLCHAIN_FILE=..\toolchain_ARMCLANG.cmake" -DTEST_NS=ON -DTEST_S=ON -DCMAKE_BUILD_TYPE=Debug -DBL2=ON -DTEST_NS_QCBOR=OFF [1233/1238] Linking C executable bin\tfm_ns.axf FAILED: bin/tfm_ns.axf cmd.exe /C "cd . && D:\apps\Keil_v5\ARM\ARMCLANG\bin\armlink.exe --cpu=cortex-m33 --info=summarysizes,sizes,totals,unused,veneers --strict --symbols --xref --diag_suppress=6312 --diag_suppress=6314 --diag_suppress=6304 --diag_suppress=6329 --fpu=softvfp --map --scatter=D:/Projects/trusted-firmware-m/armclang/platform/target/CMakeFiles/tfm_ns_scatter.dir/./Device/Source/armclang/musca_ns.o platform\libplatform_ns.a app\libtfm_ns_integration_test.a app\libtfm_api_ns.a ns_log\libtfm_ns_log.a test\suites\core\libtfm_test_suite_core_ns.a app\libtfm_ns_integration_test.a test\suites\core\libtfm_test_suite_core_ns.a test\suites\attestation\libtfm_test_suite_attestation_ns.a test\suites\crypto\libtfm_test_suite_crypto_ns.a test\suites\qcbor\libtfm_test_suite_qcbor_ns.a -ltfm_qcbor_test test\suites\ps\libtfm_test_suite_ps_ns.a test\suites\its\libtfm_test_suite_its_ns.a test\suites\t_cose\libtfm_test_suite_t_cose_ns.a test\suites\t_cose\libtfm_t_cose_test.a test\suites\t_cose\libtfm_t_cose_ns.a test\suites\qcbor\libtfm_qcbor_ns.a test\suites\platform\libtfm_test_suite_platform_ns.a test\suites\ipc\libtfm_test_suite_ipc_ns.a lib\ext\tfm_test_repo-src\CMSIS\RTOS2\RTX\Library\ARM\RTX_V8MMN.lib app\libtfm_api_ns.a secure_fw\libtfm_s_veneers.a ns_log\libtfm_ns_log.a platform\libplatform_ns.a app\CMakeFiles\tfm_ns.dir\main_ns.o app\CMakeFiles\tfm_ns.dir\__\__\platform\ext\target\arm\musca_s1\Device\Source\armclang\startup_cmsdk_musca_ns.o app\CMakeFiles\tfm_ns.dir\__\ns_interface\ns_client_ext\tz_shim_layer.o app\CMakeFiles\tfm_ns.dir\__\CMSIS\RTOS2\RTX\Config\RTX_Config.o app\CMakeFiles\tfm_ns.dir\__\CMSIS\RTOS2\RTX\Source\rtx_lib.o app\CMakeFiles\tfm_ns.dir\os_wrapper_cmsis_rtos_v2.o -o bin\tfm_ns.axf --list=bin\tfm_ns.axf.map && cd ." Fatal error: L3900U: Unrecognized option '-ltfm_qcbor_test'. Finished: 0 information, 0 warning, 0 error and 1 fatal error messages. ninja: build stopped: subcommand failed. -- 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> -- 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> -- 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> -- 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>

4 years, 7 months

1
0
0 0

d4dbaa93, "Add FPU support for gnu arm embedded toolchain" causing build errors

by Thomas Törnblom

Looks like this patch is causing build errors, at least for Musca S1. cmake line: cmake -GNinja -S .. -B . -DTFM_PLATFORM=arm/musca_s1 "-DTFM_TOOLCHAIN_FILE=..\toolchain_ARMCLANG.cmake" -DTEST_NS=ON -DTEST_S=ON -DCMAKE_BUILD_TYPE=Debug -DBL2=ON -DTEST_NS_QCBOR=OFF [1233/1238] Linking C executable bin\tfm_ns.axf FAILED: bin/tfm_ns.axf cmd.exe /C "cd . && D:\apps\Keil_v5\ARM\ARMCLANG\bin\armlink.exe --cpu=cortex-m33 --info=summarysizes,sizes,totals,unused,veneers --strict --symbols --xref --diag_suppress=6312 --diag_suppress=6314 --diag_suppress=6304 --diag_suppress=6329 --fpu=softvfp --map --scatter=D:/Projects/trusted-firmware-m/armclang/platform/target/CMakeFiles/tfm_ns_scatter.dir/./Device/Source/armclang/musca_ns.o platform\libplatform_ns.a app\libtfm_ns_integration_test.a app\libtfm_api_ns.a ns_log\libtfm_ns_log.a test\suites\core\libtfm_test_suite_core_ns.a app\libtfm_ns_integration_test.a test\suites\core\libtfm_test_suite_core_ns.a test\suites\attestation\libtfm_test_suite_attestation_ns.a test\suites\crypto\libtfm_test_suite_crypto_ns.a test\suites\qcbor\libtfm_test_suite_qcbor_ns.a -ltfm_qcbor_test test\suites\ps\libtfm_test_suite_ps_ns.a test\suites\its\libtfm_test_suite_its_ns.a test\suites\t_cose\libtfm_test_suite_t_cose_ns.a test\suites\t_cose\libtfm_t_cose_test.a test\suites\t_cose\libtfm_t_cose_ns.a test\suites\qcbor\libtfm_qcbor_ns.a test\suites\platform\libtfm_test_suite_platform_ns.a test\suites\ipc\libtfm_test_suite_ipc_ns.a lib\ext\tfm_test_repo-src\CMSIS\RTOS2\RTX\Library\ARM\RTX_V8MMN.lib app\libtfm_api_ns.a secure_fw\libtfm_s_veneers.a ns_log\libtfm_ns_log.a platform\libplatform_ns.a app\CMakeFiles\tfm_ns.dir\main_ns.o app\CMakeFiles\tfm_ns.dir\__\__\platform\ext\target\arm\musca_s1\Device\Source\armclang\startup_cmsdk_musca_ns.o app\CMakeFiles\tfm_ns.dir\__\ns_interface\ns_client_ext\tz_shim_layer.o app\CMakeFiles\tfm_ns.dir\__\CMSIS\RTOS2\RTX\Config\RTX_Config.o app\CMakeFiles\tfm_ns.dir\__\CMSIS\RTOS2\RTX\Source\rtx_lib.o app\CMakeFiles\tfm_ns.dir\os_wrapper_cmsis_rtos_v2.o -o bin\tfm_ns.axf --list=bin\tfm_ns.axf.map && cd ." Fatal error: L3900U: Unrecognized option '-ltfm_qcbor_test'. Finished: 0 information, 0 warning, 0 error and 1 fatal error messages. ninja: build stopped: subcommand failed. -- *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 Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>

4 years, 7 months

3
5
0 0

Open CI Does Not Cover ITS/PS Access Flash Tests on MUSCA_B1

by Xinyu Zhang

Hi, I'm sorry to inform you that ITS/PS access flash on MUSCA_B1 could not be covered on Open CI for the time being. Because the flash on MUSCA_B1 board in Open CI is broken, we temporarily use RAM_FS as workaround. This issue will be fixed ASAP. We'll keep following and inform you with further updates. Sorry for any inconvenience! BR, Xinyu

4 years, 7 months

2
2
0 0

Re: [TF-M] TF-M release v1.5.0 will start after Nov 15

by Anton Komlev

Hello, To include all planned changes we need more time to review the patches so the feature freeze is postponed to the beginning of the next week when release branch will be created. This gives all a few more days for reviews and last moment changes. The intention is to keep the final date unchanged. Best regards, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Thursday, November 11, 2021 8:33 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M release v1.5.0 will start on Nov 15 Hello, Following the updated release strategy, presented on the tech forum today I plan to create the release branch on Nov 13, and freeze project features at that moment. Please review and merge all patches intended for v1.5.0 by the end of this week. Normal development can continue on the main branch without any restriction. Thanks, Anton

4 years, 7 months

1
0
0 0

Another PSoC problem

by Chris.Brand＠infineon.com

Build command is: cmake -S . -B output -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DTFM_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DTEST_NS_MULTI_CORE=ON -DTFM_ISOLATION_LEVEL=1 The result is a hang at this point: > Executing 'MULTI_CLIENT_CALL_HEAVY_TEST' Description: 'Multiple outstanding NS PSA client calls heavyweight test' Totally 5 threads for test start Each thread run 0x20 rounds tests Some experimentation shows that: It happens with both gcc and armclang (unable to test IAR). It doesn't always happen, but does seem to hang more often than it succeeds. It doesn't happen with TFM_ISOLATION_LEVEL=2. It looks like this test was passing consistently before 5e68b11764673ee32bae0de8ecf3cde45cc55ea1, so I guess this is another scheduling issue. There's not a lot of code that differs with TFM_LVL, so I wonder if there's a race condition that is always present but just doesn't happen to get hit at TFM_LVL=2...? BTW, being able to build just the one test is extremely useful! 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>

4 years, 7 months

4
5
0 0

race condition in IPC

by Sebastian Bøe

Hi, are there any known race conditions in IPC/PS that affect TF-M 1.4-ish? More specifically TF-M revision a199c3047f320a2f82b9a0c27af5b50991184e0f, which is 38 commits prior to TF-Mv1.4.0-RC1. I am observing that adding printfs, or otherwise changing the flash alignment and therefore runtime of my code will affect whether the PS reliability test suite passes or not. More specifically, if it triggers a secure fault after x iterations of 2001, or y iterations of 2002, etc. depending on where I put my printfs or otherwise affect the alignment of the code. This is run on the nrf platform as a part of the nrf SDK. Test Suite PS reliability tests (TFM_PS_TEST_2XXX)... 'repetitive sets and gets in/from an asset' 'repetitive sets, gets and removes' It does not reproduce under GDB and I am unable to unwind the backtrace from the secure fault handler. Any tips about recovering a backtrace from a secure fault handler would also be appreciated. #0 SecureFault_Handler () at /home/sebo/ncs/modules/tee/tfm/trusted-firmware-m/secure_fw/spm/cmsis_psa/arch/tfm_arch_v8m_main.c:96 #1 0xffffffb4 in ?? () I have not been able to reproduce it in the latest upstream TF-M release/revision, but that could just be because I haven't been able to hit the race condition. Sebastian Bøe

4 years, 7 months

2
5
0 0

[ATTENTION REQUIRED] Manifest Tool being aware of Secure Partition enabled status when building

by Kevin Peng

Hi, I worked out a patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/12025> to make the Manifest Tool (tfm_parse_manifest_list.py) aware of the Secure Partition status when building. Currently, the tool generates everything and then the Build System picks up the files needed. With the development of FF-M 1.1 feature, we need the tool to be aware of the Secure Partition enabled status to generate SPM configurations. The patch make use of the feature of CMake command configure_file which substitutes variable values referenced as @VAR@ or ${VAR}. It requires the "conditional" attributes in manifest lists to be surrounded by "@" for "${}". Then when you disable some Partition for building, the tool will not generate anything for that Partition such as PID/SID and TF-M Partition load info. So please out of tree Secure Partition manifest lists do the corresponding change to make the tool aware of that any Partitions are DISABLED. The tool currently only takes conditional value "OFF" or "FALSE" as Partitions being disabled, all other values are treated as enabled. This means if you do not make the change in the manifest list, the tool treats all the partitions as enabled always. Best Regards, Kevin

4 years, 7 months

1
1
0 0

TF-M release v1.5.0 will start on Nov 15

by Anton Komlev

Hello, Following the updated release strategy, presented on the tech forum today I plan to create the release branch on Nov 13, and freeze project features at that moment. Please review and merge all patches intended for v1.5.0 by the end of this week. Normal development can continue on the main branch without any restriction. Thanks, Anton

4 years, 7 months

1
0
0 0

Musca B1 SE build broken?

by Chris.Brand＠infineon.com

Hi, I'm trying to build Musca B1 SE (as part of my work to create a new ns_agent_mailbox partition), and it seems that it has been missed in some HAL API changes: spm/libtfm_spm.a(backend_ipc.o): In function `ipc_system_run': .../secure_fw/spm/ffm/backend_ipc.c:132: undefined reference to `tfm_hal_update_boundaries' spm/libtfm_spm.a(spm_ipc.o): In function `tfm_spm_init': .../secure_fw/spm/cmsis_psa/spm_ipc.c:643: undefined reference to `tfm_hal_bind_boundaries' spm/libtfm_spm.a(spm_ipc.o): In function `do_schedule': .../secure_fw/spm/cmsis_psa/spm_ipc.c:694: undefined reference to `tfm_hal_update_boundaries' spm/libtfm_spm.a(static_load.o): In function `load_irqs_assuredly': .../secure_fw/spm/cmsis_psa/static_load.c:195: undefined reference to `tfm_hal_irq_enable' .../secure_fw/spm/cmsis_psa/static_load.c:198: undefined reference to `tfm_hal_irq_disable' spm/libtfm_spm.a(psa_api.o): In function `tfm_spm_partition_psa_eoi': .../secure_fw/spm/ffm/psa_api.c:830: undefined reference to `tfm_hal_irq_clear_pending' .../secure_fw/spm/ffm/psa_api.c:831: undefined reference to `tfm_hal_irq_enable' spm/libtfm_spm.a(psa_api.o): In function `tfm_spm_partition_irq_enable': .../secure_fw/spm/ffm/psa_api.c:858: undefined reference to `tfm_hal_irq_enable' spm/libtfm_spm.a(psa_api.o): In function `tfm_spm_partition_irq_disable': .../secure_fw/spm/ffm/psa_api.c:876: undefined reference to `tfm_hal_irq_disable' spm/libtfm_spm.a(tfm_core_svcalls_ipc.o): In function `tfm_flih_prepare_depriv_flih': .../secure_fw/spm/cmsis_psa/tfm_core_svcalls_ipc.c:137: undefined reference to `tfm_hal_update_boundaries' spm/libtfm_spm.a(tfm_core_svcalls_ipc.o): In function `tfm_flih_return_to_isr': .../secure_fw/spm/cmsis_psa/tfm_core_svcalls_ipc.c:170: undefined reference to `tfm_hal_update_boundaries' Chris Brand Cypress Semiconductor (Canada), Inc. An Infineon Technologies Company 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> International Place 13700 V6V 2X8 Richmond Canada www.infineon.com<www.cypress.com> www.cypress.com<http://www.cypress.com> Discoveries<http://www.infineon.com/discoveries> Facebook<http://www.facebook.com/infineon> Twitter<http://www.twitter.com/Infineon> LinkedIn<http://www.linkedin.com/company/infineon-technologies> Part of your life. Part of tomorrow. NOTICE: The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material of Infineon Technologies AG and its affiliated entities which is for the exclusive use of the individual designated above as the recipient. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact immediately the sender by returning e-mail and delete the material from any computer. If you are not the specified recipient, you are hereby notified that all disclosure, reproduction, distribution or action taken on the basis of this message is prohibited.

4 years, 7 months

2
1
0 0

Technical Forum call - Nov 11

by Anton Komlev

Hi, The next Technical Forum is planned on Thursday, Nov 11, 7:00-8:00 UTC (Asia time zone). Please reply on this email with your proposals for agenda topics. Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

4 years, 7 months

1
1
0 0

lpcxpresso55s69 builds broken

by Thomas Törnblom

More breakage: In file included from ../secure_fw/spm/include/tfm_arch.h:19, from ../secure_fw/spm/cmsis_psa/spm_ipc.h:13, from ../secure_fw/partitions/idle_partition/load_info_idle_sp.c:10: ../secure_fw/spm/include/tfm_arch_v8m.h:58:2: error: #error "VTOR not present, check configurations." 58 | #error "VTOR not present, check configurations." | ^~~~~ ninja: build stopped: subcommand failed. Same issue with IAR. /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 Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>

4 years, 7 months

3
13
0 0

PSoC64 TF-M - Port to CYB06447BZI-D54

by Cristiano Rodrigues

Hi guys, I am trying to put tf-m running in the PSoC64 board. However, I have a board that is slightly different from the one used by default in the tf-m. (I have *CYB06447BZI-D54* and the default tf-m is prepared to *CYS0644xxZI-S2D44). *For what I saw, the main difference among them is in memory, *CYB06447BZI-D54 *has 1MB of flash and 256kB of RAM and *CYS0644xxZI-S2D44 *has 2MB of Flash and 1MB of RAM. So now I'm trying to make a small port from tf-m to *CYB06447BZI-D54. * I changed the flash size in the flash_layout.h file to meet the *CYB06447BZI-D54 *flash size, however, I am having some difficulties in changing the RAM size. I am trying to change the RAM partitions size in region_defs.h and the smpu definitions of that partitions in smpu_config.h, but without much success. My question are: - Is possible to do the porting? Or does *CYB06447BZI-D54* not have enough memory to run tf-m? - If possible, what is I missing? Are more changes needed than I'm making? Best regards, Cristiano Rodrigues

4 years, 7 months

2
2
0 0

Key derivation from HUK in NS application

by Kevin Townsend

Hi, I need to derive a new key from the HUK using HKDF, but are we able to request key derivation with the HUK from the NS side, or would we need to create a custom ARoT partittion for that? The requirements are identical to what PS does here with HKDF -- no salt and a fixed 'info' value, resulting in a key that is device-bound and can be regenerated at startup with no storage requirements: https://tf-m-user-guide.trustedfirmware.org/docs/technical_references/desig… (that API usage looks to be out of date, BTW, since "psa_open_key" now takes two params). I tried to do something similar from the NS side, modifying this code https://github.com/zephyrproject-rtos/zephyr/blob/main/samples/tfm_integrat… ..., but get an error when trying to open the HUK with "TFM_CRYPTO_KEY_ID_HUK". That isn't surprising, but is there any alternative to generate keys from the HUK without a custom ARoT service? The fact that no storage is required when deriving from the HUK is significant. Best regards, Kevin

4 years, 8 months

1
0
0 0

Using software random generator for FIH library

by Roman.Mazurak＠infineon.com

Hi all, Does anyone know if using software random generator seeded with TRNG to provide random delays for Fault Injection Hardening library is correct from PSA Level 3 certification point of view? The basic idea is to : 1. Use TRNG to provide seed for software random generator on fih_delay_init. 2. Use software random generator to implement fih_delay_random. 3. Periodically reseed software random generator with data from TRNG (optional). Thanks, Roman.

4 years, 8 months

2
1
0 0

Commit b8bc0d2a breaks Musca_S1

by Thomas Törnblom

Appears there are more recent breakage. b8bc0d2a "HAL: Expand the scope of tfm_hal_platform_init API" breaks Musca_S1 /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 Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>

4 years, 8 months

2
1
0 0

fce78aef breaks psoc64 console output with IARARM and ARMCLANG toolchain

by Thomas Törnblom

The current version breaks console output for the secure partition on psoc64 with IAR or ARMCLANG. Appears to work with GNUARM. It appears that this commit is the culprit: fce78aef Platform: Duplicate the tfm_hal_platform_init The console starts out good, then during tests only garbage is seen. Linker script issues? /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 Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>

4 years, 8 months

4
4
0 0

BL2 builds, no "PYTHON_EXECUTABLE" defined

by Thomas Törnblom

While attempting to build for the musca_s1, with mcuboot, on Windows, the build failed very late and brought up a Code Writer window on my screen. I nailed it down to no "PYTHON_EXECUTABLE" being defined while processing bl2/ext/mcuboot/CMakeLists.txt, which caused the build line to just attempt to run wrapper.py, with no interpreter, and windows brought up the appropriate tools to write python code. Adding "-DPYTHON_EXECUTABLE=python" to the cmake line fixed that, but it seems that this shouldn't be needed. The build tools should handle this, or? There is a line: #! /usr/bin/env python3 in wrapper.py, and I assume linux will handle this appropriately, but it doesn't seem windows does. Cheers, Thomas -- *Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>

4 years, 8 months

2
1
0 0

Flash definitions usage

by Bohdan.Hunko＠infineon.com

Hi everyone, I was trying to understand usage of TOTAL_ROM_SIZE and FLASH_TOTAL_SIZE from musca_b1/sse_200/partitions/flash_layout.h file. I haven't found any usage of these definitions. Does anyone know what is the reason to have them defined? Regards, Bohdan Hunko Cypress Semiconductor Ukraine Engineer CSUKR CSS ICW SW FW Mobile: +38099 50 19 714 Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>

4 years, 8 months

1
0
0 0

Inline asm syntax unified and symbol reference in IAR toolchain

by Ken Liu

Hi Thomas and all, I noticed there are some #if !defined(__ICCARM__) ".syntax unified \n" #endif In source code, looks like ".syntax unified" is not support in IAR, is that true? If it could not be supported in a short term, we can define some wrapper such as: #ifdef __ICCARM__ #define CLAIM_SYNTAX_UNIFIED "\n" #else #define CLAIM_SYNTAX_UNIFIED ".syntax unified \n" #endif Another question is about the: #if defined(__ICCARM__) #pragma required = do_schedule #endif If we claim do_schedule in the constraints, is the above "#pragma required" still needed? __asm (".... :: "i"(do_schedule)); We can create a patch to test this - using a constraint looks more proper. Thanks. /Ken

4 years, 8 months

2
5
0 0

Re: [TF-M] System reset

by Andrew Thoelke

Hi Sebastian, The section in the Platform Security Model is describing the behavior of a system reset – the recommendation is that any preceding runtime state (in volatile memory, or in CPU or peripheral registers) does not influence the execution of the reboot. This is except for an optional suspend or hibernate state, which explicitly maintains runtime state while powering off most or all of the system and will resume via a CPU reset. System security requirements might require explicit clearing of volatile memory on reset to prevent cold-boot style attacks that could allow an attacker to read any residual RAM contents – although software-based attacks of this kind are partly mitigated by trusted boot, which prevents an attacker from running arbitrary code at reset (unlike devices that boot from untrusted flash memory). The specific bullet list in the PSA Firmware Framework for M (in §3.5.1 on Panics) is describing the challenges for an implementation that does NOT do the recommended action of resetting the system when a Secure Partition panics, which justifies the recommendation to reset the system. If the SPM does reset the system, then the challenges in that bullet list are avoided. The issues listed are: > * An individual Secure Partition cannot be reset and restarted in isolation. > * A Secure Partition may have state maintained on behalf of clients that will be destroyed when restarting the service. There is no mechanism to re-synchronize the clients. > * It is not possible to determine at the point of panic how much corruption has occurred within the Secure Partition and elsewhere in the SPE. If the SPM only restarted the Secure Partition that panicked, then any previous runtime state within that Secure Partition is lost, including any ongoing connections with clients of services within that partition, or any resources that those services were managing for their clients. FF-M does not provide a specified mechanism for such clients to be informed that the connections are broken, and there is no way to provide a general strategy that allows a client to recover from a service failure. This is what is meant by “There is no mechanism to re-synchronize the clients.”. I have just realized that in FF-M 1.1, there may be scenarios in which restarting a Secure Partition could be justified and technically feasible. If a Secure Partition with only Stateless services maintains no client state or resources, and also maintains no connections to other RoT Services (so there are no RoT Services maintaining state for this Secure Partition) – then restarting this Secure Partition might not suffer from the first two complications listed in §3.5.1. The third issue is harder to control: the risks from the data corruption that lead up to the panic depends partly on the SPE isolation policies, and on what this Secure Partition was responsible for. Reset remains the recommended response to a Secure Partition panic in v1.1.0. Regards, Andrew Thoelke Arm Ltd. From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: 26 October 2021 10:51 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] System reset Hi Sebastian, The specification writer looks not here these two days, let me try to explain it based on my understanding. I think two specs both recommend clearing general runtime data while resetting. If the booting runtime clearing code can clear the RAM data for a specific platform, the memory clearing in the 'tfm_spm_hal_system_reset ' can be skipped. Basically, simple hardware reset triggering is just fine. The special-purpose memory to be retained during resetting is not a generic runtime memory, hence they need to be treated specially, such as putting them in a special bank or region and skipping clearing them during booting. This special region can be treated as a private asset of one service, which could NOT be shared between components for direct access. The owner service provides the functionality around this asset. Please put more comments or corrections, thanks. /Ken From: TF-M <mailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Sebastian Bøe via TF-M Sent: Monday, October 25, 2021 3:16 PM To: mailto:tf-m@lists.trustedfirmware.org Subject: [TF-M] System reset Hi, I would like some clarification about system reset. There are these two statements about it in the PSM and PSA-FF: "No run-time state from before the reset should be retained or used, except where necessary if suspend or hibernate are supported, see section 4.6." -- PSM page 22. "A Secure Partition may have state maintained on behalf of clients that will be destroyed when restarting the service." -- PSA-FF page 47. Is it the responsibility of tfm_spm_hal_system_reset to destroy this state or is it OK to destroy it after reset as a part of the C runtime startup procedure? I assume for instance that PRoT .bss is cleared as a part of the C runtime startup procedure, but should it also have been destroyed as a part of tfm_spm_hal_system_reset ? PSM - Platform Security Model. https://developer.arm.com/documentation/den0128/0100/ PSA-FF PSA Firmware Framework https://armkeil.blob.core.windows.net/developer/Files/pdf/PlatformSecurityA… Sebastian Bøe Nordic Semiconductor

4 years, 8 months

2
1
0 0

[PLATFORM ATTENTION REQUIRED] Unify the HAL APIs for IPC Model

by Kevin Peng

Hi all, I'm been working to unify the HAL APIs for IPC Model. The IPC Model currently uses two different sets of HAL APIs: * tfm_spm_hal_* - This is mainly used by the Library Model and IPC Model re-uses some of them * tfm_hal_* - This is introduced for IPC Model and some are shared to Library Model This might be confusing for platform vendors. So I'm trying to make it clear for IPC Model by: * Duplicating the shared APIs and rename the IPC copy to tfm_hal_* * Combining several platform init APIs to a single tfm_platform_init for IPC Model * tfm_spm_hal_enable_fault_handlers * tfm_spm_hal_system_reset_cfg * tfm_spm_hal_init_debug * tfm_spm_hal_nvic_interrupt_target_state_cfg * tfm_spm_hal_nvic_interrupt_enable With these changes, IPC Model will use tfm_hal_* APIs only. Please platform owners review these patches<https://review.trustedfirmware.org/q/topic:%22decouple_legacy_hal_for_ipc%2…> to see if any mistakes (the patches mainly move codes around) or any platforms missed in the patches. Plan to have them merged before the end of October. Thanks. Best Regards, Kevin

4 years, 8 months

1
1
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M