Welcome! Log In Create A New Profile

Advanced

Verifying Checksum ... Bad Data CRC

Posted by rsantag 
Verifying Checksum ... Bad Data CRC
March 01, 2021 04:09PM
I have a Pogoplug Mobile that I've updated with the latest uboot. It boots debian off the SD card just fine, but I also set these environment variables so it would boot the original Cloud Engines OS if there's no SD card inserted:

Quote

bootcmd_exec=if run load_uimage; then if run load_initrd; then if run load_dtb; then bootm $load_uimage_addr $load_initrd_addr $load_dtb_addr; else bootm $load_uimage_addr $load_initrd_addr; fi; else if run load_dtb; then bootm $load_uimage_addr - $load_dtb_addr; else bootm $load_uimage_addr; fi; fi; else run bootcmd_pogo; fi
bootcmd_pogo=if ubi part root 2048 && ubifsmount ubi:rootfs && ubifsload 0x800000 uboot.mtd0.dockstar.original.kwb ; then go 0x800200; fi

I've done this on lots of others, and it works fine. But this one wouldn't boot, so I hooked up a console and saw this:

Quote

Write allocate disabled

USB 0: host mode
PEX 0: interface detected no Link.
Net: egiga0 [PRIME], egiga1
Hit any key to stop autoboot: 0

Loading from NAND 128MB 3,3V 8-bit, offset 0x200000
Image Name: Linux-2.6.31.8
Created: 2011-08-23 20:00:55 UTC
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 2080956 Bytes = 2 MB
Load Address: 00008000
Entry Point: 00008000
## Booting image at 00800000 ...
Image Name: Linux-2.6.31.8
Created: 2011-08-23 20:00:55 UTC
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 2080956 Bytes = 2 MB
Load Address: 00008000
Entry Point: 00008000
Verifying Checksum ... Bad Data CRC
CE>>

As I said, debian boots fine, so not really a big deal. Just trying to understand what would cause this. Maybe a bad eraseblock? I did check dmesg and there was 1 bad block at something like block 273. Could that have caused the /boot/uboot.mtd0.dockstar.original.kwb file to be corrupted?
Re: Verifying Checksum ... Bad Data CRC
March 01, 2021 05:10PM
rsantag,


> Loading from NAND 128MB 3,3V 8-bit, offset
> 0x200000
> Image Name: Linux-2.6.31.8
> Created: 2011-08-23 20:00:55 UTC
> Image Type: ARM Linux Kernel Image
> (uncompressed)
> Data Size: 2080956 Bytes = 2 MB
> Load Address: 00008000
> Entry Point: 00008000
> ## Booting image at 00800000 ...
> Image Name: Linux-2.6.31.8
> Created: 2011-08-23 20:00:55 UTC
> Image Type: ARM Linux Kernel Image
> (uncompressed)
> Data Size: 2080956 Bytes = 2 MB
> Load Address: 00008000
> Entry Point: 00008000
> Verifying Checksum ... Bad Data CRC
> CE>>[/quote]
>

> Could that have caused the
> /boot/uboot.mtd0.dockstar.original.kwb file to be
> corrupted?

Not the original u-boot. It was already booted. The corruption is with the stock uImage on NAND.

And you are correct to suspect that the bad block might have something to do with it.

However, let's calculate the bad block position 273 * 128KB = 34,944 KB = 34.125 MB.

So the bad block is inside stock rootfs (at 16MB location). This is OK. Usually, that bad block was marked and not used by the rootfs file system.

mtdparts=orion_nand:2M(u-boot),3M(uImage),3M(uImage2),8M(failsafe),112M(root) earlyprintk=serial

My conclusion is the uImage (at 2MB location) is actually corrupted. It needs to be restored using a good copy of mtd1 from another Pogo V4 or Mobile box.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Author:

Your Email:


Subject:


Spam prevention:
Please, enter the code that you see below in the input field. This is for blocking bots that try to post this form automatically. If the code is hard to read, then just try to guess it right. If you enter the wrong code, a new image is created and you get another chance to enter it right.
Message: