STM32MP157C DFU unstable with Secure Boot enabled when SCMI is active

[FabienL]

Hello,

I am facing an issue with DFU mode on an STM32MP157C when Secure Boot is enabled (OTP locked) and SCMI is active via OP-TEE, and I would like to confirm whether this is an expected behavior or a known limitation.

I am using STM32CubeProgrammer to load FSBL and the FIP image into RAM, then entering U-Boot DFU mode in order to flash the eMMC. This workflow is used for recovery and reprogramming purposes.

I am using the same software stack (ATF 2.12, OP-TEE 4.3.0, U-Boot 2025.01, device tree with SCMI configuration) on the two boards (based on stm32mp157c-dk2).

The only difference between them is the Secure Boot state: one board is not locked, the other one has Secure Boot enabled.

On the non-locked board, DFU works reliably with STM32CubeProgrammer. I can enter DFU mode, send the FlashLayout, and perform multiple DFU transactions without any issue. OP-TEE does print errors related to SCMI TA loading, but DFU continues normally.

On the locked board, DFU becomes unstable. Typically, the initial DFU upload works, but when sending the FlashLayout, DFU fails with a “Wrong sequence number” error. This behavior is reproducible and only happens when Secure Boot is enabled.

Boot over usb0!
D/TC:? 0 tee_ta_init_pseudo_ta_session:303 Lookup pseudo TA 1a8342cc-81a5-4512-99fe-9e2b3e37d626
D/TC:? 0 ldelf_load_ldelf:110 ldelf load address 0x105000
D/LD:  ldelf:142 Loading TS 1a8342cc-81a5-4512-99fe-9e2b3e37d626
D/TC:? 0 ldelf_syscall_open_bin:163 Lookup user TA ELF 1a8342cc-81a5-4512-99fe-9e2b3e37d626 (early TA)
D/TC:? 0 ldelf_syscall_open_bin:167 res=0xffff0008
D/TC:? 0 ldelf_syscall_open_bin:163 Lookup user TA ELF 1a8342cc-81a5-4512-99fe-9e2b3e37d626 (Secure Storage TA)
D/TC:? 0 ldelf_syscall_open_bin:167 res=0xffff0009
E/LD:  init_elf:493 sys_open_ta_bin(1a8342cc-81a5-4512-99fe-9e2b3e37d626)
E/TC:? 0 ldelf_init_with_ldelf:152 ldelf failed with res: 0xffff0009
D/TC:? 0 tee_ta_open_session:696 init session failed 0xffff0009
dfu_alt_init: dfu_alt_num=4
DFU alt info setting: dfu_fill_entity: @FlashLayout/0x00/1*256Ke ram c2000000 40000 interface: ram dev: <NULL>
dfu_fill_entity: @virtual/0xf1/1*512Be interface: virt dev: 241
dfu_fill_entity: @OTP/0xf2/1*776Be interface: virt dev: 242
dfu_fill_entity: @PMIC/0xf4/1*8Be interface: virt dev: 244
done
D/TC:? 0 tee_ta_init_session_with_context:557 Re-open trusted service 94cf71ad-80e6-40b5-a7c6-3dc501eb2803
D/TC:? 0 tee_ta_close_session:460 csess 0x2ffe7e00 id 2
D/TC:? 0 tee_ta_close_session:479 Destroy session
D/TC:? 0 tee_ta_init_session_with_context:557 Re-open trusted service 94cf71ad-80e6-40b5-a7c6-3dc501eb2803
D/TC:? 0 tee_ta_close_session:460 csess 0x2ffe7e00 id 2
D/TC:? 0 tee_ta_close_session:479 Destroy session
D/TC:? 0 tee_ta_init_session_with_context:557 Re-open trusted service a8cfe406-d4f5-4a2e-9f8d-a25dc754c099
D/TC:? 0 tee_ta_close_session:460 csess 0x2ffe7e00 id 2
D/TC:? 0 tee_ta_close_session:479 Destroy session
D/TC:? 0 tee_ta_init_session_with_context:557 Re-open trusted service a8cfe406-d4f5-4a2e-9f8d-a25dc754c099
D/TC:? 0 tee_ta_close_session:460 csess 0x2ffe7e00 id 2
D/TC:? 0 tee_ta_close_session:479 Destroy session
D/TC:? 0 tee_ta_init_session_with_context:557 Re-open trusted service a8cfe406-d4f5-4a2e-9f8d-a25dc754c099
D/TC:? 0 tee_ta_close_session:460 csess 0x2ffe7e00 id 2
D/TC:? 0 tee_ta_close_session:479 Destroy session
D/TC:? 0 tee_ta_init_session_with_context:557 Re-open trusted service a8cfe406-d4f5-4a2e-9f8d-a25dc754c099
D/TC:? 0 tee_ta_close_session:460 csess 0x2ffe7e00 id 2
D/TC:? 0 tee_ta_close_session:479 Destroy session
D/TC:? 0 tee_ta_init_session_with_context:557 Re-open trusted service a8cfe406-d4f5-4a2e-9f8d-a25dc754c099
D/TC:? 0 tee_ta_close_session:460 csess 0x2ffe7e00 id 2
D/TC:? 0 tee_ta_close_session:479 Destroy session
dfu_read: name: @virtual/0xf1/1*512Be buf: 0xdc77c100 size: 0x1000 p_num: 0x0 i_buf: 0x00000000
dfu_transaction_initiate: @virtual/0xf1/1*512Be 512 [B]
#
UPLOAD ... done
Ctrl+C to exit ...
dfu_write: name: @FlashLayout/0x00/1*256Ke buf: 0xdc77c100 size: 0x1c8 p_num: 0x2 offset: 0x0 bufoffset: 0x0
dfu_write: Wrong sequence number! [0] [2]

In both cases, OP-TEE reports errors while trying to load the SCMI Trusted Application (UUID 1a8342cc-81a5-4512-99fe-9e2b3e37d626), returning TEE_ERROR_ITEM_NOT_FOUND. The difference seems to be that this SCMI-related error is tolerated on a non-locked board, while on a locked board the stricter Secure Boot behavior appears to interfere with the DFU flow.

My goal is to be able to re-enter DFU mode and reflash the board using CubeProgrammer even when the board is locked, for recovery or update purposes.

Please fin attached, OP-TEE config.h file and the both boot logs

Best regards,

Fabien