TF-M March 2026

tf-m@lists.trustedfirmware.org

8 participants
7 discussions

Unable to determine default CMAKE_INSTALL_LIBDIR directory

by Quach, Brian

Hi, I'm seeing this warning when running cmake from a conan pkg: `/home/brian/.conan/data/cmake/3.21.3-0/library-msp/ga/package/be241241e9d4718e5bab4eb33935bbb69606bb0c/bin/cmake -S . -B build -DTFM_PLATFORM=arm/mps2/an521`. Does anyone know how to fix it? I see the language is set by `project("Trusted Firmware M" VERSION ${TFM_VERSION} LANGUAGES C CXX ASM)`. Per-partition files done: CMake Warning (dev) at /home/brian/.conan/data/cmake/3.21.3-0/library-msp/ga/package/be241241e9d4718e5bab4eb33935bbb69606bb0c/share/cmake-3.21/Modules/GNUInstallDirs.cmake:236 (message): Unable to determine default CMAKE_INSTALL_LIBDIR directory because no target architecture is known. Please enable at least one language before including GNUInstallDirs. Call Stack (most recent call first): build/lib/ext/mbedcrypto-src/CMakeLists.txt:42 (include) This warning is for project developers. Use -Wno-dev to suppress it. Regards, Brian Quach SimpleLink MCU Texas Instruments Inc. 12500 TI Blvd, MS F-4000 Dallas, TX 75243 214-479-4076

4 days, 13 hours

Technical Forum call - July 21

by Anton Komlev

Hi, The next Technical Forum is planned on Thursday, July 21, 7:00-8:00 UTC (East time zone). Please reply on this email with your proposals for agenda topics. Link to the forum: https://linaro-org.zoom.us/j/92535794925?pwd=TTl0cmo4R2hTNm8wcHo1M3ZKdjlnUT… Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

3 weeks

Upcoming TF-M Releases: v2.3.0 and v2.1.5

by Anton Komlev

Hello, We're preparing two new TF-M releases: v2.3.0 and v2.1.5. The current plan is to start on April 1st and target April 14th for v2.3.0. Among other improvements and fixes, v2.3.0 will be based on PSA-Crypto v1.1 expected on March 31st . We'll aim to test both releases in parallel with priority given to v2.3.0, while v2.1.5 will follow. If there are any changes you'd like included in these releases, please ensure they are reviewed and merged by March 31st. After successful testing of the v2.3.0 on platforms in OpenCI we plan to allow a one-week window for other platforms to validate and confirm correct operation. For v2.1.5, we don't expect platform-specific testing, assuming the changes are platform-independent and that CI coverage will be sufficient. However, please feel free to reach out if you have any concerns or anticipate any platform impact. Thank you and best regards, Anton

6 months, 3 weeks

TF-M to stm32h563

by Mogens Lund

Hi Is there any plans to include the STM32H563 as a supported TF-M platform ? If I clone the existing STM32H573_DK and adapts it to the STM32H563, what is then the process to get it upstreamed ? Med venlig hilsen / Best regards Mogens Lund SW Designer [e-logga-signatur-2] Niels Jernes vej 14, 9220 Aalborg Ø, Denmark Mobile: +45 2677 8879 Switchboard: +45 3315 9090 mogens.lund(a)prevas.dk<mailto:henrik.moller@prevas.dk> www.prevas.dk<http://www.prevas.dk/> ___________________ [Linkedin]<https://www.linkedin.com/company/prevasdenmark/> [Facebook] <https://www.facebook.com/prevasdenmark/> [Instagram] <https://www.instagram.com/prevasdenmark/> [YouTube] <http://www.youtube.com/user/Prevas100>

7 months, 4 weeks

Feedback requested: Dynamic provisioning data configuration for STM board b_u585i-iot02a

by Benjamin GROLLEAU

Dear TF-M maintainers, I am currently developing an application using the STM board b_u585i-iot02a (target: b_u585i_iot02a/stm32u585xx/ns). As mentioned in this issue<https://github.com/zephyrproject-rtos/zephyr/issues/92670>, , the provisioning data is currently statically programmed. Instead of changing this hardcoded data directly, I created a jinja2 template and a generation script based on the original file. This follows the same pattern used in trusted-firmware-m/platform/ext/common/provisioning_bundle/CMakeLists.txt. This approach works well locally, but I would like some feedback to ensure it meets the project's standards before opening a PR. First, what are your thoughts on this method? Should this feature be made available for all STM boards, or is it better to restrict it to the b_u585i-iot02a for now? Additionally, I am currently passing variables such as huk, iak, and boot_seed from my local project's CMakeLists.txt. If they are not provided, the script simply falls back to the default hardcoded values. Thank you in advance for your time and guidance. Best regards, ——— Benjamin Grolleau benjamin.grolleau(a)outlook.com

7 months, 4 weeks

TF-M CI failures

by Anton Komlev

Hello, TF-M CI is currently failing in most builds due to a documentation issue. The documentation was recently upgraded and now requires additional Python components in Docker image. We are aware of the issue and are working on fixes. Best regards, Anton

7 months, 4 weeks

Short enums and short wchar

by Bohdan.Hunko＠infineon.com

Hi all, Currently TFM specifies -fshort-wchar and -fshort-enums There previously was a discussion about this in https://lists.trustedfirmware.org/archives/list/tf-m@lists.trustedfirmware.… The decision was to remove these flags – which was done in https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/6186 But then fix was reverted in https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/6349 because: Removing the -fshort-wchar flag will cause link error with RTX library while using armclang and debug mode. Now we faced same issue when linking some of our prebuilt crypto libraries. Since RTX libraries ware prebuilt by TFM maintainers (prebuilt RTX libs are not part of CMSIS RTX) – I believe it is better to rebuild them without -fshort-wchar and -fshort-enums and remove these flags in TFM. Does TFM team still have a possibility to rebuild these RTX libs? Does this change make sense to TFM community? Best regards, Bohdan Hunko Cypress Semiconductor Ukraine LLC Senior Engineer CSS ICW SW INT BFS SFW Mobile: +380995019714 Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>

8 months

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M March 2026