- TF-M - lists.trustedfirmware.org

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

1 hour, 13 minutes

15
114
0 0

Local library patching issue

by Bohdan.Hunko＠infineon.com

Hi, I was trying to build TF-M with local libraries and noticed that patches were not applied in that flow. I found an issue with fetch_remote_library() when using local library paths instead of downloading the dependency. The function exposes LIB_FORCE_PATCH, and the documentation says it should control patching when the library source is provided as a local folder. However, in the current implementation this does not really work for local libraries. We have our Modus Toolbox IDE which builds TFM as part of a project where all the libraries are already cloned, thus we need a way to forca patch local sources. Is upstream community interested in this ? If so I can propose a fix soon. A patch is available for review. 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>

2 days, 2 hours

1
1
0 0

Inquiry for crypto opaque functions

by 김륜현

HI, i'm developing the RSE firmware based on TF-Mv2.3.0(with TF-Mv2.3.0 release tag) for the our platform that refers to rdv3r1. In TF-M runtime security service, it needs a IAK(Initial Attestation Key) derived by IAK seed to create IAT(Initial Attestation Token). When i checked tfm_plat_get_iak(), it gets IAK_seed by just reading KMU slot which IAK_seed is stored. However, the KMU keyslot storing IAK_seed have been locked since IAK_seed is created so that IAT creation is failed. I was checking possible ways that exports locked key in KMU keyslot and found some evidence in the source codes. That is using CC3xx opaque key that is the method using the KMU export with keyslot index instead using raw key values. Currently, it seems that cc3xx opaque keys feature is supported only for HW keys and AES / CMAC algorithm. However, IAK_seed is stored in S/W keyslot and IAK needs ECC algorithm derivation. (CC3xx lowlevel seems to support it but PSA crypto driver doesn't support it) According to TODO comments like below, it seems that there is some long term plan about it. (I guess that it will be removed When PSA crypto driver supporting all keys and algorithm is implemented) rse_setup_iak_seed()(a)rse_kmu_keys.c /* TODO: Should be removed once setup_key properly locks KMU slots */kmu_err = kmu_set_key_locked(&KMU_DEV_S, RSE_KMU_SLOT_IAK_SEED);if (kmu_err != KMU_ERROR_NONE) {    return (enumtfm_plat_err_t) kmu_err;} Are there any plans or progress regarding this? Best Regards RH Kim

3 days, 11 hours

1
0
0 0

[BUG] Windows build broken: Architectural conflict between CMake object hashing (commit 8df5c30) and hardcoded .o paths

by Sławomir Piotrowski

Hi TF-M Maintainers, I've encountered a systemic build issue when compiling TF-M on Windows using new CMake version (4.2.1+). The build currently fails on Windows, whereas it compiles perfectly fine on Linux (or via Docker or using older CMake vsrsion). After investigating, the root cause appears to be an architectural conflict introduced by commit 8df5c30845fba7e63253c64407d009b40a37ff95. This commit attempts to solve Windows MAX_PATH limitations by forcing CMake to use short object names (hashing and flattening the output paths for .o files). However, multiple parts of the TF-M build system fundamentally rely on predictable, unhashed intermediate object file names. The conflict manifests in at least two critical areas: 1. Image Signing / Bootloader: The build process requires .o files (like signing layouts) to be in specific, predictable locations for the signing process. With path hashing enabled on Windows, the build scripts cannot locate these artifacts. 2. Linker Script(s): At least STM target relies on filename wildcards to place symbols into specific memory sections. In file bl2.ld the script explicitly looks for *mpu_armv8m_drv.o. Since CMake renames this file to a hash on Windows, the rule is silently ignored, causing memory layout failures. The Problem: We cannot simultaneously use CMake object path hashing and rely on predictable intermediate file paths. Relying on .o names in linker scripts is inherently fragile. Proposal: Given that this issue breaks the core Windows build and likely hides more bugs in other target-specific linker scripts or CMake configurations, I suggest reverting commit 8df5c30845fba7e63253c64407d009b40a37ff95 for now. Before re-enabling short object names on Windows, a deeper architectural audit is needed. For example, moving away from file-based section placement in linker scripts and instead using compiler attributes (e.g., __attribute__((section("...")))) directly in the C source code, making the build agnostic to object file names. As I am consuming TF-M primarily through the Zephyr ecosystem, I am not intimately familiar enough with pure TF-M's complex CMake structure to patch all these instances safely myself. Could someone with deeper knowledge of the TF-M build system look into this and decide on the best path forward? Best regards, Sławomir Piotrowski

