[U-Boot] The system hangs when the load_address==os.start, using uncompressed Image, ARM11.

Hi guys, I am trying to set the load_address same as os.start, which means the os.load equals os.start, to avoid copying the image from the os.load to os.start. The uncompressed kernel image Image is employed to generate the uImage, through following command. mkimage -A arm -O linux -T kernel -C none -a 80008000 -e 80008040 -n Linux-2.6.28 -d Image uImage Using the following boot command to boot up the kernel, but it hangs. Uboot> tftp 0x80008000 uImage;bootm 0x80008000
The boot log is as follows.
Loading from NAND 2GiB 3,3V 8-bit, offset 0x100000 Image Name: Linux-2.6.28 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 1911932 Bytes = 1.8 MB Load Address: 80008000 Entry Point: 80008040 Automatic boot of image at addr 0xc0008000 ... * kernel: default image load address = 0xc0008000 ## Booting kernel from Legacy Image at c0008000 ... Image Name: Linux-2.6.28 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 1911932 Bytes = 1.8 MB Load Address: 80008000 Entry Point: 80008040 kernel data at 0xc0008040, len = 0x001d2c7c (1911932) ## No init Ramdisk ramdisk start = 0x00000000, ramdisk end = 0x00000000 bootm load os front load: = 80008000 blob_start: = c0008000 image_start:= c0008040 image_len := 1d2c7c XIP Kernel Image ... OK OK kernel loaded at 0xc0008000, end = 0xc01dacbc ----boot_fn[c7f017e0]-1-c7e7f968-c7f21d40 ## Transferring control to Linux (at address 80008040) ...
Starting kernel ... hangs here
But if the compressed kernel image zImage is employed to generate the uImage, it boots up successfully. mkimage -A arm -O linux -T kernel -C none -a 80008000 -e 80008040 -n Linux-2.6.28 -d zImage uImage The boot log is as follows.
Uncompressing Linux................................................................... ........................................................... done, booting the kernel. Linux version 2.6.28 (gcc version 4.1.2) #20 PREEMPT Mon Dec 28 14:44:42 CST 2009 CPU: ARMv6-compatible processor [4117b363] revision 3 (ARMv6TEJ), cr=00c5387f
In principle, both cases should work. Has anyone met this before ?
Best Regards. William Lai
participants (1)
-
Lai Weilin-B04597