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

6
我花了几天时间尝试理解,但我卡住了。在我的STM32F429I-DISC1板上输入“bootm 8100000”后,我只得到一个“Starting kernel…”的消息。
在将uboot从2011年更新到2016年之前,它是“Starting Kernel…”+ UNHANDED EXCEPTION HARDFAULT,但现在我只有“Starting Kernel…”的消息。
MCU是stm32F429,2MB Flash + ext. 8MB RAM。
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'内核/配置文件,我得到了相同的日志,除非入口点似乎更正确,因为它是08100001。
在robutest/emcraft内核上,我尝试激活板子的LCD屏幕,但没有任何反应。
在所有测试中,我都激活了内核配置中的"early printk"和"DEBUG_LL_xxx"选项。
这是我的.config文件链接:http://pastebin.com/gBNYx3Gs 附注:我尝试使用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 ...

编辑3:我在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。


1
Stack Overflow是一个关于编程和开发问题的网站。这个问题似乎不属于编程或开发范畴。请参阅帮助中心中的我可以在这里问什么样的问题。也许超级用户Unix&Linux Stack Exchange更适合提问。另请参阅我应该在哪里发布Dev Ops相关问题? - jww
1
@jww 我们正在谈论软件开发,即使是针对嵌入式设备。 你能告诉我如何设置输出UART吗?我认为这个连接是由dtb完成的。 - svalsesia
2个回答

4

我找到了!

谢谢亚历山大,UART技巧非常有效!!多亏了你,我第一次尝试在嵌入式系统中破解内核,学到了很多东西。

对于那些遇到这个问题的人,对我来说是XIP_PHYS_ADDR的问题!别忘了64字节的头文件!!

我正在将XIP内核刷写到0x08060000,所以XIP_PHYS_ADDR(以及引导项)应该是0x08060040!!

再次感谢亚历山大!!


1
顺便说一句,我不知道为什么我将“正常”的内核解压到RAM中然后启动时不起作用......但我稍后会看到这个问题,现在我有更多的RAM :)由于XIP引起的损失大约是500ko的ROM,使我节省了2Mo的RAM。我并不真正需要很多RAM,但我们永远不知道,现在它可以工作 :) - svalsesia
2
很高兴看到你做到了!祝你在编程中好运! - alexander
2
你对VFS ramdisk有了解吗?:P - svalsesia

1
我曾经遇到过同样的问题,但原因不同。问题出在一个名为“u-boot结构字段”的地方,它存储了“未压缩Linux内核”的“大小”。 u-boot没有将此字段填充为未压缩大小,而后来的“Linux内核”使用该大小来调整其“堆栈”,从而使系统进入未定义状态。
一旦“u-boot”打印出“Starting kernel…”消息,下一条消息应该是“Uncompressing Linux… done, booting the kernel”,之后“u-boot”会传输一个“SMM Handler”给内核接管执行,也许“内核”正在寻找此字段。如果您正在使用基于“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,则需要查找此字段。

谢谢添加,可能会帮助到某人 :) - svalsesia

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接