运行 Linux Cortex-M4 STM32F4 (29I-DISC1) 上的 4.9

Question

我花了几天时间试图理解，但我被卡住了。在我的 STM32F429I-DISC1 板上输入 'bootm 8100000' 后，我只收到一条 "Starting kernel..." 消息。

在我将 uboot 从 2011 更新到 2016 之前这是一个 "Starting Kernel..." + 未处理的异常硬故障，但现在我只有 "Starting Kernel..." 消息。

MCU 是 stm32F429，2MB Flash + ext。 8MB 内存。

Flash 起始地址是 0x08000000（uboot 地址），我把我的内核放在第二个 flash bank 的开头 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

这就是我构建内核的方式：

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' kernel/config 文件，我得到了相同的日志，除非入口点看起来更正确，因为它是 08100001。

在robutest/emcraft内核上，我尝试激活开发板的液晶屏，但没有任何反应。

在我所有的测试中，我激活了内核配置 "early printk" 和 "DEBUG_LL_xxx" 东西。

这是我的 .config 文件的 link： http://pastebin.com/gBNYx3Gs

PS：我尝试使用 uCLinux emcraft/robutest 试图找出发生了什么，但我的主要目标是运行 Linux 4.9.

感谢阅读我！！！

编辑：我试图通过 dtb "the old way"，但结果相同：

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 ...

我很绝望，欢迎任何想法:'(

EDIT2：我试过用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中的memory/USART1地址，没问题。为什么我没有内核消息？

EDIT4：使用 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。

Answer 1

找到了！

谢谢 alexander，UART 的技巧非常有用！！！！多亏了你，我第一次尝试破解嵌入式系统的内核，多亏了你，我学到了很多东西。

对于那些会遇到这个问题的人，对我来说是XIP_PHYS_ADDR！不要忘记 64 字节 header!!

我正在刷新 XIP 内核 @ 0x08060000，所以 XIP_PHYS_ADDR（顺便说一句，引导条目）是 0x08060040！！！！

再次感谢亚历山大!!

Answer 2

我遇到过同样的问题，但原因不同。问题出在存储 uncompressed linux kernel. 的 size 的 u-boot structure field 之一 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，则需要查找此字段。

运行 Linux Cortex-M4 STM32F4 (29I-DISC1) 上的 4.9

Running Linux 4.9 on Cortex-M4 STM32F4 (29I-DISC1)

linux

linux-kernel

embedded-linux

u-boot

stm32f4