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

501 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
8 Replies

410 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

312 Views
PBouchand
Contributor I

Hello,

Can someone shed some light on this topic?

Regards.

 

0 Kudos
Reply

287 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

279 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

238 Views
Manuel_Salas
NXP TechSupport
NXP TechSupport

Hello!

 

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

Manuel_Salas_0-1757083435077.png

 

You can try with SRAM.

 

Best regards,

Salas.

0 Kudos
Reply

157 Views
PBouchand
Contributor I

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.

0 Kudos
Reply

95 Views
Manuel_Salas
NXP TechSupport
NXP TechSupport

Hello.

 

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

Manuel_Salas_0-1757525283207.png

 

Please take as reference the sai_low_power_audio example inside the SDK.

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

Manuel_Salas_1-1757525435387.png

 

Best regards,

Salas.

 

0 Kudos
Reply

470 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