2388181_ja-JP

[#1]

i.Cortex M7のMX8MPメモリレイアウト(DRAM 1GB)

当社では、1GBのDRAMを搭載したi.MX8MPを使用するプロジェクトがあります。Cortex M7用にリンカーファイルを調整し、RPMSG用にDevicetreeを、Cortex M7用にDRAM予約メモリを調整しました。U-Bootからrpmsg ping pongを開始すると、例えばLinuxで起動し、カーネルモジュールを読み込み、正しい出力を確認できます。メモリマップは、1GB DRAM内の設定済み領域にあるm_data2セクションについても正しく見えます。

Linuxから同じファームウェア(elf)をremoteprocで起動すると動作しますが、rpmsgネームサービスの発表を待つ間にデモがフリーズします。

移植作業において、何か見落としている点はあるだろうか？

よろしくお願い申し上げます。

Re: i.MX8MP memory layout for Cortex M7 with DRAM 1GB

既に述べたように、デバイスツリーとリンカーファイルが調整されました。remoteproc ELFローダーがファイルをロードして実行します。MXUXSDKからの移植されたHello WorldデモはLinuxから起動すると問題なく動作します。RPMSGのデモはロードされ、起動します（M7デバッグコンソールに有効な出力が表示されます）が、rpmsg自体は動作しません。

M7用のMPU初期化コードに何らかの互換性の問題があるのではないかと疑っています。8MP EVKのDRAM空間には、1GBを超えるアドレスが存在するのでしょうか？

Re: i.MX8MP memory layout for Cortex M7 with DRAM 1GB

1. Linuxを起動する前にprepare_mcore実行を追加します

U-Bootでは、bootcmd / bsp_bootcmdを実行する前に、以下を追加します。

prepare_mcore を実行します

もしこれを自動で使いたいなら、Linuxを起動する前にボードの起動コマンドに含めてください。

2. デバッグ中は未使用のクロックを有効にしておく

起動時には、以下も追加してください。

setenv mmcargs " ${mmcargs} clk_ignore_unused"

saveenv

一部のダウンストリームBSPは、clk-imx8mp.mcore_booted=1; のようなより具体的な回避策を使用します。Toradexは、これによりLinuxがi.MX8MPのCortex-M7ルートクロックを無効化できないと指摘しています。

3. ランタイム DTB が RPMsg 対応の DTB であることを確認してください。

EVKの場合、NXPのサポート回答としては、M7リモートプロック/RPMsgに対してimx8mp-evk-rpmsg.dtbを使用することが一般的です。有効なNXP RPMsgファームウェアでi.MX8MP M7リモートプロックが失敗した「carveout doesn't fit da request」では、NXPのサポート回答にはLinuxでimx8mp-evk-rpmsg.dtbを使用していることを確認してくださいと書かれています。[community.nxp.com]

カスタム1GBボードの場合、ファイル名は異なりますが、重要な点は、ランタイムDTBにimx8mp-cm7リモートプロシージャノード、MUメールボックス、およびすべてのRPMsg予約メモリノードが含まれている必要があるということです。

4. 予約済みメモリとリソーステーブルのアライメントを確認する

i.MX8MPの場合、一般的なRPMsgレイアウトでは、次のような領域が使用されます。

dtsは完全にはサポートされていません。構文ハイライトはプレーンテキストに基づいています。

vdev0vring0: vdev0vring0@55000000 {

reg = <0 0x55000000 0 0x8000>;

地図なし;

};

vdev0vring1: vdev0vring1@55008000 {

reg = <0 0x55008000 0 0x8000>;

地図なし;

};

vdevbuffer: vdevbuffer@55400000 {

compatible = "shared-dma-pool";

reg = <0 0x55400000 0 0x100000>;

地図なし;

};

rsc_table: rsc_table@550ff000 {

reg = <0 0x550ff000 0 0x1000>;

地図なし;

};

i.MX8MPの公開されたLinux Remoteprocの議論では、このスタイルのDTセットアップが示されており、rsc-da = <0x55000000>、mbox = <μ 0 1 μ 1 μ 3 1>、memory-region = <&vdevbuffer>、<&vdev0vring0>、<&vdev0vring1>、<&rsc_table>、...などが含まれます。 [community.nxp.com]

1GBのDRAM CASEでは、これらの領域がLinuxの通常のメモリ、CMA、GPU、OP-TEE、または他の予約範囲内に入っていないことを確認してください。また、M7ファームウェアのrsc_table.cも確認してください。リンカーファイルはLinux DTと同じvring/リソースアドレスを使用します。

5. 1GB DRAMポートについては、ELFプログラムヘッダーを確認してください。

Linux remoteprocは「U-Bootがコピーした場所」だけでなく、プログラムヘッダーでELFを読み込むため、以下の点を確認してください:

readelf -l your_m7_firmware.elf

readelf -S your_m7_firmware.elf | grep -E "resource|data|bss|text"

すべての読み込み可能なセグメントがLinuxのリモートプロックがi.MX8MPに変換可能なアドレスにマッピングされているか、そしてm_data2リージョンが実際の1 GB DRAM範囲内で、予約メモリのカブアウトと一致しているかを確認してください。

6. デバッグ中に古いリソーステーブル領域をクリアする

繰り返し起動モードをテストする場合は、M7を起動する前にRPMsgリソーステーブル領域をクリアしてください。i.MX Linuxユーザーガイドによると、i.MX8M Plus LPDDR4 EVKの場合、リソーステーブル領域は以下でクリアできます:

mw 0x550ff000 0 4

これは、リソーステーブルの値が不正になることを回避するために特に文書化されています。

Re: i.MX8MP memory layout for Cortex M7 with DRAM 1GB

AEチームと話し合っています。

Re: i.MX8MP memory layout for Cortex M7 with DRAM 1GB

エラーログがあれば共有していただけますか？

rpmsgはDRAM設定と直接リンクしないようです。

Re: i.MX8MP memory layout for Cortex M7 with DRAM 1GB

バイナリファイルとELFファイルは、同じコードとリンカーファイルによって同時に生成されるんですよね？

「M7のMPU初期化コードに何らかの互換性の問題があるのではないかと疑っています。」8MP EVKのDRAM空間には1GBを超えるアドレスが存在するのですか？

- もしubootではすべて正常でLinux rprocが問題ない場合、MPUの問題ではないようです。

まずはubootとlinux rproc boot Mの違いを一時停止しようと思います。以下の2点を顧客確認することをおすすめします。

1) imx_rproc.cimx_rproc_att_imx8mn は、新しい DRAM サイズに合わせて変更されましたか？

2) セクション.resource_tableが適切な位置にあるか確認すること?UbootはcopyResourceTableでこのテーブルを読み込みますが、Linuxは.resource_tableを解析します。.elf からのセクションファイル。

彼らはどのデモを使用しているのですか？LinuxやM7 SDK向けのすべての修正パッチを提供できますか?そして、ログには「RPMSG デモがロードされ、起動します (M7 デバッグ コンソールに有効な出力があります) が、rpmsg 自体は動作しません」と表示されます。