bad block markers + ONFI

bad block markers + ONFI

[Brian Norris]

Hello,

I've wondered for a while what the MTD community expects from ONFI
NAND with respect to bad block markers and bad block scanning. I'll
try to enumerate some observations, followed by some recommendations
and rationale. Please comment, and maybe I'll code one of these
options shortly. I'd like to settle the high level points first
though.

Observations:

(A) ONFI spec says the host should scan the 1st OOB byte of the 1st
and last pages of each block. See reference [1] for exact text.
(B) There are some ONFI parts whose data sheets do not list bad block
scanning specifications. Presumably these are inheriting the ONFI
definition as stated in (A).
(C) There are many ONFI parts whose data sheets list their own bad
block scanning specifications that do not match (A) exactly. See
reference [3] for examples.

Currently, we don't follow (A) for NAND that reports ONFI
compatibility. In fact, we do not even have a flag that gives the
option for scanning 1st and last pages of a device (this can be
overcome pretty easily). Instead, after ONFI detection, nand_base
proceeds to its regular BBM code. This causes different manufacturers'
chips to be scanned according to their non-ONFI rules.

Now, I was considering trying to implement (A) more strictly, so that
if the chip reports ONFI compatibility, we scan 1st and last pages.
This would help define the otherwise ambiguous behavior for parts from
(B), which might otherwise default to the rules already in
nand_base.c. On the other hand, this would also modify the current
"established" behavior as well as violate the contradicting
definitions (as in (C)).

So I came up with a few options:
(a) Implement (A) for all ONFI-capable NAND
(b) Implement a flag for (A) without enforcing it for all ONFI NAND
(allow driver to specify, perhaps?)
(c) Make no change

We can rationalize (a) by the ONFI standard and claim that it makes
little breakage, since:
* all of the exceptions (in reference [3]) allow at least the 1st
page, 1st OOB byte scans. Last page is not a big addition
* the "1st and 2nd page" scans are only intended for when it wasn't
possible to scan the first page
* the "1st or 6th byte" scans can be safely treated with 1st-byte-only
scans (discussed in another thread recently)

Rationale for (b) is to totally prevent breakage while allowing
deterministic behavior for drivers that want to use the exact ONFI
specification.

Rationale for (c) is laziness or "selective effort" (whichever you
prefer). It seems that there are very few chips that actually follow
ONFI's BBM guidelines properly, so it may not really be worth it to
try to implement them and deal with the breakage. However, this leaves
no deterministic solution for chips that fall under (B).

FWIW, the motivating example for these questions (point (B): Hynix
H27U4G8F2DTR-BC) defaults to scanning the last page of each block in
the current nand_base.c. This may not be significantly different than
1st and last page.

Comments are appreciated. If you've read this far, you probably have
something to say :)

Brian

[1] ONFI 1.0 specification, section 3.2.2
A defective block is indicated by a byte value equal to 00h for 8-bit
access or a word value equal to 0000h for 16-bit access being present
at the first byte/word location in the defect area of either the first
page or last page of the block. The host shall check the first
byte/word of the defect area of both the first and last past page of
each block to verify the block is valid prior to any erase or program
operations on that block.

[2] Example of (B): Hynix H27U4G8F2DTR-BC

[3] http://www.linux-mtd.infradead.org/nand-data/nanddata.html
There are a range of data sheets that say to scan:
1st and 2nd page (1st byte in OOB)
1st page (1st byte in OOB)
1st page (1st or 6th byte in OOB)

Re: bad block markers + ONFI

[Florian Fainelli]

Hello Brian,

