STM32MP157 not exiting suspend to Linux

[adegrandcourt]

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

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

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"

[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?

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.

[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