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

[Lai Weilin-B04597]

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