私の組み込みデバイスでセキュアブートを正常に有効にしました。問題は、このモードで起動すると、次の行以降にプロセスが中断されるようです。
Starting kernel ...
U-bootがカーネルをメモリにコピーし、bootmコマンドを実行すると。
デバッガでは、PCがyieldコマンドに停止し、割り当てにかかることをキャッチできました。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つが圧縮されていないサイズでフィールドを埋めるのではなく、後でそのサイズを使用してsizeサイズuncompressed linux kernel.を変更するため、システムが未定義のままになることです。u-bootlinux kernelstack
u-bootこのメッセージが印刷されると、u-bootがaを呼び出してカーネルに実行を引き継ぎ、おそらくこのフィールドを見つけた後にStarting kernel...次のメッセージを表示する必要があります。基本ベースのシステムを使用している場合、解凍は次のファイルディレクトリにあります。Uncompressing Linux... done, booting the kernelSMM Handlerkernelx86
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に変更があったので、両方を言及しました。