STM32MP157 on custom board: Start / Stop M4 FW via remote proc (stm32_rproc). Set BOOT_MCU bit

Tilo · ‎2021-03-29

HOLD_BOOT: After an power-on reset the BOOT_MCU is '0' and we can set the

bit to '1', after an MCU reset (MCU_RST) the M4 FW start (CRun). All is fine.

But after that we can't reset the BOOT_MCU bit back to '0'. The BOOT_MCU bit

remains on '1' and we can't reach the HOLD_BOOT state again.

Is there any ideas why the BOOT_MCU bit remains on '1' ?!

ArnaudP · ‎2021-04-07

Hello,

In ST distribution, the BOOT_MCU is managed in the secure mode, by OP-TEE or TF-A depending on your configuration.

In this case the linux stm32_rproc accesses to the HOLD_BOOT through the SCMI, and can not update it directly.

Specific code is used in TF-A and OP-TEE to manage it, the BOOT_MCU bit is not managed in the same way that other reset.

For instance for TF-A the code is implemented here:

Do you update something in TF-A, OP-TEE, Linux remoteproc or in the m4_rproc devicetree node?

Could you also specify the version of the distribution you are using for your development?