5
votes

I am working on Freescale board imx50evk. I have built the uboot.bin and uImage using LTIB (linux target image builder). At the U-Boot prompt I enter the bootm addr command, and then it hangs after showing the message "Loading Kernel..."

> MX50_RDP U-Boot > boot

MMC read: dev # 0, block # 2048, count 6290 partition # 0 ... 
6290 blocks read: OK
## Booting kernel from Legacy Image at 70800000 ...
   Image Name:   Linux-2.6.35.8
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1323688 Bytes =  1.3 MB
   Load Address: a0008000
   Entry Point:  a0008000
   Verifying Checksum ... OK
   Loading Kernel Image ...
2
Verify that you really have RAM at 0xa0008000, which is the kernel "load address". U-Boot is probably trying to copy the image to that region of memory when it appears to hang.sawdust
then how to change the load address of kernel??? to 70800000ASB
there are utilities such as mkImage, by which you can relocate the addresspeeyush
Something like: mkimage -A arm -O linux -T kernel -C none -a 0x70800000 -e 0x70800000 -n "2.6.35.8-imx5" -d arch/arm/boot/zImage ../../uImageCaptainBli
Please provide us with your u-boot environment (you can do that in u-boot shell, with env print command). It can help to debug your problem.Sam Protsenko

2 Answers

1
votes

You need to verify that your board really has RAM at 0xa0008000, which is the kernel "load address". U-Boot is probably trying to copy the image to that region of memory when it appears to hang.

[By your comment, I'll assume that you have verified that main memory does not exist at physical address 0xAXXXXXXX.]

The uImage file that you are using was made from the zImage file using the mkimage utility.

You probably have to manually edit the line that looks like

zreladdr-y     := 0xa0008000

in arch/arm/mach-XXX/Makefile.boot for your board. The convention is that this address should be the base of physical RAM plus an offset of 0x8000 (32K). Then adjust the other values in the file. Delete the zImage file and perform another make for the kernel.

0
votes

While building 3.20 development kernels for rockchip's rk3288 I found using LZO image compression made the device hang at 'Starting the kernel.' I assume it's because of a version miss-match between the build hosts LZO and the deployed decompression code, so it could probably happen with any of the compression algorithms. In my case switch to gzip fixed it.

This is only my assumption for why changing the compression algorithm gave a bootable kernel. Please correct me if I'm wrong.