こんにちは。以前、HSE_B で OTP (セキュアデバッグパスワード) とライフサイクル (LC) を変更する際に、バックグラウンドプロセスが原因で問題が発生しました。
その結果、OTPおよびLCの更新処理を保護するためにクリティカルセクションを使用するよう助言を受けました。
さらに、 ImportKey、 FormatKeyCatalogs、 SmrEntryInstall、 CrEntryInstallなど、OTPではなくNVM領域にアクセスするサービスリクエストも、クリティカルセクションを使って保護する必要があるのでしょうか?
こんにちは、 @lukaszadrapa さん。
ご返信よろしくお願いします。
CASE、クリティカルセクションに入る代わりに、フラッシュにアクセスする前にHSE_CONFIG_GPR3レジスタを確認してフラッシュアクセス可能かどうかを確認するだけで十分でしょうか?
こんにちは、 @wodudwo さん。
全体像を把握するには、HSEファームウェアのリファレンスマニュアルの説明を読むことをお勧めします。2.7節：
「14.6.5HSEとアプリケーションコア間のフラッシュ読み書きアクセスの同期」:
https://www.nxp.com/webapp/sd/collateral/1765990353647716033651?version=2.7
表149、150、151には典型的なシナリオの詳細が記載されています。
要するに、HSEファームウェアが実行されている場合、そのファームウェアが実行されているフラッシュブロックをプログラムすることはできません。S32K344 CASE や FULL_MEM CASE (あくまで例ですが) ではブロック3、AB_SWAP CASE ではブロック1です。HSEがアイドル状態になるまで待ち、その後他のHSEサービスを起動しないことが大切です。
HSEがSYS-IMGに対してフラッシュ操作(キーカタログのフォーマット、キーのインポート、NVM属性の書き込みなど)を行っている場合、さらにデータフラッシュメモリへのアクセスは不可能です。
HSEがOTPデータ(属性、ライフサイクル進行、パスワードのプログラミングなど)を書き込んでいる場合、UTESTとフラッシュブロック0の両方にアクセスすることはできません。なぜなら、UTESTとフラッシュブロック0が同じ読み取りパーティション内にあるからです。そして、ADKPプログラミングやライフサイクル進行に問題がある場合、これが重要なポイントとなるようです。フラッシュブロック0から移動する必要があるものについて説明したこちらの投稿をご覧ください。
https://community.nxp.com/t5/S32K/S32K324-HSE-Setting-ADKP-Issue/mp/2369325/highlight/true#M58774
また、フラッシュとHSEの同期について話す際、RTDのFLSとCRYPTOモジュール間の同期サポートがバージョン5.0.0以降に追加されたことに注目してください。
以下はバージョン6.0.0のスクリーンショットです。
古いRTDバージョンを使う場合は、ユーザーが対応する必要があります。この同期では、OTP属性をUTESTにプログラミングする際の問題は解決されないことに注意してください。コードはフラッシュブロック0から移動させる必要がある。
よろしくお願いいたします。
ルーカス
こんにちは、 @lukaszadrapa
ご説明ありがとうございました。
私の理解が正しければ、HSE_CONFIG_GPR3レジスタのチェックだけでは不十分であり、クリティカルセクションを用いた保護が依然として必要となる。
私の理解では、割り込みが発生しても、フラッシュにアクセスする前にHSE_CONFIG_GPR3レジスタを確認することで、アプリケーションコアとHSEコアが同時に同じフラッシュブロックにアクセスするのを防ぐはずです。
クリティカルセクションが使われない場合、アプリケーションコアとHSEコア間の同時フラッシュアクセス以外に起こりうる問題はありますか?
状況によります。
「さらに、 ImportKey、 FormatKeyCatalogs、 SmrEntryInstall、 CrEntryInstallなど、OTPではなくNVM領域にアクセスするサービスリクエストも、クリティカルセクションを使って保護する必要があるのでしょうか?」
このシナリオでは、答えはノーです。HSE_CONFIG_GPR3、HSEがフラッシュブロックで読み書き/実行やプログラム/消去をブロックした場合にユーザーに通知します。しかし、これはあなたのコードにおけるクリティカルセクションのような保護機能ではありません。クリティカルセクションは、データフラッシュにアクセスする割り込みや、操作に干渉する割り込みが起きないことを保証します。しかし、これはHSE_CONFIG_GPR3の状態とは何の関係もありません。
いずれにせよ、ImportKey、FormatKeyCatalogs、SmrEntryInstall、CrEntryInstallといったサービスは、管理された環境下で順番に実行する必要のある重要な構成サービスです。クリティカルセクションを使用するのは理にかなっている。その間に重要な割り込みを処理する必要がある場合には、使用される割り込みリソースがHSEおよびHSEで使用されるフラッシュブロックに干渉しないようにする必要があります。
先ほど述べたHSEファームウェアリファレンスマニュアルの表149、150、151に戻ります。プログラムの流れを評価し、表に記載されているシナリオと比較し、対策が必要かどうかを判断する必要があります。そうでなければ、HSEがアプリケーションコアを妨害したり、その逆を妨げるリスクがあります。
よろしくお願いいたします。
ルーカス
こんにちは、 @lukaszadrapa
ご説明ありがとうございました。あなたの回答は大変参考になりました。
こんにちは、 @lukaszadrapa
ご返信よろしくお願いします。
HSEファームウェアリファレンスマニュアルの表149、150、151によると、同時フラッシュプログラム/消去操作の同期要件を説明しています。
同期手順は不要です。M7_0/1コアは、データフラッシュをプログラムしている際にHSEに対してプログラム/消去操作に関するコマンドを出さないことが期待されています。
逆に、アプリケーションコアがプログラム/消去操作を行っている間にHSEがすでにプログラム/消去操作を行っている場合も問題になるのでしょうか?
もしそうなら、アプリケーションコアがプログラム/消去操作を開始する前に、HSE_CONFIG_GPR3レジスタの21:16だけでなく29:24ビットもチェックすることでこの状況を防げますか?
この方法ではこのような競合を防ぐのに十分でない場合、これらのサービス要求を保護するための推奨される解決策はクリティカルセクションを使用することでしょうか？
さらに、表はアプリケーションコアがコードフラッシュブロックからコードを実行している間に、HSEが同じコードフラッシュブロックに対してプログラム/消去操作を行う場合を明示的に説明していません。
このシナリオは、同期処理なしでも安全だと考えられるのでしょうか、それとも何らかの保護対策が必要でしょうか？
このシナリオにおいて保護が必要な場合、推奨される実装方法はどのようなものでしょうか？
逆に、アプリケーションコアがプログラム/消去操作を行っている間にHSEがすでにプログラム/消去操作を行っている場合も問題になるのでしょうか?
- はい、問題はあります。なぜなら、フラッシュ操作を同時に実行できなくなるからです。
もしそうなら、アプリケーションコアがプログラム/消去操作を開始する前に、HSE_CONFIG_GPR3レジスタの21:16だけでなく29:24ビットもチェックすることでこの状況を防げますか?
- はい。これは、HSEがすでにフラッシュをプログラムしていて、アプリケーションコアが別のフラッシュ操作を始めたい場合に役立ちます。
この方法ではこのような競合を防ぐのに十分でない場合、これらのサービス要求を保護するための推奨される解決策はクリティカルセクションを使用することでしょうか？
- HSEが前述のNVM操作(カタログ形式、キーインポートなど)を行う際、アプリケーションは他のフラッシュ操作を開始しず、HSEがプログラムしているフラッシュブロックにもアクセスしてはいけません。割り込みハンドラによってそのような処理が行われる場合、クリティカルセクションによってこの競合は防止されます。
さらに、表はアプリケーションコアがコードフラッシュブロックからコードを実行している間に、HSEが同じコードフラッシュブロックに対してプログラム/消去操作を行う場合を明示的に説明していません。
このシナリオは、同期処理なしでも安全だと考えられるのでしょうか、それとも何らかの保護対策が必要でしょうか？
- コードフラッシュメモリは、HSE/SBAFがHSEファームウェアをインストール/更新/復旧/消去する場合にのみ、HSEによってプログラムされます。これはリセット後に自動的に行われるか、ソフトウェアによってトリガーされます。
HSEファームウェアは、コードフラッシュの末尾（FULL_MEMバージョン）またはアクティブブロックとパッシブブロックの末尾（AB_SWAPバージョン）に配置されます。アプリケーションは下位のフラッシュブロックから開始することが期待されており、初期化が完了し、HSEが初期化(および可能なフラッシュ操作)を完了するまで待ちます。ですので、このケースにはリスクはありません。アプリケーションがHSEファームウェアの更新をトリガーした場合、対応するフラッシュブロックがこの操作中にアクセスされないようにするのはユーザーが確認します。
このシナリオにおいて保護が必要な場合、推奨される実装方法はどのようなものでしょうか？
- 前述の通り – リセット後は、初期化が完了するまでHSEファームウェアを含むフラッシュブロックにアクセスしないでください。また、ソフトウェアがHSEファームウェアアップデートを開始する際にフラッシュブロックにアクセスしないでください。