Le vendredi 11 novembre 2011 01:52:37, Brian Norris a écrit :
> Hello,
> 
> I've wondered for a while what the MTD community expects from ONFI
> NAND with respect to bad block markers and bad block scanning. I'll
> try to enumerate some observations, followed by some recommendations
> and rationale. Please comment, and maybe I'll code one of these
> options shortly. I'd like to settle the high level points first
> though.
> 
> Observations:
> 
> (A) ONFI spec says the host should scan the 1st OOB byte of the 1st
> and last pages of each block. See reference [1] for exact text.
> (B) There are some ONFI parts whose data sheets do not list bad block
> scanning specifications. Presumably these are inheriting the ONFI
> definition as stated in (A).
> (C) There are many ONFI parts whose data sheets list their own bad
> block scanning specifications that do not match (A) exactly. See
> reference [3] for examples.
> 
> Currently, we don't follow (A) for NAND that reports ONFI
> compatibility. In fact, we do not even have a flag that gives the
> option for scanning 1st and last pages of a device (this can be
> overcome pretty easily). Instead, after ONFI detection, nand_base
> proceeds to its regular BBM code. This causes different manufacturers'
> chips to be scanned according to their non-ONFI rules.
> 
> Now, I was considering trying to implement (A) more strictly, so that
> if the chip reports ONFI compatibility, we scan 1st and last pages.
> This would help define the otherwise ambiguous behavior for parts from
> (B), which might otherwise default to the rules already in
> nand_base.c. On the other hand, this would also modify the current
> "established" behavior as well as violate the contradicting
> definitions (as in (C)).
> 
> So I came up with a few options:
> (a) Implement (A) for all ONFI-capable NAND
> (b) Implement a flag for (A) without enforcing it for all ONFI NAND
> (allow driver to specify, perhaps?)
> (c) Make no change
> 
> We can rationalize (a) by the ONFI standard and claim that it makes
> little breakage, since:
> * all of the exceptions (in reference [3]) allow at least the 1st
> page, 1st OOB byte scans. Last page is not a big addition
> * the "1st and 2nd page" scans are only intended for when it wasn't
> possible to scan the first page
> * the "1st or 6th byte" scans can be safely treated with 1st-byte-only
> scans (discussed in another thread recently)
> 
> Rationale for (b) is to totally prevent breakage while allowing
> deterministic behavior for drivers that want to use the exact ONFI
> specification.
> 
> Rationale for (c) is laziness or "selective effort" (whichever you
> prefer). It seems that there are very few chips that actually follow
> ONFI's BBM guidelines properly, so it may not really be worth it to
> try to implement them and deal with the breakage. However, this leaves
> no deterministic solution for chips that fall under (B).
> 
> FWIW, the motivating example for these questions (point (B): Hynix
> H27U4G8F2DTR-BC) defaults to scanning the last page of each block in
> the current nand_base.c. This may not be significantly different than
> 1st and last page.
> 
> Comments are appreciated. If you've read this far, you probably have
> something to say :)

We have already seen a manufacturer reporting that a specific Flash part was 
ONFI-capable while it was not in fact, I also expect them not to 100% comply 
with the ONFI bad block scanning scheme (for compatibility reasons or no).

Considering that options a) is going to introduce quite some code, with a 
possibility of breakage, so in the end, we need the old non-ONFI BBM scanning 
code, I would vote for option b) which adds less code, preserves the existing 
scanning behavior, and still allows us to comply with the ONFI spec if we 
want.

> 
> Brian
> 
> [1] ONFI 1.0 specification, section 3.2.2
> A defective block is indicated by a byte value equal to 00h for 8-bit
> access or a word value equal to 0000h for 16-bit access being present
> at the first byte/word location in the defect area of either the first
> page or last page of the block. The host shall check the first
> byte/word of the defect area of both the first and last past page of
> each block to verify the block is valid prior to any erase or program
> operations on that block.
> 
> [2] Example of (B): Hynix H27U4G8F2DTR-BC
> 
> [3] http://www.linux-mtd.infradead.org/nand-data/nanddata.html
> There are a range of data sheets that say to scan:
> 1st and 2nd page (1st byte in OOB)
> 1st page (1st byte in OOB)
> 1st page (1st or 6th byte in OOB)
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

-- 
Florian

Re: bad block markers + ONFI

[Artem Bityutskiy]

On Thu, 2011-11-10 at 16:52 -0800, Brian Norris wrote:
> So I came up with a few options:
> (a) Implement (A) for all ONFI-capable NAND
> (b) Implement a flag for (A) without enforcing it for all ONFI NAND
> (allow driver to specify, perhaps?)
> (c) Make no change

Well, if we know that some NANDs will break with a), then probably it is
not an option, so we have only b) and c), right?

Artem.

Re: bad block markers + ONFI

[Brian Norris]

On Thu, Nov 17, 2011 at 1:51 PM, Artem Bityutskiy <dedekind1@gmail.com> wrote:
> On Thu, 2011-11-10 at 16:52 -0800, Brian Norris wrote:
>> So I came up with a few options:
>> (a) Implement (A) for all ONFI-capable NAND
>> (b) Implement a flag for (A) without enforcing it for all ONFI NAND
>> (allow driver to specify, perhaps?)
>> (c) Make no change
>
> Well, if we know that some NANDs will break with a), then probably it is
> not an option, so we have only b) and c), right?

I suppose.

I can't see how a driver would really want to use (b), though.
Essentially, the driver would have to have foreknowledge that the NAND
actually follows the ONFI BBM spec.

And (c) is a disappointing alternative. Still, it may not have much
practical effect, since, for instance, scanning just 1st page instead
of 1st and last does not usually cause any difference in bad block
detection.

Brian