[U-Boot] [u-boot] CRC / ECC protection of environment

[Arno Steffen]

2011/9/22 Wolfgang Denk <wd at denx.de>:
> Dear Arno Steffen,
>
> In message <CAACX+R3ep2g0eytXC=U8GaCJgRG9h3f5quKgq1t4mHuYKwA74g at mail.gmail.com> you wrote:
>>
>> This is a good advice - I will check this next. Thanks, Scott!
>> I use an OMAP3 (simular to EVM 3530 board) with uboot-2010.03.
>> My assumption of not using ECC (or doing CRC first) is derived from,
>> that I had several devices with CRC error in environment but not even
>> a single board ever complains about the kernel, which is 12x bigger!
>> (It is from what I know also CRC protected, but in another way). From
>> my knowledge about statistics this behaviour is very unlikely.
>
> Eventually the ernel got written a lot less frequently than the
> environment blocks - I would not be surprised if you are just
> experiencing the "normal" wear of NAND blocks.
>
> [And keep in mind that NAND also develops erros when you only read
> it.]
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> I'm frequently appalled by the low regard you Earthmen have for life.
>        -- Spock, "The Galileo Seven", stardate 2822.3
>

I think I have the proof, that ECC is not working on my OMAP.
This might be a configuration problem or whatever - so I don't blame
it on the uboot itselft, but what?

I have here 2 failing devices:

uboot gives me a CRC error or bad NAND. While nanddump (running from
linux) gives me
nanddump -p /dev/mtd2 -f /tmp/env_crc_dump.txt
ECC failed: 0
ECC corrected: 2
Number of bad blocks: 0
Number of bbt blocks: 0
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00000000 and ending at 0x00040000...
ECC: 1 corrected bitflip(s) at offset 0x00012800

There is one strange issue: It gives 0 errors and 2 corrections, but
only reports 1 corrected bitflip.

While dumping this with and without ECC I could indeed identify a bit:
-0x00012e60: 00 00 00 00 00 00 00 80 00 00 00 00 00 00 00 00
+0x00012e60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00


Another device gives me
anddump -p -f /tmp/crc_env.txt /dev/mtd2
ECC failed: 0
ECC corrected: 0
Number of bad blocks: 0
Number of bbt blocks: 0
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00000000 and ending at 0x00040000...
ECC: 1 corrected bitflip(s) at offset 0x0000a800

While dumping this with and without ECC I could indeed identify a bit:
-0x0000a8d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+0x0000a8d0: 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00

Best regards
Arno