[Yaffs] yaffs2 oob offset problem
Artis Kugevics
artis at mikrotik.com
Wed Aug 3 10:39:06 BST 2005
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: yaffs2-oob-offset.diff
Type: text/x-diff
Size: 666 bytes
Desc: not available
Url : http://lists.aleph1.co.uk/pipermail/yaffs/attachments/20050803/fd337bb0/yaffs2-oob-offset.bin
More information about the yaffs
mailing list