Mike 

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 of
> 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 one
> 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, and 
in particular does not handle erase suspend, but still is being used for 
quite a few shipping products.

You're doing the right thing with the two blocks being treated as one large 
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 have 
to emulate this. Each page  (a page == a chunk) is 512bytes data + 16 bytes 
spare = 528 bytes.
So each block should have 256kB/528 = 496 pages.

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

Check that your device, once initialised, has

nChunksPerBlock = 496

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


-- CHarles