On Thursday 04 August 2005 16:06,
tglx@linutronix.de wrote:
> 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".
>
Thomas, you may well be right. But the text is confusing; you cut
it short in your quote. The full paragraph from the datasheet
reads:
quote: "The devices are supplied with all the locations inside
valid blocks erased (FFh). The Bad Block Information
is written prior to shipping. Any block,
where the 1st and 6th Bytes, or 1st Word, in the
spare area of the 1st page, does not contain FFh,
is a Bad Block."
The "does not contain" inverts the logic for me, so I interpreted
this as "if the (1st != 0xff || 6th != 0xff) then bad",
but it could be "if the (1st == 0xff || 6th == 0xff) then good".
I choose the first interpretion to be safe.
Thank goodness we don't program in English like lawyers do!
> 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.
We have tight system start-up timing requirements and the 100-200
milliseconds that it takes MTD to scan our NAND device is better
avoided for our application. The changes only encompass a dozen
lines or so. Yaffs does its scan later in our start-up
sequence, and it only scans the region of NAND that covers the
Yaffs filesystem. We much prefer the bad-block test be done on
the fly. We were planning to do this with our own modifications
and were pleased to see MTD how supports this scheme.
-imcd
(text/plain)