OpenAMP Demo Failing to Suspend A7 on OSD32MP1-BRK

[mwayned]

I am attempting to show the “wake up mail box functionality” running on the OpenSTLinux image provided from the getting started page, files located on the system here:

/usr/local/Cube-M4-examples/STM32MP157C-DK2/Applications/OpenAMP/OpenAMP_TTY_echo_wakeup

/usr/local/Cube-M4-examples/STM32MP157C-EV1/Applications/OpenAMP/OpenAMP_TTY_echo_wakeup

Note: the README file at this location details the following commands used to attempt to put different portions of the IC to sleep.

The M4 processor can be stopped via ‘echo “*stop” >/dev/ttyRPMSG0’ and started via ‘echo “start” >/dev/ttyRPMSG0’, as well as properly delays for 20 seconds than echos “delay” upon receiving ‘echo “*delay” >/dev/ttyRPMSG0’.

I have run “echo enabled > /sys/devices/platform/soc/4c001000.mailbox/power/wakeup” to enable the A7 to wakeup from an external (to the processor) line toggled by the M4.

However ‘systemctl suspend’, which should put the A7 into sleep mode, instead results in this:

[ 776.838204] Filesystems sync: 0.010 seconds[ 776.846268] Freezing user space processes … (elapsed 0.002 seconds) done.[ 776.854679] OOM killer disabled.[ 776.859069] Freezing remaining freezable tasks … (elapsed 0.001 seconds) done.[ 776.866692] printk: Suspending console(s) (use no_console_suspend to debug)?[ 777.058781] stm32-dma 48001000.dma: Suspend is prevented by Chan 1[ 777.058814] PM: dpm_run_callback(): platform_pm_suspend+0x0/0x48 returns -16[ 777.058826] PM: Device 48001000.dma failed to suspend: error -16[ 777.058837] PM: Some devices failed to suspend, or early wake event detected[ 777.078745] dwc2 49000000.usb-otg: resuming usb gadget configfs-gadget[ 777.197004] dwc2 49000000.usb-otg: new device is high-speed[ 777.237999] dwc2 49000000.usb-otg: new address 57[ 777.285164] OOM killer enabled.[ 777.288276] Restarting tasks … done.[ 777.296113] PM: suspend exit[ 777.367021] dwc2 49000000.usb-otg: new device is high-speed[ 777.371186] dwc2 49000000.usb-otg: dwc2_hsotg_enqueue_setup: failed queue (-11) [ 782.919298] dwc2 49000000.usb-otg: new device is high-speed[ 782.923442] dwc2 49000000.usb-otg: dwc2_hsotg_enqueue_setup: failed queue (-11) [ 788.539504] dwc2 49000000.usb-otg: new device is high-speed[ 788.543648] dwc2 49000000.usb-otg: dwc2_hsotg_enqueue_setup: failed queue (-11) [ 794.159812] dwc2 49000000.usb-otg: new device is high-speed[ 794.163955] dwc2 49000000.usb-otg: dwc2_hsotg_enqueue_setup: failed queue (-11) *delay
(note the delay message from the M4!)
dmesg gives slightly more details:

stm32-dma 48001000.dma: Suspend is prevented by Chan 1

PM: dpm_run_callback(): platform_pm_suspend+0x0/0x48 returns -16

PM: Device 48001000.dma failed to suspend: error -16

PM: Some devices failed to suspend, or early wake event detected

I realize the BRK is not the dev kits in the two file paths above (STM32MP157C-DK2, STM32MP157C-EV1), however they are included in both the OpenSTLinux and Debian images for the OSD32MP1-BRK. Is there a fix that would allow the A7 to properly suspend? It seems the DMA system is not in a state to sleep.

Thanks,
Matthew

[Neeraj Dantu]

Matthew,

This happens because of the device tree configuration for the BRK. You will encounter the same error if you use the DK2 if you boot with the default device tree: ‘stm32mp157c-dk2.dtb’. If you use stm32mp157c-dk2-m4-examples.dtb, you will be able to run the example without errors. Please take a look at the device tree here: https://github.com/STMicroelectronics/linux/blob/v5.10-stm32mp/arch/arm/boot/dts/stm32mp157c-dk2-m4-examples.dts.

Best,

Neeraj

[mwayned]

Neeraj,

Thank you for the help, sorry for the slow reply.

I copied the dtb file you suggested over the existing one with this command:

cp kernel/linux-4.19.94/arch/arm/boot/dts/stm32mp157c-dk2-m4-examples.dtb /media/<user>/bootfs/osd32mp1-red.dtb

