Hi all,
Sorry to inform you that TF-M Open CI is down for the time being - tests cannot be run.
I'll let you know as long as CI is back to normal.
Apologize for any inconvenience!
Thanks,
Xinyu
Hi,
Thank Chris made a couple of changes to move the mailbox mechanism from a kernel-coupled one into a partition-based one, which simplifies the programming model much.
And mailbox-related platforms (musca-b1 secure enclave and corstone 1000) may get affected after merged, please mentioned platform owners take a try on these patches. Another solution is we can merge them and then fix the problems found.
Will wait for one more week for the last patch (Patches no affecting platforms out of PSoC are merged already).
I think checkout this one should bring all related changes into local:
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/12311
Feel free to comment, thanks.
/Ken
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>
