我已成功在嵌入式裝置上啟用安全啟動。問題是，當我在此模式下啟動時，該過程似乎在該行之後卡住了：
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儲存 的 的之一中，沒有使用未壓縮的大小填充該字段，size稍後uncompressed linux kernel.會使用該大小來調整其大小，從而使系統進入未定義的狀態。u-bootlinux kernelstack
一旦u-boot列印了這條Starting kernel...訊息，下一則訊息應該是Uncompressing Linux... done, booting the kernel在u-boot呼叫aSMM 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 發生了變化。