2402744_ja-JP

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

2402744_ja-JP

2402744_ja-JP

iMX8 Nanoのカーネルを5.15から6.18にアップデート

こんにちは

A53コア用にカーネルを5.15から6.18に移植する際、rpmSGの問題に直面しています。
# dmesg -T |grep -Ei 'rpmsg|rproc'
[2024年10月8日火曜日 15:42:28] IMX RPMSGドライバーが登録されました。
[2024年10月8日火曜日 15:42:29] imx-rproc imx8mn-cm7: error -ENOENT: クロックを有効にしられませんでした
[2024年10月8日火曜日 15:42:29] imx-rproc imx8mn-cm7: ドライバ付きプローブ imx-rproc エラー -2 で失敗
[火曜日 2024年10月8日 15:42:29] remoteproc remoteproc0: releaseingimx-rproc

このエラーが出ます。このエラーをオンラインで検索したところ、DTSにダミークロックを追加するように求められました。
IMX8Mn-CM7 {
互換性 = "FSL,IMX8mn-CM7";
RSC-DA = <0xb8000000>;
クロック = <&CLK IMX8MN_CLK_DUMMY>;
mbox-names = "tx", "rx", "rxdb";
mbox = <μ 0 1
&ミュー 1 1
μ 3 1>;
memory-region = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>, <&rsc_table>;
status = "OK";
}

これが唯一の変更なのでしょうか?この変更の理由は何ですか。

よろしくお願いいたします
ヤドゥナス・R

Re: iMX8 Nano Kernel updation from 5.15 to 6.18

いいえ、私は clocks = <&clk IMX8MN_CLK_DUMMY>; を唯一の必要な変更として扱うつもりはありません。これで即時の-ENOENT: Failed to Enable Clock probe failureを乗り越えられるかもしれませんが、i.MX8M Nanoの場合、重要な要件はLinuxがM7ファームウェアを読み込み/起動する際にCortex-M7のルートクロックが有効のままであるということです。

理由:

  • imx-rproc ノードにはクロックエントリがあることが想定されています。AN5317 では、compatible = "fsl,imx8mn-cm7" と clocks = <...> プロパティ、さらに mailbox および memory-region エントリを持つ i.MX8M remoteproc DTS ノードが示されています。
  • あなたのエラーは、カーネル6.18のimx-rprocドライバーがそのノードからクロックを取得して有効化しようとした際、-ENOENTでクロック検索が失敗したため、リモートプローク0がレジスタジアムのままになる前にプローブが中止されたことを意味します。
  • NXPのAMPガイダンスには「i.MX 8Mプラットフォームでは、M7/M4のルートクロックを常にLinuxで有効にしてファームウェアコードを読み込み、Cortex M7/M4を起動させる必要があります」とあります。 また、NXP Linux BSPはU-BootからMコアを起動した際にこのルートクロックを有効にしているとも書かれています。それ以外の場合、MコアをLinuxブートから起動した場合、ドライバ/clk/imx/clk-composite-8m.cを更新してMコアクロックのゲート登録をスキップする必要があります。

したがって、この変化には二つの意味が考えられます。

  • ダミークロックを互換性回避策として使う
    カーネル6.18 imx-rprocがクロックの性質を必要としているが、実のM7クロックが共通クロックフレームワークで意図的に制御されていない場合、IMX8MN_CLK_DUMMYを追加することでドライバーのクロック処理要件を満たし、-ENOENTを回避できます。
  • 実クロック制御の修正
    もしLinuxが実際にM7の読み込みや起動を担当している場合、ダミークロックだけではプローブエラーを隠すかもしれませんが、M7クロックが有効になる保証はありません。その場合、NXP BSPクロックドライバーの処理かclk-composite-8m.cのいずれかでM7/M4のルートクロックがオンになっていることを確認してください変更内容はAN5317に記載されています。

クロックラインだけでなく、remoteproc/rpmsg DTSの残りの部分も確認してください。

imx8mn-cm7 {

互換性 = "fsl,imx8mn-cm7";

     rsc-da = <...>;

clocks = <&clk IMX8MN_CLK_DUMMY>; /* または、お使いのBSPで使用される正しいM7クロック */

     mbox-names = "tx", "rx", "rxdb";

     mboxes = <μ 0 1>, <μ 1 1>, <μ 3 1>;

     memory-region = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>, <&rsc_table>;

status = "オーケー";

};

メモリ領域リストは重要で、AN5317ではこのプロパティがファームウェアELFで使用されるメモリセクションを含まなければならず、remoteprocがsysfsから再ロードできるとされています。

推奨されるチェックパス:

  • M7をU-Bootから起動する場合は、NXPのprepare_mcore/bootauxなどのフローを使い、その後Linuxを起動します。AN5317によると、BSPはこの経路でMコアのルートクロックを有効にしています。
  • Linux remoteprocからM7を起動する場合、6.18クロックドライバーにNXP対応が含まれているか確認し、Mコアのルートクロックを常に有効にしてください。そうでなければ、ダミークロックはプローブのみを修正し、実行時の開始・ロードは修正されません。
  • 作成したDTSファイルをNXP imx8mn-*-rpmsg.dtsと比較してください。同じ BSP リリースの場合、特にクロック、mboxes、rsc-da、および予約済みメモリレイアウト。

ダミークロックは即時の-ENOENTプローブ故障を説明しますが、実際の設計要件はi.MX8MN M7のルートクロックを有効にしておくことです。DTSだけで十分かどうかは、6.18 BSPクロックドライバーがすでにそのクロックを保持しているかどうかに依存します。


Tags (1)
No ratings
Version history
Last update:
Thursday
Updated by: