state of support for "external ECC hardware"
gerlando.falauto at keymile.com
Wed Nov 14 05:12:34 EST 2012
thanks once more.
Speaking of compatibility, I was wondering: doesn't a NAND flash have
*any* spare storage space at all, where software could store some
information about the current OOB layout and/or ECC mechanism?
Partition tables on hard drives for instance have a "partition type"
byte which provides some hints about what to expect from the data within
This would be especially useful for *future* compatibility (i.e. old
software reading a NAND "formatted" with unknown mechanism could simply
stop working, or force read-only mode disabling ECC altogether).
Feasibility aside, would that make any sense?
On 11/12/2012 07:52 PM, Ivan Djelic wrote:
> On Mon, Nov 12, 2012 at 05:39:45PM +0000, Gerlando Falauto wrote:
>> Hi Ivan,
>> wonderful, thanks a lot!
>> If you also happen to have an opionion to using it for chips only
>> needing 1-bit correction, I'd love to hear that...
> I would recommend using the strongest ECC your hardware can provide without
> hurting performance too much. This is what I do on my hardware (e.g. 8-bit
> correction on current 4-bit devices). I find it has 2 advantages:
> - increased reliability
> - seamless transition to newer devices with stronger ecc requirements
> The latter is important, because changing ECC strength can be painful: it
> means changing the OOB layout, impacting bootloader and kernel, thus breaking
> compatibility, etc.
More information about the linux-mtd