ああ、楽しみのために、実行環境が SPI NOR Flash XIP であることを忘れないでください。
このシナリオを実際に実行した人はいますか?
こんにちは、ディエゴ。
Hello World バージョン 4 と 5 では「SPI NOR - Simplified」が選択されるのに、バージョン 6 では「SPI NOR - Complete FCB」を選択しなければならないのはなぜですか?
よろしくお願いします。
ロン
こんにちは@Littell
お返事ありがとうございます！
残念ながら、私にはそのような実装手順はありませんが、私の理解では、あなたのアイデアは興味深いものです。
より高いバージョン番号の更新されたイメージを実行するために再起動をテストしていません。これが最も重要なステップだと思います。イメージの受信と書き込みのカスタム方法をCAN実装できるため、これは bootROM からのデュアル ブート機能とは独立しているようです。また、イメージ実行中の書き込みはフラッシュメモリの機能に依存します。参考までに、このアプリケーションノートAN12564 i.MX RTシリーズでのRWWの実装を確認してください。
ディエゴ
いいえ、イメージの更新には、ダウンロードしたイメージを提供するエンティティ以外の外部エンティティが関与することはできません。
デュアルイメージ構成の XPI SPI NOR フラッシュでは、次のように考えます。
どうすればもっと明確に、あるいはもっとシンプルにできるのか分かりません。
こんにちは@Littell
お返事ありがとうございます！
OTA のように、イメージを新しいバージョンに更新することについて言及していることを理解しています。そうでない場合はお知らせください。
このシナリオでは、MCU を手動でシリアル ダウンローダー モードで起動し、SPT (低レベルで BLHOST を実装) 経由でイメージをプログラムします。何らかのオートメーションが必要な場合にはそうするべきだと思います。SW からブートローダを再度呼び出す必要がある単純なシナリオがあります。これは、runBootloader() API を使用して実行でき、その後、異なる SW バージョンの新しいイメージを BLHOST 経由で送信して、デュアル イメージ機能のメリットを享受できます。
より洗練された方法については、SBL リファレンス プロジェクトとドキュメントを参照することをお勧めします。SBL ユーザーガイドにはデュアル イメージの使用例が詳しく記載されていますが、ここでは ROM ブートローダーは使用しません。
ディエゴ
SPI NOR フラッシュで XIP を使用するときに、SPI NOR フラッシュを新しいイメージでプログラムし、そのイメージで再起動するために必要な手順は何ですか?
こんにちは@Littell
早速のフィードバックとご関心をいただきありがとうございます!あなたの忍耐と助けにも感謝します。あなたからの更なるコメントをお待ちしております。
ところで、実行環境の機械化についてさらに詳しく説明していただけますか?
ディエゴ
私は確かにこれを綿密に調べるつもりです。最初に読むと、これはイメージ バージョンの動作に関する私の理解と一致しているように見えます。
初読時のメモ:
- 「プロジェクト作成手順」では、「L」と「H」は接頭辞ではなく接尾辞です。
- 2 つのイメージ バージョンが同一であるCASEは、「ブート イメージの基準」テーブルでは対処されていないようです。
- 「冗長」と「二重イメージ」の概念は、大幅に明確化される必要があります。
私の EVKB の bootROM バージョンは K3.0.1 です。RT1170 リファレンス マニュアルのセクション 10.13.1 の情報を使用して抽出しました。
これは良い情報であり、入手できるようにするために私がSO一生懸命働きかけなければならなかったのは残念です。しかし、これは私たちが直面している全体的な問題の一部にすぎません。アプリケーションの実行環境は、SPI NOR フラッシュからの XIP です。私たちのプロジェクトの重要な機能は、新しいイメージで Flash をダウンロードしてプログラムし、そのイメージで再起動できることに依存しています。この実行環境でこれをどのように機械化しますか?
こんにちは@Littell
まず、このトピックはまだ検証中なので、これをまだ公式ドキュメントとして考えないでください。すでにご覧のとおり、英語の公式ドキュメントはまだありませんが、これに取り組んでいます。ご関心をお寄せいただき感謝申し上げます。また、ご不便をおかけしましたことをお詫び申し上げます。以下をご覧になり、問題や矛盾が見つかった場合はフィードバックをお知らせください。
私はこれを i.MX RT1170 EVKB と MCUXpresso Secure Provisioning Tool v9 でテストしました。
この点では bootROM が重要な役割を果たします。始める前に、bootROM のバージョンを確認してください。以下にその実行方法のスナップショットを示します。
私の RT1170 にはバージョン T2.0.0 の bootROM が含まれていました。MCU をシリアル ダウンローダー モードに設定し、以下のコマンドを呼び出して、確認するのを手伝ってください。
blhost u VID,PID -- get-property 24 command. 古いバージョンや異なるバージョンのブートローダーをお持ちの場合はお知らせください。
準備：
1 MCUXpresso Secure Provisioning Tool の最新バージョンをダウンロードしてインストールします。
2 EVK フラッシュを一括消去します。これは、以前のバージョン番号を回避するためです。MCUXpresso IDE を使用すると、一括消去が簡単にできます。
プロジェクト作成手順:
- Hello word デモをインポートし、イメージ L プレフィックスを追加します。プロジェクト名はHello_word_ImageLになります。
- デモのソースコードでは、Printに「Hello word from image L」と出力します。
- Hello word デモをインポートし、イメージ H プレフィックスを追加します。プロジェクト名はHello_word_ImageHになります。
- デモのソースコードで、Print に「Hello word from image H」と出力させます。
- 各プロジェクトで XIP_BOOT_HEADER_ENABLE=0 を削除します。
- 各プロジェクトをコンパイルします。
セキュアプロビジョニングツールの手順:
- RT1170 用の新しい SPT ワークスペースを作成します。
- デュアルイメージブートボタンをクリックし、ターゲットイメージ0とイメージ1を選択し、イメージオフセットを0x0040_0000に設定します。
- ツールは、指定されたオフセットを格納するために 0xC80 ヒューズを焼き付ける必要があることを検出すると、OTP 構成が赤色に変わります。
- RT1170 をシリアル ダウンローダー モードに設定し、たとえば USB 経由で接続をテストします。
- OTP 構成を開き、現在のプロセッサ ヒューズを読み取ります。
- ヒューズ 0xC80 を見つけると、ツールは必要な値と現在の値を表示します。必要に応じて「修正」オプションをクリックし、「OK」をクリックします。
すると、OTP 構成が緑色に変わります。
- ソース イメージとしてイメージ L を指定し、イメージ バージョンを 0x5 に設定します。これはバージョン番号の例です。
注: この設定では、SPT はイメージ バージョン 5 と同じイメージを、それぞれ 0x3000_2000 と 0x3040_0000 の imageL と imageH の両方のアドレス空間に書き込みます。
- イメージをビルドして書き込みます。
この方法では、イメージ L はイメージ H のオフセットとスペースに書き込まれるため、メモリに 2 回書き込まれます。これは冗長ブートとしてみなされます。
- MCU を内部ブートに設定し、シリアル ターミナルを使用して、コンソールでイメージ L がブートすることを確認します。
- ここで、イメージ H をソース イメージとして指定し、イメージ バージョンを 0x6 に設定します。
- デュアル イメージ ブートをクリックし、イメージ 1 を選択します。
この方法では、SPTはimageH（またはimage 1）のオフセットとスペースにのみ書き込みます。
- 警告がポップアップ表示されます。イメージ H に必要なカスタム FCB を作成して警告を解決します。FlexSPI NOR - Simplified ボタンをクリックして、FCB を作成します。
注：SPTにバグを発見しました。 「FCBに変換」ボタンでFCBブロックを作成すると、FCB周辺の領域が消去されます。消去される領域のサイズは、メモリの最小消去可能ブロックに依存します。これにより、RT10xx/RT11xxデバイスにおいて、FCBブロックの直後に配置されているユーザーデータまたはイメージバージョンが消去される可能性があります。このバグの解決策はSPT v10で用意されています。異常な動作が見られる場合は、イメージLとイメージHを再度書き込んでください。
- 画像 H を構築して書き込みます。
- イメージHが起動するかどうかを確認します。
- 異なる有効なバージョン番号を使用して H と L をプログラミングし、テストを続けます。イメージは、より有効なバージョンのほうが起動されるはずです。
下の画像は、さまざまなアプリケーションを起動する機能を示しています。
私のテストによれば、次のことを定義できました。
以下の表は、2 つのイメージがフラッシュにプログラムされている場合のブート イメージの基準を示しています。
|
Lサイズ画像 |
H画像バージョン |
ブートイメージの基準 |
ブーツタイプ |
|
有効 |
有効 |
BootROM は、有効なバージョン番号が高いイメージを起動します。 |
デュアルイメージブート |
|
0xFFFF_FFFFF |
有効 |
BootROM は最初にイメージ L を起動します。 |
冗長ブート |
|
有効 |
0xFFFF_FFFF |
BootROM は最初にイメージ L を起動します。 |
冗長ブート |
|
無効 |
有効 |
BootROM は有効なイメージ バージョンのみでイメージを起動します。 |
冗長ブート |
|
有効 |
無効 |
BootROM は有効なイメージ バージョンのみでイメージを起動します。 |
冗長ブート |
ここで、
L : フラッシュ メモリにイメージが 2 つある場合、L イメージはメモリ上の最も低い物理アドレスに配置されているイメージです。0x3000_0000 にある画像と 0x3040_000 にある別の画像を考えてみましょう。L は 0x3000_0000 にある画像です。
H : フラッシュメモリにイメージが 2 つある場合、H イメージはメモリ上の最上位の物理アドレスに配置されているイメージです。0x3000_0000 にある画像と 0x3040_000 にある別の画像を考えてみましょう。H は 0x3040_0000 にある画像です。
イメージバージョン: 4 バイトのタグです。最初の 2 つの重要度の低いバイトは、実際のイメージ バージョン (0x0000 から FFFF の範囲) を表し、次の 2 つの重要なバイトは、2 つの実際のイメージ バージョン バイトの逆の値を表します。
有効または有効なイメージ バージョン: 実際のバージョン番号バイトと逆数値バイトが一致するイメージ バージョンです。たとえば、0xFFFE_0001 の場合、0001 は実際のバージョン番号であり、0xFFFE は 0x0001 の逆の値です。
無効または無効な画像バージョン : 実際のバージョン番号バイトと逆数値バイトが一致しないイメージ バージョンです。例: 0x0000_0001。
0xFFFF_FFFF : これは 4 つのバイトすべてに F が含まれる特殊なCASEであり、有効なバージョン番号としても考慮されます。冗長ブートをテストするのに便利な特別なバージョン値です。
冗長ブート: 以下の条件が満たされた場合、bootROM は常に最初のイメージ L のブートを試行します。
- フラッシュメモリには 2 つのイメージ (イメージ L とイメージ H) が存在します。
- ヒューズ0xC80[23:16]の値がゼロと異なります。
- イメージ L には、有効なバージョン番号または 0xFFFF_FFFF に相当する値が含まれています。
上記の条件が満たされない場合、またはイメージ L のブートに失敗した場合、bootROM はイメージ H のブートを試みます。
デュアルブート : 以下の条件が満たされている場合、bootROM は常に最も高いバージョン番号のイメージを最初に起動することを選択します。
- フラッシュメモリには 2 つのイメージ (イメージ L とイメージ H) が存在します。
- ヒューズ0xC80[23:16]の値がゼロと異なります。
- イメージ L には、0xFFFF_FFFF 以外の有効なバージョン番号が含まれています。
- イメージ H には、0xFFFF_FFFF 以外の有効なバージョン番号が含まれています。
上記の条件が満たされない場合、または選択したイメージのブートに失敗した場合、bootROM は他のイメージからのブートを試行し、冗長ブートを実行します。
これがお役に立てれば幸いです。
ディエゴ