[Yaffs] Garbage collection issue.

Charles Manning manningc2@actrix.gen.nz
Mon, 28 Feb 2005 11:27:35 +1300


Mike=20

You're definitely on the right track.

When GC goes wrong you can bet on it being a geometry issue.


> Eventually, I determined that this was happening when the garbage
> collector ran. To verify, I modified the yaffs_CheckGarbageCollection()
> function to just return YAFFS_OK without doing any garbage collection o=
f
> any kind. As soon as I did this, all of my problems went away.
>
> I do not believe that this is a bug in the YAFFS code. Rather, I think
> the problem has to do with my definition of a block size and what is
> physically hooked up on my board.
>
> I have two NOR (StrataFlash) devices hooked up together to look like on=
e
> device. Is there anything special that I need to do with this situation=
?
>
> Currently, each individual chip has a block size of 0x20000 bytes. So, =
I
> have been reporting to YAFFS that the block size of the device is
> 0x40000 bytes. That way, when YAFFS wants to erase a block, I should be
> erasing one block from each chip and there won't be any overlap.

First off, please be warned that YAFFS was not really designed for NOR, a=
nd=20
in particular does not handle erase suspend, but still is being used for=20
quite a few shipping products.

You're doing the right thing with the two blocks being treated as one lar=
ge=20
block (ie. your 2x128kB blocks look like one 256 kB block).

Now NOR (typically) does not have spare/oob bytes and pages so you will h=
ave=20
to emulate this. Each page  (a page =3D=3D a chunk) is 512bytes data + 16=
 bytes=20
spare =3D 528 bytes.
So each block should have 256kB/528 =3D 496 pages.

Your flash access code should then be doing a mapping to make sure the da=
ta=20
and spare eareas are all addressed correctly.

Check that your device, once initialised, has

nChunksPerBlock =3D 496

I've seen this approach work fine on systems with 64kB blocks and 128kB=20
blocks. I have not yet seen it tried on 256kB blocks. It should all work =
OK=20
since I don't think there any limitations that will hurt.


-- CHarles