カスタム ハードウェアで Linux カーネル 3.0.21 を使用しています。
ハードウェアを初めて起動すると、正常に起動します。
適切にシャットダウンしてハードウェアを再起動すると、正常に起動します。
しかし、システムが起動したら、rebootコマンドを入力するとカーネルが再起動し、ハングします
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
ソフト再起動のたびにこれに直面する理由がわかりません。これを回避するには、ハード リセットする必要があります (電源をオフにして、もう一度電源をオンにします)。
なぜ私はこの問題に直面しているのですか? カーネルに欠落しているクリーンアップ機能はありますか? この問題をデバッグするには?
はい、ハードウェアのプラットフォームサポートのどこかで、ソフトリブートに対処するためのロジックが欠落しているようです。
クリーンアップコードを追加しても、システムがクラッシュしてからソフトリブートされる可能性があるため、問題は解決しません。
したがって、システムを起動するコードは、システムがソフトリブートされることに対処するために作成する必要があります。
デバッグするには、最初に、ソフトリブート中にカーネルがスタックしている場所を見つける必要があります。これを行う最も簡単な方法は、ハードウェアデバッガーを使用することです。
もう1つのオプションは、起動コードを読み、コールドリブートに依存している可能性のある領域を見つけて動作させることです。起動時などにTLBがクリアされることを期待するコード。
再起動する前にハードウェアを無力化できなかったようです。候補として考えられるのは、MMU、TLB、キャッシュ、または割り込みです。これらが再有効化されると、カーネル起動の早い段階でクラッシュが発生します (これは、カーネルが再起動前にそれらをすべて無効にできなかったか、またはもちろんソフトにならないハードリセット状態に依存しているブートローダーである可能性があります)。リセットします）。
他の人が指摘しているように、JTAG ハードウェア デバッグ プローブは、この問題を解決する唯一の方法です。
デバッグを開始するには、有効にしています
CONFIG_DEBUG_LL=y
カーネルビルドで。これにより、追加のデバッグが有効になります...ハングアップの場合と正常な起動の場合、ログとデバッグを比較して、カーネルがスタックしている場所を調整します....そしてその理由