Linux内核引导在“解压缩Linux”时停止...好的，引导内核

Question

我有一个关于将内核从旧SH4移植到新SH4的问题。 请让我展示它们之间的区别。

[旧SH4]
引导加载程序：redboot v2.0
内核版本：2.4

[新SH4]
引导加载程序：u-boot v2009.03
内核版本：2.6

在旧的SH4中，许多源代码都是基于内核2.4开发的，因此将内核2.4移植到新的SH4看起来比在内核2.6中重新编译源代码更容易。 因此，我将mkimage应用于为旧版SH4开发的zImage，如下所示。

mkimage -A sh -O linux -T kernel -C none -a 0x8c210000 -e 0x8c210000 -n 'Old kernel' -d zImage uImage

如下图所示，该图像已加载到新的SH4上。

tftpboot 8c800000 uImage
cp.b $(fileaddr) a0100000 $(filesize)
bootm a0100000

但是，在“解压缩Linux ...好，启动内核”之后，启动停止并挂起。 我发现无限循环发生在kernel / head.S的以下几行，但是我想这些行没有问题，因为kernel / head.S没有经过定制，并且可以在旧版SH4上运行。

   !               Clear BSS area
   mov.l   3f, r1 ! __bss_start
   add     #4, r1
   mov.l   4f, r2 ! _end
   mov     #0, r0
9: cmp/hs　r2, r1
   bf/s    9b     ! while (r1 < r2)
   mov.l　 r0,@-r2

因此，我想这个问题来自新旧SH4之间的环境差异。 在旧版SH4中，我执行fconfig命令并设置变量，如下所示。

Load Linux Kernel & File System: true
Linux Kernel Destination address: 0x8c210000
Linux Kernel Source address: 0x80140000
Linux Kernel Size: 0x100000
RAM disk Destination address: 0x8c360000
RAM disk Source address: 0x80140000
RAM disk Size: 0x400000
Modify Linux Kernel Parameter: true
Linux Kernel base address: 0x8c001000
Linux Kernel ENTRY address: 0x8c210000
Linux Kernel INITRD size: 0xc00000
Linux Kernel INITRD start address: 0x360000
Linux Kernel loader type: 1
Linux Kernel mount root read only: 1
Linux Kernel original root device: 0x100
Linux Kernel RAM disk flags: 0
Linux Kernel Enable Virtual Terminal Console: false

我认为我可以在新的SH4上设置这些参数，尽管u-boot没有fconfig命令。 但是我找不到如何设置参数Linux Kernel Source address和Linux kernel base address。 这与挂起问题有关吗？ 否则，由于我是Linux嵌入式系统的新手，因此有关下一步应检查的任何建议都会有所帮助。

谢谢你的帮助。

将帖子
在下面添加了信息，以显示u-boot上的printenv结果。

bootcmd =打开
靴子a0100000
的bootdelay = 2
波特率= 115200
网络掩码255.255.255.0 =
IPADDR = 192.168.1.2
SERVERIP = 192.168.1.1
gatewayip = 0.0.0.0
bootargs =控制台= ttySC1,115200，N，8 mem = 32M ether = 8,0x1300,0,0，eth0 video = e1356fb：system：ms104sh4，display：crt，bpp：8,800x600 @ 60
标准输入=串行
标准输出=串行
标准错误=串行

Answer 1

我从未使用过SH4，但过去这对我有帮助： http ： //www.denx.de/wiki/view/DULG/LinuxPostMortemAnalysis