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

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

[Arno Steffen]

Assumed Uboot and environment are located in NAND flash.
Just a short question: Is the ECC done before the CRC check, or is the
CRC check done first?

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

[Wolfgang Denk]

Dear Arno Steffen,

In message <CAACX+R1vfc7C7XvygfVD8TV+ypaqSyON_EFX7VheQ8R56vncaA@mail.gmail.com> you wrote:
> Assumed Uboot and environment are located in NAND flash.
> Just a short question: Is the ECC done before the CRC check, or is the
> CRC check done first?
> From my observation I would assume that first CRC is checked. But if

Your observations are wrong.

> so - imho in my case (environment in NAND, which is handled with ECC)
> this wouldn't make sense.
> Am I right, that in this situation I should configure uboot to NOT use
> CRC protection?

No, you should not meddle with the CRC checking.

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
Star Trek Lives!

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

[Arno Steffen]

2011/9/20 Wolfgang Denk <wd@denx.de>:
> Dear Arno Steffen,
>
> In message <CAACX+R1vfc7C7XvygfVD8TV+ypaqSyON_EFX7VheQ8R56vncaA@mail.gmail.com> you wrote:
>> Assumed Uboot and environment are located in NAND flash.
>> Just a short question: Is the ECC done before the CRC check, or is the
>> CRC check done first?
>> From my observation I would assume that first CRC is checked. But if
>
> Your observations are wrong.
>
>> so - imho in my case (environment in NAND, which is handled with ECC)
>> this wouldn't make sense.
>> Am I right, that in this situation I should configure uboot to NOT use
>> CRC protection?
>
> No, you should not meddle with the CRC checking.
>
> 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
> Star Trek Lives!
>

Thank you for clarification. Although I am estonished, that after some
time of running 2 devices come up with CRC errors (with just read
access to environment!!).
Unfortunatly I don't know a way just to change 1 bit in flash without
changing the OOB data to simulate a toogling bit.

Best regards
Arno

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

[Scott Wood]

On 09/21/2011 04:59 AM, Arno Steffen wrote:
> Thank you for clarification. Although I am estonished, that after some
> time of running 2 devices come up with CRC errors (with just read
> access to environment!!).
> Unfortunatly I don't know a way just to change 1 bit in flash without
> changing the OOB data to simulate a toogling bit.

http://patchwork.ozlabs.org/patch/114262/ provides the ability to do a
raw write.  Copy out the good data (including OOB), erase the block,
flip a bit in the RAM copy, and raw-write it all back at once.

What board and nand driver are you using?

-Scott

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

[Arno Steffen]

2011/9/21 Scott Wood <scottwood@freescale.com>:
> On 09/21/2011 04:59 AM, Arno Steffen wrote:
>> Thank you for clarification. Although I am estonished, that after some
>> time of running 2 devices come up with CRC errors (with just read
>> access to environment!!).
>> Unfortunatly I don't know a way just to change 1 bit in flash without
>> changing the OOB data to simulate a toogling bit.
>
> http://patchwork.ozlabs.org/patch/114262/ provides the ability to do a
> raw write. ?Copy out the good data (including OOB), erase the block,
> flip a bit in the RAM copy, and raw-write it all back at once.
>
> What board and nand driver are you using?
>
> -Scott

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.
- Arno

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

[Wolfgang Denk]

Dear Arno Steffen,

In message <CAACX+R3ep2g0eytXC=U8GaCJgRG9h3f5quKgq1t4mHuYKwA74g@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

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

[Arno Steffen]

2011/9/22 Wolfgang Denk <wd@denx.de>:
> Dear Arno Steffen,
>
> In message <CAACX+R3ep2g0eytXC=U8GaCJgRG9h3f5quKgq1t4mHuYKwA74g@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