2024-10-11 03:14 AM - edited 2024-10-11 07:41 AM
Hi,
I work on a custom board using a DHCOR SoM with a STM32MP157C SoC. I setup the TF-A + OP-TEE boot chain for the secure boot and I managed to boot on the linux stm32 (v6.1). The board hangs at reboot :
[ 1480.467975] reboot: Restarting system
I/TC: Forced system reset
To reboot the board, the OP-TEE OS writes '1' in the RCC_MP_GRSTCSETR register bit 0. If TZEN = '1', this register can only be modified in secure mode. TZEN is set to '1' by writing a '1' in the RCC_TZCR register bit 0, which is done by the rcc driver if the 'compatible' property is set to "st,stm32mp1-rcc-secure" in the OP-TEE device tree. The RCC is switched in "secure mode", which is confirmed at boot :
D/TC:0 0 check_rcc_secure_configuration:347 RCC/PWR secure hardening: TZEN enable, MCKPROT enable
From the documentation, chapter 10.4.14 RCC TrustZone function :
"The bit TZEN allows the RCC and the PWR to be switched in secure mode. The RCC_TZCR register is only accessible by a secure access. When TZEN = ‘1’, some RCC and PWR registers can only be modified using secure accesses. The reading of registers is always allowed."
The secure attribute of the RCC_MP_GRSTCSETR register is "S", which means from the table 74 :
"This register can only be written in secure mode when TZEN = ‘1’ or when TZEN AND MCKPROT = ‘1’."
What I understand is that by setting RCC in secure mode with TZEN = '1' write access requires to be in secure mode. But what is the "secure mode" here ? What did I miss in my configuration ?
Regards,
Pierre-Loup
2024-10-30 08:28 AM
My RCC configuration seems to be correct. In fact, it is possible to reboot from the non-secure world with u-boot.
I can reproduce the hang by removing the 'st,mask-reset' property of the buck3 PMIC vdd regulator in the OP-TEE device tree. So I my guess is the vdd regulator is shutdown when it is Linux asking for a reboot, preventing the board to reboot (akin to a power off).
Given that the PMIC and reboot is the scope of the OP-TEE, what can cause this behavior ?
2024-10-30 09:51 AM
Hi @Pierre-Loup
mask reset is to avoid VDD power cycling upon STPMI1 detects NRST low.
If reboot working by removing the mask reset on VDD, it might be highlighting that your boot flash needs a VDD power cycle to correctly respond to BootROM. This is usually the case for SD-Card when used in UHS-I mode and maybe some Serial-Flash. eMMC are usually not requiring power cycle.
What is your boot Flash ?
Could you please check if 'hang' mean bootrom is failing to get TF-A from the Flash using this trace dump : https://wiki.st.com/stm32mpu/wiki/STM32_MPU_ROM_trace_analyzer#On_STM32MP1-lines
Regards.
2024-10-31 03:37 AM
Hi @PatrickF,
My boot flash is the eMMC. The BootROM load the TF-A from the hardware boot partition of the eMMC (selected by the eMMC EXT_CSD register).
@PatrickF wrote:If reboot working by removing the mask reset on VDD [...]
My explanation was perhaps not clear, it is the opposite. With mask reset on VDD (in OP-TEE device tree), the board reboot from u-boot but not from Linux. Without mask reset, the board do not reboot from u-boot and Linux (same behavior). The device tree of U-boot and Linux are similar.
For the trace analyser I have to use the ST-LINK as the debugger ?