Hello,
I'm working with the STM32MP15 and have found a problem with USART1 during the boot process on a secure boot enabled (TZEN) hardware. The system freezes when U-Boot tries to reset USART1.
The problem is with the RCC_APB5RSTSETR register (0x188). This register, including the USART1RST bit, can only be changed in secure mode (by OP-TEE) because of the TZEN restriction. However, U-Boot (non-secure world) attempts to modify this register by default. This is because of arch/arm/dts/stm32mp15-u-boot.dtsi:
&usart1 {
resets = <&rcc USART1_R>;
};
The ST devkits use UART4RST, this is not TZEN protected. But USART1 is and that causes a bus error:
The system freezes.
I solved this by using SCMI (so that OP-TEE does the actual reset):
resets = <&scmi_reset RST_SCMI_USART1>;
Initially, I thought to put this change in my stm32mp153c-custom-scmi.dtsi, but that ...u-boot.dtsi overrides it. So, the change needs to go in a stm32mp153c-custom-u-boot.dtsi.
It took me half a day to figure this all out. To help prevent this in the future, I suggest:
- Maybe stm32mp15-u-boot.dtsi should have a note saying the RCC for USART1_R can only be changed when TZEN is off?
- How about adding an error message in stm32-reset.c for attempts to change TZEN-protected registers?
- Is creating a stm32mp153c-custom-scmi-u-boot.dtsi file a good idea for better organization?
- Is ST planning to reorganize the STM32MP devkit DTS files to make them less confusing?
I'm looking forward to hearing your thoughts and suggestions.
Thanks
