Re: nand oob layout assumptions

[Thomas Gleixner <tglx@linutronix.de>]

On Saturday 27 March 2004 08:40, Charles Manning wrote:
> >
> > We should check the possibility to use the 16 bit buswith with the same
> > driver. The command interface is still 8 bits, only the data interface is
> > 16 bit. It should be possible to combine those in one go.
>
> I think it is time we re-think the whole mtd interface for NAND. There are
> a bunch of new NAND parts out there that bring a whole new bunch of issues.
>
> For instance, the bad block handling is different in different NAND parts.
> 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.

> This is, BTW, the approach I have taken for YAFFS2. YAFFS2 has no ECC calcs
> or bad block logic in the file system "guts". Instead the mtd glue layer is
> currently tasked with this job, though in time I hope the actiual mtd ends
> up with the job.

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.

-- 
Thomas
________________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx@linutronix.de