the boot now hangs at ” Waiting for root device /dev/mmcblk1p6…”

Copying the correct osd32mp1-red.dtb back into place results in proper booting again.

Should I investigate differences between stm32mp167a-dk1.dts (the file that defines the pins and sd card devices for stm32mp157c-dk2-m4-examples.dtb) and osd32mp1-red.dts?

Thanks,
Matthew

[Neeraj Dantu]

Matthew,

Because the hardware configuration for DK2 and RED are different, you will not be able to use the DK2 device tree to implement the M4 demo. You will need to include the device tree nodes in the stm32mp157c-dk2-m4-examples.dts file in osd32mp1-red.dts and recompile the device tree to be able to exercise the M4 peripherals.

Please take a look at https://wiki.st.com/stm32mpu-ecosystem-v1/wiki/How_to_compile_the_device_tree_with_the_Developer_Package.

Best

Neeraj

[mwayned]

Neeraj,

Could you specify which nodes in the stm32mp157c-dk2-m4-examples.dts should be integrated into the osd32mp1-red.dts in order to get these examples functioning?
I have attempted many high level merges of this file into or taking the place of the osd32mp1-red.dts file without success.

Thanks,
Matthew

[Eshtaartha Basu]

Hello Matthew,

Yes, please carefully investigate the differences between DK2 DT and RED DT. Suitably copy only those nodes that would be required by M4 examples from stm32mp157c-dk2-m4-examples.dts file to RED DT. Button and LED pinmux also needs to be updated to match RED hardware. Then, rebuild DT to use it.

You will have to copy/overwrite the following DT nodes from M4 examples DT to RED DT:

All nodes from line 28 (&dmamux1) of https://github.com/STMicroelectronics/linux/blob/v4.19-stm32mp/arch/arm/boot/dts/stm32mp157c-dk2-m4-examples.dts to line 129 (&timers1)

Line 116: PH7 is not connected to an LED on the RED versus DK2. Replace PH7 with PF3 and ensure JP12 is in pos 1-2.
Line 122: PE9 is available as pin20 of DSI connector X8 on the RED

You also may have to take care of any missing phandle references in device tree hierarchy. These app notes should help you take care of phandle references and also help you to better configure device trees and system resources:

OSD335x Lesson 2: Linux Device Tree

https://wiki.st.com/stm32mpu/wiki/How_to_configure_system_resources

[mwayned]

All,

Thank you for your help. I have spliced lines 28 to 129 of the stm32mp157c-dk2-m4-examples.dts at the end of the osd32mp1-red.dts file and rebuilt the dtb file.
With this change in place I see various peripherals drivers failing on startup due to the now different DMA configuration (this is good, I don’t need those peripherals and it shows my device tree changes are on board). I can still control putting the M4 to sleep/waking it up as I can see the current decrease/increase respectively. However when trying to put the A7s to sleep the “systemctl suspend” command has no effect on power consumption (or the terminal interactivity, can continue to interact with the shell). If I call “systemctl suspend” again I get this message:

Failed to suspend system via logind: There’s already a shutdown or sleep operation in progress

dmesg outputs this:
[ 353.395298] PM: suspend entry (deep)
[ 353.397488] PM: Syncing filesystems … done.

Is the “suspend” script located at /etc/systemd/sleep.conf configured to properly sleep? I uncommented lines in this file pertaining to suspend

AllowSuspend=yes
SuspendState=mem standby freeze

but with or without those lines the “systemctl suspend” command has no effect on the system, and upon subsequent calls will result in the “Failed to suspend…. already a shutdown or sleep operation in progress” error message from above.

Is there a simpler way to demonstrate the low power modes of both the M4 and the A7 that I am missing?

Thanks,
Matthew

[Neeraj Dantu]

Matthew,

Which Kernel version are you using?

If you are using a 4.19 kernel, that is probably the reason you are seeing the behavior you are seeing. The low power modes are not properly supported in this kernel. You should see the difference between the RED board and the BRK. BRK has no trouble entering a low power state as it uses 5.4 Kernel. We are working on upgrading both RED and BRK to the latest (5.10) kernel in the coming weeks. You should see a release in 9/2021.

Best,

Neeraj

[mlarkin]

Neeraj –

Are you still projecting a release in 9/2021?

Just wondering as there is only a week left to 9/2021 and we have been waiting quite some time for said updates so that the OSD boards are inline with STMicro releases.

[Neeraj Dantu]

mlarkin,

