Author: Ian McDonnell Date: To: tglx CC: yaffs Subject: Re: [Yaffs] yaffs2 oob offset problem
On Thursday 04 August 2005 09:22, Thomas Gleixner wrote: > > 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. We do.
> > 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 ? Because the standard one only looks at a single byte at position
this->badblockpos.... read on...
> 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.
My interpretation of the text in the ST MicroElectronics spec. is that a bad
block may be marked bad by a non-0xff byte at offset 0 *and/or* offset 5.
I agree that if it is just 'and' then testing the first byte is sufficient,
but I read the text as 'and/or' so I want to test both bytes. Thus a private
nand_block_bad function.