2387347_ja-JP

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

2387347_ja-JP

2387347_ja-JP

S32K342 FOTAブートローダーアーキテクチャに関するガイダンスが必要(UARTベースのアップデート)

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

S32K342向けにカスタムファームウェア無線アップデート(FOTA)ソリューションを開発しており、推奨されるフラッシュアーキテクチャとブートフローについてアドバイスをいただきたいと考えています。

MCU詳細
装置:S32K342

PFlash: 2 MB

バンク0:1MB

バンク1:1MB

DFlash: 128 KB

現状
私たちはファームウェアアップデートインターフェースとしてUARTを使用しています。

これまでに、私たちは以下のことに成功しました:

UART経由でファームウェア(.binファイル)を受信する

バイナリ全体をフラッシュメモリに保存する

受信した画像が正しく保存されていることを確認してください。

残された課題は、ブートローダーアーキテクチャとアプリケーションスイッチングの仕組みを実装することです。

以下の点についてご説明をお願いいたします。
1. 推奨されるFOTAフラッシュレイアウト
S32K342デュアルイメージFOTA実装における推奨メモリレイアウトは何ですか?

具体的には、以下の場所について推奨される場所を知りたいです。

ブートローダ

アプリケーションスロットA

アプリケーションスロットB

メタデータ/ブートフラグ

バージョン情報

CRC

ロールバック情報

アドレスを含むメモリマップの例があると非常に助かります。

2. 推奨ブートフロー
NXPが推奨する完全な起動手順を誰か説明してもらえますか?

例:

リセット

ブートローダーが起動します

ブートフラグを確認する

アクティブアプリケーションを選択してください

画像の検証(CRC/署名)

アプリケーションへジャンプ

フロー図またはプロセス全体の説明をいただけると幸いです。

3. ブートローダーからアプリケーションジャンプへ
S32K342の場合、標準的なCortex-M7ジャンプシーケンスで十分でしょうか?

例:

アプリケーションベースアドレスからMSPを読み込みます

Reset_Handlerをベース+4から読み込む

MSPを設定する

VTORをアップデート

Reset_Handlerへジャンプ

制御を移管する前に、S32K342固有の要件や初期化手順はありますか?

4. デュアルアプリケーションイメージ
もしアプリAとアプリBが異なるフラッシュアドレスにある場合:

各アプリケーションに独自のリンカースクリプトを持つべきでしょうか?

それともデュアルスロットアプリケーションをビルディングするための推奨されるNXPのアプローチはありますか?

5. フラッシュバンクの使用
S32K342には1MBのPFlashバンクが2つあるため、

推奨されるアプローチは以下ですか?

バンク0からブートローダーを実行する

新しいファームウェアをバンク1にプログラムする

検証成功後のスイッチ実行

2つのPFlashバンク間で、書き込み中の読み出しや消去/プログラミングに関する制限はありますか?

6. メタデータの保存
保管場所として最適な場所はどこですか?

アクティブイメージフラグ

画像の妥当性

ファームウェアのバージョン

CRC

ロールバックステータス

これらはどこに保管すべきでしょうか?

予約済みPFlash

DFlash

別の専用地域ですか?

7. UARTベースのFOTA
当社のアップデートインターフェースはUARTなので、推奨されるワークフローを知りたいです。

以下の流れは正しいですか?

PC

UART

ブートローダーは.binファイルを受け取ります

ファームウェアを非アクティブなフラッシュスロットに保存します

CRCの確認

起動メタデータの更新

MCUをリセット

ブートローダーが新しいイメージを選択する

アプリケーションへジャンプ
それともNXPは別のアプローチを推奨しているのでしょうか?

8. AB_SWAPとカスタムブートローダーの比較
S32K342で本番環境のFOTAを実施する場合、HSE AB_SWAPは必須ですか?

それとも、デュアルアプリケーションスロットを備えた完全カスタムブートローダーもサポートされ、一般的に使われるアーキテクチャなのでしょうか?

もしFOTA、UARTファームウェアアップデート、デュアルイメージブートローダーに関するアプリケーションノート、参考プロジェクト、ブートローダーの例、またはドキュメントなど、S32K342を網羅したものがあれば、ぜひご参考いただけると幸いです。

ごサポートありがとうございます。
S32K3 S32DS-ARM 

Re: S32K342 FOTA Bootloader Architecture Guidance Required (UART-Based Update)

こんにちは、 @bavinkumar_02さん

1.S32K342のCASE、AB_SWAPには一つのセットアップしか考えられません。「3.5.3.2」を参照HSE FirmwareリファレンスマニュアルのAB_SWAP」に掲載されたフラッシュメモリのレイアウトのイラストは、ドキュメントからダウンロード可能です -> Secure files: https://www.nxp.com/products/S32K3

あなたのCASE、最も便利で一般的なレイアウトは以下の通りです:

lukaszadrapa_0-1782731189993.png


