NAND OOB Questions...

NAND OOB Questions...

[Steve Finney]

I have 3 questions about OOB and NAND chips that I'm
hoping someone can answer. Per an earlier post, I think
there may be two (obscure?) bugs in nand_base.c, but
there's too much I don't know about NAND (and the code) to be sure.
I believe the following description applies to the most recent
stable kernel source (2.6.16.19).

1) The Samsung K9F56* NAND chip allows doing more than one write
to the OOB area of a page without an erase; the second write
may zero bits that were set to 1 by the first write. Is the Samsung
chip unusual in this, or is this normal NAND behavior? (I believe
this would be normal for NOR flash).

2) In nand_base.c:nand_write_page(), OOB data is written even when
NAND_ECC_NONE is set. Under what circumstances is this useful?
(The issue with this is that, in conjunction with (1), this may
overwrite OOB in a circumstance where you're trying to write it
yourself from user space; pernaps this is something that's only relevant
for diagnostics/debugging).

3) nand_prepare_oobbuf() makes a point of setting the internal oobbuf
to 0xFF if it's had ECC bytes written to it (based on the this->oobdirty
flag). However, the default case (which includes hardware ECC) in
nand_write_page() can write the internal oobbuf without setting
this->oobdirty, and thus not triggering the later reset to 0xFF. Is
there a rationale for this? (The OOB issue induced by 1 & 2 would be
benign if oobbuf was cleared to 0xFF).

Thanks for any info.
sf

Re: NAND OOB Questions...

[Thomas Gleixner]

On Thu, 2006-06-01 at 09:38 -0700, Steve Finney wrote:
> 1) The Samsung K9F56* NAND chip allows doing more than one write
> to the OOB area of a page without an erase; the second write
> may zero bits that were set to 1 by the first write. Is the Samsung

Bits can not be set to 1 by the first write. FLASH cells are set to 1 by
erasing and programming can set bits to 0.

> chip unusual in this, or is this normal NAND behavior? (I believe
> this would be normal for NOR flash).

On NOR you can do this almost unlimited. NAND is much more restricted
vs. write ordering.

> 2) In nand_base.c:nand_write_page(), OOB data is written even when
> NAND_ECC_NONE is set. Under what circumstances is this useful?
> (The issue with this is that, in conjunction with (1), this may
> overwrite OOB in a circumstance where you're trying to write it
> yourself from user space; pernaps this is something that's only relevant
> for diagnostics/debugging).

The buffer is usually 0xff except when a caller provides content.

> 3) nand_prepare_oobbuf() makes a point of setting the internal oobbuf
> to 0xFF if it's had ECC bytes written to it (based on the this->oobdirty
> flag). However, the default case (which includes hardware ECC) in
> nand_write_page() can write the internal oobbuf without setting
> this->oobdirty, and thus not triggering the later reset to 0xFF. Is
> there a rationale for this? (The OOB issue induced by 1 & 2 would be
> benign if oobbuf was cleared to 0xFF).

Well, if you use ECC then ECC is always at the same offset in the buffer
so there is no point in setting it back to 0xff all them time.

Please be aware that the NAND driver has been refactored and some of the
algorithms have been changed. 
See: http://git.infradead.org/?p=mtd-2.6.git;a=summary
These changes will hit mainline in the 2.6.18 merge window.

	tglx

Re: NAND OOB Questions...

[Charles Manning]

On Monday 05 June 2006 20:14, Thomas Gleixner wrote:
> On Thu, 2006-06-01 at 09:38 -0700, Steve Finney wrote:
> > 1) The Samsung K9F56* NAND chip allows doing more than one write
> > to the OOB area of a page without an erase; the second write
> > may zero bits that were set to 1 by the first write. Is the Samsung
>
> Bits can not be set to 1 by the first write. FLASH cells are set to 1 by
> erasing and programming can set bits to 0.
>
> > chip unusual in this, or is this normal NAND behavior? (I believe
> > this would be normal for NOR flash).
>
> On NOR you can do this almost unlimited. NAND is much more restricted
> vs. write ordering.

Just one point of clarification that tglx might not have spelled out clearly 
here.

In both NAND and NOR you cannot set a 0 bit back to a 1 bit by programming. 
You can only do this by erasing the erasable block.

Where NOR and NAND differ is that if you program a pattern into NOR that tries 
to set a 0 to a 1 then (in most cases) the programming operation will be 
aborted. However, NAND will program the zeros only and 1 bits are just "don't 
care".

Re: NAND OOB Questions...

[Thomas Gleixner]

On Mon, 2006-06-05 at 08:17 -0700, Steve Finney wrote:
> >From: Thomas Gleixner <tglx@linutronix.de>
> >The buffer is usually 0xff except when a caller provides content.
> 
> I'm not going to repeat all the previous content, but from what you've said,
> it confirms that there is a bug in the current nand_base.c code under the following particular
> set of circumstances:
> 
> 1) A NAND flash that allows more than one cycle of writing between erases (at
>   least in the OOB area). (e.g., the Samsung K9F* chip).
> 2) Using hardware ECC (e.g., the Samsung S3C2410 processor).
> 3) A sequence in which you initially write to the device with ECC, and then
>   turn off ECC and do additional writes including the OOB area.
> 
> In the above sequence, the ECC the user writes to the OOB may get corrupted.

Yeah. I did not think about that abstruse scenario :) What the hell is
this for ?

> I  have an (ugly) user-level workaround: before I turn off the ECC, I write a 
> block that I know will generate ECC bytes consisting of 0xFF. Then the subsequent
> user ECC writes are OK.
> 
> It's obscure enough that it's probably not worth fixing (well, I'm not going to try to
> fix it :-) ),  and hopefully it's fixed in the refactoring. 

Should be.

	tglx

Re: NAND OOB Questions...

[Thomas Gleixner]

On Tue, 2006-06-06 at 07:12 -0700, Steve Finney wrote:
> >Yeah. I did not think about that abstruse scenario :) What the hell is
> >this for ?
> 
> Well, I didn't go looking for bugs :-). The hardware is the board I'm working on,
> and what I wanted to do was force single bit errors to verify that the read correction
> code worked. My way of doing that was to let the kernel write the correct ECC, 
> and then read it back, corrupt a single data bit, and write the data +OOB back with unchanged
> OOB. It didn't work :-(.

Ok. Makes sense.

> As long as I'm here...is there any clever way of clearing a bad block marker? I realize
> you do _not_ want to do this in the real world, but I created a few fake bad blocks for
> testing purposes and there seems to be no way to get rid of them; neither Linux nor U-Boot
> will let you call erase on a bad block. You can recompile U-Boot to allow it to do so, but
> I'm wondering if there's any other way.

Yes, switch the bad block stuff off in the kernel. :) You can do this
also from your module by overriding the block_bad function.

	tglx