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
(text/plain)