2403593_ja-JP

Yes

imx8 nanoカーネルのA53コアへの5.15から6.18への移行 imx_rproc_kick

こんにちは

A53コアのカーネルを5.15から6.18にアップグレードしていますが、imx_rproc_kickが見つかりません。

デバッグメッセージを探してください

# DMESG |grep -nE "rpmsg|virtio|remoteproc|imx-rproc|imx_rproc_kick|goodbye|new
チャネル|get [0-9]」
118:[ 0.030048] IMX RPMSGドライバーが登録されています。
222:[ 1.538994] remoteproc remoteproc0: imx-rproc が利用可能です
224:[ 1.544537] RemoteProc RemoteProc0: IMX-rprocへの接続
225:[ 1.555034] rproc-virtio rproc-virtio.1.auto:割り当てられた予約メモリノードvdevbuffer@b8400000
226:[ 1.564322] virtio_rpmsg_bus virtio0: rpmSGホストがオンライン
227:[ 1.569846] rproc-virtio rproc-virtio.1.auto:登録済みVirtio0(タイプ7)
228:[ 1.576689] RemoteProc RemoteProc0: リモートプロセッサ IMX-Rproc が接続されました
327:[ 5.860600] IMX-rproc imx8mn-cm7: imx_rproc_kick: failed (1, err:-62)

敬具
ヤドゥナート・R

Re: imx8 nano kernel migration for a53 core from 5.15 to 6.18 imx_rproc_kick

imx_rproc_kick 6.18カーネルに欠けているわけではありません。ログにはドライバーが到達しエラーを返したことが示されています:

imx-rproc imx8mn-cm7: imx_rproc_kick: 失敗しました (1、エラー:-62)

err:-62 は、リモートコアへのキックがタイムアウトしたことを意味します。NXPのi.MX remoteproc/RPMsgのコンテキストでは、これはRPMsgキックパス中のタイムアウトとして説明されています。デフォルトのBSPリモート準備完了待機時間は50msですが、キャッシュがオフになっている場合やファームウェアがまだ準備できていない場合など、RPMsgの初期化が遅れるとMコアはより長い時間が必要になる場合があります。

あなたのログによると、Linux側はここまで来ています:

remoteproc0: imx-rprocに接続中

rproc-virtio... 予約済みメモリノード vdevbuffer@b8400000 を割り当てました

virtio_rpmsg_bus virtio0: rpmsgホストはオンラインです

リモートプロセッサIMX-RproCが接続されました

つまり、A53/Linux側はすでに動作中のM7に接続し、virtio RPMsgホストを作成しています。失敗は後にLinuxがvirtqueue 1に通知しようとした際に発生しますが、MU/RPMsg側が間に合わずハンドシェイクを完了しません。i.MX remoteprocキックパスは、LinuxとハードウェアのMU(リモートプロック)間のIPC割り込み信号にメールボックス/MUを使用します。

5.15 → 6.18へのアップグレードでデバッグが必要になる可能性が最も高い箇所：

M7ファームウェアリソーステーブル/RPMsgメモリレイアウト

M7のファームウェアリソーステーブルがLinuxのDT予約メモリ配置と一致しているか確認してください。

NXPのドキュメントによると、リソーステーブルはvirtioデバイスおよびvringエントリを定義しており、RSC_VDEV、NUM_VRINGS、VDEV0_VRING_DA_BASE、VRING_ALIGN、バッファカウントなどが含まれます。

有効なリソーステーブルが存在しない場合、NXPのLinuxユーザーガイドではリソーステーブル領域をクリアすべきと記載されています。i.MX 8M Mini/Nano/Quad LPDDR4 EVK では、文書化されたコマンドは mw 0xb80ff000 0 4 です。

デバイスツリーの予約メモリとrsc-da

6.18 DT が、M7 ファームウェアが想定するアドレスと同じアドレスに RPMsg vring/buffer/resource-table 領域を予約していることを確認してください。

ログにはLinuxが割り当てられたvdevbuffer@b8400000が表示されているので、M7ファームウェアのRPMsg-Lite/OpenAMP設定が同じvring/bufferベース領域を使っているか確認してください。

また、imx8mn-cm7ノードに、お使いのボード/ファームウェアに適したmboxes、memory-region、rsc-daの値が設定されていることを確認してください。

M7ファームウェアの準備状況

ログにはタイムアウト前のRPMsg「新しいチャネル」ラインは表示されません。これはLinuxがRPMsgホストとしてオンラインであることを示唆していますが、M7側が正しくチャネルをアナウンス・サービスしていない可能性があります。

Linuxがトラフィックを送信する前にM7アプリケーションがRPMsg-Lite/OpenAMPを初期化し、エンドポイントを有効にする前にブロックされていないことを確認してください。

新しいカーネルのRPMsgに関する前提に基づいて構築されたファームウェア

NXPは、リモートRPMsgリソースが破壊された後もLinux側がM7をキックし続けた事例を記録しており、その結果imx_rproc_kick失敗(...、ええと:-62)が出ています。

SDKのピンポン風デモを使う場合は、M7ファームウェアが一定数のメッセージ後にRPMsgエンドポイントを終了または破壊するかどうかを確認してください。そのパターンはまさにこの種類の誤りを引き起こすことがあります。

推奨される次のデバッグコマンド：

ls -l /sys/class/remoteproc/remoteproc0/

cat /sys/class/remoteproc/remoteproc0/state

cat /sys/class/remoteproc/remoteproc0/name

また、5.15と6.18のこれらの値を比較してください。

grep -n "imx8mn-cm7" -n your-board.dts

grep -n "vdevbuffer\|vdev0vring\|rsc\|rpmsg\|reserved-memory" your-board.dts

まず最初に確認すべきことは、 6.18 デバイスツリーが M7 ファームウェアのリソーステーブルと RPMsg メモリアドレスと一致しているかどうかです。Linux側は正常に接続しています。故障はMU/RPMsgのキック/アクック段階にあり、これはimx_rproc_kick機能の欠如よりもM7の準備状況、メールボックス/DTの設定、リソーステーブル/vringの不一致を示唆しています。