On Wed, 2005-08-03 at 11:44 -0400, Ian McDonnell wrote:
> The hacked nand_read_oob function included in my earlier posting assumes
> that the first element in the 'oobfree' list defines a region that is
> sufficient for yaffs2 tags, i.e. at least 28 bytes. The hack does not
> do the full oob scatter/gather thing.
> 
> The root problem is that YAFFS2 needs AUTOPLACMENT functionality
> on mtd->read_oob when MTD is provided the ECC functionality, and
> mtd->read_oob is providing a raw interface.

Makes sense. I look into this to find an acceptable solution, which
covers also the scattered case.

> Our mtd flash i/o setup uses its own struct nand_oobinfo nand_oob_64,
> see below.  I 'reserved' the first 6 bytes because the ST large-page
> chip we are using (NAND01GW3B2AN6) has bad-block markers at the 1st
> and the 6th bytes.  MTD's equivalent struct (in nand_base.c) starts
> user data at offset 2 so would/will overwrite the factory installed

Therefor you can provide board specific oobinfo.

> bad-block status in the sixth byte.  [For this reason too we have our
> own mtd nand_block_bad function and there was some MTD hacking necessary
> to get that working -- if you need that, e-mail].

Hmm, why do you need your own nand_block_bad function ? I'd prefer a
clean integration into the bad block table code. This is preferrable for
speed reasons anyway.

I'm not sure whether it is necessary to handle the offset 5 marker at
all. AFAICS this is only a compatibility thingy vs. the small page FLASH
types. The data sheets clearly say that both locations are non 0xFF. So
it's sufficient for me to look at offset 0 only. If a block is bad it is
not touched anyway, so nothing will ever overwrite there.

tglx