Re: [Yaffs] Why does YAFFS skip the first block?

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(which
> in my case is 64K in size) by setting dev->startBlock = 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 zero
is guaranteed good while others might not. On many systems, the first n
chunks hold boot image etc. Sometimes chunk zero is used to store bad block
tables etc.

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

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

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

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

eg.
int (*writeChunkToNAND)(struct yaffs_DeviceStruct *dev,int chunkInNAND, const 
__u8 *data, yaffs_Spare *spare)
{
      chunkInNAND -= dev->nChunksPerBlock; 

     .....   // 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 start
and end blocks accordingly. If you have, say, 32 physical blocks numbered
from 0 to 31, then just set up startBlock=1 and endBlock =32;

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

-- Charles