Re: [Yaffs] Make YAFFS2 work, patch1

Top Page
Attachments:
Message as email
+ (text/plain)
Delete this message
Reply to this message
Author: Charles Manning
Date:  
To: yaffs
CC: Martin Fouts
Subject: Re: [Yaffs] Make YAFFS2 work, patch1
On Friday 14 October 2005 11:14, Martin Fouts wrote:
> Thank you for the patch. I've added it to my patch queue, and will test
> it as soon as I have time available.
>
> Marty
>
> > -----Original Message-----
> > From:
> > [mailto:yaffs-bounces@stoneboat.aleph1.co.uk] On Behalf Of
> > Sergey Kubushyn
> > Sent: Wednesday, October 12, 2005 10:12 AM
> > To: yaffs-list
> > Subject: [Yaffs] Make YAFFS2 work, patch1
> >
> > This is a quick hack probably good for foreseable future. I
> > don't think a revolution for large page devices is on the
> > horizon, we will be using that
> > nand_oob_64 autoplacement scheme for quite a long time.
> >
> > The proper way is to consult mtd_info->nand_oobinfo->oobavail
> > and handle YAFFS tags placement ourselves, in that same
> > mtdif2.c. Autoplacement is not rocket science, there is
> > nothing divine in it. As a matter of fact it's as simple as a
> > shovel and proper handling of oobavail part of the entire oob
> > area is trivial and easier to implement than to write a "Hello, world"
> > program.


My understanding from a IRC discussion where this was discussed with Thomas G,
and I might be wrong in this, is that the whole idea behind AUTOPLACE is for
the mtd decides on the actual physical location of the bytes.

The reason for using this, rather than any fixed placement is that it allows
the mtd user (YAFFS in this case) to ask the mtd to store/retrieve data on
its behalf without concern as to the actual physical address.

The patch shifts the data 2 bytes to move it past the bad block marker, since
the default position for a bad block marker is position 0 in the OOB area.,
and then does a raw read.

This makes some assumptions that:
* the default bad block marker is being used.
* the rest of the oob area has sufficient contigous area to store the packed
tags.

These assumptions are not valid for many situations. eg some that use HWECC or
some that use some different layout.

The whole point of AUTOPLACE is that the user can say: "Here is a buffer of
data. Store it as you see fit. I don't want to know about it". At present we
can only use AUTOPLACE semantics for a full page read/wr and not an OOB
read/wr. We still need to know the inside trickery for any raw reads.

I expect the patch will fix the situation for many, perhaps even most, users.
It is definitely an improvement and is worth applying, but it is not the end
of the road. We still should be using AUTOPLACE to do this properly.


> >
> > BTW, it is NOT a very good idea to write mtd->oobsize (i.e.
> > 64) bytes of data out of yaffs_PackedTags2 structure...


That is a good observation. It should really use the spareBuffer like the read
path does.

Charles