[U-Boot] "Bad Data CRC" after ramdisk size increase

[Detlev Zundel <dzu@denx.de>]

Hi Rhanesh,

>> I am also trying to load Linux from uboot.  When i try to boot Linux 
>> from uboot it stops at Verifying Checksum and stops there. What might be 
>> the reasson for this?
>> 
>> This is my output.
>> 
>> U-Boot 1.1.2 (Jun 10 2008 - 18:55:13)
>> 
>> Board: MIPS CPU Speed 200 MHz
>> DRAM:  16 MB
>> sflash.c:266:DF_F_DataflashProbe: Entered
>> sflash.c:269:DF_F_DataflashProbe: flash type is 0x1
>> sflash.c:270:DF_F_DataflashProbe: num pages 32768
>> DataFlash:Nb pages:  32768
>> Page Size:    256
>> Size= 8388608 bytes
>> Logical address: 0xAD000000
>> Nb Erase Blocks:    128
>> Erase Block Size:  65536
>> Area 0:    AD000000 to AD003FFF
>> Area 1:    AD004000 to AD03FFFF
>> Area 2:    AD040000 to AD30BFFF
>> Area 3:    AD30C000 to AD7FFFFF
>> crc matched
>> In:    serial
>> Out:   serial
>> Err:   serial
>> Net:    Eth.
>> 
>> Type "run flash_nfs" to mount root filesystem over NFS
>> 
>> Hit any key to stop autoboot:  \b\b\b 0
>> ### JFFS2 loading '/boot/uImage' to 0x80800000
>> Scanning JFFS2 FS:   \b\b.  \b\b..............................\b\b- \b\b done.
>> ### JFFS2 load complete: 3249008 bytes loaded to 0x80800000
>> ## Booting image at 80800000 ...
>>   Image Name:   Linux Kernel Image with ramdisk.
>>   Created:      2009-06-22   4:37:12 UTC
>>   Image Type:   MIPS Linux Kernel Image (gzip compressed)
>>   Data Size:    3248944 Bytes =  3.1 MB
>>   Load Address: 80100000
>>   Entry Point:  80578000
>>   Verifying Checksum ... Bad Data CRC

Well, this is what it is - the data is not consistent with the checksum
in contained in the U-Boot headers.

If I look at the datasize (3248944) and remember that the U-Boot headers
are 64 bytes, then "3249008 bytes loaded" looks pretty good.  So we
likely do have no truncation here.  So either the image in flash is
corrupt or it gets corrupted on the transfer into RAM.

You could test for the latter by transferring the image twice into
different locations into RAM and "cmp"ing them.  If this fails you know
that you very likely still have hw problems.  If it passes, try to
regenerate the image and check it with "imi <address>" after every
step.  This will ensure the checksum is still correct.

Cheers
  Detlev

-- 
The best way to predict the future is to invent it.
                                           -- Alan Kay
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de