我花了几天试图了解，但我卡住了。 在我的STM32F429I-DISC1板上input'bootm 8100000'后，我得到的只是一个“正在启动内核…”的消息。
在我更新uboot之前，从2011年到2016年这是一个“正在开始的内核…”+未被发现的exception硬件，但现在我只是“正在启动内核…”消息。
单片机是一个stm32F429,2MB的Flash +分机。 8MB RAM。
Flash启动addr是0x08000000 （uboot addr），我把我的内核放在0x08100000第二闪存银行的开始 。
外部8MB RAM的开始是0xD0000000
u-boot-2016.11似乎在板子上运行的很好，bdi给我：
U-Boot > bdi arch_number = 0x00000000 boot_params = 0xD0000100 DRAM bank = 0x00000000 -> start = 0xD0000000 -> size = 0x00800000 current eth = unknown ip_addr = <NULL> baudrate = 115200 bps relocaddr = 0xD07D6000 reloc off = 0xC87D6000 irq_sp = 0xD05D3EE0 sp start = 0xD05D3ED0 Early malloc usage: e0 / 400 这是我如何build立内核：
make CROSS_COMPILE=arm-none-eabi- ARCH=arm uImage LOADADDR=08100000 -B
这是bootm命令的完整输出：
U-Boot > bootm 8100000 ## Booting kernel from Legacy Image at 08100000 ... Image Name: Linux-4.9.0 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 839872 Bytes = 820.2 KiB Load Address: 08100000 Entry Point: 08100000 Verifying Checksum ... OK Loading Kernel Image ... OK Starting kernel ...
使用'robutest'/'emcraft'内核/configuration文件，我得到了相同的日志，除非入口点似乎更正确，因为它是08100001。
在robutest / emcraft内核上，我尝试激活电路板的LCD屏幕，但没有发生任何事情。
在我所有的testing中，我激活内核configuration“早期printk”和“DEBUG_LL_xxx”的东西。
这是我的.config文件的链接： http : //pastebin.com/gBNYx3Gs
PS：我尝试了一下uCLinux emcraft / robutest来试图找出发生了什么，但是我的主要目标是运行Linux 4.9。
感谢您阅读我！
编辑：我试图通过dtb“旧的方式”，但具有相同的结果：
U-Boot > bootm 08100000 - 08040000 ## Booting kernel from Legacy Image at 08100000 ... Image Name: Linux-4.9.0 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 805744 Bytes = 786.9 KiB Load Address: 08100000 Entry Point: 08100000 Verifying Checksum ... OK ## Flattened Device Tree blob at 08040000 Booting using the fdt blob at 0x8040000 Loading Kernel Image ... OK Loading Device Tree to d05ce000, end d05d2a9f ... OK Starting kernel ...
我很绝望，欢迎任何想法：'（
编辑2：我试图用u-boot解压缩内核，它是一样的：
U-Boot > bootm 8100000 - 8040000 ## Booting kernel from Legacy Image at 08100000 ... Image Name: uImage Image Type: ARM Linux Kernel Image (gzip compressed) Data Size: 940696 Bytes = 918.6 KiB Load Address: d0008000 Entry Point: d0008001 Verifying Checksum ... OK ## Flattened Device Tree blob at 08040000 Booting using the fdt blob at 0x8040000 Uncompressing Kernel Image ... OK Loading Device Tree to d05ce000, end d05d2a9f ... OK Starting kernel ...
EDIT3：我检查了dtb中的内存/ USART1地址，没关系。 为什么我没有内核的消息？
编辑4：与uxipImage：
U-Boot > bootm 08060000 - 08040000 ## Booting kernel from Legacy Image at 08060000 ... Image Name: uxipImage Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 1497396 Bytes = 1.4 MiB Load Address: 08060000 Entry Point: 08060041 Verifying Checksum ... OK ## Flattened Device Tree blob at 08040000 Booting using the fdt blob at 0x8040000 Loading Kernel Image ... OK Loading Device Tree to d05ce000, end d05d2a9f ... OK Starting kernel ...
我尝试了不同的入口点，08060000，08060040和08060041。
我发现！
谢谢亚历山大，UART作品的窍门就像一个魅力！ 感谢你，第一次尝试在嵌入式系统中破解内核，并且由于你的学习，我学到了很多东西。
对于那些有这个问题的人来说，对我来说就是XIP_PHYS_ADDR！ 不要忘记64个字节的标题！
我闪烁的XIP内核@ 0x08060000所以XIP_PHYS_ADDR（和启动项btw）它是0x08060040！
亚历山大再次感谢你！
我面对同样的问题，但原因是不同的。 问题出在u-boot structure field ，它存储了uncompressed linux kernel.的size uncompressed linux kernel. u-boot并没有使用未压缩的大小填充这个字段， linux kernel稍后使用它调整它的stack大小，从而使系统进入未定义的状态。
一旦u-boot打印Starting kernel...消息，下一个消息应该是Uncompressing Linux... done, booting the kernel在u-boot传送一个SMM Handler给内核接管执行之后启动内核，也许kernel正在寻找这个领域。 如果您正在使用基于x86的系统，则解压缩将位于以下文件目录中：
arch/x86/boot/uncompressed/head_32.S arch/x86/boot/uncompressed/piggy.S
解决方案是在这里使用最新的u-boot foun： https ： //github.com/andy-shev/u-boot
但是，如果您使用自定义的u-boot，则需要查找此字段。