"crc error" when uncompressing kernel (pre-built image)

grante · **Posted:** Sat Jun 13, 2009 12:07 am

I'm Still trying to get Linux running on a G20-EK board. [It
really shouldn't be so hard]. I had to set up a windows box
since the Linux version of SAM-BA is broken, but now I've got
UBoot running from nand-flash, and I'm on to the next step:

I'm trying to boot a pre-built kernel image from linux4sam.com,
and no matter what pre-built image I try, I get a crc error
when the kernel is uncompressing itself. UBoot seems happy
with the uimage checksum, so I'm pretty sure the file is
uncorrupted.

Here's what happens:

Code:

U-Boot 1.3.4 (Dec 12 2008 - 12:18:30)

DRAM:  64 MB
NAND:  256 MiB
In:    serial
Out:   serial
Err:   serial
Net:   macb0
macb0: Starting autonegotiation...
macb0: Autonegotiation complete
macb0: link up, 10Mbps half-duplex (lpa: 0x0021)
Hit any key to stop autoboot:  0

 
U-Boot> printenv
bootargs=console=ttyS0,115200 root=/dev/mtdblock5 mtdparts=at91_nand:128k(bootstrap)ro,256k(uboot)ro,128k(env1)ro,128k(env2)ro,2M(linux),-(root) rw rootfstype=jffs2
bootcmd=nand read 0x22000000 0xA0000 0x200000; bootm
bootdelay=3
baudrate=115200
ethact=macb0
ethaddr=10.0.0.99/8
ipaddr=10.0.0.99
serverip=10.0.0.1
stdin=serial
stdout=serial
stderr=serial

Environment size: 355/131067 bytes


U-Boot> tftp 22000000 G20/linux-2.6.27-at91-exp-at91sam9g20ek.bin
macb0: link up, 10Mbps half-duplex (lpa: 0x0021)
Using macb0 device
TFTP from server 10.0.0.1; our IP address is 10.0.0.99
Filename 'G20/linux-2.6.27-at91-exp-at91sam9g20ek.bin'.
Load address: 0x22000000
Loading: #################################################################
         #################################################################
         #################################################################
         #################################################################
         ########################################
done
Bytes transferred = 1531808 (175fa0 hex)


U-Boot> bootm
## Booting kernel from Legacy Image at 22000000 ...
   Image Name:   linux-2.6
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1531744 Bytes =  1.5 MB
   Load Address: 20008000
   Entry Point:  20008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

Uncompressing Linux...................................................................................................

crc error

 -- System halted

Everything I've Googled so far indicates that the above message
means that the zImage decompression code has found a problem
with the data its trying to uncompress. Everybody says this is
usually caused by a truncated or corrupted zImage file.
However, uboot has verified the uImage encapsulation is OK. I
think that means that the zImage file that was given to mkimage
(presumably by somebody at Atmel) was already broken.

Am I doing something wrong? I've put the pre-built jffs rootfs
into flash at 0x400000, but I don't think the kernel has even
gotten to the point where it's looking for the root filesystem.

I've tried about a half dozen different pre-built kernel images
downloaded from linux4sam.com, and they all do the same thing.

limpens · **Joined:** Sun Sep 02, 2007 1:39 pm **Posts:** 77

grante wrote:

I'm trying to boot a pre-built kernel image from linux4sam.com,
and no matter what pre-built image I try, I get a crc error
when the kernel is uncompressing itself. UBoot seems happy
with the uimage checksum, so I'm pretty sure the file is
uncorrupted.

Here's what happens:

...

Am I doing something wrong? I've put the pre-built jffs rootfs
into flash at 0x400000, but I don't think the kernel has even
gotten to the point where it's looking for the root filesystem.

I've tried about a half dozen different pre-built kernel images
downloaded from linux4sam.com, and they all do the same thing.

When you've tried multiple different images, which all fail, it might be a hardware issue.

