Re: [Yaffs] yaffs2 oob offset problem

Top Page
Attachments:
Message as email
+ (text/plain)
Delete this message
Reply to this message
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.

-imcd