i.MX ProcessorsのトピックRe: RPMsg-Lite rpmsg_lite_alloc_tx_buffer Blocks or Faults When A55 is Suspended

RPMsg-Lite rpmsg_lite_alloc_tx_buffer Blocks or Faults When A55 is Suspended

PBouchand — Wed, 30 Jul 2025 12:09:34 GMT

Hello,

I'm encountering an issue with the RPMsg-Lite communication between the Cortex-M33 and the Cortex-A55 on the i.MX93.

When the A55 enters suspend mode, any call to rpmsg_lite_alloc_tx_buffer() on the M33 side either blocks indefinitely or results in a hard fault, depending on the exact circumstances. The function rpmsg_lite_is_link_up() continues to return true, which prevents detecting this state cleanly.

The underlying issue appears to be that vq->vq_ring.avail remains mapped, but accessing vq->vq_ring.avail->idx triggers a fault or a hang. There seems to be no safe mechanism to detect that the A55 has suspended and that communication is no longer reliable.

This makes it difficult to ensure robustness on the M33 side. Ideally, we would like rpmsg_lite_alloc_tx_buffer() to either return an error or timeout safely without crashing or blocking indefinitely when the A55 is suspended.

Do you have any recommendation or workaround to safely handle this case, or is there an update planned to address this situation?

Best regards,

Patrice

Re: RPMsg-Lite rpmsg_lite_alloc_tx_buffer Blocks or Faults When A55 is Suspended

Manuel_Salas — Tue, 05 Aug 2025 21:03:47 GMT

Hello @PBouchand

I hope you are doing very well.

Is this just happening when Cortex A55 is in suspend?

Could you please share steps to replicate it by my side?

Best regards,

Salas.

Re: RPMsg-Lite rpmsg_lite_alloc_tx_buffer Blocks or Faults When A55 is Suspended

PBouchand — Mon, 25 Aug 2025 12:08:38 GMT

Hello,

Yes, it always happens when the A55 is in suspend mode. It’s really easy to reproduce:

Use an M33 firmware that regularly sends messages to the A55 (which it can receive via /dev/ttyRPMSG ttyRPMSG30) or triggered by a key press on its debug console.
Put the A55 into suspend mode using echo mem > /sys/power/state.
As soon as the M33 tries to send a message after the suspend mode, it gets stuck at rpmsg_lite_alloc_tx_buffer, and the issue seems to be related to access to vq->vq_ring.avail->idx triggers.

I also have a related question: Is it possible on the A55 Linux side to know whether the M33 is in sleep mode?

Thanks.

Re: RPMsg-Lite rpmsg_lite_alloc_tx_buffer Blocks or Faults When A55 is Suspended

PBouchand — Mon, 01 Sep 2025 05:35:17 GMT

Hello,

Can someone shed some light on this topic?

Regards.

Re: RPMsg-Lite rpmsg_lite_alloc_tx_buffer Blocks or Faults When A55 is Suspended

Manuel_Salas — Thu, 04 Sep 2025 01:53:51 GMT

Hello,

You can try to change vdev0vring and vdevbuffer to SSRAM instead of DRAM.

As you can see on reference manual, DRAM is clock gated on deep sleep mode:

In the device tree of i.mx8ulp you can see those are configured in DRAM:

Best regards,

Salas.

Re: RPMsg-Lite rpmsg_lite_alloc_tx_buffer Blocks or Faults When A55 is Suspended

PBouchand — Thu, 04 Sep 2025 06:36:13 GMT

Hello,

Indeed, I’m using the Variscite DTS which defines:

vdev0vring0: vdev0vring0@87ee0000 { reg = <0 0x87ee0000 0 0x8000>; no-map; }; vdev0vring1: vdev0vring1@87ee8000 { reg = <0 0x87ee8000 0 0x8000>; no-map; }; vdev1vring0: vdev1vring0@87ef0000 { reg = <0 0x87ef0000 0 0x8000>; no-map; }; vdev1vring1: vdev1vring1@87ef8000 { reg = <0 0x87ef8000 0 0x8000>; no-map; };

I haven’t tried it yet, but your solution really looks promising!

Thank you very much.

Re: RPMsg-Lite rpmsg_lite_alloc_tx_buffer Blocks or Faults When A55 is Suspended

Manuel_Salas — Fri, 05 Sep 2025 14:44:25 GMT

Hello!

Thank you for the clarification. But actually, the address used in the Variscite Device Tree is also for DRAM:

You can try with SRAM.

Best regards,

Salas.

Re: RPMsg-Lite rpmsg_lite_alloc_tx_buffer Blocks or Faults When A55 is Suspended

PBouchand — Mon, 08 Sep 2025 09:03:43 GMT

Hello,

I tried to set up the vdev vrings as you suggested:

reserved-memory { #address-cells = <2>; #size-cells = <2>; ranges; ethosu_mem: ethosu_region@88000000 { compatible = "shared-dma-pool"; reusable; reg = <0x0 0x88000000 0x0 0x8000000>; }; vdev0vring0: vdev0vring0@aff00000 { reg = <0 0xaff00000 0 0x8000>; no-map; }; vdev0vring1: vdev0vring1@aff08000 { reg = <0 0xaff08000 0 0x8000>; no-map; }; vdev1vring0: vdev1vring0@aff10000 { reg = <0 0xaff10000 0 0x8000>; no-map; }; vdev1vring1: vdev1vring1@aff18000 { reg = <0 0xaff18000 0 0x8000>; no-map; }; rsc_table: rsc-table@2021e000 { reg = <0 0x2021e000 0 0x1000>; no-map; }; vdevbuffer: vdevbuffer@87f00000 { compatible = "shared-dma-pool"; reg = <0 0x87f00000 0 0x100000>; no-map; }; ele_reserved: ele-reserved@87de0000 { compatible = "shared-dma-pool"; reg = <0 0x87de0000 0 0x100000>; no-map; }; };

With the following in the M33 code:

#define VDEV0_VRING_BASE (0xAFF00000U) #define VDEV1_VRING_BASE (0xAFF10000U)

The communication works fine when the A55 is not in suspend, but the M33 always crashes on rpmsg_lite_alloc_tx_buffer when the A55 is in suspend mode.

Have you tested this on your side? Is this supposed to work?

Thanks for your time and help.

Re: RPMsg-Lite rpmsg_lite_alloc_tx_buffer Blocks or Faults When A55 is Suspended

Manuel_Salas — Wed, 10 Sep 2025 17:30:53 GMT

Hello.

As I said before, that address is not SRAM. You can use the Shared SRAM:

Please take as reference the sai_low_power_audio example inside the SDK.

There you can see the linker file pointing to the SRAM:

Best regards,

Salas.