[Yaffs] Why does YAFFS skip the first block?

[Charles Manning]

On Wednesday 22 June 2005 07:25, Peter Barada wrote:
> I have a NOR implementation of YAFFS, and I've been pounding my head
> with mkyaffsimage.c trying to get an image that can be built on a linux
> box and used on a ColdFire mcf5475 based embedded Linux board using
> kernel 2.4.26.
>
> To do this, I've set up the MTD access such that the spare abuts its
> corresponding data chunk which all seems to work(this is that I make
> sure that a data chunk and spare are in the same block).  What I
> stumbled across is that YAFFS refuses to use the first flash block(whic=
h
> in my case is 64K in size) by setting dev->startBlock =3D 1 in
> yaffs_internal_read_super.  This causes it to behave bizarrely when I
> first burned the image created by mkyaffsimage into the flash starting
> at block zero.
>
> If I change dev->startBlock to zero, then yaffs_GutsInitialize() fails
> due to checks for a non-zero startBlock.  If I change those checks to
> allow a zero startBlock, things look like they work fine, including the
> image that mkyaffsimage created(after I modified write_chunk to place
> the data and spares in the appropriate offsets).
>
> Am I setting myself up for a bunch of problems by changing the
> startBlock to zero?

Not using chunk zero is a historical accident, of sorts. On NAND, chunk z=
ero=20
is guaranteed good while others might not. On many systems, the first n=20
chunks hold boot image  etc. Sometimes chunk zero is used to store bad bl=
ock=20
tables etc.

I needed a value for "invalid chunk" and "invalid block" and, because of =
the=20
above, and because zero is easy to use, I chose zero.  In hindsight, it m=
ight=20
have been better to use -1/0xffffffffff.

Most NAND folk don't hurt to much if a single block has to be lost (since=
=20
NAND typically has many blocks), but it can be  nasty for NOR folk with f=
ew=20
blocks.

All is not lost though, there is a way to use that block zero,  and it is=
=20
pretty straight forward. You just need to tell YAFFS some lies!

All yaffs flash calls go through a few access functions.=20
All you need to do is to do a mapping in these functions so that yaffs bl=
ock=20
1 =3D physical block 0.

eg.
int (*writeChunkToNAND)(struct yaffs_DeviceStruct *dev,int chunkInNAND, c=
onst=20
__u8 *data, yaffs_Spare *spare)
{
      chunkInNAND -=3D dev->nChunksPerBlock;=20

     .....   // rest of stuff
}

int (*eraseBlockInNAND)(struct yaffs_DeviceStruct *dev,int blockInNAND)
{
    blockInNAND--;
    ...// rest of stuff
}

Now you must need to keep the illusion going by setting up the device sta=
rt=20
and end blocks accordingly. If you have, say, 32 physical blocks numbered=
=20
from 0 to 31, then just set up startBlock=3D1 and endBlock =3D32;

There is no chunk or block info imprinted in the actual YAFFS data, so no=
=20
changes are needed to mkyaffsimage etc to make this work.

-- Charles



    =20