2398221_ja-JP

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

2398221_ja-JP

2398221_ja-JP

NXP iMX8MP: U-Boot内のWFIベースのCPUアイドル状態が復帰しない

親愛なるNXPサポートチームへ、

私たちはi.MX8M Plusベースの製品向けにU-Bootの低消費電力待機メカニズムを調査しており、NXPからの指導を歓迎する段階に達しています。

ソフトウェアのバージョン

  • SoC: NXP i.MX8M Plus
  • BSP:
    • ATF: lf_v2.10_android-15.0.0_1.2.0
    • U-Boot: lf_v2024.04_android-15.0.0_1.2.0
    • 公開されているNXP BSPに基づいています(Varisciteフォークには、ATF/GICコードパスに関する重要な変更は含まれていません)。

ゴール

アプリはAndroidを起動する前に、バッテリーが完全に放電された状態で数分間U-Bootに留まっている必要があります。

mdelay()に基づくビジーループは不必要な電力を消費し、追加の熱を発生させるため、ARMジェネリックタイマー(CNTP, PPI 30)を使って定期的に低消費電力のアイドル状態とウェイクに入ろうとしています。

初期実装

  • CNTPタイマーの設定
  • PPI 30を有効にする
  • EL2から生のwfi()を実行する

プロセッサはwfi()から決して起動しません。UARTの出力は、例外やクラッシュもなく、単に停止するだけです。

PSCIの実装

  • PSCI_VERSIONは1.1を返します。
  • PSCI_FEATURES(CPU_SUSPEND) は 0 を返します (サポートされています)
  • CPU_SUSPENDを呼び出してスタンバイ電源状態を要求します

これにより、ATFスタンバイ実装であるimx_cpu_standby()に到達しますが、システムは全く同じようにハングアップします。例外も発生せず、UART出力もなく、実行は再開されません。

したがって、両方とも:

  • EL2で実行されたraw wfi()
  • wfi() は ATF を介して PSCI で実行されます

全く同じ動作を生み出す。

既に検証済みのもの

CPUとタイマー

  • U-BootはEL2上で実行されます。
  • CNTPタイマーは正しくプログラムされています。
  • CNTP_TVAL_EL0 は正しくカウントダウンします。
  • CNTP_CTL_EL0 には以下が表示されます。
    • 有効 = 1
    • IMASK = 0
    • 武装直後のISTATUSは0です。

CPUインターフェース

  • ICC_PMR_EL1は正しく設定されています。
  • ICC_IGRPEN1_EL1が有効になっています。

仮想化

HCR_EL2には以下が含まれます:

  • IMO = 0
  • FMO = 0

したがって、EL2仮想化による割り込みルーティングは関与しません。

割り込みセキュリティ分類

ATFの情報筋から以下のことを確認しました。

  • すべてのPPIは、汎用GICv3ヘルパーコードによって最初にグループ1非セキュアとして設定されます。
  • SGI8 (およびオプションで SDEI SGI) のみがセキュアとして再構成されます。
  • PPI 30 はセキュア割り込みプロパティテーブルに存在しません。

したがって、Generic Timer 割り込みは予想通りグループ1非安全のままのままです。

SCR_EL3.TWE

当初、非セキュアな wfi() が SCR_EL3.TWE を介して EL3 にトラップされるのではないかと疑っていましたが、wfi() が PSCI を介して ATF 自体の中で実行された場合にも同じ動作が発生するため、これは可能性が低いと思われます。

追加調査

ATFのGIC初期化を追跡していると、gicv3_distif_init()がDistributor EnableGrpビットをクリアし、セキュア割り込みプロパティテーブルで要求されたビットのみを再有効化していることに気付きました。

ヘルパーは Group0 と Group1 の Secure プロパティのみを生成するため、EnableGrp1NS が明示的に再度有効になることはないようです。

これを検証するために、我々は以下のことを行いました。

  • GICD_CTLR を読み込む
  • EnableGrp1NS = 0 を観測しました
  • EL2からEnableGrp1NSを独自に設定しようと試みました。

意外なことに:

  • 書き込みは問題なく完了します。
  • RWPは正常に動作します。
  • しかし、読み戻し後もEnableGrp1NSは0のままです。

また、以下の点も確認しました。

  • GICD_CTLR.DS == 0
  • GICメモリ領域に対するRDC保護は無効になっています(ENA = 0)。
  • RDC違反記録はゼロのままです。

したがって、RDCは書き込みを妨げていないようです。

残りの疑問

現時点で、以下の項目を除外しました。

  • タイマープログラミング、
  • CPUインターフェース構成、
  • 割り込み優先度マスキング、
  • 割り込みグループ分類、
  • SCR_EL3.TWE トラッピング、
  • PSCIと生のWFI実行の比較、
  • RDC保護。

残された説明のつかない挙動は、アーキテクチャ的に非安全な書き込み可能なディストリビュータ制御ビット(EnableGrp1NS)がこのプラットフォーム上で書き込みを受け入れていないようで、その結果、生のwfi()もPSCIもGeneric Timer割り込みで起動CPU_SUSPENDしないことです。

  1. この動作はi.MX8M Plus Android 15 BSPで予想されるのでしょうか?
  2. 汎用タイマーPPIがwfi()からCPUを起動させるために、公開ATFソース以外でプラットフォーム固有の初期化が欠けているのでしょうか?
  3. EnableGrp1NSは、このプラットフォーム上で安全でないソフトウェアによる変更を意図的に防いでいるのでしょうか?
  4. U-Bootから定期的にウェイクアップする機能を、以下のいずれかの方法で実装することに成功した人はいますか?
    • 生のwfi()、または
    • PSCI CPU_SUSPEND
      ARMのジェネリックタイマーで動かされているのか?

初期化シーケンスやプラットフォーム固有の動作についてのご意見をいただけると大変ありがたいです。

よろしくお願いします。

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

桟橋

Tags (1)
No ratings
Version history
Last update:
15 hours ago
Updated by: