STM32MP157 not exiting suspend to Linux

[drew]

We are seeing some strange behavior on our stm32mp157 system exiting suspend mode.

This is not a 'weston' build, so we enter (deep) suspend mode by executing "echo mem > /sys/power/state" and the system powers down and enters low power.

root@stm32mp157:~ # echo deep > /sys/power/mem_sleep

root@stm32mp157:~ # echo mem > /sys/power/state

[  30.426284] PM: suspend entry (deep)

[  30.428793] PM: Syncing filesystems ... done.

[  30.477793] Freezing user space processes ... (elapsed 0.001 seconds) done.

[  30.484664] OOM killer disabled.

[  30.487814] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.

[  30.495358] Suspending console(s) (use no_console_suspend to debug)

When a wake up happens the processor wakes up and the TF-A detects that the processor exited STANDBY and is running from eMMC, however the system never executes the Linux system, it hangs after "Preparing exit to normal world"

NOTICE: CPU: STM32MP157C?? Rev.B

NOTICE: Model: STM32MP157C System

INFO:  Reset reason (0x810):

INFO:  System exits from STANDBY

INFO:  PMIC version = 0x10

INFO:  Using EMMC

INFO:   Instance 2

INFO:  Boot used partition fsbl1

NOTICE: BL2: v2.0-r3.0(debug):

NOTICE: BL2: Built : 14:46:55, Aug 21 2020

INFO:  BL2: Doing platform setup

INFO:  RAM: DDR3-1066/888 bin G 1x4Gb 533MHz v1.45

INFO:  BL2 runs SP_MIN setup

INFO:  BL2: Loading image id 4

INFO:  Loading image id=4 at address 0x2ffef000

INFO:  Image id=4 loaded: 0x2ffef000 - 0x30000000

INFO:  BL2: Skip loading image id 5

NOTICE: BL2: Booting BL32

INFO:  Entry point address = 0x2ffef000

INFO:  SPSR = 0x1d3

NOTICE: SP_MIN: v2.0-r3.0(debug):

NOTICE: SP_MIN: Built : 14:46:56, Aug 21 2020

INFO:  ARM GICv2 driver initialized

INFO:  stm32mp HSI (18): Secure only

INFO:  stm32mp HSE (20): Secure only

INFO:  stm32mp PLL2 (27): Secure only

INFO:  stm32mp PLL2_R (30): Secure only

INFO:  SP_MIN: Initializing runtime services

INFO:  SP_MIN: Preparing exit to normal world

*********** Halts here, doesn't go any further

I have tested suspend using an EV1 board, and confirmed that the TF-A messages are the same, but the EV1 does successfully re-start the Linux system.

Should the Linux system have some additional configuration to allow to execute after STANDBY?

[Olivier GALLIEN]

Hi @drew​ 

Sorry for late reply and miss of your post.

What the status today ?

Thanks

Olivier

[drew]

The system is still behaving as described. We have confirmed the problem exists with other boards and builds using STM32MP1xx

The system uses sources from the ST github repository.

• Kernel 4.19.125 (r3.2)
• uboot 2018.11 (r4.3)
• Arm Trusted Firmware (TF-A 2.0 r3.2)

These versions are almost the same as the EV1 board, but the EV1 board correctly exits suspend to RAM

[drew · Accepted solution]

It appears the problem is the STM32MP1 was entering the SUSPEND low power mode due to the selected wakeup sources.

The wakeup button for the PMIC was enabled as a wakeup source, however no core peripherals (I2C,UART,etc) were set as wakeup sources, thus the system entered STANDBY low power state rather than Stop or LP-Stop.

root@stm32mp1:~ # find /sys/devices/platform/ -name wakeup
/sys/devices/platform/soc/5c004000.rtc/power/wakeup
/sys/devices/platform/soc/49000000.usb-otg/usb1/power/wakeup
/sys/devices/platform/soc/40013000.i2c/power/wakeup
/sys/devices/platform/soc/5c002000.i2c/i2c-3/3-0033/5c002000.i2c:stpmic@33:onkey/power/wakeup
/sys/devices/platform/soc/5c002000.i2c/power/wakeup
/sys/devices/platform/soc/40012000.i2c/power/wakeup
/sys/devices/platform/soc/40010000.serial/power/wakeup
/sys/devices/platform/soc/40010000.serial/tty/ttySTM0/power/wakeup
/sys/devices/platform/soc/40018000.serial/power/wakeup
/sys/devices/platform/soc/40018000.serial/tty/ttySTM2/power/wakeup
/sys/devices/platform/soc/4c001000.mailbox/power/wakeup
/sys/devices/platform/soc/40015000.i2c/power/wakeup
root@stm32mp1:~ # cat `find /sys/devices/platform/ -name wakeup`
enabled
disabled
disabled
enabled
disabled
disabled
disabled
disabled
disabled
disabled
disabled
disabled
root@stm32mp1:~ #

App Note AN5109 says that STANDBY can only be exited with "Group3:BOR,Vbat mon,Temp mon,LSE CSS,RTC,TAMP,Wakeuppins". Because of this, the TF-A would wake up, but the Linux system would not wake up since the onkey is not on a wakeup pin.

Enabling a core peripheral such as I2C or UART wakeup sources makes the STM32MP1 enter Stop/LP-Stop which can be exited with "Group 1:USB,CEC, ETH,USART,I²C, SPI,LPTIM"

[rishi2]

Hi there,

You were able to solve this issue ? i am facing exactly the same behavior, when coming out of standby mode (blocks at):

INFO:  SP_MIN: Preparing exit to normal world

Was it the tfa issue or kernel device tree ? (i am really confused where the problem is)

Thanks, Rishi

[AKudr.1]

It`s not the best answer. It is not the topic answer at all. How TF-A wakes up, but loading Linux kernel fails?

I have similar problem. My board wakes up from CSTOP with UART wake source, but cannot wakes with RTC or WAKEUP PINs from STANDBY. TF-A output strange errors at the end:

ERROR:  Illegal access to 0xe0000000 in :

ERROR:     Non-Secure

ERROR:     Privilege

ERROR:     Read

And nothing goes on until watchdog reset.

Could anyone explain what is going wrong when I`m trying wakes from STANDBY?

[drew]

This is the correct answer, the wakeup sources were not enabled in the kernel and the system entered in to a lower power state than desired. TF-A wakes up but the kernel did not.

It appears your question relates to exiting STANDBY, enabling the RTC and WAKEUP pin sources, combined some some ERRORs about secure boot.

[AKudr.1]

Hello, Drew! Could you, please, explain me how could you wake only TF-A? I don`t understand this sentence. Thanks