linux-kernel - Re: System can not go into suspend when remoteproc is probed on AM62X

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <prvj5e2y3ruqgn35auolaia5zwoahtfecosumwshappy32ylrq@eivdt62vp7rh>
Date: Tue, 5 Aug 2025 15:41:28 -0300
From: Hiago De Franco <hiagofranco@...il.com>
To: Andrew Davis <afd@...com>
Cc: Beleswar Prasad Padhi <b-padhi@...com>, 
	linux-remoteproc@...r.kernel.org, Bjorn Andersson <andersson@...nel.org>, 
	Mathieu Poirier <mathieu.poirier@...aro.org>, Suman Anna <s-anna@...com>, linux-kernel@...r.kernel.org, 
	Hiago De Franco <hiago.franco@...adex.com>
Subject: Re: System can not go into suspend when remoteproc is probed on AM62X

On Mon, Aug 04, 2025 at 04:14:26PM -0500, Andrew Davis wrote:
> On 8/4/25 2:31 PM, Hiago De Franco wrote:
> > Hi Andrew,
> > 
> > Sorry for the delay, I am back this week, I was testing the patches and
> > removing the ping was not enough, there is one extra message being sent,
> > which is the k3_rproc_kick() from ti_k3_common.c. This one is a callback
> > from remoteproc_virtio.c.
> > 
> 
> So tracing back, looks like this message will be added to the mailbox
> when Linux tries to start communication with the remote core, and that
> happens if the firmware advertises vrings in its resource table.

Got it, thanks for explaining.

> 
> > I belive this one is necessary to make the firmware works, but with the
> > hello world demo, I still have the issue where I can not go into suspend
> 
> Which "hello world demo" is this? In Zephyr, we do not add the VDEV to
> the resource table if the firmware does not intend to communicate[0].
> But MCU+SDK firmware might add these unconditionally, I'm not sure. You
> could check what is in the table with:
> 
> $ readelf -x .resource_table <your_firmware.elf>
> 
> and empty one might look like:
> 
> > Hex dump of section '.resource_table':
> >   0xa3100000 01000000 00000000 00000000 00000000 ................
> 
> one with VDEV will be much longer.

Correct Andrew, indeed by removing the ping and testing with Zephyr
Hello World example, it works fine, the resource table is empty.

I was testing the hello world from TI mcu_plus_sdk_am62x_10_00_00_14,
and first it was not working, I got a -22 from the remoteproc driver,
and no .resource_table is present at all.

So to fix this I enabled IPC sysconfig, which created a non-empty
resource table into the ELF and made the hello world work, but broke
suspend. Now it is clear why this is happening.

On the AM62X Academy it mentions a empty resource table, but it
reccomends to just enable IPC instead [0].

Thanks for the help, I will then create the patch to remove the ping.

[0] https://dev.ti.com/tirex/explore/node?node=A__AcD0ahYJlxouUnP8vWuDYw__AM62-ACADEMY__uiYMDcq__LATEST&placeholder=true

Best regards,
Hiago.

> 
> Andrew
> 
> [0] https://github.com/zephyrproject-rtos/zephyr/blob/main/lib/open-amp/resource_table.h#L34
> 
> > mode. Removing both mbox_send_message() calls makes the suspend work
> > again:
> > 
> > root@...din-am62-15479173:~# dmesg | grep -i -E "remoteproc|rproc|omap-mailbox|hfranco"
> > [    0.000000] Kernel command line: root=PARTUUID=096221e5-02 ro rootwait console=tty1 console=ttyS2,115200 dyndb
> > g="file ti_k3_common.c +p; file remotecore_proc.c +p; file remoteproc_virtio.c +p"
> > [   10.520920] omap-mailbox 29000000.mailbox: omap mailbox rev 0x66fc9100
> > [   10.711357] k3-m4-rproc 5000000.m4fss: assigned reserved memory node m4f-dma-memory@...00000
> > [   10.753040] k3-m4-rproc 5000000.m4fss: configured M4F for remoteproc mode
> > [   10.793640] remoteproc remoteproc0: 5000000.m4fss is available
> > [   10.856735] remoteproc remoteproc0: powering up 5000000.m4fss
> > [   10.895961] remoteproc remoteproc0: Booting fw image am62-mcu-m4f0_0-fw, size 451080
> > [   11.000752] rproc-virtio rproc-virtio.4.auto: assigned reserved memory node m4f-dma-memory@...00000
> > [   11.101614] rproc-virtio rproc-virtio.4.auto: registered virtio0 (type 7)
> > [   11.151665] remoteproc remoteproc0: remote processor 5000000.m4fss is now up
> > [   12.123724] remoteproc remoteproc1: 30074000.pru is available
> > [   12.171118] remoteproc remoteproc2: 30078000.pru is available
> > [   12.337287] remoteproc remoteproc0: vring0: va 00000000cabe42be qsz 256 notifyid 0
> > [   12.337337] remoteproc remoteproc0: vring1: va 00000000a651968a qsz 256 notifyid 1
> > [   12.348543] remoteproc remoteproc0: kicking vq index: 0
> > [   12.348559] hfranco: sending msg 0x0, name mbox-m4-0
> > [ 2514.508396] remoteproc remoteproc0: stopped remote processor 5000000.m4fss
> > [ 2518.010399] omap-mailbox 29000000.mailbox: fifo 1 has unexpected unread messages
> > [ 2518.010433] omap-mailbox 29000000.mailbox: PM: dpm_run_callback(): platform_pm_suspend returns -16
> > [ 2518.010461] omap-mailbox 29000000.mailbox: PM: failed to suspend: error -16
> > 
> > In this case, I was wondering if we should drop the messages for now,
> > until we have the routine to save the messages first. Any suggestion you
> > might have?
> > 
> > Thanks for the help,
> > Hiago.
> >