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