[U-Boot] Why data corrected by ecc are not rewrite to the flash?

[U-Boot] Why data corrected by ecc are not rewrite to the flash?

[Ivan Nardi]

Hello!

I'am having a look at the ecc algorithms in nand code and I observe (both in
kernel and in u-boot) that when ecc corrects some data, corrected data are
given to the user, but the data storage in the nand do not change. In other
words, I expected the flash would be written with the new (corrected) data.

Why data corrected by ecc are not rewrite to the flash?

I think that it should be easy achieve this goal. In the read function, if
ecc corrects some data on a page, I read the entire block, erase it and
write back (correct) data to the flash.

Nobody is interested in this feature? Or is it more difficult than I think?

Thanks a lot!

[U-Boot] Why data corrected by ecc are not rewrite to the flash?

[Albert ARIBAUD]

Le 15/06/2010 12:42, Ivan Nardi a ?crit :
> Hello!
>
> I'am having a look at the ecc algorithms in nand code and I observe (both in
> kernel and in u-boot) that when ecc corrects some data, corrected data are
> given to the user, but the data storage in the nand do not change. In other
> words, I expected the flash would be written with the new (corrected) data.
>
> Why data corrected by ecc are not rewrite to the flash?
>
> I think that it should be easy achieve this goal. In the read function, if
> ecc corrects some data on a page, I read the entire block, erase it and
> write back (correct) data to the flash.
>
> Nobody is interested in this feature? Or is it more difficult than I think?
>
> Thanks a lot!

Let me play the devil's advocate here: what would be the interest of 
writing back corrected data to the flash? Here's my take at the pros and 
cons of writing ECC-corrected data back to flash:

Cons:

- risk of the write failing more or less critically;

- performance hit (albeit marginal hopefully);

- risk of spurious data corruption: if the ECC detection/correction or 
write decision code is buggy, you may end up with a write-back where 
unnecessary, and possibly write the wrong data back to flash. The 
current situation, at least, guarantees that the Flash content is 
preserved even if ECC detection/correction gets it wrong.

Pros:

- marginal performance gain for subsequent reads of ECC, assuming the 
data is read frequently enough that the correction time becomes 
significant wrt all the rest of the bootloader execution.

But the bottom line is: there is no benefit as far as the data itself is 
concerned since it is correct without writing it back to Flash.

Amicalement,
-- 
Albert.

[U-Boot] Why data corrected by ecc are not rewrite to the flash?

[Ivan Nardi]

Thank you for your replay and for your interest.

You are right: rewriting the corrected data may be a critical
operation that may fail and having an untouch flash content is useful
to prevent damages from buggy algorithms.

Yet I was thinking about a particular scenario. If flash memory is
wearing a little at a time (ie, the first time I read a page I find 1
bit wrong, then I found 2 errors in the same page and so on until I
am not able to correct data) rewrite corrected data may be useful.

Is this scenario so unlikely?

On 15 June 2010 13:01, Albert ARIBAUD <albert.aribaud@free.fr> wrote:
> Le 15/06/2010 12:42, Ivan Nardi a ?crit :
>> Hello!
>>
>> I'am having a look at the ecc algorithms in nand code and I observe (both in
>> kernel and in u-boot) that when ecc corrects some data, corrected data are
>> given to the user, but the data storage in the nand do not change. In other
>> words, I expected the flash would be written with the new (corrected) data.
>>
>> Why data corrected by ecc are not rewrite to the flash?
>>
>> I think that it should be easy achieve this goal. In the read function, if
>> ecc corrects some data on a page, I read the entire block, erase it and
>> write back (correct) data to the flash.
>>
>> Nobody is interested in this feature? Or is it more difficult than I think?
>>
>> Thanks a lot!
>
> Let me play the devil's advocate here: what would be the interest of
> writing back corrected data to the flash? Here's my take at the pros and
> cons of writing ECC-corrected data back to flash:
>
> Cons:
>
> - risk of the write failing more or less critically;
>
> - performance hit (albeit marginal hopefully);
>
> - risk of spurious data corruption: if the ECC detection/correction or
> write decision code is buggy, you may end up with a write-back where
> unnecessary, and possibly write the wrong data back to flash. The
> current situation, at least, guarantees that the Flash content is
> preserved even if ECC detection/correction gets it wrong.
>
> Pros:
>
> - marginal performance gain for subsequent reads of ECC, assuming the
> data is read frequently enough that the correction time becomes
> significant wrt all the rest of the bootloader execution.
>
> But the bottom line is: there is no benefit as far as the data itself is
> concerned since it is correct without writing it back to Flash.
>
> Amicalement,
> --
> Albert.
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>

[U-Boot] Why data corrected by ecc are not rewrite to the flash? Why data corrected by ecc are not rewrite to the flash?

[Wolfgang Denk]

Dear Ivan Nardi,

In message <AANLkTikV1wyzcjLr2lIr4cPAvf_vw-pnmO361mWk2_lL@mail.gmail.com> you wrote:
> 
> I'am having a look at the ecc algorithms in nand code and I observe (both in
> kernel and in u-boot) that when ecc corrects some data, corrected data are
> given to the user, but the data storage in the nand do not change. In other
> words, I expected the flash would be written with the new (corrected) data.

Where exactly have you been looking? At plain simple NAND flash
drivers? These provide only the lowest software layer to access NAND
storage. Recovery from error situations like these requires a little
more intelligence and is typically implemented in higer software
layers.

> Why data corrected by ecc are not rewrite to the flash?
> 
> I think that it should be easy achieve this goal. In the read function, if
> ecc corrects some data on a page, I read the entire block, erase it and
> write back (correct) data to the flash.

Such a simple approach would be way too dangerous. ECC errors are an
indication that this sector has problems. But you can still read the
data. What would you do if the write-back of the data fails? Now you
still have the data, but where to store these if the original block
cannot be written any more? 

> Nobody is interested in this feature? Or is it more difficult than I think?

It is more difficult than you think, but there is definitely interest
in such things, and actually the problem has been solved a long time
ago.  The name of the solution is UBI.  U-Boot supports UBI, so you
just have to enable it in your board configuration.

Note that for reliable booting from NAND you want to read the U-Boot
image from a (static) UBI volume, which is kind of challenging for the
1st stage NAND boot loader that usually must fit in very small memory
such as 4 KiB or so.

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
Teenagers are people who express a burning desire to be different by
dressing exactly alike.
There are some strings. They're just not attached.

[U-Boot] Why data corrected by ecc are not rewrite to the flash? Why data corrected by ecc are not rewrite to the flash?

[Ivan Nardi]

>
> It is more difficult than you think, but there is definitely interest
> in such things, and actually the problem has been solved a long time
> ago. ?The name of the solution is UBI. ?U-Boot supports UBI, so you
> just have to enable it in your board configuration.
>

Thanks for the hint. I don't know UBI: I'll have a look at it.
Best regards,

Ivan Nardi