2414142_ja-JP

はい

i.MX95: A55は電源投入も電源切断も完了せず、2つの異なるボードで同じように停止する。

概要

i.MX95のカスタムシステムマネージャ設定では、A55論理マシン(LM1)の起動は共有ドライバ関数 SRC_MixSoftPowerUp() (devices/MIMX9/drivers/fsl_src.c) for srcMixIdx = PWR_MIX_SLICE_IDX_A55P (index 11)でフリーズします。 SRC_MixPowerUpCompleted() 決して真を返さない、 FUNC_STAT 混合状態または不整合な状態でフリーズし、最終的にSM自身のWDOG2がFCCUリセットを実行します。

重要なのは、シーケンスが完全な電源オフ・オンサイクルを強制されるとき 電源停止要求も完了しない ハードウェアはこのミックスのソフトウェア電源制御にいずれ方向にも応答しないことです。

同じファームウェアは物理的に異なる2つのボード(FRDM-IMX95 15x/LPDDR4xおよびFRDM-IMX95-PRO 19x19/LPDDR5)で同じように停止しますが、両ボードの工場出荷時のeMMCイメージは完全なLinuxユーザースペースで起動するため、シリコンや基板自体は実証的に対応可能です。

具体的な証拠（下記参照）に基づいて、多くの候補原因を除外することができました。残りの原因についてご助言いただければ幸いです。

環境

商品の価値

SoC	i.MX95 (B0)
ボード	FRDM-IMX95 (15x15、LPDDR4x) そして FRDM-IMX95-PRO (19x19、LPDDR5)
システムマネージャー	nxp-imx/imx-sm で lf-6.18.20-2.0.0-5-g3198944
SM設定	カスタム（SMCT/.mex生成）、ない mx95evk
M33/SMステータス	完全に動作します
M7ステータス	完全に動作 — SCMI、TRDCパーティショニング、STOP/SUSPEND/ディープアイドル、I2C、イーサネットMDIOはすべて機能しています
A55 (LM1)	説明どおりに失敗する
テストされたブートメディア	SD そして eMMC（同一の結果）

兆候

A55はM7からオンデマンドでブートされます SCMI_LmmBoot() （手動でも再現可能） LM1ブート（SMデバッグモニターより）。

SCMI呼び出し自体は成功しました。ステータス = 0
LM1はその後報告する SCMI_LMM_STATE_SUSPEND （状態＝2）
執行が停滞 SRC_MixSoftPowerUp() 待機中 SRC_MixPowerUpCompleted(PWR_MIX_SLICE_IDX_A55P)
FUNC_STAT 400万回以上の投票反復の間、凍結されたままです。
制限が解除されると、SMのWDOG2監視ウォッチドッグがFCCUリセット（errId = 18）を実行し、M7を含むシステム全体がダウンします。

証拠を登録する

SRC_XSPR_CORTEXMIX_PLATFORM （ミックスインデックス11） FUNC_STAT 凍結 0x00001010 または 0x00001011 入国時の状態によって異なります。

7 つのステータスフィールドを解読 PWR_MIX_FUNC_STAT_PUP/PDN:

観測されたフィールド状態

PSW_STAT	「アップ」パターン
SSAR_STAT	「アップ」パターン
A55_HDSK_STAT	「アップ」パターン
SYSMAN_STAT	「アップ」パターン
RST_STAT	「電源オフ」パターン
ISO_STAT	「電源オフ」パターン
MEM_STAT	「電源オフ」パターン

これは、完全に電源が入った状態でも、完全に電源が切れた状態でも一致しない、矛盾した状態であり、進行しません。

ハードウェア測定

スコープが取り付けられました VDD_ARM (出力キャップC211–C215、インダクタL7の後、DCDCの離散PPF5301下流に設置され、このボードには専用ARMレールが搭載されています。その間 LM1ブート試み：

鉄道はすでに稼働しています 約0.92V 試み
それ 目に見えて低下する 試み

つまり、これは単なる権限やタイミング、ソフトウェアのアーティファクトではなく、物理的に観察可能な不完全な電力移行です。

最も有益な単一データポイント

A55Pミックスに対して電源オフと電源オンのサイクル全体を無条件に強制する（ MEM_STAT == 0 ゲート — つまり SLICE_SW_CTRL |= PDN_SOFT、待機電源オフ完了、 SLICE_SW_CTRL &= ~PDN_SOFT、待機 PowerUpCompleted) は、 明示的な電源オフ要求さえも完了しない。 FUNC_STAT 待機中ずっと変化しない。

これは、問題がSRCレジスタインターフェースの下にあることを示唆しており、例えばGPCハンドシェイクの前提条件、SRCブロック自体へのクロックの欠如、ボードやPMICの応答問題などがあり、 SRC_MixSoftPowerUp()自身のシーケンスロジックで修正可能な問題ではないことを示唆しています。

既に調査済みで、証拠に基づき除外済み