1 week, 3 days

2
1
0 0

Stm32: Memory mapped external Flash not available for non secure domain

by Sławomir Piotrowski

Hello, I'm working with the STM32U585 on the b_u585i_iot02a board using Zephyr and TF-M. Currently, the OSPI2 controller itself is correctly assigned to the Non-Secure (NS) domain, allowing standard indirect flash operations. However, when I enable the Memory-Mapped mode for the external flash, any read attempt (e.g., using memcpy via flash_read) immediately triggers a SecureFault. This happens because the memory-mapped region (0x70000000) is not configured as Non-Secure in the SAU and GTZC (MPCWM) during the TF-M boot process. Since the configuration file (platform/ext/target/stm/common/stm32u5xx/secure/target_cfg.c) is located in the common directory rather than the board-specific folder, it's difficult to override this behavior cleanly in an out-of-tree custom board definition. Proposed Solution: I suggest adding a conditional configuration in target_cfg.c that checks for board-specific definitions (e.g., EXTERNAL_FLASH) to explicitly allow NS/Unprivileged read access to the OSPI mapped region. I have attached a patch demonstrating this simple fix. Note: Since the OSPI peripheral is already exposed to the NS domain, granting access to its memory-mapped region does not introduce a new security risk (an attacker could already read the flash via indirect commands). It simply restores the intended functionality. Alternatively, an architectural redesign - such as moving board-specific security configs out of common or providing __weak hooks for board files - would be ideal, but this simple patch resolves the immediate blocker. thank you, Sławomir Piotrowski

1 week, 6 days

2
1
0 0

STM32U5: BL2 HardFault after HDP activation due to missing .BL2_NoHdp_Code in MPU driver

by Sławomir Piotrowski