Are you able to boot a kernel over tftp? That might eliminate errors in flash (nand/nor - I don't know what storage is available on these boards).

If the error still occurs, it might be flacky memory. However, this also might be due to timings, perhaps something is wrong in the (hardware) configuration by the bootloader?

As u-boot IS running, ever tried to use its ram-test functions?

HTH.

grante · **Posted:** Sat Jun 13, 2009 3:24 pm

limpens wrote:

When you've tried multiple different images, which all fail, it
might be a hardware issue.

That's about the only thing I can think of.

Quote:

Are you able to boot a kernel over tftp?

No. That's what I showed in my posting -- both the ftfp
command and bootm command are in the uboot session log.

Quote:

That might eliminate errors in flash

I wasn't trying to boot from flash. I was booting from RAM
after loading the uimage file via tftp.

Quote:

(nand/nor - I don't know what storage is available on these boards).

The board has NAND flash, but I wasn't attempting to boot the
kernel from it.

Quote:

If the error still occurs, it might be flacky memory. However,
this also might be due to timings, perhaps something is wrong
in the (hardware) configuration by the bootloader?

Perhaps.

Quote:

As u-boot IS running, ever tried to use its ram-test functions?

Yes. The uboot ram test passes as long as I don't try to test
the last 2MB of RAM where uBoot is running. I've run the
ramtest on the first 62MB of the 64MB of SDRAM -- that includes
both the original location of the uimage file and the location
to which the kernel is un-compressed.

So far I'm a pretty dissappointed in how this is going:

The Linux version of SAM-BA can't talk to be board at all.
The Windows version of SAM-BA only detects the dataflash about
10% of the time and can never write to it.
The board's USB interface can't be plugged into a hub.
Pre-built kernel images specifically for this board won't run.

I guess it's on to the next eval board...

limpens · **Joined:** Sun Sep 02, 2007 1:39 pm **Posts:** 77

Sorry, didn't read your entire boot log, didn't notice you where using tftp.

But..... (this might seem far fetched) tftp is a really dumb protocol, running over udp.

Could it be network problems? My board (9263ek) is booting 100Mpbs / full duplex.

Code:

macb0: Starting autonegotiation...
macb0: Autonegotiation complete
macb0: link up, 100Mbps full-duplex (lpa: 0xc5e1

Yours 10Mbps / half duplex... tried a simple cross-cable between your tftp host and the board?

Eric.

edit:

Just checked your printenv output.

Is your ethaddr properly configured?

Code:

ethact=macb0
ethaddr=10.0.0.99/8
ipaddr=10.0.0.99

Mine:

Code:

ethact=macb0
ethaddr=00:de:ad:be:ef:01
boot_addr=0x21400000
serverip=172.16.0.1
ipaddr=172.16.0.254

grante · **Posted:** Sat Jun 13, 2009 4:43 pm

limpens wrote:

But..... (this might seem far fetched) tftp is a really dumb
protocol, running over udp.

Could it be network problems?

No, it's not a network problem. The file is transferred
properly. The correct number of bytes are loaded, and the
checksum of the loaded file verifies. If the data is corrupted
[I intentionally changed a word in RAM after tftp'ing the
file], here's what happens:

Code:

U-Boot> bootm
## Booting kernel from Legacy Image at 22000000 ...
   Image Name:   linux-2.6
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1531744 Bytes =  1.5 MB
   Load Address: 20008000
   Entry Point:  20008000
   Verifying Checksum ... Bad Data CRC
ERROR: can't get kernel image!

But, that doesn't happen. The CRC of the uimage file in
RAM is correct. I've also looked at the ethernet trace of
the file transfer, and it's fine.

Quote:

My board (9263ek) is booting
100Mpbs / full duplex.

Code:

macb0: Starting autonegotiation...
macb0: Autonegotiation complete
macb0: link up, 100Mbps full-duplex (lpa: 0xc5e1

Yours 10Mbps / half duplex...

That is correct. The board is plugged into a 10M Ethernet hub,
so 10M/half is what it should be running at.

Quote:

Is your ethaddr properly configured?

Technically, no, it wasn't set to a "legal" address per IEEE.
[My keyboard sometimes produces strings other than what I
intend. Odd, that.] However, the network connection is OK.
The tftp transfer is fine. I've since switched to a more
"legal" MAC address, and it doesn't make any difference.

Should the tftp/bootm command sequence work?

I've tried using both the default "bootargs" value and deleting
bootargs. Both fail the same way.

nferre · **Joined:** Wed Feb 14, 2007 11:17 am **Posts:** 67

Hi,

I must admit that your issue is quite tricky to solve. Even though you cannot boot your board, I have to say that binaries found on Linux4sam.org are working ok on at91sam9g20ek boards that we have.

grante wrote:

So far I'm a pretty dissappointed in how this is going:

The Linux version of SAM-BA can't talk to be board at all.

Future revision of SAM-Ba will address this problem

grante wrote:

The Windows version of SAM-BA only detects the dataflash about
10% of the time and can never write to it.

Did you follow what is advised in this FAQ ?
http://support.atmel.no/bin/customer?=&action=viewKbEntry&id=699

grante wrote:

The board's USB interface can't be plugged into a hub.

Strange ? Should work.

grante wrote:

Pre-built kernel images specifically for this board won't run.

... on your precise board. Be sure that they are working various at91sam9g20ek boards.

My best advice is to check the hardware and, if you can, test on another at91sam9g20ek board. Even if your memory seems ok with u-boot and its memory test, it is a big difference when you enable the D+I caches like Linux does.

grante · **Posted:** Thu Jun 25, 2009 8:27 pm

Quote:

I must admit that your issue is quite tricky to solve. Even
though you cannot boot your board, I have to say that binaries
found on Linux4sam.org are working ok on at91sam9g20ek boards
that we have.

I know. I e-mailed my kernel file (which was downloaded from
Linux4sam.org) to one of the FAE's and it
works fine on his board.

Quote:

Did you follow what is advised in this FAQ ?
http://support.atmel.no/bin/customer?=&action=viewKbEntry&id=699

No -- I didn't particularly care whether dataflash worked or
not. I was just trying it as an alternative to my failed
attempts to boot via tftp and via NAND flash.

Quote:

[*]The board's USB interface can't be plugged into a hub.

Strange ? Should work.

That's what I thought (I've never found anything else that
wouldn't work plugged into that hub), but somebody from Atmel
admitted to me that neither the JTAG-ICE unit nor the dev board
will work reliably plugged into a hub.

Quote:

... on your precise board. Be sure that they are working
various at91sam9g20ek boards.

My best advice is to check the hardware.

After spending some time on the phone with an FAE, we decied it
pretty much has to be a flakey SDRAM. I've sent the board back
to Atmel for FA.

Quote:

and, if you can, test on another at91sam9g20ek board.

I'd love to do that, but the Atmel FAE, the local distributor,
or the local rep all say they don't have another at91sam9g20ek
board to loan me [in distinct contrast to Freescale, who had a
replacement board for me in 24 hours when it was discovered
that the original one was too old for recent Linux distros].

Quote:

Even if your memory seems ok with u-boot and its memory test,
it is a big difference when you enable the D+I caches like
Linux does.

Definitely. I'm confident that the FAE will discover the SDRAM
fails when you stress it a little.

kk2mkk · **Joined:** Sun Feb 21, 2010 9:22 pm **Posts:** 4

I am facing a similar issue I just wanted to know did you overcome this CRC issue by changing the SDRAM?

koan · **Posted:** Sat Apr 10, 2010 12:18 pm

Is this board a custom or an original Atmel?
In the former case did you set properly the settings for the SDRAM registers in u-boot?

DSY · **Joined:** Wed Apr 28, 2010 10:04 am **Posts:** 1

Advise to double check SDRAM timing settings which would cause such issue.

zruiff · **Joined:** Thu Oct 01, 2009 4:13 am **Posts:** 2

I think it is caused by SDRAM hardware error,try to reduce the MCK frequence,maybe it can be solved.

grante · **Posted:** Tue May 11, 2010 10:23 pm

kk2mkk wrote:

I am facing a similar issue I just wanted to know did you overcome
this CRC issue by changing the SDRAM?

We got a replacement G20EK board, and it worked fine.

Getting a non-faulty eval board took a couple weeks and a lot of
hassle. We eventually had to have one of our board of directors talk
to a member of the board of directors for the distributor.

--
Grant

kk2mkk · **Joined:** Sun Feb 21, 2010 9:22 pm **Posts:** 4

Ours is custom board similar to Atmel evaluation kit.I have a higher SDRAM of 64MB.

I tried replacing the SDRAM with a 32MB and boards works fine.

Here are the changes I did for SDRAM in the at91rm9200ek.h

#define CONFIG_SYS_SDRC_CR_VAL 0x7fffffd9 /*64 MB set up the CONFIG_SYS_SDRAM */
//#define CONFIG_SYS_SDRC_CR_VAL 0x7fffffd5 /*32 MB set up the CONFIG_SYS_SDRAM */

When I use 32MB I can boot the kernel but when I use 64 MB I always get crc error after kernel uncompressing.

I reduced the MCK to 22MHz and then the system with 64MB becomes stable.

I am not sure if I am facing a Signal Integrity issue as the board works fine for a 32MB SDRAM. Please let me know if there is any spefic setting for
the SDRAM that I need to look into or any uboot changes that needs to done for 64MB. I am using at91rm9200ek_config and doing the changes as per my board in the sourcecode.

at91rm9200ek has only 32MB of SDRAM. The chip that I am using is MT48LC16M16 whereas the atmel kit uses MT48LC8M16

Regards
KK

nferre · **Joined:** Wed Feb 14, 2007 11:17 am **Posts:** 67

Hi,

SDRAM configuration is done by the bootloader. Be sure that you have the proper configuration of sDRAM in your first level bootloader.
Usually, on AT91/Linux we use AT91Bootstrap to setup SDRAM timings and configuration.

For sure, as you already done, you have to change the Linux boot arguments to increase to 64M.

kk2mkk · **Joined:** Sun Feb 21, 2010 9:22 pm **Posts:** 4

I am doing the change to SDRAM in uboot only. Also I am passing the 64M as the bootargs from uboot. I am not sure if my SDRAM configuration are are fine

SDRAM_CR:0x7fffffd9
SDRAM_TR: 0x000002E0

All other changes were kept same as the AT91RM9200EK board.

I would like to have suggestion on any important parameter that needs to be looked into.

"crc error" when uncompressing kernel (pre-built image)

Who is online