Hello,

I wonder, at what oob offset yaffs2 out-of-band data is placed for curent 
yaffs2 users? This offset is taken from default nand_oobinfo structure in 
MTD. If not overriden, then it is nand_oob_64 in mtd/nand/nand_base.c, which 
sets offset to 2 (oobfree = {{2,38}}).

I personally, had to modify yaffs2 source, for it to work with such setting. 
Modification is necessarry, because that mtd->read_oob() call returns oob 
data from offset 0 (and not from offset 2, as specified by nand_oobinfo 
structure). My patch is attached for reference.

If nand_oobinfo structure is overriden and offset is set to 0, then patch in 
yaffs2 is not required anymore. But, MTD will recognize all used blocks as 
BAD. Offset 0 is used by MTD to mark block as bad. If it does not contain 
0xff, block is considered bad. So, here something has to be changed as 
well...

My solution does not look clean. I have a feeling, that it should be fixed in 
some other way, probably somewhere else. Maybe in MTD?
Does anyone have a patch to fix read_oob() call in MTD to return data from 
correct offset? Does yaffs1 still work after such change?
If changing read_oob() implementation in MTD is the correct way, then why it 
is not already fixed in MTD CVS? It looks like read_oob() by definition has 
to return oob data from offset 0...

I have a feeling, that MTD interface as such does not offer to read only OOB 
data from correct offset... Maybe read_ecc() can be used for this? Or maybe I 
have missed something?

How do others deal with that?

Thanks,
Artis