Description: When booting TF-M 2.3.0 on the STM32U5 platform with TFM_HDP_PROTECT_ENABLE=1, a Secure HardFault occurs in BL2 right before jumping to the primary image. The fault is caused by an instruction fetch error from the hidden memory area because the MPU configuration functions lack the necessary section attributes. Execution Flow & Root Cause: boot_platform_start_next_image() is called. It invokes LL_SECU_UpdateRunTimeProtections(), which enables the hardware Hide Protection (HDP) firewall. From this point, most of the BL2 flash area becomes unreadable/unexecutable. It then calls mpu_appli_cfg(). This function is correctly placed outside the firewall using __attribute__((section(".BL2_NoHdp_Code"))). However, mpu_appli_cfg() calls mpu_armv8m_region_enable() (located in mpu_armv8m_drv.c). BUG: mpu_armv8m_region_enable() does not have the .BL2_NoHdp_Code attribute. Since it resides in the standard .text section hidden by HDP, the CPU immediately throws a HardFault when trying to execute it. Stack Trace: mpu_appli_cfg @ 0x0c036182 LL_SECU_UpdateRunTimeProtections @ 0x0c03614e boot_platform_start_next_image @ 0x0c036078 do_boot @ 0x0c014e38 main @ 0x0c01505e Proposed solution: Add __attribute__((section(".BL2_NoHdp_Code")) guarded by #ifdef BL2 to mpu_armv8m_region_enable() and mpu_armv8m_region_enable_check(). thank you, Sławomir Piotrowski

2 weeks, 1 day

1
0
0 0

Re: Proposal to unify tf.org vulnerability referencing in NVD

by sandrine.afsa＠arm.com

The content of this message was lost. It was probably cross-posted to multiple lists and previously handled on another list.

2 weeks, 3 days

1
0
0 0

BL2 support for STM32U3 platform

by Jaun, Mario

Hello We are interested in integrating TF-M into a project which is based on a STM32U3 MCU. The documentation states under limitations "TF-M Supported without BL1/BL2". Are there technical reasons that BL2 is not supported? If no, is support planned to be implemented in the near future? If no, would you be open for contributions regarding adding BL2 support? Thanks for your response. Best Mario

3 weeks, 5 days

2
1
0 0

Proposal to unify tf.org vulnerability referencing in NVD

by sandrine.afsa＠arm.com

The content of this message was lost. It was probably cross-posted to multiple lists and previously handled on another list.

3 weeks, 6 days

1
0
0 0

CI infrastructure scheduled maintenance: 4th June Sep 2026

by Saheer Babu

Hi all, We will be upgrading Cloudbees CI and clusters hosting review.trustedfirmware.org and ci.trustedfirmware.org on Wednesday, 3rd June 2025 at 16:00 GMT+1. During this maintenance window, both services will be unavailable for approximately 8 hours. A follow-up email will be sent once the services are fully restored. Best regards, Saheer [LOGO SMALL] Saheer Babu Principal Software Engineer CESW – Engineering Infrastructure

4 weeks

1
2
0 0

Re: no ATU setting in RDV3r1 with TF-M v2.3.0

by 김륜현

Hi Nick First, i share that i'm reviewing TF-M v2.3.0 with tag https://review.trustedfirmware.org/plugins/gitiles/TF-M/trusted-fi… In the shared commit, platform/ext/target/arm/rse/neoverse_rd/rdv3/bl2/boot_hal_bl2.c call atu_rse_drv_init() in boot_platform_post_init() like below. int32_t boot_platform_post_init(void) {     int32_t result;     enum atu_error_t atu_err;     result = rse_sam_init(RSE_SAM_INIT_SETUP_FULL);     if (result != 0) {         return result;     }     atu_err = atu_rse_drv_init(&ATU_DEV_S, ATU_DOMAIN_ROOT, atu_regions_static, atu_stat_count);     if (atu_err != ATU_ERR_NONE) {             return result;     } But, atu_rse_drv_init don't be called in platform/ext/target/arm/rse/neoverse_rd/rdv3r1/bl2/boot_hal_bl2.c anywhere. So, i tried to find ATU setting to other sources in RDV3R1 platform, i couldn't find ATU setting to load post image. Is there any codes setting ATU for each processor region that image will be loaded? Best Regards RH Kim ----- 원본 메시지 ----- 보낸 사람: Nicola Mazzucato <Nicola.Mazzucato(a)arm.com> 받는 사람: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.xn--org>,-7104au55ev23e <winxp4333(a)adtek.co.kr> 날짜: 2026-05-13 17:01:37 제목: Re: [TF-M] no ATU setting in RDV3r1 with TF-M v2.3.0 Thanks RH Kim, The commit you shared did not remove any ATU initialisations from what I see. To understand better, are you working on a branch or old commit where you see atu_rse_drv_init for RDV3R1? If so, can you please share? I'm also not very familiar with that platform so it's likely I'm missing something, though it seems that the platform_post_init sequence is different from RDV3. Thanks Best regards, Nick From: 김륜현 via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 13 May 2026 03:16 To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] no ATU setting in RDV3r1 with TF-M v2.3.0   Dear all, i'm developing the RSE firmware based on rdv3r1. I'm reviewing TF-M v2.3.0 was recently released for checking difference our project codes. Among many differences, i discovered missing ATU settings to load post processor images. In the similar platform rdv3, it calls atu_rse_drv_init() at boot_platform_post_init().  But rdv3r1 doesn't call atu_rse_drv_init() also i can't found ATU settings to load post images in BL2. Is there any intentions? Or was it just missing while integrating by this commit https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/… Please check it  Best Regards RH Kim

1 month, 2 weeks

1
0
0 0

no ATU setting in RDV3r1 with TF-M v2.3.0

by 김륜현

Dear all, i'm developing the RSE firmware based on rdv3r1. I'm reviewing TF-M v2.3.0 was recently released for checking difference our project codes. Among many differences, i discovered missing ATU settings to load post processor images. In the similar platform rdv3, it calls atu_rse_drv_init() at boot_platform_post_init().  But rdv3r1 doesn't call atu_rse_drv_init() also i can't found ATU settings to load post images in BL2. Is there any intentions? Or was it just missing while integrating by this commit https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/… Please check it  Best Regards RH Kim

1 month, 2 weeks

2
1
0 0

TF-M v2.1.5 release announcement

by Anton Komlev

