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.

-imcd