[PATCH 1/8] mtd: nand: remove NAND_BBT_SCANBYTE1AND6 option

[Angus CLARK]

Hi Brian,

On Tue, 31 May 2011 16:31:20 -0700, Brian Norris
<computersforpeace at gmail.com> wrote:
> This patch reverts most of:
>     commit 58373ff0afff4cc8ac40608872995f4d87eb72ec
>     mtd: nand: more BB Detection refactoring and dynamic scan options
> 
> According to the discussion at:
>     http://lists.infradead.org/pipermail/linux-mtd/2011-May/035696.html
> the NAND_BBT_SCANBYTE1AND6 flag, although technically valid, can break
> some existing ECC layouts that use the 6th byte in the OOB for ECC data.
> Furthermore, we apparently do not need to scan both bytes 1 and 6 in
> the OOB region of the devices under consideration; instead, we only need
> to scan one or the other.
> 
> Thus, the NAND_BBT_SCANBYTE1AND6 flag is at best unnecessary and at
> worst a regression.
> 

Sorry to bring this up again, but I just thought you might be interested
in the following clarification I received from Micron (who now own the
ST/Numonyx NAND portfolio):

---
"In the factory, we mark bad blocks by programming (in the spare area of
the first page of the block) SPARE[0] = 00h and SPARE[5] = 00h.  On x16
devices we program SPARE[0] = 0000h.

Due to the fact that the block is bad, it may be impossible to program
some of the bits.  The most reliable test for a bad block is therefore:

x8 device: (SPARE[0] != FFh) OR (SPARE[5] != FFh)
x16 device: (SPARE[0] != FFFFh)

Having said that, it is very unlikely that all 8 bits of a location will
be stuck at '1', so if you just want to test SPARE[0] OR SPARE[5], that
should be reliable enough for most applications."
---

So, I believe this confirms your original interpretation of the
ST/Numonyx datasheets and that the NAND_BBT_SCANBYTE1AND6 is valid.  The
question still remains what to do with this information, in view of the
potential clash with existing ECC layouts (including the default S/W ECC
layout).  A couple of options you proposed previously:

1) Retain the NAND_BBT_SCANBYTE1AND6 flag, and add some code to mask out
the flag if necessary based on the ECC layout (possibly in
nand_scan_tail()?).

2) Revert the flag, as done in this patch, and accept the very small
possibility of missing some factory-marked bad-blocks.

My preference would be 1), since it is technically correct, and would
allow drivers to make use of the information if possible, while avoiding
regressions associated with ECC layout clashes.

I appreciate the patch for 2) has already made it to l2-mtd2.6 so it may
be too late anyway...

Cheers,

Angus