nand: oob question

Joshua Wise joshua at joshuawise.com
Tue Dec 9 21:12:07 EST 2003


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 09 December 2003 7:38 pm, you wrote:
> NAND typically has pages with 512bytes data + 16 bytes oob.
Right, that would be consistant with my 16MiB Samsung flash on h1910.

> Why do you think jffs2 wants 32bytes of OOB?

fs/jffs2/wbuf.c:944 (or thereabouts, I've added debugging printks here and 
there)
/*
                   *    We read oob data from page 0 and 1 of the block.
                   *    page 0 contains cleanmarker and badblock info
                   *    page 1 contains failure count of this block
                 */
                ret = c->mtd->read_oob (c->mtd, offset, oob_size << 1, 
&retlen, buf);

This is interesting for a number of reasons.
Firstly, nandwrite does not handle writing failure counts of a block. This is 
bad, or so I think.
Secondly, in nand_read_oob, we only send the NAND_READOOB command once at one 
column. This would, per my flash's specs, only send one 16byte set of data. 
This is again bad, or so I think. When I modify it to send the NAND_READOOB 
stuff as we increment col, then it gets somewhere, but it still seems to be 
giving garbage results (ie, the same 16 bytes.) The failure symptoms without 
NAND_READOOB being resent are a slowly increasing failure count (1~128), with 
some bumps of garbage (sometimes my NAND flash likes to insert 12 bytes of 
garbage at the beginning of a read, which is an issue of its own. Jacking the 
cmd delay up way high seems to have done something about that though.)

I'm rather perplexed here. I thought I understood it fairly well, although it 
is evident that I don't. Can someone enlighten me?

> -- Charles
/joshua

- -- 
Joshua Wise | www.joshuawise.com
GPG Key     | 0xEA80E0B3
Quote       | <lilo> I akilled *@* by mistake
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/1oD3Pn9tWOqA4LMRAjYTAJ0Q0zt7tFHTEjhAb1zHMsxaASG/nwCfQ32h
TzIUtUWazzQn8TxiOCwhIL0=
=IGlY
-----END PGP SIGNATURE-----




More information about the linux-mtd mailing list