Linux内核挂在“启动内核.”

Question

我已经成功地在嵌入式设备上启用了安全启动。问题是，当我在这种模式下启动时，进程似乎在行之后就被卡住了：

Starting kernel ...

一旦U复制了内存中的内核并发出了一个bootm命令。

在调试器中，我能够捕捉到PC卡在yield指令上，然后是分配给pc = pc-4 -所以本质上是一个循环。

我从来没有在这么低的水平上提过linux，所以我不知道该从哪里开始研究。不过，我确实注意到，在不处于安全模式时，我能够成功地引导内核映像，因此对于供应商来说，这可能是一个更合适的问题。

1)一般来说，在哪里可以找到有关执行切换阶段的U-boot诊断信息？

2)在什么时候执行完全给内核？也就是说，U引导何时失效？

Answer 1

您可以使用下面的过程转储linux早期打印的内存。原因可能是，内核正在引导，但它挂在控制台init之前。此外，在uboot的内核入口点放置打印，并确认将控制交给内核。

查找System.map文件。使用下面的命令标识log_buf地址：

grep __log_buf System.map

这将输出类似于

c0352d88 B __log_buf

热启动板(内存中的内容不应被擦除)。

在Uboot中，转储__log_buf (c0352d88)的内存。它将转储内核控制台打印。这样你就可以确定扩展挂起发生在哪里了。

Answer 2

我也面临过同样的问题，并找到了解决办法。问题在于存储u-boot structure field的size of uncompressed linux kernel. u-boot没有使用未压缩的大小填充该字段，linux kernel稍后使用该大小来调整stack的大小，从而使系统处于未定义的状态。

一旦u-boot打印了Starting kernel...消息，下一条消息应该是u引导后的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名词：https://github.com/andy-shev/u-boot。

但是，如果您使用的是自定义的u引导，则需要查找此字段。

Answer 3

x86？使用earlycon=efifb或earlyprintk=vga引导。我提到这两者，因为在提交69c1f396f25b805aeff08f06d2e992c315ee5b1e时，从earlyprintk到earlycon发生了更改。