STM32MP15, cannot reboot in secure mode (TZEN = 1)

[Pierre-Loup]

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

[Pierre-Loup]

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 ?

[PatrickF]

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.

[Pierre-Loup]

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 ?

[Pierre-Loup]

I do not have an available JTAG on my custom board. But my board have a boot switch to choose the boot source : NOR, eMMC, etc. If I boot on Linux from the eMMC but before reboot I switch to NOR, the board reboot properly on the FSBL present on NOR.

---

---

---

eMMC are usually not requiring power cycle.

---

---

It seems that the eMMC is reset (power cycle), but only when rebooting from Linux, since the reset is working from u-boot. I have tried successfully to reboot on eMMC from a Linux stable (without secure boot chain). What can cause this behavior ?

Regards,

[PatrickF]

Hi,

May you check the version of your silicon ?
Rev.B (REV_ID = 0x2000) have some issues with many eMMC (Rev.B has bee produced in early days few years ago, but maybe some distri have still some old parts in stock).

all that are solved on Rev.Z (REV_ID = 0x2001).
Revision is mention on the package or usually listed during boot.

Please refer to ES0438 document.

Regards.

[PatrickF]

---

@Pierre-Loup wrote:

I do not have an available JTAG on my custom board.

---

If fail occur at bootrom, bootrom trace dump is required (JTAG is not mandatory as it could be done with only two wires SWD).

Regards,

Patrick

[Pierre-Loup · Accepted solution]

Hi,

I solved my issue. Is not related with linux stm and secure boot chain.

Our SoC revision is Rev.Z. Our custom board is based on the avenger96 (Rev.B) with the same eMMC (SDINBD4-8G), but the RST pin schematic is a bit different. We use discrete components for supplies.

I found your discussion about a similar problem (Rev.B), you said:

If you are using discrete components for supplies, you have to ensure your eMMC is reset when NRST pulse occur. This could be done either by doing a power cycle on the eMMC supplies or connecting NRST to the memory reset pin (need to permanently enable this pin in the eMMC RST_n_FUNCTION register)

---

Thus, I enable the eMMC reset pin in the EXTCSD register and now the board reboot on the eMMC. But I am not quite sure to understand the solution, so please if you can enlighten me.

The ROM code use the JEDEC boot sequence (CMD0) and get the boot sector on DAT0 pin. Maybe the mmc driver set our eMMC in an incompatible mode with the ROM code during the kernel startup (because before mmc driver probing the board reboot with a kernel panic, and not after). From the JEDEC spec, the eMMC HW RST pin is disabled by default.

Does the ROM code try to send a HW RST signal to the eMMC at boot time to set the eMMC in a pre-idle state ?

---

@PatrickF wrote:

---

@Pierre-Loup wrote:

I do not have an available JTAG on my custom board.

---

If fail occur at bootrom, bootrom trace dump is required (JTAG is not mandatory as it could be done with only two wires SWD).

---

The SWD wires are not accessible on our custom board.

Regards,

[PatrickF]

Hi,

BootROM do the following:

- CMD0 + 0xF0F0F0F0F0 (GO_PRE_IDLE_STATE). Which as JEDEC states, should be equivalent to an HW reset. RSTn should normally not being required (bit maybe some eMMC behave differently)

- Then uses 'CMD low' mechanism to get the boot sector.
something like this

Regards

[Pierre-Loup]

Thanks for your answer, I want to know what I am doing to avoid side effects.

So, if I understand your graph correctly, an RST_n signal occurs at boot time, but not initiated by the ROM code ?

As you said, maybe it is optional but required for our eMMC to be in pre-idle state to be used as a boot device. The HW reset chapter of the sandisk eMMC documentation just refers to the JEDEC spec :

And I read in the TI forum :

"The reason is when you use eMMC in your system it is most likely your boot device, hence you want maximum reliability for this device to be ready and in working order during every boot. This implies that you probably want hardware to control the eMMC reset signal in some way".

I cannot test on the avenger96 since the SoC Rev.B cannot boot on eMMC due to timeout issue, but I think the RST pin needs to be enabled for this eMMC.

Regards,