2409898_ja-JP

はい

LSDK 21.08 OP-TEE でブートが壊れる

LS1043AEを使用したカスタム基板では、OP-TEEなしでもセキュアブートが問題なく動作します。OP-TEEをシステムに導入しようとしてコンソールに出力され、そこでハングアップします。

注意：2GB DDR4、32ビット、CL=11、ECCオフ
お知らせ：BL2：v2.4（リリース）：LSDK-21.08-1-ga08bfddba-dirty
お知らせ：BL2：ビルド日時：2026年8月31日 22:39:20
通知：SECブロックの初期化と設定を行っています。
注意：Secは既に初期化および設定済みです。
通知: RSA の検証
通知: ハッシュを検証しています
通知: RSA の検証
通知: ハッシュを検証しています
通知: RSA の検証
通知: ハッシュを検証しています
通知: BL2: BL31を起動しています
お知らせ：BL31：v2.4（リリース）：LSDK-21.08-1-ga08bfddba-dirty
お知らせ：BL31：製造日時：2026年8月31日 22:39:48
お知らせ：ls1043aerb BL31フェーズへようこそ

Google/Geminiによると、GICには問題があると考えているとのことです。ATFとOP-TEEは64kページアラインを使用しているようですが、ubootのdtsファイルでは4kページアラインになっています。この問題ではないと思う、少なくとも今のところは。OP-TEEを全く初期化していないように見えるからです。

ご意見は？

QorIQ LS1デバイス

Re: LSDK 21.08 OP-TEE breaks boot

どうやらU-Bootに問題があるようです。

OPTEEを有効にした状態で通常のU-boot(セキュアなし)を起動できるかどうか試していただけますか?

Re: LSDK 21.08 OP-TEE breaks boot

試してみるのは構わないが、それは何のためのテストなのか？現在、u-bootにどのような問題があると考えていますか？Opteeなしで動作するので、何が問題なのか、何を注意すべきか気になります。

Re: LSDK 21.08 OP-TEE breaks boot

まず最初に確認すべきこと：

TF-Aをデバッグモードで再構築し、正確な停止箇所を確認してください。
実用的であればDEBUG=1 LOG_LEVEL=50を使うか、初期BL31プラットフォームコードにNOTICE()のパンくずを加えることもできます:

プラットフォーム設置エントリー

GIC初期化

TZC/TZASC/TZPC 設定

セキュアペイロードディスパッチャー/OP-TEEセットアップ

BL32エントリーポイント準備
NXPのサポートでは、同様のLS1043Aハングに対するガイダンスとして、ATF/U-Bootのデバッグプリントを追加するか、CodeWarrior/JTAGを使って実行が詰まっている箇所を点検することが挙げられます。

FIPに実際にBL32が含まれていること、そしてBL31がOP-TEEサポートで構築されているかを確認してください。
TF-A の OP-TEE の場合、ビルドには SPD=opteed と BL32= を含める必要があります。セキュアブート/NXP CoT の場合、セキュア TF-A ビルドフローには、TRUSTED_BOARD_BOOT=1、CST_DIR=...、BL32=$TEE_BIN、SPD=opteed、および BL33=$UBOOT_SECURE_BIN も含まれます。
次のようなコマンドを実行してください。

fiptool info fip.bin

BL31、BL32/OP-TEE、およびBL33がすべて存在することを確認してください。BL32が欠落している場合、またはBL31がSPD=opteedで構築されていない場合、OP-TEEは入力されません。

LS1043Aのセキュアブートにおける予約メモリの処理を確認してください。
LS1043Aのセキュアブートに関する問題が報告されていますが、plat/nxp/soc-ls1043a/soc.def NXP_ROM_RSVD の値を0x5900から0x8000に変更することで修正されます。既にセキュアブートを実施していて、さらに署名付きのFIPコンポーネントを追加するのであれば、早めに確認しておく価値があります。これは、後期のU-Boot DTS GICのアライメント問題よりも可能性が高い。

「RSA/ハッシュ検証済み」と表示されているからといって、画像レイアウトが良好であるとは限りません。
BL2ログは検証したコンポーネントの認証が成功したことを証明しますが、ランタイムアドレス、予約メモリの重複、BL32ロードアドレス、またはBL31のセキュアペイロード構成が正しいことは証明できません。BL2は、検証後にBL31/BL32/BL33をDDRにロードしてから、制御をBL31に渡すように文書化されている。

ハングがBL31: Initializing BL32に移動した場合は、OP-TEE本体にフォーカスを移します。
その後の段階では、OP-TEEのロードアドレス、セキュアDDRの切り出し、ページャー/非ページャーのレイアウト、CAAM/SECの設定、およびOP-TEEコンソールを確認します。OP-TEE/暗号化関連のコンテキストにおいて、OP-TEEの暗号化初期化が早期に行われている疑いがある場合、CFG_NXP_CAAM=nおよびCFG_CRYPTO_DRIVER=nを設定してOP-TEEの暗号化/CAAMを無効にすることを推奨するNXPのガイダンスがあります。しかし、現在のログでは、OP-TEEが入力されていることはまだ証明されていません。

私の最も強い仮説は、BL31はOP-TEEを有効にすると異なるビルドや構成がされており、OP-TEEバナーやBL32エントリーの前の初期BL31プラットフォーム/SPDセットアップで止まっているということです。まずはBL31をGIC/プラットフォーム設定に合わせて計測し、FIP/SPD=opteed / BL32=tee.bin/secure-boot CSF レイアウトを実行してから、LS1043A NXP_ROM_RSVD=0x8000 の問題を確認してください。

Re: LSDK 21.08 OP-TEE breaks boot

そこでATFをデバッグでビルドし、サイレントハングの直前に出る最後のメッセージは次の通りです:

情報:BL31:BL32の初期化中

もしあなたの指示を正しく理解していれば、今は特にOP-TEEに集中すべきですよね?

Re: LSDK 21.08 OP-TEE breaks boot

はい、まずOP-TEEを通常の起動(セキュアなし)で確認し、OP-TEEでのビルディングや展開手順に問題がないか確認してください。

Re: LSDK 21.08 OP-TEE breaks boot

おそらく間違ったtee.binファイルを使っていたのだと思います。

私は、OP-TEEを手動でビルドした際に生成されたtee.binを使用しており、生成する必要があったobjcopyバージョンを使用していませんでした。これによりシステムは初期化してLinuxで起動できるようです。

opteeに関するカーネルログのメッセージが他にも残っていますが、この特定の問題は解決したのでこのスレッドは閉じます。