Hi,
The next Technical Forum is planned on Thursday, Jan 6, 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
Hi everyone,
While taking a look into PSA header files from interface/include/psa/ folder I have found out that they are actually slightly different from PSA headers in build_folder/lib/ext/mbedcrypto-src/include/psa/ folder.
Here is list of files that are different:
* crypto.h
* crypto_compat.h
* crypto_extra.h
* crypto_sizes.h
* crypto_struct.h
* crypto_types.h
* crypto_values.h
My expectation was that PSA interface (header files) should be the same in both folders.
Maybe we should use only one version of those files (remove files from interface/include/psa/ and just use files from build_folder/lib/ext/mbedcrypto-src/include/psa/)?
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>
Back after the holidays I have tested a few builds and I've noticed that
a few builds fail a bunch of tests.
Fails on all tool chains.
Is this a known issue?
psoc64, musca_s1 works.
Musca_B1 (nxp lpcxpresso55s69 also fails:
PS D:\Projects\tf-m6\trusted-firmware-m\armclang> cmake -GNinja -S .. -B
. -DTFM_PLATFORM=arm/musca_b1/sse_200
"-DTFM_TOOLCHAIN_FILE=..\toolchain_ARMCLANG.cmake" -DTEST_NS=ON
-DTEST_S=ON -DCMAKE_BUILD_TYPE=RelWithDebInfo -DBL2=ON
...
Running Test Suite PSA internal trusted storage S interface tests
(TFM_S_ITS_TEST_1XXX)...
> Executing 'TFM_S_ITS_TEST_1001'
Description: 'Set interface'
Set should not fail with valid UID (Failed at
D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/its/its_tests_common.c:32)
TEST: TFM_S_ITS_TEST_1001 - FAILED!
> Executing 'TFM_S_ITS_TEST_1002'
Description: 'Set interface with create flags'
Set should not fail with no flags (Failed at
D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/its/its_tests_common.c:91)
TEST: TFM_S_ITS_TEST_1002 - FAILED!
> Executing 'TFM_S_ITS_TEST_1003'
Description: 'Set interface with NULL data pointer'
Set should succeed with NULL data pointer and zero length (Failed at
D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/its/its_tests_common.c:115)
TEST: TFM_S_ITS_TEST_1003 - FAILED!
> Executing 'TFM_S_ITS_TEST_1004'
Description: 'Set interface with write once UID'
Set should not rewrite a write once UID (Failed at
D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/its/its_tests_common.c:138)
TEST: TFM_S_ITS_TEST_1004 - FAILED!
> Executing 'TFM_S_ITS_TEST_1005'
Description: 'Get interface with valid data'
Set should not fail (Failed at
D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/its/its_tests_common.c:186)
TEST: TFM_S_ITS_TEST_1005 - FAILED!
> Executing 'TFM_S_ITS_TEST_1006'
Description: 'Get interface with zero data length'
Set should not fail (Failed at
D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/its/its_tests_common.c:293)
TEST: TFM_S_ITS_TEST_1006 - FAILED!
...
(lots more failed tests)
...
*** Non-secure test suites summary ***
Test suite 'PSA protected storage NS interface tests
(TFM_NS_PS_TEST_1XXX)' has PASSED
Test suite 'PSA internal trusted storage NS interface tests
(TFM_NS_ITS_TEST_1XXX)' has FAILED
Test suite 'Crypto non-secure interface test (TFM_NS_CRYPTO_TEST_1XXX)'
has FAILED
Test suite 'Platform Service Non-Secure interface
tests(TFM_NS_PLATFORM_TEST_1XXX)' has PASSED
Test suite 'Initial Attestation Service non-secure interface
tests(TFM_NS_ATTEST_TEST_1XXX)' has PASSED
Test suite 'QCBOR regression test(TFM_NS_QCBOR_TEST_1XXX)' has PASSED
Test suite 'T_COSE regression test(TFM_NS_T_COSE_TEST_1XXX)' has PASSED
Test suite 'PSA firmware update NS interface tests
(TFM_NS_FWU_TEST_1xxx)' has PASSED
Test suite 'Core non-secure positive tests (TFM_NS_CORE_TEST_1XXX)' has
PASSED
Test suite 'IPC non-secure interface test (TFM_NS_IPC_TEST_1XXX)' has PASSED
Test suite 'TFM IRQ Test (TFM_IRQ_TEST_1xxx)' has PASSED
*** End of Non-secure test suites ***
--
*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>
Hello,
This platform is tested for profile medium and low (-DTFM_PROFILE=profile_small or -DTFM_PROFILE=profile_medium). I just checked on master with medium profile and GNUARM.
The default config takes a crypto config with its associated crypto tests that leads to overlap in flash area. (This device has 512Kbytes Flash)
Best Regards
ST Restricted
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Bøe, Sebastian via TF-M
Sent: mercredi 22 décembre 2021 13:40
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] nucleo_l552ze_q platform does not build since TF-M 1.5
Hi,
I am observing that the nucleo_l552ze_q platform is producing hex files that overlap
since the 1.5 release. Tested on master and 1.5.
Is there an STM maintainer that could look into this?
Steps to reproduce:
rm -rf cmake_build && cmake -S . -B cmake_build -DTFM_PLATFORM=stm/nucleo_l552ze_q -DTFM_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=MinSizeRel -DTEST_S=ON -DTEST_NS=ON && make -C cmake_build install && /usr/bin/python3.8 /home/sebo/ncs/zephyr/scripts/mergehex.py -o merged.hex $(find cmake_build -name "*.hex")
"/usr/bin/python3.8 /home/sebo/ncs/zephyr/scripts/mergehex.py" must be replaced
with the preferred hex file merging tool.
output:
Traceback (most recent call last):
File "/home/sebo/ncs/zephyr/scripts/mergehex.py", line 28, in merge_hex_files
ih.merge(to_merge, overlap=overlap)
File "/home/sebo/.local/lib/python3.8/site-packages/intelhex/__init__.py", line 875, in merge
raise AddressOverlapError(
intelhex.AddressOverlapError: Data overlapped at address 0xC014400
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/sebo/ncs/zephyr/scripts/mergehex.py", line 56, in <module>
main()
File "/home/sebo/ncs/zephyr/scripts/mergehex.py", line 52, in main
merge_hex_files(args.output, args.input_files, args.overlap)
File "/home/sebo/ncs/zephyr/scripts/mergehex.py", line 30, in merge_hex_files
raise AddressOverlapError("{} has merge issues".format(hex_file_path))
intelhex.AddressOverlapError: cmake_build/install/outputs/STM/NUCLEO_L552ZE_Q/tfm_s.hex has merge issues
PS: Depending on the revision tested, it might be necessary to also apply this patch:
modified platform/ext/target/stm/common/stm32l5xx/CMakeLists.txt
@@ -90,7 +90,7 @@ target_sources(platform_s
${CMAKE_CURRENT_SOURCE_DIR}/hal/Src/stm32l5xx_hal_gtzc.c
${CMAKE_SOURCE_DIR}/platform/ext/common/tfm_hal_isolation_mpu_v8m.c
${CMAKE_SOURCE_DIR}/platform/ext/common/tfm_hal_nvic.c
- $<$<BOOL:${TFM_PARTITION_PLATFORM}>:${CMAKE_CURRENT_SOURCE_DIR}/secure/tfm_platform_system>
+ $<$<BOOL:${TFM_PARTITION_PLATFORM}>:${CMAKE_CURRENT_SOURCE_DIR}/secure/tfm_platform_system.c>
${CMAKE_CURRENT_SOURCE_DIR}/hal/Src/stm32l5xx_hal_rng.c
${CMAKE_CURRENT_SOURCE_DIR}/hal/Src/stm32l5xx_hal_rng_ex.c
PUBLIC
Hi,
I am observing that the nucleo_l552ze_q platform is producing hex files that overlap
since the 1.5 release. Tested on master and 1.5.
Is there an STM maintainer that could look into this?
Steps to reproduce:
rm -rf cmake_build && cmake -S . -B cmake_build -DTFM_PLATFORM=stm/nucleo_l552ze_q -DTFM_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=MinSizeRel -DTEST_S=ON -DTEST_NS=ON && make -C cmake_build install && /usr/bin/python3.8 /home/sebo/ncs/zephyr/scripts/mergehex.py -o merged.hex $(find cmake_build -name "*.hex")
"/usr/bin/python3.8 /home/sebo/ncs/zephyr/scripts/mergehex.py" must be replaced
with the preferred hex file merging tool.
output:
Traceback (most recent call last):
File "/home/sebo/ncs/zephyr/scripts/mergehex.py", line 28, in merge_hex_files
ih.merge(to_merge, overlap=overlap)
File "/home/sebo/.local/lib/python3.8/site-packages/intelhex/__init__.py", line 875, in merge
raise AddressOverlapError(
intelhex.AddressOverlapError: Data overlapped at address 0xC014400
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/sebo/ncs/zephyr/scripts/mergehex.py", line 56, in <module>
main()
File "/home/sebo/ncs/zephyr/scripts/mergehex.py", line 52, in main
merge_hex_files(args.output, args.input_files, args.overlap)
File "/home/sebo/ncs/zephyr/scripts/mergehex.py", line 30, in merge_hex_files
raise AddressOverlapError("{} has merge issues".format(hex_file_path))
intelhex.AddressOverlapError: cmake_build/install/outputs/STM/NUCLEO_L552ZE_Q/tfm_s.hex has merge issues
PS: Depending on the revision tested, it might be necessary to also apply this patch:
modified platform/ext/target/stm/common/stm32l5xx/CMakeLists.txt
@@ -90,7 +90,7 @@ target_sources(platform_s
${CMAKE_CURRENT_SOURCE_DIR}/hal/Src/stm32l5xx_hal_gtzc.c
${CMAKE_SOURCE_DIR}/platform/ext/common/tfm_hal_isolation_mpu_v8m.c
${CMAKE_SOURCE_DIR}/platform/ext/common/tfm_hal_nvic.c
- $<$<BOOL:${TFM_PARTITION_PLATFORM}>:${CMAKE_CURRENT_SOURCE_DIR}/secure/tfm_platform_system>
+ $<$<BOOL:${TFM_PARTITION_PLATFORM}>:${CMAKE_CURRENT_SOURCE_DIR}/secure/tfm_platform_system.c>
${CMAKE_CURRENT_SOURCE_DIR}/hal/Src/stm32l5xx_hal_rng.c
${CMAKE_CURRENT_SOURCE_DIR}/hal/Src/stm32l5xx_hal_rng_ex.c
PUBLIC
Hi,
Currently, in the compiler link script, the CMSE VENEER section is placed at a fixed address which is at the end of tfm code. See code for armclang<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/platform/e…> and gnu arm<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/platform/e…>.
Placing the veneers at the fixed address has the benefit that the when the secure image updates, the veneer symbols remain unchanged. So, the nonsecure image does not have to be updated together.
The problem is that the size of tfm_s.bin is always the same in different TF-M build configurations(debug mode, release mode, profile small, profile large and so on). So, there can be large empty space between the end of tfm code and the veneer section.
As we discussed on today's tech forum meeting, I propose to move the LR_VENEER from the end of tfm code to right after the secure vector table. In this way, the space between the tfm code and the veneers section is eliminated. Also, the supported number of interrupts for each platform is fixed. So, the size of the vector table is fixed for each platform. So, the start address of veneer section is still fixed for each platform. The size of tfm_s.bin is reduced significantly after this change. Take the AN521 platform for example, the size of tfm_s.bin has a 70 percent reduction.
The link script change for armclang<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/12620/6/plat…> and gnu arm<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/12620/6/plat…> in this patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/12620/> can help me demonstrating my proposal. I am not hurry asking for review and merge this patch. As it impacts all the platforms, I want to get confirmed that all platforms which are using the common link script are happy with this proposal.
Any comments or especially concerns on this proposal?
Thanks,
Regards,
Sherry Zhang
Hi,
Wondering if anybody can throw some light on any ongoing efforts on power management on a system with TFM (deep sleep, etc).
thanks
Suresh Marisetty
Infineon Semiconductor Corporation
CYSC CSS ICW SW SSE
Mobile: +5103863997
Suresh.Marisetty(a)infineon.com<mailto:Suresh.Marisetty@infineon.com>
I'm working on the IAR part of this and I'm having a problem with the
following test in isolation level 3:
---
Running Test Suite TFM IRQ Test (TFM_IRQ_TEST_1xxx)...
> Executing 'TFM_NS_IRQ_TEST_SLIH_1001'
Description: 'SLIH HANDLING Case 1'
---
If I run the test at full speed, it will run into a MemManage fault
while if I single step through the entire test it will pass.
Is there a race condition somewhere in there?
If I disable the SLIH tests it succeeds.
The exception happens when dereferencing "dev" in this function:
bool timer_cmsdk_is_initialized(const struct timer_cmsdk_dev_t* dev)
{
return dev->data->is_initialized;
}
dev is 0x30002440 at the time.
I've been trying to figure out what part of the memory protection system
it is that is causing the exception.
DACCVIOL is set and MMFAR shows the faulting address.
Ideas?
The build line:
cmake -GNinja -S .. -B . -DTFM_PLATFORM=arm/musca_b1/sse_200
"-DTFM_TOOLCHAIN_FILE=..\toolchain_IARARM.cmake" -DTEST_NS=ON
-DTEST_S=ON -DCMAKE_BUILD_TYPE=Debug -DBL2=ON -DTFM_ISOLATION_LEVEL=3
-DTEST_NS_SLIH_IRQ=ON -DTEST_NS_QCBOR=OFF
Notice that this build runs into a linker bug in the IAR toolchain and I
have a non-released fixed version I'm using, in case anyone is
attempting to replicate the issue.
Cheers,
Thomas
Den 2021-12-17 kl. 11:30, skrev TrustedFirmware Code Review (Code Review):
>
> Attention is currently required from: Kevin Peng, Ken Liu, David Hu,
> Chris Brand, Anton Komlev, Thomas Törnblom.
>
> "Build Successful
>
> http://ci.trustedfirmware.org/job/tf-m-static/3226/display/redirect :
> SUCCESS"
>
> Patch set 16:Verified +1
>
> View Change
> <https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/12620>
>
> To view, visit change 12620
> <https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/12620>.
> To unsubscribe, or for help writing mail filters, visit settings
> <https://review.trustedfirmware.org/settings>.
>
> Gerrit-Project: TF-M/trusted-firmware-m
> Gerrit-Branch: master
> Gerrit-Change-Id: I0084aef576d90af45513c7eaae58ba6c6dbbddab
> Gerrit-Change-Number: 12620
> Gerrit-PatchSet: 16
> Gerrit-Owner: sherryzhang <sherry.zhang2(a)arm.com>
> Gerrit-Reviewer: Anton Komlev <Anton.Komlev(a)arm.com>
> Gerrit-Reviewer: David Hu <david.hu(a)arm.com>
> Gerrit-Reviewer: Ken Liu <ken.liu(a)arm.com>
> Gerrit-Reviewer: Sebastian Bøe <Sebastian.boe(a)nordicsemi.no>
> Gerrit-Reviewer: Thomas Törnblom <thomas.tornblom(a)iar.com>
> Gerrit-Reviewer: TrustedFirmware Code Review
> Gerrit-Reviewer: sherryzhang <sherry.zhang2(a)arm.com>
> Gerrit-CC: Andrej Butok <andrey.butok(a)nxp.com>
> Gerrit-CC: Chris Brand <chris.brand(a)cypress.com>
> Gerrit-CC: Gabor Abonyi <gabor.abonyi(a)arm.com>
> Gerrit-CC: Kevin Peng <kevin.peng(a)arm.com>
> Gerrit-CC: Michel Jaouen
> Gerrit-CC: Márk Horváth <mark.horvath(a)arm.com>
> Gerrit-CC: Satish Kumar <satish.kumar01(a)arm.com>
> Gerrit-CC: jamie.mccrae(a)lairdconnect.com
> Gerrit-Attention: Kevin Peng <kevin.peng(a)arm.com>
> Gerrit-Attention: Ken Liu <ken.liu(a)arm.com>
> Gerrit-Attention: David Hu <david.hu(a)arm.com>
> Gerrit-Attention: Chris Brand <chris.brand(a)cypress.com>
> Gerrit-Attention: Anton Komlev <Anton.Komlev(a)arm.com>
> Gerrit-Attention: Thomas Törnblom <thomas.tornblom(a)iar.com>
> Gerrit-Comment-Date: Fri, 17 Dec 2021 10:30:20 +0000
> Gerrit-HasComments: No
> Gerrit-Has-Labels: Yes
> Gerrit-MessageType: comment
--
*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>
Hi everyone,
I’m wondering if there is any existing effort on enabling X.509 CSR generation and certificate verification inside TF-M? Our project has some custom secure partitions which need to generate the CSR and verify the issued certificates by themselves. The current TF-M implementation hasn’t added X.509’s support. So, I’m wondering if any open source project already does that which we can leverage?
Regards,
Jun Li
Intel Corporation, CA
Hello,
In the light of the end of the year celebrations expecting not many joiners on Dec 23, specially for US time zone, hence
let's cancel the forum at the next week.
Thanks and wish you the great holidays,
Anton
I recently switched to a new MBP that ships with OS X Monterey, and on both
12.0 and 12.1 (released this week) git clone seems to be broken when you're
using HTTP rather than SSH:
digital envelope routines:CRYPTO_internal:bad key length
In order to clone TF-M, I had to make the following changes.
1. Add these details to $HOME/.ssh/config (microbuilder being my github
username, associated with my TF-M account):
Host trustedfirmware.org
User microbuilder
Hostname review.trustedfirmware.org
Port 29418
IdentityFile ~/.ssh/id_rsa
IdentitiesOnly yes
2. Then try to clone with:
$ git clone trustedfirmware.org:/TF-M/trusted-firmware-m.git
This fails, however, since it tries to clone tf-m-tests.git, so:
3. Edit lib/ext/tf-m-tests/fetch_repo.cmake, changing:
FetchContent_Declare(tfm_test_repo
GIT_REPOSITORY trustedfirmware.org:TF-M/tf-m-tests.git
# GIT_REPOSITORY https://git.trustedfirmware.org/TF-M/tf-m-tests.git
GIT_TAG ${TFM_TEST_REPO_VERSION}
GIT_PROGRESS TRUE
)
This let me at least clone TF-M until the issues with HTTP-based cloning
are fixed.
Hope this is useful to someone else working on OS X natively.
Kevin
Hi,
The next Technical Forum is planned on Thursday, Dec 9, 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
Hi,
for PSA Certification level 2 a log of significant security events is required. Which I assume
should be done with the Audit log service.
But the Audit log service does not support IPC mode.
Should PSA Certification level 2 be done with IPC mode or with library mode?
Hello,
TF-M project released v1.5.0 in release/v1.5.x<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/log/?h=release/…> branch and tagged as TF-Mv1.5.0.
In the following days the changes from the release branch will be integrated with the main branch.
Please take a look into the release notes for the new features and changes:
https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/relea…
The HTML version will be available after the main branch update.
New major features are:
* MCUboot updated to v1.8.0.
* Thread mode SPM.
* Add Non-secure Client Extension (NSCE) for non-secure client ID management support.
* Secure Function model support in framework.
* Support Memory-mapped IOVECs.
* Decouple documentation and binary builds.
* Manifest tool skips disabled Secure Partitions.
* Provisioning and OTP are supported.
* PSA Protected Storage, Internal Trusted Storage, Initial Attestation services are converted to Stateless services.
* Support out-of-tree build of Secure Partitions.
* Support out-of-tree build of platform specific test suites.
* Introduce platform binding HAL.
* ITS enhancement for harden ITS module against invalid data in Flash.
* Support to select/deselect single or multiple TF-M regression test cases.
* Decouple regression test flag configuration from TF-M.
* New platforms added.
Thank you, everyone who contributed to this milestone.
Anton Komlev
Hello,
Having no items to discuss - let's cancel the forum today.
Have a happy Thanksgiving day and enjoy your turkey if you celebrate it.
Thanks,
Anton
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M
Sent: Monday, November 22, 2021 12:04 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] Technical Forum call - Nov-25
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
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
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/+/12563https://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>
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/+/12563https://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>
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
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