nand oob layout assumptions

David Woodhouse dwmw2 at infradead.org
Sat Mar 27 05:24:37 EST 2004


On Sat, 2004-03-27 at 09:07 +0100, Thomas Gleixner wrote:
> > For instance, the bad block handling is different in different NAND parts.

And in some cases in the _same_ NAND parts in different environments.
Consider the DiskOnChip, where on first format we look at the 'bad
block' markers in the OOB areas and build a separate bad block bitmap in
a dedicated sector. Then we erase the good blocks and use _every_ byte
in the OOB area. That's why I added the ->block_is_bad() callback from
the NAND code to the board-specific code, but I'm not sure that's
sufficient.

> > It is wrong, IMHO, to be handling bad-block logic in the file system.
> > Instead, the bad block handling should be done in mtd so that each
> > different chip can have its own methods and the file system can be kept
> > "clean".
> 
> I have already considered this. 
> But the fs must be aware of the bad block marker position in the OOB area, as 
> it can not use this byte for storing fs dependend data. The OOB usage is 
> given by the fs layer.

It might not be in the OOB area. The fs does need to be told which bytes
of the OOB area are reserved for hardware ECC and/or bad block markers,
but the hardware driver should still be responsible for bad block
handling.

> Not sure. The generic nand driver provides mechanisms to tell you where the 
> bad block marker is located and a basic protection against the erasing of bad 
> blocks. All other bad block handling tasks should be done in the fs layer.

Other than noticing them and avoiding them, there really isn't much
handling to be done.

-- 
dwmw2





More information about the linux-mtd mailing list