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@verdin-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@9cb00000 > > [ 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@9cb00000 > > [ 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. > >
