RPMsg-Lite rpmsg_lite_alloc_tx_buffer Blocks or Faults When A55 is Suspended

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

RPMsg-Lite rpmsg_lite_alloc_tx_buffer Blocks or Faults When A55 is Suspended

242 Views
PBouchand
Contributor I

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

 

0 Kudos
Reply
5 Replies

151 Views
PBouchand
Contributor I

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.

 

0 Kudos
Reply

53 Views
PBouchand
Contributor I

Hello,

Can someone shed some light on this topic?

Regards.

 

0 Kudos
Reply

28 Views
Manuel_Salas
NXP TechSupport
NXP TechSupport

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:

Manuel_Salas_0-1756950683418.png

 

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

Manuel_Salas_1-1756950780006.pngManuel_Salas_2-1756950795515.png

 

Best regards,

Salas.

0 Kudos
Reply

20 Views
PBouchand
Contributor I

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.

 

0 Kudos
Reply

211 Views
Manuel_Salas
NXP TechSupport
NXP TechSupport

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.

0 Kudos
Reply