We apologize for the delay. You should see a BRK release this week followed by a RED release.

Best,

Neeraj

[Geoff Danielson]

Neeraj,

I’m following up on this. We have flashed STlinux to the SD card, and it boots fine.

When I go through the steps to do the demo, this is what happens:

root@stm32mp1:/usr/local/Cube-M4-examples/STM32MP157C-DK2/Applications/OpenAMP/OpenAMP_TTY_echo_wakeup# ./fw_cortex_m4.sh start
fw_cortex_m4.sh: fmw_name=OpenAMP_TTY_echo_wakeup.elf
[ 816.684551] remoteproc remoteproc0: powering up m4
[ 816.689156] remoteproc remoteproc0: Booting fw image OpenAMP_TTY_echo_wakeup.elf, size 228192
[ 816.697167] mlahb:m4@10000000#vdev0buffer: assigned reserved memory node vdev0buffer@10042000
[ 816.705969] virtio_rpmsg_bus virtio0: creating channel rpmsg-tty-channel addr 0x0
[ 816.713061] virtio_rpmsg_bus virtio0: rpmsg host is online
[ 816.719062] rpmsg_tty virtio0.rpmsg-tty-channel.-1.0: new channel: 0x400 -> 0x0 : ttyRPMSG0
[ 816.726923] mlahb:m4@10000000#vdev0buffer: registered virtio0 (type 7)
[ 816.733524] remoteproc remoteproc0: remote processor m4 is now up

root@stm32mp1:/usr/local/Cube-M4-examples/STM32MP157C-DK2/Applications/OpenAMP/OpenAMP_TTY_echo_wakeup# echo enabled > /sys/devices/platform/soc/4c001000.mailbox/power/wakeup
root@stm32mp1:/usr/local/Cube-M4-examples/STM32MP157C-DK2/Applications/OpenAMP/OpenAMP_TTY_echo_wakeup# echo “*delay” > /dev/ttyRPMSG0
root@stm32mp1:/usr/local/Cube-M4-examples/STM32MP157C-DK2/Applications/OpenAMP/OpenAMP_TTY_echo_wakeup# systemctl suspend
root@stm32mp1:/usr/local/Cube-M4-examples/STM32MP157C-DK2/Applications/OpenAMP/OpenAMP_TTY_echo_wakeup#
[ 866.198175] PM: suspend entry (deep)
[ 866.211649] Filesystems sync: 0.011 seconds
[ 866.226474] Freezing user space processes … (elapsed 0.002 seconds) done.
[ 866.234603] OOM killer disabled.
[ 866.237711] Freezing remaining freezable tasks … (elapsed 0.001 seconds) done.
[ 866.245290] printk: Suspending console(s) (use no_console_suspend to debug)
[ 866.372938] dwc2 49000000.usb-otg: suspending usb gadget configfs-gadget
[ 866.439066] stm32-dma 48001000.dma: Suspend is prevented by Chan 1
[ 866.439096] PM: dpm_run_callback(): platform_pm_suspend+0x0/0x48 returns -16
[ 866.439107] PM: Device 48001000.dma failed to suspend: error -16
[ 866.439118] PM: Some devices failed to suspend, or early wake event detected
[ 866.458849] dwc2 49000000.usb-otg: resuming usb gadget configfs-gadget
[ 866.661605] OOM killer enabled.
[ 866.664755] Restarting tasks … done.
[ 866.684270] PM: suspend exit

root@stm32mp1:/usr/local/Cube-M4-examples/STM32MP157C-DK2/Applications/OpenAMP/OpenAMP_TTY_echo_wakeup#

I searched around on this issue and came to this page: https://community.st.com/s/question/0D53W00000rYk3ySAC/openampttyechowakeup-examples-dont-work

So, how do I “select the right Linux boot mode” on the -BRK board? I don’t see a dtb for the BRK board specific to the m4 examples, but I also don’t know how I’d start selecting one in uboot either.

Suggestions?

[Neeraj Dantu]

Geoff,

2 things to note here:

1. You should be using the latest OpenSTLinux release from Octavo. You can generate the latest image by following instructions here: https://github.com/octavosystems/meta-octavo-osd32mp1

2. OSD32MP1-BRK has its own device tree. You will need to regenerate device tree binary after modifications that allow the demo to work on the BRK. Please see earlier post here: https://octavosystems.com/forums/topic/openamp-demo-failing-to-suspend-a7-on-osd32mp1-brk/#post-11610

Best,
Neeraj

[Author]

Posts