組み込みデバイスでセキュア ブートを正常に有効化しました。問題は、このモードで起動すると、次の行の直後でプロセスが停止してしまうことです。
Starting kernel ...
U-boot がカーネルをメモリにコピーし、bootmコマンドを発行すると、
yieldデバッガーでは、PC が命令とそれに続く割り当てで停止していることpc = pc-4、つまり本質的にループしていることをキャプチャできます。
これまで Linux をこれほど低いレベルで扱ったことがないので、どこから調べ始めればよいかわかりません。ただし、セキュア モードではないときにカーネル イメージを正常に起動できることに気付いたので、これはベンダーに問い合わせたほうが適切かもしれません。
1) 一般的に、実行ハンドオフ段階に関する U-Boot 診断情報はどこで入手できますか?
2) どの時点で実行がカーネルに完全に委ねられるのでしょうか? つまり、U-boot が機能しなくなるのはいつですか?
答え1
次の手順で Linux の初期プリントのメモリをダンプできる可能性があります。原因としては、カーネルが起動しているが、コンソールの初期化前にハングしていることが考えられます。また、uboot のカーネル エントリ ポイントにプリントを配置し、制御がカーネルに渡されていることを確認します。
ファイルを見つけますSystem.map。以下のコマンドを使用してlog_bufアドレスを特定します。
grep __log_buf System.map
次のような出力になります
c0352d88 B __log_buf
ボードをウォームブートします (RAM の内容は消去されません)。
Uboot で (c0352d88) のメモリをダンプします__log_buf。カーネル コンソールの出力がダンプされます。これにより、ハングが発生した場所を特定できます。
答え2
私も同じ問題に直面したことがあり、解決策を見つけました。問題は、のu-boot structure fieldを保存する の 1 つにあります。 は、このフィールドに圧縮されていないサイズを入力しません。 は、後で のサイズを変更するためにこのサイズを使用します。そのため、システムは未定義の状態になります。sizeuncompressed linux kernel.u-bootlinux kernelstack
u-bootメッセージが印刷されるとStarting kernel...、次のメッセージは、Uncompressing Linux... done, booting the kernelu-boot がSMM Handlerカーネルに実行を引き継ぐためにを転送した後に表示されるはずですkernel。おそらく がこのフィールドを探しているのでしょう。 ベースのシステムで作業している場合x86、解凍は次のファイル ディレクトリにあります。
arch/x86/boot/uncompressed/head_32.S
arch/x86/boot/uncompressed/piggy.S
解決策は、ここにある最新の u-boot を使用することです。https://github.com/andy-shev/u-boot
ただし、カスタム u-boot を使用している場合は、このフィールドを探す必要があります。
答え3
x86 ですか?earlycon=efifbまたはで起動しますearlyprintk=vga。コミット 69c1f396f25b805aeff08f06d2e992c315ee5b1e の頃に earlyprintk から earlycon への変更があったため、両方について言及しています。