Hi TF-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.
Best Regards,
Ziyauddin Dhukka Senior Technical Lead +91 9427545552
Ziyauddin.Dhukka@einfochips.commailto:Ziyauddin.Dhukka@einfochips.com
[eInfochips | Enriching Lives Through Engineering Excellence]https://www.einfochips.com/ [cid:29b86944-c203-40c6-b638-331943212c39]https://www.einfochips.com/awards-and-accolades/
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.
Best Regards,
Ziyauddin Dhukka
This is a question for @Ronan GABOUmailto:ronan.gabou@st.com or @Marc JACOBmailto:marc.jacob@st.com
Thanks, Antonio
Sent from Outlook for Mac
From: Ziyauddin Dhukka via TF-M tf-m@lists.trustedfirmware.org Date: Thursday, 5 November 2026 at 08:59 To: tf-m@lists.trustedfirmware.org tf-m@lists.trustedfirmware.org Subject: [TF-M] TF-M Platform Support on STM32H5F5J-DK: Upstreaming Plan and Questions
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.
Best Regards,
Ziyauddin Dhukka
Thanks Ziyauddin Dhukka
While I let STM maintainers to reply on your questions, I'd suggest to submit your changes for review in review.trustedfirmware.org as described in https://trustedfirmware-m.readthedocs.io/en/latest/contributing/contributing...
Best regards, Nick
________________________________ From: Ziyauddin Dhukka via TF-M tf-m@lists.trustedfirmware.org Sent: 05 November 2026 08:58 To: tf-m@lists.trustedfirmware.org tf-m@lists.trustedfirmware.org Subject: [TF-M] TF-M Platform Support on STM32H5F5J-DK: Upstreaming Plan and Questions
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.
Best Regards,
Ziyauddin Dhukka
Hi Nick,
Thanks for your quick response. I will update changes as per the defined process and commit for your review.
Best Regards,
Ziyauddin Dhukka
________________________________ From: Nicola Mazzucato Nicola.Mazzucato@arm.com Sent: Thursday, November 5, 2026 2:39 PM To: tf-m@lists.trustedfirmware.org tf-m@lists.trustedfirmware.org; Ziyauddin Dhukka Ziyauddin.Dhukka@einfochips.com Subject: [External] Re: TF-M Platform Support on STM32H5F5J-DK: Upstreaming Plan and Questions
You don't often get email from nicola.mazzucato@arm.com. Learn why this is importanthttps://aka.ms/LearnAboutSenderIdentification
CAUTION: This email originated from outside of the organization. This message might not be safe, use caution in opening it. If in doubt, do not open the attachment nor links in the message.
Thanks Ziyauddin Dhukka
While I let STM maintainers to reply on your questions, I'd suggest to submit your changes for review in review.trustedfirmware.org as described in https://trustedfirmware-m.readthedocs.io/en/latest/contributing/contributing...
Best regards, Nick
________________________________ From: Ziyauddin Dhukka via TF-M tf-m@lists.trustedfirmware.org Sent: 05 November 2026 08:58 To: tf-m@lists.trustedfirmware.org tf-m@lists.trustedfirmware.org Subject: [TF-M] TF-M Platform Support on STM32H5F5J-DK: Upstreaming Plan and Questions
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.
Best Regards,
Ziyauddin Dhukka
Hi Nic,
Committed new changes: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/56220 Please review and let me know your feedback.
Best Regards,
Ziyauddin Dhukka
________________________________ From: Ziyauddin Dhukka Ziyauddin.Dhukka@einfochips.com Sent: Thursday, November 5, 2026 2:52 PM To: Nicola Mazzucato Nicola.Mazzucato@arm.com; tf-m@lists.trustedfirmware.org tf-m@lists.trustedfirmware.org Subject: Re: [External] Re: TF-M Platform Support on STM32H5F5J-DK: Upstreaming Plan and Questions
Hi Nick,
Thanks for your quick response. I will update changes as per the defined process and commit for your review.
Best Regards,
Ziyauddin Dhukka
________________________________ From: Nicola Mazzucato Nicola.Mazzucato@arm.com Sent: Thursday, November 5, 2026 2:39 PM To: tf-m@lists.trustedfirmware.org tf-m@lists.trustedfirmware.org; Ziyauddin Dhukka Ziyauddin.Dhukka@einfochips.com Subject: [External] Re: TF-M Platform Support on STM32H5F5J-DK: Upstreaming Plan and Questions
You don't often get email from nicola.mazzucato@arm.com. Learn why this is importanthttps://aka.ms/LearnAboutSenderIdentification
CAUTION: This email originated from outside of the organization. This message might not be safe, use caution in opening it. If in doubt, do not open the attachment nor links in the message.
Thanks Ziyauddin Dhukka
While I let STM maintainers to reply on your questions, I'd suggest to submit your changes for review in review.trustedfirmware.org as described in https://trustedfirmware-m.readthedocs.io/en/latest/contributing/contributing...
Best regards, Nick
________________________________ From: Ziyauddin Dhukka via TF-M tf-m@lists.trustedfirmware.org Sent: 05 November 2026 08:58 To: tf-m@lists.trustedfirmware.org tf-m@lists.trustedfirmware.org Subject: [TF-M] TF-M Platform Support on STM32H5F5J-DK: Upstreaming Plan and Questions
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.
Best Regards,
Ziyauddin Dhukka
H Ziyauddin ,
Thank you for reaching out and sharing your progress on the STM32H5F5 port, along with your findings and proposed patch series.
On our side, we are currently working on integrating STM32 hardware cryptographic acceleration into TF-M through the TF-PSA-Crypto driver interface.
We will review your questions internally and get back to you with more detailed feedback.
Best regards, Marc JACOB
From: Ziyauddin Dhukka via TF-M tf-m@lists.trustedfirmware.org Sent: Thursday, November 5, 2026 5:52 AM To: tf-m@lists.trustedfirmware.org Subject: [TF-M] TF-M Platform Support on STM32H5F5J-DK: Upstreaming Plan and Questions
Hi TF-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.
Best Regards,
Ziyauddin Dhukka Senior Technical Lead +91 9427545552
Ziyauddin.Dhukka@einfochips.commailto:Ziyauddin.Dhukka@einfochips.com
[eInfochips | Enriching Lives Through Engineering Excellence]https://www.einfochips.com/ [cid:image002.png@01DD6D4B.BAF276D0]https://www.einfochips.com/awards-and-accolades/
tf-m@lists.trustedfirmware.org
-
Antonio De Angelis -
Marc JACOB -
Nicola Mazzucato -
Ziyauddin Dhukka