こんにちは、
現在はNXP RIOP評価ボードと連携しており、Getting Startedガイドを無事に完了し、事前プログラムされたFreeMASTERデモもテストしました。
次のステップは、デモをソースコードから再構築し、ボードに書き込んで、ビルドと書き込みのパイプライン全体が正しく動作することを確認することです。
以下のドキュメントと情報源を確認しました:
はじめ:GS-REMOTE-IOプラットフォーム
RIOPユーザーガイド:UG10224
GitHubリポジトリ: nxp-appcodehub/rd-riop-demo
GitHubリポジトリには2つのプロジェクトが含まれています。
riop_M33LEADER_DEMO
riop_M7FOLLOWER_DEMO
必要なSDKおよびツールのバージョン、MIMXRT1189 SDK 25.09.00を含むことを規定しています。
私にとってまだ完全には理解できていないのは、これら2つのプロジェクトから、基板に搭載されているものと同じ起動可能なファームウェア構成にどうやって到達するかということです。
質問:
M33およびM7プロジェクトを構築する際の推奨される方法は？MCUXpressoで両方のプロジェクトを個別にインポートしてビルドすればよいのでしょうか、それともビルド順序や依存関係が必要なのでしょうか？VS Code拡張機能も使えますか?
生成されたM33およびM7の画像は、どのようにRIOPにプログラムされるのですか？Secure Provisioning Toolは、アプリケーション全体を作成・フラッシュするための意図された方法なのでしょうか?
2つのイメージがどのように結合されるか（正しいメモリレイアウトとフラッシュアドレスを含む）を示す、既存のセキュアプロビジョニングツールの構成例またはサンプルはありますか？
RIOPデモの画像認証はどのように扱われていますか?工場出荷時の設定でセキュアブート／署名検証は有効になっていますか？また、デモ版を自作してフラッシュする際に、キーのプロビジョニングは必要ですか？
rd-riop-demoを上書きする前に、現在ボードにプログラムされているrd-riop-demoのバージョンを特定する方法はありますか？
例コードから見ると、RT1189 Boot ROMがM33アプリケーションを起動し、M33がMCMGRを使って0x303C0000でM7を起動するようです。これは工場出荷時イメージの完全なブートフローですか、それともGitHubリポジトリに含まれていない追加のブートステージがありますか？
必要ならボードを元のすぐに使える状態に戻せるよう、元の工場出荷イメージはどこかに入手できますか?
コマンドライン／ヘッドレスビルドのワークフローも利用可能ですか？長期的には、ビルドを再現可能にし、CI（継続的インテグレーション）に適したものにしたいと考えています。
Getting Startedガイドはすぐに使えるのデモをよく説明しており、GitHubリポジトリにもソースがありますが、今のところ両者のつながりが分かりません。
GitHubソース → M33/M7をビルド → ブート可能なイメージを作成 → フラッシュ → 同じデモを実行
UG10224か他の文書の該当箇所を見落としたのかもしれません。
ご回答をお待ちしています。
こんにちは、シェリーさん。
詳細なご回答をありがとうございました！
よろしくお願いいたします。
Marco
ご質問への回答は以下のとおりです。
1.RIOPデモはMCUXpresso IDEとVS Code + MCUXpresso for VS Codeの両方をサポートしています。VS Codeのご利用をお勧めします。riop_M7FOLLOWER_DEMOとriop_M33LEADER_DEMOプロジェクトをインポートした後、まずM7フォロワープロジェクトをビルドし、次にM33リーダープロジェクトをビルドすることをお勧めします。これは、M33プロジェクトがriop_M7FOLLOWER_DEMO.axf.oを参照しているためです。M7プロジェクトによってマルチコアスレーブイメージとして生成されたファイル。
2. Secure Provisioning Tool (SPT) を使用してフラッシュメモリに書き込む必要があるのは、riop_M33LEADER_DEMO.axf ファイルのみです。UG10224のセクション4.1.5を参照してください。「デモアプリケーションの実行中」。最新版のSPT v26.06をダウンロードして使用することをお勧めします。一部の設定設定はユーザーガイドに示されているものとは若干異なることに注意してください。
3. 独自のRIOP SPTワークスペースを作成するには、UG10224を参照してください。SPT側では、主な役割はブート可能なRT1189アプリケーションイメージを生成し、デバイスにプログラムすることです。
4. 開発中は、機能検証のために署名なし/オープン構成を使用することを推奨し、eFuseやキーのプログラミングは推奨しません。
プログラミングヒューズは不可逆的な操作であり、シャドウレジスタなど適切な検証後の本番セキュリティプロセスの一部としてのみ実施されるべきです。セキュアブート、イメージ署名、暗号化を有効にするかどうかは、最終的には本番環境のセキュリティ要件とSPT設定によって決定されるべきです。
5. 現在のファームウェアがFreeMASTER変数、UART出力、またはバージョン文字列を通じてバージョン情報を公開しない場合、ボード上で現在実行されているrd-riop-demoのバージョンを確実に判別することはできません。フラッシュメモリの内容を上書きする前にバックアップを取るか、カスタムファームウェアにバージョン情報を追加することをお勧めします。
6.現在のプロジェクトで実装されている起動モデルは、RT1189がまずCM33(M33リーダー)を起動し、その後M33がマルチコア/MCMGRフレームワークを通じてM7フォロワーを起動するというものです。追加の起動段階は不要です。
7. 復元が必要な場合、最も信頼できる方法は、既存のフラッシュイメージを読み返して保存し、再プログラムすることです。バックアップが利用できない場合は、rd-riop-demoを再構築して再プログラムするしか選択肢はありません。これにより、システムは機能的に同等の状態に復元されます。
8. コマンドラインワークフローがサポートされています。SPTは内部的にOpenSSLやSPSDKなどのコマンドラインツールを呼び出し、鍵の生成やイメージのビルド/書き込みを行います。詳細については、以下のドキュメントをご参照ください。
2つの画像がどのように関連付けられているかについては、主要な流れは以下のとおりです。
1.デモは、リンクされた2つのマルチコアプロジェクトとして構成されています。
RIOPデモリポジトリには、2つのプロジェクトディレクトリが含まれています。
riop_M33LEADER_DEMO/
riop_M7FOLLOWER_DEMO/ 。
MCUXpressoのマルチコアプロジェクトモデルでは、プライマリ/リーダープロジェクトがセカンダリー/フォロワープロジェクトにリンクします。プライマリプロジェクトが構築されると、まずセカンダリプロジェクトが構築され、セカンダリ出力イメージがプライマリイメージに組み込まれる／埋め込まれる。
2. M33プロジェクトはマルチコアマスターとして構成され、M7プロジェクトはスレーブとして構成されます。
riop_M33LEADER_DEMO/.cproject では、プロジェクトは __MULTICORE_MASTER と __MULTICORE_MASTER_SLAVE_M7SLAVE を定義しています。そのマルチコアマスター構成は以下を指し示しています。
${workspace_loc:/riop_M7FOLLOWER_DEMO/Debug/riop_M7FOLLOWER_DEMO.axf.o} 。
これは、まず riop_M7FOLLOWER_DEMO.axf が .axf.o に処理され、そのオブジェクトが「スレーブオブジェクト」として M33 リーダーイメージにリンクされることを意味します。
M7プロジェクトは、CM7 ITCM/DTCMメモリ領域を使用して、M7SLAVE / __MULTICORE_M7SLAVEとして構成されます。
3.実際のマージは主にリンク/ビルド後の段階で行われます。
MCUXpressoのマルチコアフローは、セカンダリコアイメージを処理し、セカンダリコアセクションをシフトしてから、それらを完全なマルチコアイメージにリンクします。
したがって、最終的なriop_M33LEADER_DEMO.axfは、M33リーダーELFにM7フォロワーの画像データ/セクションが埋め込まれたものであり、2つの独立したAXFファイルを単純にバイナリで連結したものではありません。
4.実行時に、M33はM7を開始します。
riop_M33LEADER.c 内M7ブートアドレスは次のように定義されます。
CORE1_BOOT_ADDRESS = 0x303C0000、CORE1_KICKOFF_ADDRESS = 0x0。
SystemInitHook() では、Prepare_CM7(CORE1_KICKOFF_ADDRESS) が呼び出され、その後 main() で MCMGR_StartCore(kMCMGR_Core1, CORE1_BOOT_ADDRESS, ...) が呼び出されてセカンダリ コアが起動します。
したがって、M7イメージはM33リーダーAXFに埋め込まれていますが、M7の実行は実行時にM33によって明示的に起動されます。
5. 起動可能なイメージは依然としてSPTプロセッシングが必要です
RT1180については、ドキュメントによるとデバイスはCM33からのみ起動できると記載されています。Secure Provisioning Toolは、生アプリケーションイメージからブートヘッダー付きのブート可能なイメージを生成するために使用されます。MCUXpressoの出力タイプには.axfが含まれます。
通常の流れは次の通りです:
riop_M7FOLLOWER_DEMO.axf→riop_M7FOLLOWER_DEMO.axf.oに処理されます→ riop_M33LEADER_DEMO.axf にリンクされます → SPT は M33 リーダー AXF を使用してブート可能なフラッシュ イメージを生成します。
よろしくお願いいたします。
シェリー
こんにちは、シェリーさん。
続報です。
RIOPリポジトリにはriop_M7FOLLOWER_DEMO/scripts/image_hash_tool.pyが含まれていませんが、元のプロジェクトでは条件付きでこのファイルが呼び出されています。RIOPマルチコアデモにおいて、ヘルパー関数が欠落しているのは意図的なものですか？もしそうなら、VS CodeのプロジェクトコンバーターはWindows上で元の「スキップ・if uncessent」の動作を保持し、失敗するcmd.exeコマンドを生成せずに済むのでしょうか?意図的でない場合、意図された image_hash_tool.py はどこで提供され、SPT で M33 画像をプロセッシングする前に必須ですか?
よろしくお願いいたします。
Marco
image_hash_tool.py スクリプトは以下の場所にあります。
riop_M33LEADER_DEMO\scripts\
これは、ビルド後の段階でファームウェアELFイメージのハッシュ値を計算し、生成されたハッシュ値をELFファイル内の予約済みセクション/オフセットに書き戻すために使用されます。これにより、起動コードやセキュリティ機構が実行時にファームウェアイメージの整合性を検証できます。
この設計ではM7コアが主要なブートコアではないため、M7イメージではこの後処理ステップは一般的に不要です。image_hash_tool.py が見つからないことに関連する警告が表示された場合は、それらは無視して、ビルドプロセスを続行してください。
よろしくお願いいたします。
シェリー