U-Boot hangs while loading kernel?

Question

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 ...

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, Sep 22 '12 at 22:34
then how to change the load address of kernel??? to 70800000 — ASB, Sep 24 '12 at 04:54
there are utilities such as mkImage, by which you can relocate the address — peeyush, Sep 24 '12 at 05:36
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 ../../uImage` — CaptainBli, Sep 04 '13 at 21:15
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, Apr 01 '15 at 08:57

sawdust · Answer 1 · 2012-09-24T07:49:29.727

1

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.

edited Sep 24 '12 at 07:49

answered Sep 24 '12 at 06:37

sawdust

16,103
3
40
50

ya i have changed the load address of kernel image using mkimage and it works fine on loading kernel, but now it hangs out at Starting kernel ... and never returns to prompt... – ASB Sep 24 '12 at 07:40
@ASB - Not much has to happen after the *"Starting kernel ..."* before the *"Uncompressing Linux..."* is displayed when the U-Boot wrapper coder is executed. Maybe you need to use an **in-circuit emulator** (i.e. J-Link) to investigate what is going wrong. Isn't this an evaluation board? Isn't there a demo kernel with source code to use as an example? Why are you encountering gross errors like incorrect load addresses? Have you configured your build scripts properly for your board? – sawdust Sep 26 '12 at 01:32
Verify the machine ID that U-Boot passes to the kernel. If it's incorrect or unrecognized, then that can cause the decompression program to hang on some Freescale SoCs. See http://stackoverflow.com/questions/18378563/how-do-i-find-arm-linux-entry-point-when-it-fails-to-uncompress/18392238#18392238 – sawdust Jun 18 '14 at 07:58
Enable **earlyprintk** in kernel (via `CONFIG_EARLYPRINTK` option and some other options like UART number, just check it in `menuconfig`, they are all in the same group). And also pass `earlyprintk` param to kernel from u-boot via `bootargs` environment variable. This way you will be able to see where kernel stuck. – Sam Protsenko Apr 01 '15 at 08:56

score 0 · Answer 2 · answered Apr 01 '15 at 08:24

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.

U-Boot hangs while loading kernel?

2 Answers2

Linked