こんにちは、
i.MX93 上の Cortex-M33 と Cortex-A55 間の RPMsg-Lite 通信で問題が発生しています。
A55 がサスペンド モードに入ると、M33 側での rpmsg_lite_alloc_tx_buffer() への呼び出しは、正確な状況に応じて無期限にブロックされるか、ハード エラーが発生します。関数 rpmsg_lite_is_link_up() は引き続き true を返すため、この状態が明確に検出されません。
根本的な問題は、vq->vq_ring.availがマッピングされたままであるが、vq->vq_ring.avail->idxにアクセスすると、障害またはハングを引き起こします。A55 が停止し、通信が信頼できなくなったことを検出する安全なメカニズムは存在しないようです。
これにより、M33 側の堅牢性を確保することが難しくなります。理想的には、A55 が中断されたときに、rpmsg_lite_alloc_tx_buffer() がクラッシュしたり無期限にブロックしたりすることなく、安全にエラーを返すかタイムアウトするようにします。
このCASEを安全に処理するための推奨事項や回避策はありますか? また、この状況に対処するための更新が予定されていますか?
よろしくお願いいたします。
パトリス
こんにちは、
前に言ったように、そのアドレスは SRAM ではありません。共有 SRAM を CAN:
SDKs 内の sai_low_power_audio の例を参考にしてください。
ここで、SRAM を指しているリンカー ファイルをCANます。
よろしくお願いいたします。
サラス。
こんにちは、
ご提案のとおり、vdev vrings を設定してみました。
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;
};
};M33 コードでは次のようになります。
#define VDEV0_VRING_BASE (0xAFF00000U)
#define VDEV1_VRING_BASE (0xAFF10000U)
A55 がサスペンド状態でない場合、通信は正常に動作しますが、A55 がサスペンド モードの場合、M33 は常に rpmsg_lite_alloc_tx_buffer でクラッシュします。
あなたの側でこれをテストしましたか?これは動作するはずですか?
お時間を割いてご協力いただきありがとうございました。
こんにちは！
ご説明ありがとうございます。しかし実際には、Variscite デバイス ツリーで使用されるアドレスも DRAM 用です。
SRAMで試すことができます。
よろしくお願いいたします。
サラス。
こんにちは、
実際、私は以下を定義する Variscite DTS を使用しています。
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;
};
まだ試していませんが、あなたの解決策は本当に有望に見えます!
ご返信よろしくお願いします。
こんにちは、
vdev0vring と vdevbuffer を DRAM ではなく SSRAM に変更してみることもCANます。
リファレンス・マニュアルに記載されているように、DRAM はディープ スリープ モードではクロック ゲーティングされます。
i.mx8ulp のデバイス ツリーでは、これらが DRAM に構成されていることがわかります。
よろしくお願いいたします。
サラス。
こんにちは、
誰かこのトピックについて説明してくれませんか?
よろしくお願いします。
こんにちは、
はい、A55 がサスペンド モードのときは常に発生します。再現するのは本当に簡単です:
- A55 に定期的にメッセージを送信する (/dev/ttyRPMSG ttyRPMSG30 経由で受信可能)、またはデバッグ コンソールのキーを押すことによってトリガーされる M33 ファームウェアを使用します。
- echo mem > /sys/power/state を使用して A55 をサスペンド モードにします。
- M33がサスペンドモード後にメッセージを送信しようとするとすぐに、rpmsg_lite_alloc_tx_bufferで停止し、問題はvq->vq_ring.avail->idxへのアクセスに関連しているようです。トリガー。
関連する質問もあります。A55 Linux 側で、M33 がスリープ モードになっているかどうかを知ることは可能ですか?
ありがとうございます。
こんにちは@PBouchand
お元気でお過ごしのことと思います。
これは Cortex A55 がサスペンド状態のときにのみ発生するのでしょうか?
私の側でそれを再現する手順を共有していただけますか?
よろしくお願いいたします。
サラス。