我已成功在嵌入式设备上启用安全启动。问题是，当我在此模式下启动时，该过程似乎在该行之后卡住了：
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 发生了变化。