2393077_ja-JP

Yes

S32K3ブートローダーとHSE - ベストプラクティスとは？

こんにちは、NXPチームの皆様、

当社は、HSEのフルブロックA/Bスワップを使用して、S32K312上で堅牢なOTAアップデートアーキテクチャを実装しています。

我々の目標とするアーキテクチャは以下のとおりです。

- S32K312は、2MBのPFlashを2つの1MBの物理ブロックに分割して搭載しています。
- HSE AB_SWAPは、パッシブブロックのアクティベーションサービスを介して使用されます。
- OTAパッケージはModbus/シリアル経由で受信されます。
- ブートローダーは署名付きイメージをパッシブPFlashブロックに段階化します。
- HSEは受動イメージ/SMRを検証します。
- ブートローダーがAP_SWAPを要求します。
リセット後、新しく交換されたバンクは暫定的に起動します。
確認コマンドを実行すると、スワップが永続的に適用されます。そうでない場合は、デバイスはロールバックされます。

当初は、2つのPFlashバンクとは別に、DFlashに1つのグローバルブートローダーを配置しようと試みました。そのブートローダーはOTAを受信し、パッシブPFlashバンクをプログラムし、HSE AP_SWAPを要求し、その後、確認/ロールバックの管理を継続します。

そのアプローチでは、アーキテクチャと実行時の複雑さという問題に直面しました。

1. HSE AB_SWAP は、任意のアプリケーションパーティションではなく、PFlash ブロックの境界全体で動作するようです。
2. 単一のDFlashブートローダーは、スワップ/認証済みバンクイメージの外にあります。
3. アクティブなPFlashバンクは、スワップ後も有効なブート/IVT/リセット構造を必要とします。
4. DFlashがブートローダーの実行時/レコード処理にも関与していた場合、実行時に重大なハザードが発生しました。
5.グローバルDFlashブートローダーがクリーンなフルバンクのHSE AB_SWAP生産設計と互換性があるかどうかは不明瞭になりました。

そのため、当面はPFlashブートローダーを複製したモードに移行しました。

- 各1MBのPFlashバンクには独自のIVT + ブートローダー+アプリケーションが含まれています。
- ブートローダーは、各バンクの底部に予約済みのスロットを持っています。
- アプリケーションはブートローダースロットの後に起動します。
- 署名付きOTAイメージは、ブートローダー+アプリケーションを含むフルバンクイメージです。
- HSE AB_SWAP実行後、新たにアクティブになったバンクは自己完結型でブート可能です。

HSEのフルブロックA/Bスワップには、この方法の方がはるかにクリーンに見えますが、意図された、かつ生産上安全な方法であることを確認したいと思います。これは、工場出荷時のブートローダーの目的を部分的に損なうため、最適とは言えません。

質問:

1.S32K312 HSE AB_SWAPの場合、スワップされたPFlashバンクの外に単一のグローバルDFlash常駐ブートローダーを配置するアーキテクチャは、サポート/推奨されていますか？
2. あるいは、HSE AB_SWAPは、交換された各PFlashブロックが、独自のIVT/ブートローダー/リセットパスを持ち、独立してブート可能であることを実質的に要求/推奨しているのでしょうか？
3.もしDFlashブートローダーが可能なら、SBAF/HSEブートの期待に応えられるように、スワップ後のブートフローはどのように構成すべきでしょうか?
4. S32K3上でDFlashブートローダーがフルブロックHSE AB_SWAPを管理することを示したNXPの参考例はありますか?
5.ロールバックや確認セマンティクスを持つ本番OTAの場合、複製されたPFlashブートローダーモデルの方が安全な設計でしょうか?

コードとIVTをリンカースクリプトを改変することでDFlashにリンクできるという話は見ており(私たちも試しました)、しかし私たちの質問は、HSEのフルブロックA/Bスワップやセキュアブート/SMR検証を使う場合にそれが適切かどうかについてです。

よろしくお願いします。

Re: S32K3 bootloader and HSE - best practice ?

こんにちは、 @coratron さん。

1.S32K312 HSE AB_SWAPの場合、スワップされたPFlashバンクの外に単一のグローバルDFlash常駐ブートローダーを配置するアーキテクチャは、サポート/推奨されていますか？

ハードウェアの観点からは、何の制限もありません。どちらの選択肢も可能である。データフラッシュのサイズが十分で、データに使う予定がない場合は、ブートローダーをデータフラッシュに配置できます。データフラッシュを他の用途で使用する必要がある場合は、両方のパーティションにブートローダーのコピーを2つずつ用意するのが一般的な方法です。

2. あるいは、HSE AB_SWAPは、交換された各PFlashブロックが、独自のIVT/ブートローダー/リセットパスを持ち、独立してブート可能であることを実質的に要求/推奨しているのでしょうか？

いいえ、そのような要件はありません。データフラッシュ（ブートローダーのIVT）に有効なIVTがあれば十分です。一般的な慣習としては、リセット後にブートローダーが起動され、その後ブートローダーがユーザーアプリケーションにジャンプします。

3. もしDFlashブートローダーが可能なら、SBAF/HSEのブート期待を満たすように、スワップ後のブートフローはどのように構成すべきか?

SBAFまたはHSEからの具体的な要件はありません。ブートローダーが起動すると、アプリケーションにジャンプするか、新しいアプリケーションをダウンロードするか、ロールバックを行うかなどを判断し、その後(ロールバックやスワップの場合に)デバイスをリセットするか、アプリケーションにジャンプします。

4. S32K3上でフルブロックHSE AB_SWAPを管理するDFlashブートローダーを示すNXPのリファレンスサンプルはありますか？

そのような例はありません。

5. ロールバック/確認セマンティクスを持つ本番OTAの場合、複製されたPFlashブートローダーモデルは意図された設計の方が安全なのでしょうか?

どちらの方法も、普遍的に安全だと断言することはできません。特定のアーキテクチャの適性は、全体のシステム設計、セキュリティ要件、OTAワークフロー、ロールバック戦略に依存します。両概念は堅牢な本番環境で実装可能です。

よろしくお願いいたします。
ルーカス

Re: S32K3 bootloader and HSE - best practice ?

@lukaszadrapa さん、迅速なご返信ありがとうございます。これにより状況が明確になり、大いに役立ちました。DFlashにおけるブートローダーの実装を再評価することができ、成功しました。

チームは他のベンダーのドキュメントやアクセス性に慣れており、オートモーティブアプリケーションのリーダーであるにもかかわらず、NXPは意外にも分かりにくいと感じています。

あなたの迅速なフィードバックがこれらの穴を補っています。改めてご助言ありがとうございます。とても感謝しています。あなたの回答を解決策としてマークし、あなたのチームに以下のフィードバックを送ります。

- DflashブートローダーとHSEのデモがあれば、（あなたの時間も含めて）時間を節約できたでしょう。これはAB_SWAPを使用する人にとって自然な設定だと確信しています。

- NXPはドキュメントやソフトウェアスタックを統合し、長期的に整理すべきです。互換性やバージョンが散在しており、情報源が一つにないため混乱が生じます。

よろしくお願いいたします