512-861-3400Log inCreate Account

OpenAMP Demo Failing to Suspend A7 on OSD32MP1-BRK

Forums › Devices › OSD32MP15x › OpenAMP Demo Failing to Suspend A7 on OSD32MP1-BRK

Tagged: 

Viewing 9 reply threads
  • Author
    Posts
    • May 27, 2021 at 5:07 pm #11584
      Matthew DeKoningmwayned
      Participant

        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

      • June 3, 2021 at 1:32 pm #11602
        Neeraj Dantu
        Moderator

          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

        • June 8, 2021 at 1:36 pm #11604
          Matthew DeKoningmwayned
          Participant

            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

          • June 10, 2021 at 12:50 pm #11610
            Neeraj Dantu
            Moderator

              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

            • July 28, 2021 at 5:20 pm #11744
              Matthew DeKoningmwayned
              Participant

                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

              • August 15, 2021 at 7:44 pm #11774
                Eshtaartha Basu
                Moderator

                  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

                • August 25, 2021 at 10:51 am #11782
                  Matthew DeKoningmwayned
                  Participant

                    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

                  • August 29, 2021 at 3:36 pm #11795
                    Neeraj Dantu
                    Moderator

                      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

                      • September 24, 2021 at 10:11 am #11871
                        Matthew Larkinmlarkin
                        Participant

                          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.

                        • October 4, 2021 at 10:04 am #11881
                          Neeraj Dantu
                          Moderator

                            mlarkin,

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

                            Best,

                            Neeraj

                        • March 18, 2022 at 3:00 pm #12173
                          Geoff DanielsonGeoff Danielson
                          Participant

                            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?

                          • March 23, 2022 at 10:22 am #12201
                            Neeraj Dantu
                            Moderator

                              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
                          Viewing 9 reply threads
                          • You must be logged in to reply to this topic.

                          Octavo Systems LLC all rights reserved
                          OCTAVO is registered in the U.S. Patent and Trademark Office. OSD, C-SiP, and the Octavo Logo are trademarks of Octavo Systems LLC.