# Bad Data CRC **URL:** \ **Category:** Linux\ **Tags:** connectcore9p\ **Created:** [January 7, 2013, 10:44am UTC](https://forums.digi.com/t/bad-data-crc/4966 "2013-01-07T10:44:46Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![tolym](https://avatars.discourse-cdn.com/v4/letter/t/71c47a/32.png) [@tolym](https://forums.digi.com/u/tolym)\ **Post date:** [January 7, 2013, 10:44am UTC](https://forums.digi.com/t/bad-data-crc/4966/1 "2013-01-07T10:44:46Z")
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 BR, Anatoly. ---
**Author:** ![bgeci](https://avatars.discourse-cdn.com/v4/letter/b/dfb087/32.png) [@bgeci](https://forums.digi.com/u/bgeci)\ **Post date:** [March 30, 2013, 3:47am UTC](https://forums.digi.com/t/bad-data-crc/4966/2 "2013-03-30T03:47:18Z")
Hi, I have same problem. 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 ---
**Author:** ![thomas.kuhlmann](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.digi.com/thomas.kuhlmann/32/7_2.png) [@thomas.kuhlmann](https://forums.digi.com/u/thomas.kuhlmann)\ **Post date:** [July 22, 2019, 7:02am UTC](https://forums.digi.com/t/bad-data-crc/4966/3 "2019-07-22T07:02:28Z")
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.