Hello!
My name is Anatoly. I have two “CCWi 9P 9215 16/32 LNX” devices and one “CC9P 9215” device. I use development board for working with them. When I got the devices above they didn’t load. So I read “ubootrecover.chm” and updated uBoot. All devices began to load. Then I updated linux and rootfs using images from “Digi JumpStart Development Environment…” disk (Revision 5.2, April 2010). Unfortunately, I have the following problem when starting linux on them: “Bad Data CRC”. I don’t know what should I do to fix it. Could you, please, help me.
The text from hyper terminal window is:
U-Boot 1.1.6 (Dec 8 2010 - 05:55:44 - GCC 4.3.2) master
for ConnectCore 9P 9215 on Development Board
DRAM: 16 MB
Flash: 8 MB
CPU: NS9215 @ 149.91360 MHz, SYS 299.82720 MHz, AHB 74.95680 MHz, Rev 0
Strap: 0x06f0
Autoscript from TFTP… [not available]
Hit any key to stop autoboot: 0
Reading: complete
linux will be booted now
Booting image at 00200000 …
Image Name: Linux-2.6.28.10-del-5.2-RevB
Created: 2010-02-11 12:54:14 UTC
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 1129824 Bytes = 1.1 MB
Load Address: 00008000
Entry Point: 00008000
Verifying Checksum … Bad Data CRC
command bootm 0x200000 failed
I used Digi ESP and made linux image. Booting image with tftp I received mesage
CME9210 # dboot linux tftp
TFTP from server 192.168.42.1; our IP address is 192.168.42.30
Filename ‘uImage-cme9210js’.
Load address: 0x200000
Loading: #################################################################
###############
done
Bytes transferred = 1136244 (115674 hex)
linux will be booted now
Booting image at 00200000 …
Image Name: Linux-2.6.28.10
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 1136180 Bytes = 1.1 MB
Load Address: 00008000
Entry Point: 00008000
Verifying Checksum … Bad Data CRC
command bootm 0x200000 failed
I checked filesize of image in root/digiesp/workspace/MyProject/images and size is 1136244 Bytes
this means that your kernel image (or header) is corrupted. It has not been transferred correctly into RAM or an image with wrong header was stored in flash.
Re-do: update linux flash again to get this fixed.
If the same kernel is running fine on other modules (same file checksum), make sure the kernel partition size is big enough for the kernel to fit in. Also check with “nand bad” if there are bad blocks in the kernel partition (check the partition addresses with flpart or intnvram printall).
If you are sure the image you loaded via TFTP or from flash has the correct checksum, the problem unpacking it to RAM might be in the “loadaddress”. Check the loadaddr in NVRAM is the same like on a known good module with same amount of RAM.
Finally there could be a hardware problem with the RAM. Use the U-Boot mtest command to check the RAM addresses to which the kernel is extracted to find a RAM failure. RAM failures can also occur if the power supply is too weak or on the edge of specification or additional devices are connected to the data/address bus which could temporary overload the bus.