PERF_A55 口論 (3 → 0、ODV → PRK 電圧レベル) — どちらの値でもバイトが同一で障害が発生します。DVS/電圧レベルの不一致は除外されます。
config_bctrl.h (SM_BCTRL_A_CONFIG) / SM_BCTRL_W_CONFIG) — 私の設定では空でした。 mx95evkの値は何も変更されませんでした。それから私はライブレジスターを読みました 稼働中の工場システム SMモニター経由（BLK_CTRL_NS_AONMIX） 0x44210008–0x44210024、 BLK_CTRL_WAKEUPMIX 0x42420030–0x42420064) — すべての言葉が一致しました mx95evk 正確に参照してください。
SM_A55P_CONFIG、 config_user.h、TRDC SRC/GPC/ANATOP の許可、WDOG2 タイムアウト — 全て同一であることが確認されました mx95evk は、ブロッカーではないことが確認されています。(SM自身のDOM2 TRDCアクセスはこれらのレジスタに実際に動作しており、レジスタ値の変更を読み書きできます。)注記 SM_A55P_CONFIG そして SM_DDR_CONFIG 空です mx95evk 自身の設定ファイルも。
SRC_MixIsPwrReady() guard — 正しい論理ですが、ここでは正当にfalse(混合ビット状態)を返すため、動作は変わりません。
無条件 SRC_MixSetA55HdskMode(..., ACK_WAIT) — 効果なし。 A55_HDSK_STAT 最初から最後まで正しい「上向き」のパターンだった。
より新しいSMファームウェア — ピン留めされた SRCREV を walnascar → whinlatter スパンにわたって差分化しました: 変更なし にデバイス/MIMX9/ （含む fsl_src.c、 dev_sm_cpu.c、 dev_sm_power.c)
uboot-imx 違い — リリースごとに実際の違いは存在するが、どれも PD_A55P/SRC_XSPR/A55 の電源投入。これは構造的にも真実です。U-Boot SPL は A55号線で、つまりこのパワーアップが既に成功した後にのみ有効です。
ERR053228アナログ(MTR_ACK_CTRL) — i.MX95には、ミックスごとの MTR_ACK_CTRL/MTR_ACK_STAT ハンドセイク(オフセット0x90/0x94)があり、そのリセットデフォルト(CNT_MODE = 0)はハードウェアMTRのアクセントを無期限に待ち、これはスティック MEM_STATに十分にマッチしているように見えました。私が書いた CNT_MODE = 3 （タイムアウトモード）最大 MTR_CNT_CFG 電源投入遷移前に書き込みが有効になることをリードバックで確認しました（いいえ LOCK_CFG 干渉）。 変更なし。
実際の工場APバイナリ — 抽出済み bl31.bin / tee.bin / u-boot* このボードの既知の正常な工場eMMCイメージからそれらを構築し、 flash.bin 変更なし （U-Bootの最初の命令の前に停止が発生するため、これは想定内の動作である。）
ヒューズ/OTP — 除外: ヒューズはダイごとに一度焼却され、工場出荷時のイメージと私のイメージは 同じ物理的な基板。
ブーツミディアム SDカードとeMMCの両方をテストした結果、同一であった。
ファクトリーSMバイナリの由来 これは特に強調しておきたい点です。なぜなら、「NXPは別のSMビルドを出荷している可能性がある」という可能性を排除できるからです。工場出荷時の eMMC の M33 イメージ (ROM コンテナ 3、イメージ 3、 CORE_CM33、コンテナ相対オフセット 0x79000、サイズ 0x2C800) を使用 mkimage_imx8 -soc IMX9 -parse を実行し、抽出を検証しました。 コンテナ自身の記録されたハッシュとの完全なSHA384一致。その建築バナーにはこう書かれている。

SMからのメッセージです（ビルド819、コミットc450f539、2026年3月9日 03:24:50）

c450f539 は (git merge-base --is-ancestor) であることが確認されています。 私のビルドの直接の祖先であり、唯一の介入コミットは fsl_src.c/dev_sm_cpu.c/dev_sm_power.c これは、機能的な変更を一切伴わない、純粋なテスト用足場のクリーンアップです。
A55を正常に起動させる工場出荷時イメージは、私の場合失敗したSMソースと同じ機能的に動作しています。

質問

工場出荷時イメージが機能的に同一のSMソースでA55を起動するのを踏まえると、 outside imx-sm sourceとBCTRLレジスタ構成の違いは何でしょうか?A55Pミックスの電源アップを妨げる可能性があるのです。具体的には、AHAB/ELEコンテナ署名やプロビジョニングのメタデータがA55プラットフォームの電源供給に影響するのでしょうか?
観測された FUNC_STAT パターン (PSW/SSAR/A55_HDSK/SYSMAN) 上、 RST/ISO/MEM （前進ではなく下降）既知の署名？その状態から次にどのような変化が起こると予想されるのか、そしてその変化を促す要因は何なのか？
なぜ明示的な電源オフリクエストも完了しないのですか？ それが最も有力な手がかりのようだ。 SRC_XSPR 応答する SLICE_SW_CTRL.PDN_SOFT このミックスには全く関係ない？
ERR053228以外に、A55Pミックス電源シーケンスに影響を与える既知のi.MX95 B0のエラーはありますか？
A55プラットフォームのミックスに対して、reference mx95evk flowには存在しつつ、生成された config_*.hでは表現 されていない初期化が必要ですかファイル ― つまり、カスタム SMCT ベースの設定では暗黙のうちに省略されるもの？

備考

PROボードにはJTAGが搭載されていない（ヘッダーがない）ため、15x15ボード上の脆弱な0.5mmテストパッドは使用しないことにしました。
上記の診断はすべてSM独自のデバッグモニター（lm info、えーっと、 btime、 MD）、直接レジスタ読み取り、およびスコープ測定。
私はコンテインメント修正を導入しています(元の無制限の待機が有界待ちを置き換えますその間(!SRC_MixPowerUpCompleted()) {;} ループ)を導入し、障害がスムーズに LM1 = 停止に劣化するようにしています。ウォッチドッグのようにシステム全体をリセットするのではなく。もしお役に立つようでしたら、別途お教えいたします。

Re: i.MX95: A55 never completes power-up or power-down — stalls identically on two different boards

上記の投稿は無視して、チケットを閉じてください。先ほどwrynoseを使って新規ビルドをしてみましたが、うまくいきました！以前のビルドではwhinlatterを使用していましたが（FRDM-IMX95に同梱されていたため選択しました）、うまくいきませんでした。