Re: state of support for "external ECC hardware"

[Angus CLARK <angus.clark@st.com>]

Hi Gerlando,

On 11/14/2012 10:12 AM, Gerlando Falauto wrote:
> Hi Ivan,
> 
> 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
> a partition.
> 
> 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?
> 

In general I am in favour of anything that facilitates the automatic probing of
devices.  However, I can see a number of complications in trying to implement
what you suggest.  Storing static information in a fixed location is never a
good idea on NAND.  A further issue relates to the very information you are
trying to store.  The data itself would need to be protected by ECC, but for it
to be useful, you need to be able to retrieve it without knowing what ECC/layout
was used when storing it.  Perhaps, for this ECC/layout data, one could use a
special dedicated S/W ECC scheme, strong enough for any device.  Yet another
layout of complexity though.

With regards to "spare storage", I would probably suggest the ECC/layout data be
added to the BBT area, assuming Flash-Resident BBTs are being used.

My only doubt would be whether there is sufficient motivation to overcome some
of the complexities and implement such a scheme...

Cheers,

Angus

> Thank you,
> Gerlando
> 
> 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.
>> HTH,
>> -- 
>> Ivan
> 
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 

-- 
-------------------------------------
Angus Clark
ST Microelectronics (R&D) Ltd.
1000 Aztec West, Bristol, BS32 4SQ
email: angus.clark@st.com
tel: +44 (0) 1454 462389
st-tina: 065 2389
-------------------------------------