HSEファームウェアのAB_SWAPバージョンをインストールする必要があります(スワップはHSEの機能であり、HSEファームウェアなしでは実行できません)。ファームウェアは両方のパーティションにインストールされており、図に示すように、両方のブロックで最後の176KBを占有しています。
ブロック全体が交換されるため、両方のブロックにブートローダーの正確なコピーが存在する必要がある。残りはアプリケーションに割り当てられます。
コードは常にアクティブブロックから動作しているため、ブートローダーやすべてのアプリケーションはアクティブブロック内のアドレスに合わせてコンパイルされます。
ブートローダーがアプリケーションを更新すると、そのアプリケーションは受動的なブロックにプログラムされるため、フラッシュプログラミング中の読み書き問題はありません。アプリケーションがプログラムされると、HSEサービスをHSE_SRV_ID_ACTIVATE_PASSIVE_BLOCK発動CAN。次回リセット後、パーティションはスワップされ、ブートローダーは通常通りアプリケーション(現在アクティブなブロックにある新しいアプリケーション)にジャンプします。

2. フローはアプリケーションに依存します。現代の自動車用途では、単純なCRCベースの検証はもはや十分とはみなされていません。ソフトウェアの整合性と真正性は通常、セキュアブート機構によって保証されます。S32K3デバイスでは、これはハードウェアセキュリティエンジン(HSE)によって処理され、暗号学的検証(例:署名ベース)ブート中に自律的に実行されます。量産型自動車システムは、CRCのみの検証に頼るのではなく、これらのハードウェアによるセキュリティ機能を活用することが期待されています。
セキュアブートのアプリケーションノート(デモプロジェクトを含む)を提供しています。ダウンロード可能:
https://www.nxp.com/products/S32K3
アプリケーションノートはこちらでご覧いただけます:
ドキュメント -> Secure Files -> Secure Boot アプリケーションノート v0.1.1.0(AN744511)
関連するデモプロジェクトはこちらからダウンロードできます:
デザインリソース - > ソフトウェア - > Secure Files - > SecureBootAppNoteDemo(SW745310)

セキュアブートの他の例はHSEデモ例で見ることができます:
https://www.nxp.com/webapp/Download?colCode=S32K3_HSE_DemoExamples
3つのモードすべてに例があります — 高度なセキュアブート、ベーシックセキュアブート、そしてSHEセキュアブートです。高度なセキュアブートを推奨します。
すべてのプロジェクトに含まれている Readme.md ファイルを参照してください。

3. はい、それは標準的なジャンプシーケンスです。ジャンプする前に、ブートローダーによって初期化されたすべてのリソースを初期化解除することを強くお勧めします。

4. 前述の通り、コードは常にアクティブパーティションから実行されるため、アプリケーションは常に同じリンカーファイルを使用します。

5. 前述の内容です。

6.これはユーザー次第です。アプリケーションイメージの背後やデータフラッシュの背後にデータを保存できます。

7. 量産オートモーティブCASEユースケースでは、提案されたフローはデータ転送の観点から一般的に正しいですが、前述の通りCRCを主な検証メカニズムとして利用することはお勧めしません。
オートモーティブ用途では、受信画像は通常暗号的に保護されており、例えば画像は暗号化され、その真正性や完全性はCRCだけでなくデジタル署名によって検証されます。
また、HSE AB_SWAP機構を使用する場合、ブートローダーはリセット後にソフトウェアのメタデータで新しいイメージを選択するわけではありません。新しいイメージがパッシブパーティションにプログラムされ、正常に検証された後、アプリケーション/ブートローダーはHSEサービスHSE_SRV_ID_ACTIVATE_PASSIVE_BLOCKを呼び出します。これによりパッシブブロックが有効化され、リセット後は新たに起動したパーティションからデバイスが起動します。


8. HSE AB_SWAPは厳密に必須ではありませんが、S32K342の量産オートモーティブFOTAソリューションには強く推奨されます。
HSEなしでFOTAを導入すると、S32K3プラットフォームの主要な利点の一つを活かせないことになります。これらのデバイスの主な利点は、HSEが処理するA/Bスワップ(パーティションリマッピング)の組み込みサポートです。それがなければ、ブートローダーはすべてを手動で管理しなければならないだろう。
具体的には、HSE AB_SWAPなしの場合:
A/B画像の選択には独自の仕組みを実装する必要があります
アドレス空間を慎重に管理し、各アプリケーションを異なる固定場所にリンクする必要があります
画像の交換はハードウェアが自動的に行うのではなく、完全にソフトウェア内で行われます
HSE ABスワップ機能以外に利用可能な代替ハードウェア対応のリマッピング機構はありません

さらに、AB_SWAPと統合されたセキュアブートのシンプルさと堅牢性が失われます。HSEでは、画像の有効化、検証、パーティション間の切り替えが自動車のセキュリティ要件に沿った、より管理的かつ効率的に処理されます。
まとめると、HSEなしでこれを行うことは可能ですが、複雑さが大幅に増し、プラットフォームの重要な利点を失ってしまいます。

「S32K3XX HSE and OTA Advance トレーニング [TR744101]」はダウンロード可能です。ドキュメント - > Secure ファイル: https://www.nxp.com/products/S32K3

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

Tags (1)
No ratings
Version history
Last update:
2 weeks ago
Updated by: