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

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!

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,

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@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot

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

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
participants (3)
-
Albert ARIBAUD
-
Ivan Nardi
-
Wolfgang Denk