我在我的自定義硬件上使用Linux內核3.0.21。當軟重啓Linux內核掛起在「解壓Linux ...完成，引導內核」
當我第一次啓動硬件時，它成功啓動。
如果我正確關閉並重新啓動硬件，它會成功啓動。
但一旦系統啓動運行，當我輸入reboot命令重新啓動的內核，並在
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
掛我不知道爲什麼，我在每個軟重啓面臨這樣的。爲了避免這種情況，我需要硬復位（關閉電源並再次打開電源）。
爲什麼我面臨這個問題？ 內核中是否有任何清理功能缺失？ 如何調試此問題？
要開始調試運行我在內核構建使
CONFIG_DEBUG_LL=y
。這給了一些額外的調試啓用...在掛斷的情況下，succesfull啓動的情況下，我比較日誌和調試調整哪裏馬內核卡住....爲什麼
是的，它聽起來像在某個地方的平臺支持你硬件，你錯過了一些邏輯來應對軟重啓。
添加清理代碼並不能解決問題，因爲系統可能會崩潰，然後軟重啓。
因此需要編寫引導系統的代碼來應對軟重啓系統。
要進行調試，首先需要找出軟重啓過程中內核堵塞的位置。最簡單的方法是使用硬件調試器。
另一種選擇是通讀啓動代碼，並嘗試找出任何可能依靠冷重啓工作的區域，例如。希望TLB在引導或類似時被清除的代碼。
聽起來像在重新引導之前無法消除硬件。可能的候選人是MMU，TLB，緩存或中斷。這些崩潰在內核啓動的早期就會發生，當它們被重新啓用時（這可能是內核在重啓之前無法全部禁用它們，或者依賴於硬重置狀態的啓動加載器，當然，重啓）。
正如其他人所說的那樣，JTAG硬件調試探測器只是您不能完成此任務的唯一方法。
我想你不會找到關鍵的質量SO回答這個問題。如果它是ARM板，你可能會在arm-linux-kernel郵件列表中找到更好的支持。順便說一下，您應該指定您的開發板所基於的特定CPU。 – shodanex
OMAP？非定製硬件是否會出現同樣的問題？我曾經測試過的 – shodanex
。但我的內核上有一些補丁用於我的定製主板，所以我很懷疑它不適用於非定製主板 –