Skip to main content
P
Pierre-Loup
Graduate
October 11, 2024
Solved

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

  • October 11, 2024
  • 2 replies
  • 3260 views

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

    This topic has been closed for replies.
    Best answer by Pierre-Loup

    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,

     

    2 replies

    P
    Pierre-LoupAuthor
    Graduate
    October 30, 2024

    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 ?

    P
    PatrickF
    Technical Moderator
    October 30, 2024

    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.

     

    P
    Pierre-LoupAuthor
    Graduate
    October 31, 2024

    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 ?

    P
    Pierre-LoupAuthor
    Graduate
    December 2, 2024

    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,

     

    P
    PatrickF
    Technical Moderator
    December 2, 2024

    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).

    PatrickF_0-1733160773303.png

    PatrickF_1-1733160790551.png

    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.

    Terms & ConditionsAccessibility statement