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

[PatrickF]

---

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

---

Yes, the HW should ensure the eMMC RSTn (it could be simply tied to NRST of STM32MP1/STPMIC1). Enabling it in eMMC is needed as well.

Personally, I prefer to ensure a power cycle on eMMC on each NRST toggling.

This is done automatically with STPMIC1 (except VDD/Buck3 were power cycle is 'masked' in STPMIC1 registers upon TF-A boot in our default SW deliveries).

On our MB1263 board, the eMMC VCC supply is connected to 3V3/Buck4 on purpose.

Regards.

[Pierre-Loup]

Thanks for your explanation,

I have read the MB1263 eMMC shematic. The Vcc is connected to V3v3/Buck4, and Vccq to Vdd/Buck4. Since the latter is masked to avoid power cycles, only the Vcc is powered-down during NRST toggling. According to the JEDEC power cycling standard, this puts the eMMC to the pre-idle state:

"If VCC or VCCQ are below 0.5 V for longer than 1 ms, the slave shall always return to the pre-idle state, and
perform the appropriate boot behavior, as appropriate."

But in our custom board, the Vcc and Vccq is connected to V3v3/Buck4:

Thus, on power cycling Vcc and Vccq are powered-down. Vcc and Vccq shoud not use the same supply and only Vcc should be powered-down from my understanding. This seems to be the reason why our eMMC does not return to the pre-idle state ?

Enable eMMC RSTn is the solution, but I want to know the root cause of our reboot problem.

Regards,

[PatrickF]

Maybe when both VCCQ and VCC are shutdown, the time for the eMMC to 'restart' is longer and does not accept the first CMD0 command sent few tens of ms after power-up.

If this is the root cause, I see two options:

Reprogramming STPMIC1 NVM to have buck4 in rank1 (it is rank3 by default) might give slightly more time (+3ms).

Increasing NRST capacitor could also help a bit for few ms (e.g. from 10nF to 100nF).

Regards.

[Pierre-Loup]

I thought the same thing.

I think the best solution is to change the Vccq power supply to Vdd/Buck4 for our next board revision. At this time, enabling eMMC RSTn is a workaround.

Thanks a lot for your help,

Regards

[PatrickF]

---

I think the best solution is to change the Vccq power supply to Vdd/Buck4 for our next board revision.

---

I think you talk about eMMC Vccq tied to MP15 VDD/Buck3 (as on MB1263).

[Pierre-Loup]

Yes, I just inverted. Vccq => Vdd/Buck3, and Vcc => V3v3/Buck4.