state of support for "external ECC hardware"

[Ivan Djelic]

On Wed, Nov 14, 2012 at 01:24:43PM +0000, Angus CLARK wrote:
> 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.

FWIW, I have once implemented a kind of primitive "formatting" similar to what you are describing (i.e. storage of NAND parameters inside the device itself).
For that, I used a dedicated SW BCH ECC, that adds 3 redundant bytes to each useful byte (effectively multiplying by 4 the required storage).
The resulting data can sustain up to 4 bitflips in each 32-bit word; it is also stored redundantly in multiple blocks.

BR,
--
Ivan