Kernel booting stops right after "Uncompressing Linux..."

Question

I'm trying to bring up an ARM-based board. I've got U-Boot working but can't seem to get the kernel to load. Most of the time it only goes as far as:

Starting kernel ...

Uncompressing Linux...

A couple of times while playing with U-Boot env settings it followed up with:

uncompression error

 -- System halted

I found some threads that suggested using LZO compression instead of GZIP so I've reconfigured the kernel, but now it's getting the LZO compression error message:

Compressed data violation

 -- System halted

Any suggestions how I could try to debug this? I've already enabled DEBUG_LL and printk in the kernel, but those haven't served me at all.

Solution

Seems that there was an read error so the decompressed data has no valid checksum.

Possible reasons:

• RAM/SRAM errrors.
• Too little RAM/SRAM.

Comments

[Gatica]

It's an embedded system, there's no OS installed yet. I've built the SPL, U-Boot and Kernel and have rootfs in the 2nd partition. The design is based on AM335x EVM, so I've reused/modified lots of their U-Boot codebase & found settings for our model of RAM in ddr_defs.h. U-Boot is version 2011.09 :( So I wonder if there may be bugs that could've been fixed since in the newer version of U-Boot. The old version is down to the Timesys SDK we're using.

[Admin]

It is also possible that there is not enough RAM for extraction.

[Gatica]

There's 2GB of RAM there, but I've tried passing in 512MB as the option in case it wasn't able to address the higher end of that. The uImage kernel file is only 3MB, so I doubt 512MB wouldn't be enough space for it even uncompressed. Thinking of trying uncompressed kernel, see how far it gets.

[Gatica]

Also, seems that U-Boot will only acknowledge a max of 256MB of RAM, makes no difference what value I set for CONFIG_MAX_RAM_BANK_SIZE, 2GB or 1GB, it always calculates a 256MB. Tried passing that as the mem variable to kernel, but that's not making any different. Have upgraded to U-Boot 2013.01.01, same issue most of the time, but occasionally does give the checksum error @bersch suggested, "Verifying Checksum ... Bad Data CRC". Will try an uncompressed kernel now.