Hi T-M team,
Hope you are doing well!
We are bringing up TF-M on the STM32H5F5J-DK (STM32H5F5, Cortex-M33, 4 MB flash) using ST's OEMiROT boot chain, and we plan to contribute the platform upstream.
Before completing the full port, we'd like to check whether ST or anyone else already has STM32H5F5 support in progress. If so, we're happy to collaborate and align rather than duplicate effort.
Current status on hardware:
TF-M boots successfully on the H5F5J-DK under ST OEMiROT, with TF-M BL2 disabled and OEMiROT acting as the MCUboot-based root of trust.
PSA Crypto and Internal Trusted Storage are functional.
A Non-Secure Zephyr application runs successfully and accesses TF-M services through the veneers.
During the bring-up, we found two issues in the shared STM32H5 support that appear independent of the H5F5 board port. We'd like to submit these separately first.
1. STM32H5 interrupt vector table
In:
platform/ext/target/stm/common/stm32h5xx/Device/Source/startup_stm32h5xx_s.c
parts of the interrupt vector table are guarded by:
#if defined(STM32H573xx) || defined(STM32H563xx)
For an STM32H5F5 build, this results in an incomplete/incorrect vector table. We observed:
131 vector entries versus 162 IRQs defined for H5F5.
53 empty slots, including RTC_S, FLASH_S, and RCC_S. A Secure-targeted interrupt hitting one of these vectors jumps to address 0 and HardFaults.
Three slots mapped to incorrect handlers. For example, the UART7 vector resolves to COMP1_IRQHandler.
Vectors 131-161 are missing entirely.
The existing table appears correct for H573/H563 but does not cover H5F5.
We regenerated the table against the H5F5 IRQn_Type definition and would like to submit this as a standalone fix. Guidance on the preferred upstream mechanism for selecting device-specific vector tables, for example a device macro versus a per-device startup
file, would be appreciated.
2. Entropy with CRYPTO_HW_ACCELERATOR=OFF
With the crypto accelerator disabled, the STM platform falls back to MBEDTLS_ENTROPY_NV_SEED. In our configuration, the corresponding ITS seed asset is not provisioned, causing psa_crypto_init() to fail during boot.
We worked around this by enabling MBEDTLS_ENTROPY_HARDWARE_ALT through TFM_MBEDCRYPTO_PLATFORM_EXTRA_CONFIG_PATH.
This appears to expose a more general issue with the STM32 platform configuration when hardware crypto acceleration is disabled. We could not identify an available entropy fallback for this configuration, so we'd like to address this independently of the H5F5
platform patch.
Platform specific questions
OEMiROT boot flow: Is an ST OEMiROT-based configuration with TF-M BL2 disabled acceptable for an upstream platform?
In this configuration, OEMiROT owns image authentication, installation, and rollback protection. STM32CubeH5 1.7.0 provides OEMiROT as the H5F5 reference flow, so we'd like the upstream platform to support this configuration if possible.
H5F5 CMSIS/HAL support: TF-M's bundled STM32H5 CMSIS device support predates the H5F5. For our current port, we use the H5F5 headers/HAL support from the Zephyr-pinned hal_stm32 revision, since mixing the older H573-era sources with H5F5 headers leads to register-definition
incompatibilities.
For upstream TF-M, would the preferred approach be to update the bundled STM32H5 CMSIS/HAL files, or consume the corresponding hal_stm32 support externally?
Crypto acceleration: Would there be any objection to adding H5F5 SAES/PKA/HASH acceleration using the existing H573 accelerator support as the model? We would submit this separately after the base platform support is accepted.
If there is no conflicting work already in progress, our proposed patch series is:
STM32H5 vector-table fix
STM32H5 entropy/NV-seed fix
STM32H5F5J-DK platform support
STM32H5F5 crypto accelerator support
We're happy to adjust the patch split or implementation approach based on maintainer preference.
We'll submit the patches through GitHub under BSD-3-Clause with DCO sign-off.
Please let us know if you need any additional information.