Re: [Yaffs] yaffs2 oob offset problem

Top Page
Attachments:
Message as email
+ (text/plain)
Delete this message
Reply to this message
Author: Thomas Gleixner
Date:  
To: Ian McDonnell
CC: yaffs
Subject: Re: [Yaffs] yaffs2 oob offset problem
On Thu, 2005-08-04 at 15:42 -0400, Ian McDonnell wrote:
> > 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.


"... written prior to shipping. Any block where the 1st and the 6th
Bytes, or the 1st Word, in the spare area ...."

I don't see an "or" between "1st" and "6th".

Anyway, instead of hacking a nand_block_bad replacement it would have
been much simpler to provide your own bad block scan descriptor and let
the existing code build the ram based bad block table, which is much
more efficient as nand_block_bad then just looks up a bit in RAM instead
of reading oob each time.

tglx