- TF-M - lists.trustedfirmware.org

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.

3 months, 1 week

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 months, 3 weeks

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 months, 3 weeks

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

3 months, 3 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

4 months, 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

4 months, 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

4 months, 2 weeks

1
0
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

5 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>

5 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

5 months

1
3
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M