Re: [Yaffs] Yaffs2 erasure issue on MT29 NAND part

Hello Andrew

On Friday 31 July 2009 04:24:29 Andrew McKay wrote:
> [snip]
>
> >>> Try doing some nandwrites etc to manually do stuff to the block and see
> >>> if that works.
> >>
> >> How would you recommend doing this? Unmounting the YAFFS2 file system
> >> and reading and writing the NAND block device directly?
> >
> > Yes, do some manual operations on an unmounted yaffs partition.
>
> Thanks for the help Charles
>
> I did this with mtd-utils and writing to the mtdblock device using dd. I
> didn't seem to have any issues. The blocks that YAFFS2 were saying
> couldn't be erased were erased successfully (and thus not marked bad). I
> will test a bit more with it.

First off, please pick up the latest from cvs. The most recent patches should
not be material to the issues you are dealing with but they might be
confusing things a bit.

>
> I returned the cleaned up NAND to our application developer and it worked
> for a while, but eventually started showing the same errors as previous.
> The file system doesn't seem to corrupt, but blocks get in this state where
> they apparently can't be erased or marked bad.
>
> The NAND device I'm using is a 4K page 128bit OOB part. As I mentioned I
> had to add some code to the kernel to get things working properly at the
> MTD layer. Is there a possibility that the YAFFS2 file system doesn't like
> parts with 4K pages? Or does the MTD layer make this invisible to YAFFS2?

YAFFS will happily work with 4k parts.

>
> I'm trying to get an understanding of how the OOB area is used byt both
> YAFFS2 and MTD without stepping on each other toes. I think I have it
> figured out, and I don't think that they are trying to use the same bytes
> in the OOB area.
>
> The YAFFS2 code I'm using is also older. I think I might try pulling in
> some more recent code from your repository in hopes that it will fix
> things.

Yes do, apart from picking up some fixes, it also means we have a reasonable
chance of a coherent discussion.

>
> I'm also trying to get our hardware guys to source 16Gbit NAND with 2K
> blocks and 64bit OOB in hopes that the problem will go away.

All that will do is help you have a different test case. Not a bad idea, but I
wouldn't burst a boiler to achieve it. You should be able to achieve a
working system with 4k.

>
> Anything else you'd recommend looking into?

See how the latest code works for you first.

Then I suggest doing things like:
* write some files, reboot and check the files are there (ie. checking basic
stuff).
* Do operations periodically checking /proc/yaffs, df etc looking for sanity.
* Enable mtd error checking etc.

-- CHarles