MLC NAND: all 0xff after erase?

[Ivan Djelic]

On Wed, Jul 11, 2012 at 01:36:51AM +0100, Brian Norris wrote:
> Hello all,
> 
> I've seen some issues with MLC NAND and where I might erase a block,
> read it back, and receive a few bitflips such that the data is not
> entirely 0xff (i.e., a few bytes may be 0xfe, 0x7f, 0xf7, etc.).
> However, I also notice that UBI, UBIFS, and YAFFS2 all make the
> assumption that an erased page/block will be totally pristine: all
> 0xff. This brings me to my main question:
> 
> Can someone find an example MLC NAND datasheet that guarantees reading
> an erased page will yield all 0xff data?

Hello Brian,

Due to the nature of NAND bitflips, I cannot see how a NAND datasheet
could guarantee such a thing (what would be the duration of a "0xff
guarantee" anyway ?). In practice, bitflips do appear already on 34nm SLC
devices, on blocks that have just been erased; hence I am not surprised
by your own findings on MLC devices.

See below for additional comments,

(...)
> Now, if we truly cannot rely on fully-0xff after erase, then this
> suggests a need for change in several different layers. A few comments
> and proposals:
> 
> * A few bitflips on an otherwise-0xff page should not be treated as
> unhandled corruption, as long as the erase operation did not return an
> error status. Such a page should be still usable, provided the driver
> has sufficient ECC capability.

Agreed.
 
> * My NAND controller's HW ECC flags these erased-page bitflips as
> uncorrectable errors, as there was no ECC written to the page and the
> read data does not match the 0xff special "erased" case. I assume most
> other ECC mechanisms would treat this similarly [2]. In such cases, I
> suspect that the best the driver can do is to return the raw data
> (0xff with flips) and an ECC error message.

So I guess you need to compare the _entire_ page with 0xff in your special
"erased" case ?

In my experience, the most efficient way of telling if a page has been
programmed or not is to explicitly write some kind of "programming marker"
(typically a zero byte) along with ECC in the OOB area.
This method is used by some manufacturers to implement internal ECC, when
the HW ECC bytes are such that an erased page does not have a valid ECC.
It also allows to distinguish your (b) and (c) cases.

In some cases, this marker is impossible to implement because HW controller
does not allow writing a custom byte in the OOB area; or because it would
break backward compatibility with existing devices.

Alternatively, if your controller allows it, you can xor HW-generated bytes
with a well-chosen polynomial before writing them and after reading them,
such that an erased page now has a valid ECC.

> * UBI and other FS layers need to distinguish between: (a) 0xff
> cleanly-erased, (b) 0xff with bitflips, and (c) true ECC errors. In
> the end, we may treat (a) and (b) the same (as erased pages), but the
> problem is distinguishing between (b) and (c). This may require
> modifications to:
> 
>   - the MTD API, to provide explicit notification of erased blocks.
> For instance, we might introduce a new return code for mtd_read() that
> represents (b); when MTD detects an ECC error, we check for all 0xff
> with a threshold of bitflips, then return either -EBADMSG or a special
> ERASED code.

If some MTD generic code is in charge of analyzing bitflips in empty pages,
and deciding if the number of bitflips is "acceptable" (i.e. will be correctable
by HW ecc), then it will need to know not only the ecc strength, but also
the layout of ecc blocks inside pages: having all bitflips located in the same
ecc block is not the same as having scattered bitflips. As of now this ecc block
layout is not exposed by drivers.

Maybe this "erased-page bitflip concealment" would be better managed inside
drivers that are not able to correct erased pages ? (this is what we do on
one of our platforms -- the rest are able to correct bitflips on erased pages).

Or, conversely, we could decide that erased pages are simply not ecc-protected
(which is the actual truth with many drivers), can contain anything (including
bitflips), and should be signalled as erased and dealt with in upper layers...

This is not as crazy as it may seem, because recent devices require that you
keep track of each write/erase operation and use out-of-place updates, to
guarantee power-failure robustness. In such a context, you don't rely much on
the contents of erased blocks, but track their state in a different way...

Just my 2c,

Best regards,
--
Ivan