Hello, I am pleased to announce the release of TF-M v2.1.5. Major highlights: * SPM: Fixes for FPU context cleanup, add r12 into caller context clearing * Upgrade to MbedTLS v3.6.6, which contains security advisories. Please see the release notes<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/50758/2/docs…> for full details. Many thanks to Nicola Mazzucato for leading this step, and to everyone who supported this milestone. Best regards, Anton

1 month, 3 weeks

1
0
0 0

TF-M v2.3.0 release announcement

by Anton Komlev

Hello, We're pleased to announce the release of TF-M v2.3.0. Major highlights: * Adoption of TF-PSA-Crypto 1.1.0 in place of Mbed TLS * Extended support for the Clang/LLVM Arm Toolchain for Embedded (ATfE) * TF-M Tests: RTX OS is now built from source This release also includes numerous fixes and improvements - please see the release notes<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/50322/8/docs…> for full details. Release v2.1.5 will follow shortly. Many thanks to everyone who contributed, reviewed, and supported this milestone. Best regards, The TF-M Team

1 month, 3 weeks

1
1
0 0

Need STM32 crypto accelerator support in v2.3.0

by Michael Grand

Dear all, I have seen that hw crypto acceleration has been removed from Stm32 platform in v2.3.0. I was eagerly waiting for this new LTS version however lack of crypto acceleration support for stm32 is a no go for me. Is there a plan to add crypto acceleration support later ? Or maybe I have missed something ? Best regards, Michael Grand

2 months

1
0
0 0

TF-M 2.3 PSA arch tests build fails for CM55 core

by Bohdan.Hunko＠infineon.com

Hi all, Currently build of psa arch tests fail for CM55 core of our PSE84 platform File: api-tests/tools/cmake/compiler/{ARMCLANG,GNUARM}.cmake (same in secure-debug/). Problem: The toolchain file unconditionally adds -march=... derived from CPU_ARCH. When built inside TF-M, mcpu_features.cmake already sets -mcpu=... with extension toggles. The compiler then sees two CPU specs that disagree on extensions. Why CM33 works, CM55 doesn't: CM33: -mcpu=cortex-m33 and -march=armv8-m.main describe the same extension set → accepted. CM55: -mcpu=cortex-m55+nomve+... and -march=armv8.1-m.main disagree on MVE/FP → rejected. Fix (generic): Skip the -march block when an outer build already selects the CPU (e.g. TFM_SYSTEM_PROCESSOR defined, or CMAKE_C_FLAGS contains -mcpu=/--target=). Long-term: switch psa-arch-tests to -mcpu-based selection. We have not yet pushed PSE84 psa arch tests target, but maybe this can be check by ARM team using one of ARM CM55 based platforms (e.g. Corstone-300 (MPS3))? 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>

2 months

2
2
0 0

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

2 months, 1 week

1
3
0 0

[TF-M 2.2.2] Inquiry Regarding vHUK Seed Array Inconsistency Among Clients During rse_handshake in Multi-RSE Topology

by 박진국

Hello, I am currently developing with the Multi-RSE Topology and have an inquiry regarding the following *1. Overview & Environment* - *Version:* Trusted Firmware-M (TF-M) 2.2.2 - *Target Architecture:* MULTI_RSE_TOPOLOGY enabled environment - *Related Modules:* boot_hal_bl1_2.c, rse_handshake.c *2. Background & Code Analysis* We are currently analyzing the BL1 boot sequence code to set up a Multi-RSE environment. Looking at the boot_platform_post_init() function in platform/ext/target/arm/rse/common/bl1/boot_hal_bl1_2.c, the vHUK is generated in the following sequence: 1. Calls rse_derive_vhuk_seed() 2. Checks the CM_POLICIES_VHUK_AGREEMENT_REQUIRED policy, then executes rse_handshake(vhuk_seed) 3. Calls rse_setup_vhuk() to derive the final vHUK based on the aggregated Seed array. *3. Issue Description* However, upon analyzing the operational structure in rse_handshake.c, we suspect a synchronization defect exists where the Server (Primary RSE) and multiple Clients (Secondary RSEs) will end up generating different final vHUKs. - Looking at the rse_handshake_server() logic, the server replies to the client *immediately* within the receive loop with the *currently* aggregated vhuk_seeds_buf every time it receives a Seed from a client. - Because of this behavior, Client 1 (the first to connect) receives an incomplete array (e.g., [C0, C1, 0, 0]) that lacks the seeds of subsequent clients. Only the last client to connect receives the fully populated array ([C0, C1, C2, C3]). - Consequently, each Client executes rse_setup_vhuk() with a different state of vhuk_seeds_buf. This ultimately leads to mismatched final vHUK values across the RSEs within the system. *4. Questions* 1. Is this behavior (returning an incomplete Seed array based on the client connection order) an intended operation within the security architecture? 2. If this is not intended, is this a known bug in TF-M 2.2.2 where the logic for the Server to broadcast (or perform a 2-Phase synchronization of) the completed array to all clients *after* gathering all seeds is missing? 3. Could you please provide a workaround for this issue, or guide us to a specific patch/commit if this has been resolved in a newer version? Thank you in advance for your support.

