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