Hello,
I’m going to apply and test this patch set and come back to you as soon as possible.
Ronan,
Ronan GABOU | Tel: +33 1 58 07 80 19
MDG / General Purpose Microcontroller Sub-Group / Wireless Business Line / Cellular
ST online:
www.st.com
online:
www.st.com
From: Steven Friedman <friedman@ionq.co>
Sent: Monday, April 20, 2026 1:05 AM
To: tf-m@lists.trustedfirmware.org
Cc: mogens.lund@prevas.dk; Ronan GABOU <Ronan.GABOU@st.com>; nicola.mazzucato@arm.com
Subject: [PATCH 00/20] platform: stm: STM32H563 TF-M support
|
You don't often get email from
friedman@ionq.co.
Learn why this is important |
On 17 March 2026 Mogens Lund (mogens.lund@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.
--