Skip to main content
Visitor II
March 29, 2021
Question

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

  • March 29, 2021
  • 1 reply
  • 793 views

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' ?!  

    This topic has been closed for replies.

    1 reply

    ST Employee
    April 7, 2021

    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:

    https://github.com/STMicroelectronics/arm-trusted-firmware/blob/d0faf393e7c68874ec283d95b1d6ff7cb77c76de/drivers/st/reset/stm32mp1_reset.c#L71

    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?