Re: [Yaffs] yaffs2 oob offset problem

Startseite
Anhänge:
Nachricht
+ (text/plain)
Nachricht löschen
Nachricht beantworten
Autor: Charles Manning
Datum:  
To: yaffs
CC: Ian McDonnell
Betreff: Re: [Yaffs] yaffs2 oob offset problem
Pardon the top post.

On further reflection I must concede that the current code is a bit of a mess.

It is a bit better since Luc removed the old mtd support.

If we just look at what is in CVS, the write path should be OK since YAFFS2
always writes both the data and the oob in one hit. In fact, the data-only
and spare-only paths can be removed.

The read path could have some problems because sometimes YAFFS only reads the
tags, and in that case the AUTOPLACE offset might not be applied. I'd have to
check nand_base.c properly to say.


Part of the hassle is due to two problems, in my opinion, in the mtd:

1. ECC and a few other properties are a compile time all-or-nothing affair.
IMHO these should be capabilities that you can interrogate and turn on/off at
the device level.
2. YAFFS should really be calling read_ecc always, but is seems (from a quick
look) that nand_base does not accept a null pointer for data (it should,
IMHO, do this and just treat this as "don't read").

-- Charles


On Thursday 04 August 2005 02:40, Ian McDonnell wrote:
> On Wednesday 03 August 2005 07:00, Artis Kugevics
>
> wrote:
> > 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.
>
> Attached is the hacking I did to get this to work for me.
> I have yaffs1 call mtd->read_oob normally. Then in yaffs_mtdif2.c
> I hack the call to mtd->read_oob to pass a null 'retlen'
> pointer.
>
> Then in MTD nand_base.c, I hacked the nand_read_oob function to
> not 'do-the-wrong-thing' when it is called with a null retlen.
> So I'm overloading 'retlen' and using it as a flag --- yes this
> is a hack, but so is MTD ;)
>
> I don't understand why this isn't broken for everyone?
> I don't know how yaffs2 ever works with the stock MTD code.
>
> See attached files/functions.
>
> -imcd