現在、`S32K3_HSE_DemoExamples`に含まれる`S32K344_Advanced_SecureBoot`デモを基に、HSEを使用してS32K344/S32K314上でセキュアブート機能を開発しています。機能開発のほとんどは完了しており、デバッグも無事に進めています。私たちの設定プログラムでは、ED25519を使ってBM、FBL、APPの署名を計算し、指定されたアドレスにフラッシュで書き込み、これら3つのアプリケーション(BMは起動前のSMR、FBLとAPPは起動後のSMR)ごとにSMRとCRを設定しています。しかしながら、いくつか不明瞭な点があり、皆様のご協力をいただければ幸いです。現在、HSEのFULL_MEM形式を使用しています。
すべてのアプリケーションバイナリの署名を計算するためにED25519アルゴリズムを使用しているため、設定プログラムの実行に時間がかかります。プログラムが終了する前に予期せず停電が発生した場合、HSEは回復不能なエラー状態に陥ることがわかっています。電源の再投入やファームウェアの再フラッシュを行っても、HSEはホストからの要求に一切応答しなくなった。レジスタ `0x4039C028` (HSE_CONFIG_GPR3) を確認すると、値が `0xC0` であることがわかります。ビット 0 が `0` になっていることから、HSE ファームウェアが SBAF によって消去された可能性があることがわかります。電源投入後、MU0 FSRレジスタも「0」になります。そこで、HSEファームウェアの再インストールを試みました。通常のIVTベースのインストール方法はもはや機能しないため、MUインターフェース経由で設置を試みました。
ドキュメントで説明された手順をシミュレートしましたが、ピンクイメージのSRAMアドレスをMU Txレジスタに書き込む(ステップ5)すると、HSE_CONFIG_GPR3の値がすぐに「0xC2」から「0xC0」へと変化し、ビット1が「1」から「0」に変わり、期待される成功応答「0xDACACADA」は一切受け取れないことがわかりました。
また、フォーラムでも同様の問題について言及しました： S32K3_HSEのMUインストールAB_SWAPプロセスが正しくありません。ステップ5の直後に機能的なリセットを試みましたが、リセット後も新しいHSEファームウェアはインストールできませんでした。
このような腐敗したHSE状態をどのように扱い、回復すればよいかアドバイスいただけますか?
何か調整が必要な場合はお知らせください。
こんにちは@chengjinwang
あなたが共有してくれたプロジェクトのソースファイルは暗号化されているため、読み取ることができません。暗号化されていないプレーンファイルを含むバージョンを提供してください。
数日前に、MUインターフェース経由でHSE AB_SWAPファームウェアを復元するTrace32スクリプトを作成し、すぐにFULL_MEMバージョン用に修正しました。私の環境では正常に動作しており、0xDACACADAという応答を受信しています。
ピンク色の画像の位置を書き込んだ後、次の操作を行うまでに約1.5秒待ちますか？この遅延はFULL_MEMのインストール手順には明示的に記載されていませんが、AB_SWAPバージョンでは必須です。これが問題かもしれません。
もしTrace32を使っているなら教えてください。スクリプトを共有します。
よろしくお願いいたします。
ルーカス
こちらが私がMU経由でHSE FWをインストールするために使っているリカバリープログラムです。何が問題か見てくれないか?
添付ファイルは、私が現在使用しているプロジェクトの暗号化されていないバージョンです。テストには、S32K344チップ、PEデバッガ、および添付ファイルにあるS32DSプロジェクトを使用しています。ピンク色の画像を書き込んだ後、SBAFから正常な応答が得られるまで数秒待ってみましたが、それでもうまくいきませんでした。機能リセットを直接実行しても効果はありませんでした。添付プロジェクトのMUインストールルーチンに問題がないか確認していただけますか?
私は自分のボードでそのプロジェクトをテストしました。まず、起動ファイル内のRAM初期化を修正する必要がありました。ピンク色のファイルをRAMにコピーする際にハードフォルトが発生したためです。これらのHSEデモの例ではRAMの初期化があまり良くないので、私は次のような簡単な修正を行いました:
PemicroデバッガはRAMを自動的に初期化し、機能リセット時でもRAM内容が保持されるため、おそらくこの問題は見られなかったでしょう。しかし、電源を入れても動作しなかった。デバッグにはTrace32を使っていたので、最初から気づきました。
次にIVTを修正しました。ピンクのファイルへのポインタを削除し、最初のリセット後に自動的にインストールされず、Muでインストールを確認できるようにしました。
そして結果として、0xDACACADAという値が得られ、ファームウェアはMU経由でインストールされました。つまり、手順は明らかに正しいのです。
問題は、なぜあなたの側ではうまくいかないのかということです。
お使いのデバイスのSBAFのバージョンは何ですか？0x4039_C020 のダブルワードを読み取ってください。
よろしくお願いいたします。
ルーカス
これが私が読んだ結果です。
こんにちは、 @lukaszadrapa さん。この問題はまだ解決していません。そちらで何か進展がありましたら、お知らせください。ありがとう。
返信が遅くなり申し訳ありません。
お使いのSBAFバージョンは0.15.0で、HSEファームウェア0.2.55.0と完全に互換性があります。これには何の問題もありません。
私のテストでは、サービスHSE_SRV_ID_ERASE_FWを使ってファームウェアを完全に消去したので、パッシブパーティションには有効なバックアップがありません。
あなたの場合、バックアップは利用可能なように見えるので、フローが異なるかもしれません(なぜうまくいかないのかはわかりません)。あなたのコードを見ると、スワップのみが実装されていないことがわかります。コードを追加してみてはどうですか?これで問題が解決するかもしれない。
よろしくお願いいたします。
ルーカス
ありがとう！SWAP要求を直接実行することで、HSEファームウェアの復元に成功しました。しかし、ずっとFULL_MEMファームウェアを使っていたのに、なぜ最終的にAB_SWAPで復元されたのか疑問です。
それは面白い。正直に言うと、私は間違いを犯しました。多くのお客様を行き来していて、なぜかあなたがAB_SWAPを使っていて、FULL_MEMを使っていると思っていたのです。そうでなければ、お勧めしません。2つの可能な説明が考えられます。ファームウェアの有効なバックアップがまだ残っているなら、MUの手順に記載されていなくても「swap」コマンドがFULL_MEMバージョンでも動作する可能性があるFULL_MEM。2つ目は、リカバリーアプリケーションによる機能リセットによりSBAFがファームウェアを完全に消去し、インストールが成功したというものです。よく分かりません。再現して確認するのはかなり難しいです。