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