2 months, 1 week

1
0
0 0

[PATCH 00/20] platform: stm: STM32H563 TF-M support

by Steven Friedman

On 17 March 2026 Mogens Lund (mogens.lund(a)prevas.dk) asked on this list whether STM32H563 TF-M support was planned, and whether there was a defined path for upstreaming a clone-and-adapt of the existing STM32H573I-DK port. This patchset provides that support: it extends the shared platform/ext/target/stm/common/stm32h5xx/ code to cover STM32H563 alongside STM32H573 and adds a NUCLEO-H563ZI board port that builds and runs on real hardware today. Twenty patches, internally organised into three groups that review independently: Group A [01..13] Generic STM32H5xx improvements. Every patch in this group changes STM32H573 runtime behaviour (correctness fixes, defensive hardenings, chip-family additions applicable to both H563 and H573). No #ifdef guards. Group B [14..19] STM32H563 chip-variant support. Four commits (14-17) are mechanical enablers -- linkage changes and defensive conditionals that are no-ops on H573 but required by group C. Two commits (18-19) are H563-only behaviour under #ifdef STM32H563xx; H573 is unaffected. Group C [20] NUCLEO-H563ZI board port at platform/ext/target/stm/nucleo_h563zi/, structurally mirroring the existing platform/ext/target/stm/stm32h573i_dk/ port. Thirteen of nineteen files are verbatim copies from stm32h573i_dk with original headers preserved; five contain authored content (CMakeLists.txt, cpuarch.cmake, include/board.h, include/stm32hal.h, secure/low_level_device.c); one (cpuarch.cmake) is adapted from stm32h573i_dk with a one-word chip-identifier change. See the commit body for the full file-by-file provenance. Group A patches --------------- 01 fix dual-bank flash page addressing 02 wait for HSI48 ready before RNG init 03 map fault vectors to proper handlers 04 improve Error_Handler debug spin 05 extend system-memory SAU region to cover UID (H573 also gains NS UID access; RM0481 section "Unique device ID register") 06 add SAU region for OCTOSPI1 XIP aperture 07 enable SRAMx clocks before MPCBB programming (RM0481 section "RCC_AHB2ENR" -- SRAM2EN / SRAM3EN default to 0 on reset) 08 allow NS access to I/DCACHE register interfaces 09 guard SysTick init in UART stdio driver 10 default CONFIG_TFM_ENABLE_CP10CP11 ON for stm32h573i_dk (matches platform/ext/target/adi/max32657/cpuarch.cmake precedent; docs/integration_guide/tfm_fpu_support.rst section "FPU support") 11 enable configurable fault handlers in boundary setup 12 lock Secure MPU configuration after setup 13 refresh SystemCoreClock before RNG_Init Group B patches --------------- 14 expose mpu_init() for platform overrides (linkage only -- drops 'static'; no runtime change) 15 drop static from n_configured_regions (same rationale as 14) 16 skip scratch flash area when it is not defined (conditional on FLASH_AREA_SCRATCH_OFFSET; H573's flash_layout defines it so H573 behaviour is unchanged) 17 clear AIRCR.BFHFNMINS defensively in boundary setup (no-op on H573 because Reset_Handler's LOCKSVTAIRCR lock stuck; documented mechanism for parts where it did not) 18 skip LOCKSVTAIRCR check for H563 (#ifdef STM32H563xx -- parts with BOOTHDPL = 0x01 boot at HDPL1 so the lock write is silently ignored; self-retiring when production parts ship with BOOTHDPL = 0x00) 19 skip PKA / AES / SAES TZSC config on H563 (#ifdef STM32H563xx -- H563 has none of those peripherals) Group C patch ------------- 20 add NUCLEO-H563ZI board port Dependency on STMicroelectronics' cmsis-device-h5 ------------------------------------------------- Group C compiles cleanly against the TF-M tree only after the STM32H563 CMSIS device header has been imported. The canonical source is https://github.com/STMicroelectronics/cmsis-device-h5 at the latest stable tag (v1.5.0 at the time of writing). The required imports are: 1. Add platform/ext/target/stm/common/stm32h5xx/Device/Include/stm32h563xx.h copied verbatim from the cmsis-device-h5 repository above. 2. Extend platform/ext/target/stm/common/stm32h5xx/Device/Include/stm32h5xx.h with an #elif defined(STM32H563xx) branch that #includes "stm32h563xx.h", mirroring the existing #if defined(STM32H573xx) branch. Neither change is included in this patchset because groups A and B touch zero H563-specific register symbols -- every patch tests only the STM32H563xx build macro. I would appreciate guidance from ST on whether they would like to handle the vendor import themselves (same mechanism as the existing stm32h573xx.h), or whether they would prefer a follow-up patch from me that does the import. Testing ------- All 20 patches applied together and boot-tested on NUCLEO-H563ZI hardware with a Zephyr 4.4 NSPE (CONFIG_FPU=y, thumbv8m.main-none-eabihf): BL2 -> TF-M SPE at isolation level 2 -> Zephyr NSPE hands off cleanly, zero SecureFault / HardFault / MemManage / BusFault. NS FPU access works across the S/NS boundary via the SPM-level CP10/CP11 programming enabled by the nucleo_h563zi cpuarch.cmake. I do not have an STM32H573I-DK board. Group A is expected to be strictly behaviour-improving on H573 (correctness fixes, defensive hardenings, plus patch 10 which enables a cmake knob that the stm32h573i_dk port today leaves off), but confirmation from ST or other H573 users during review would be welcome. -- STEVEN FRIEDMAN SENIOR STAFF ENGINEER *P:* 301.298.7997x168 *E:* friedman(a)ionq.co *W: *www.ionq.co

