dangerous NAND_BBT_SCANBYTE1AND6

[Ivan Djelic]

On Thu, May 26, 2011 at 08:07:36AM +0100, Ricard Wanderlof wrote:
> > ...
> > <digression>
> > The above note is probably not applicable to recent devices. Because bitflips
> > are much more likely to appear, saying that a specific byte marks a bad block
> > if it "does not contain FFh" it not realistic. ONFI 2.2 clarifies the issue and
> > states that a marker is 0x00, not just a byte that "does not contain FFh".
> > And recent Micron devices do not store markers in flash; they just return 0x00
> > for any byte read in a bad block (instead of the real data), using an internal
> > bad block table.
> > </digression>
> 
> I'm probably wrong here, but I just want to throw this thought into the 
> pot: I always thought that the reason for the 'not contain FFh' phrasing 
> was that there could be something physically wrong in a bad block so that 
> some bits could not be programmed to 0. Saying 'not contain FFh' would be 
> a way of saying 'we try to set all bytes to 0 but if for some reason some 
> bits are stuck at 1 still treat a non-FFh word as a bad block marker'.

I agree. The safest way to check a bb marker is probably to count the number of
set bits, and compare it to a threshold; instead of just comparing it to 0xff or
0x00.
But even if you stick to a simple comparison with 0x00 or 0xff on old nand
devices, I guess the probability that a bit is stuck in the marker is very low
and would maybe result in a few spurious bad blocks in a large set of devices.

Ivan