STM32 platforms with TF-M fail to boot since 4.2.0-rc1

[etienne-lms]

Describe the bug

Since Zephyr bumped to TF-M 2.2.x (commit f67be66), STM32 platforms with variant 'ns' fail to boot.
These are nucleo_l552ze_q, stm32l562e_dk and stm32l562e_dk.

Regression

• This is a regression.

Steps to reproduce

Reproduced building and programming, for example, the hello_world sample on target boards 'ns' variant:

For b_u585i_iot02a:

west build -b b_u585i_iot02a/stm32u585xx/ns samples/hello_world/
./build/tfm/api_ns/regression.sh
west flash

For nucleo_l552ze_q:

west build -b nucleo_l552ze_q/stm32l552xx/ns samples/hello_world/
./build/tfm/api_ns/regression.sh
west flash

For stm32l562e_dk:

west build -b stm32l562e_dk/stm32l562xx/ns samples/hello_world/
./build/tfm/api_ns/regression.sh
west flash

Build sequence is fine but when the boards boot, there are no trace messages printed
whereas, for the 3 boards mentioned above, we expect build traces like the below:

(...)
[INF] Starting bootloader
(...)
[INF] Bootloader chainload address offset: 0x38000
[INF] Jumping to the first image slot
Booting TF-M v2.2.0+65d861552
(...)
Creating an empty ITS flash layout.
Creating an empty PS flash layout.
[INF][PS] Encryption alg: 0x5500200
[INF][Crypto] Init HW accelerator...
[INF][Crypto] Init HW accelerator... complete.
*** Booting Zephyr OS build v4.2.0-rc1 ***
Hello World! b_u585i_iot02a/stm32u585xx/ns

Relevant log output

Impact

Major – Severely degrades functionality; workaround is difficult or unavailable.

Environment

• OS: Linux
• Toolchain: Zephyr SDK
• v4.2.0-rc1

Additional Context

No response

[github-actions]

Hi @etienne-lms! We appreciate you submitting your first issue for our open-source project. 🌟

Even though I'm a bot, I can assure you that the whole community is genuinely grateful for your time and effort. 🤖💙

[etienne-lms]

The issue seems common to those 3 boards and related to trace logs handling in BL2.
A workaround is to enforce CONFIG_TFM_BL2_LOG_LEVEL_OFF=y or CONFIG_TFM_LOG_LEVEL_SILENCE=y until Zephyr TF-M/BL2 is fixed for these boards.

[wearyzen]

I tried running mps3/corstone300/fvp/ns and mps3/corstone310/fvp/ns and was able to see the hello world logs so, all commits related to BL logs/traces should already be in the 2.2.x branch.

[INF] Starting bootloader
[INF] Beginning BL2 provisioning
[WRN] TFM_DUMMY_PROVISIONING is not suitable for production! This device is NOT SECURE
[INF] PSA Crypto init done, sig_type: EC-P256, using builtin keys
[INF] Image index: 1, Swap type: none
[INF] Image index: 0, Swap type: none
[INF] Bootloader chainload address offset: 0x0
[INF] Image version: v0.0.0
[INF] Jumping to the first image slot
Booting TF-M v2.2.0
<NUL>[INF] Beginning TF-M provisioning
<NUL>[WRN] <NUL>TFM_DUMMY_PROVISIONING is not suitable for production! <NUL>This device is NOT SECURE<NUL>
<NUL>[WRN] <NUL>This device was provisioned with dummy keys. <NUL>This device is NOT SECURE<NUL>
<NUL>[Sec Thread] Secure image initializing!
<NUL>Creating an empty ITS flash layout.
Creating an empty PS flash layout.
[INF][PS] Encryption alg: 0x5500200
[INF][Crypto] Provision entropy seed...
[INF][Crypto] Provision entropy seed... complete.
*** Booting Zephyr OS build 4.2.00-rc1 ***
Hello World! mps3/corstone310/fvp/ns
^C
Stopping simulation...

Zephyr's TF-M 2.2.x branch has 52 commits added on top on the upstream TF-M's 2.2.x branch to enable different socs, maybe something for these 3 boards was missed? tagging @tomi-font @ceolin if they have any idea about this.

[ceolin]

I tried it with stm32l562e_dk and can confirm the logging issue. I am looking the cause of the problem.

[etienne-lms]

The issue comes from a runtime lib (like tfm_sprt) being linked in BL2 firmware.
The issues comes with how STM32 HW accelerators are integrated and since commit 65d8615521 that adds crypto_service_crypto_hw to platform_bl2 target while crypto_service_crypto_hw links in platform_s in platform/ext/target/stm/*/accelerator/CMakefileLists.txt.
I try to see how to address that, in synced with TF-M mainline, but it's not that obvious. Maybe both need to be fixed if HW accelerator are to be used in TF-M/BL2.

(edited: minor typo fixes)