2 months, 1 week

2
1
0 0

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>

3 months, 2 weeks

2
3
0 0

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

3 months, 2 weeks

1
0
0 0

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

3 months, 2 weeks

1
1
0 0

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>

3 months, 3 weeks

5
11
0 0

New TF-M m maintainer

by Anton Komlev

Hi Everyone, I am glad to announce the new maintainer of TF-M project: * Nicola Mazzucato aka nicola-mazzucato-arm <nicola.mazzucato(a)arm.com<mailto:nicola.mazzucato@arm.com>> Thank you, Nicola, for agreeing to maintain the project. All the best, Anton

4 months, 2 weeks

1
0
0 0

New Clang/LLVM Toolchain Support Announcement

by Anton Komlev

Hello, I am thrilled to announce the support of new Clan/LLVM toolchain, freely available here: https://github.com/ARM-software/LLVM-embedded-toolchain-for-Arm. This extends a suite of powerful tools designed to enhance your development experience and boost productivity. Key Features: * Offers Clang frontend * Available for Linux, Windows and macOS * Builds TF-M binaries for all Arm targets * Secure side built without libc and picolib libraries, while both are available to Bootloader and Non-Secure side Important notes: * Floating point support is not verified * MVE is not supported yet * This has been verified with version v18.1.3 of the toolchain. We're excited for you to try out the new toolchain support and look forward to your feedback. The use of the toolchain_CLANG.cmake is the same as all other toolchains. I plan to present the new toolchain and compare it with the existing tools in one of the upcoming TF-M forums. Meanwhile I encourage the platform owners to include the new toolchain support using arm platforms as a reference. The relevant changes are in this chain: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/34351 There is ongoing discussion on the best name for the toolchain to avoid possible confusion. Should it be Clang as now, LLVM, or even LLVMClang? Please share your opinion. Thanks, and best regards, Anton.

4 months, 2 weeks

2
2
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M