NAND write verify failed problem

NAND write verify failed problem

[Pantelis Antoniou]

Hi

I'm testing a new board with a NAND device chip
and I've hit a couple of problems which I'm not
sure what the problem is.

My configuration is as follows.

CPU: MPC850SR powerpc
NAND: Samsung K9FF5608U0B (32Mb, 8bit interface).
Kernel: LinuxPPC 2.4.21-rc2 devel.

The kernel has fairly recent MTD drivers and a diff
found no major differences.
I use the mtd utils from the latest nightly tarball.

The NAND driver is a custom one I made based on the
example in the docs. It is fairly simple and the
chip is detected alright at boot time.

The relevant .config fragment is as follows:

CONFIG_MTD=y
CONFIG_MTD_DEBUG=y
CONFIG_MTD_DEBUG_VERBOSE=0
CONFIG_MTD_PARTITIONS=y
CONFIG_MTD_CONCAT=y
CONFIG_MTD_CMDLINE_PARTS=y
CONFIG_MTD_CHAR=y
CONFIG_MTD_BLOCK=y
CONFIG_MTD_NAND=y
CONFIG_MTD_NAND_VERIFY_WRITE=y
CONFIG_MTD_NAND_NETVIA=y # the name of my board
CONFIG_MTD_NAND_IDS=y

I intend to use JFFS2 which I used in a previous
design with a NOR flash.

Mounting an NFS root from a shell on the target...

Erasing seems to go well.

 > root$ eraseall -j /dev/mtd0
Erasing 16 Kibyte @ 1ffc000 -- 99 % complete. Cleanmarker written at 1ffc000

Making a test jffs2 image (size 540672 bytes)

 > root$ mkfs.jffs2 -e16384 -b -p -v -d /root/ -o /tmp/root.jffs2.image

Copying the image to the NAND.

 > root$ fcp -v /tmp/root.jffs2.image /dev/mtd0
 > Erasing blocks: 33/33 (100%)
 > Writing data: 528k/528k (100%)
 > Verifying data: 20k/528k (3%)File does not seem to match flash data. 
First mismatch at 0x00002800-0x00005000

We have the first warning that something is amiss.
Still no warning or error at syslog.

Now things get interesting...

 > root$ mount -t jffs2 /dev/mtdblock0 /mnt/

Mount takes 30 seconds to finish, and during that time the board does not
respond to any external stimulus. This is caused I believe from the scaning
of the NAND, which I take it is normal.

The contents of the files match what was written to the image.

But when I try to write by copying a small file the write fails
and I get the following to the syslog.

nand_write_page: Failed write verify, page 0x0000040b <5>Write of 68 
bytes at 0x00081774 failed. returned -5, retlen 0
Mar 10 21:44:22 netvia-ppc kernel: Not marking the space at 0x00081774 
as dirty because the flash driver returned retlen zero

Any ideas how to proceed?

Regards

Pantelis

Re: NAND write verify failed problem (SOLVED?)

[Pantelis Antoniou]

Pantelis Antoniou wrote:

> Hi
>
> I'm testing a new board with a NAND device chip
> and I've hit a couple of problems which I'm not
> sure what the problem is.
>
> My configuration is as follows.
>
> CPU: MPC850SR powerpc
> NAND: Samsung K9FF5608U0B (32Mb, 8bit interface).
> Kernel: LinuxPPC 2.4.21-rc2 devel.
>
> The kernel has fairly recent MTD drivers and a diff
> found no major differences.
> I use the mtd utils from the latest nightly tarball.
>
> The NAND driver is a custom one I made based on the
> example in the docs. It is fairly simple and the
> chip is detected alright at boot time.
>
> The relevant .config fragment is as follows:
>
> CONFIG_MTD=y
> CONFIG_MTD_DEBUG=y
> CONFIG_MTD_DEBUG_VERBOSE=0
> CONFIG_MTD_PARTITIONS=y
> CONFIG_MTD_CONCAT=y
> CONFIG_MTD_CMDLINE_PARTS=y
> CONFIG_MTD_CHAR=y
> CONFIG_MTD_BLOCK=y
> CONFIG_MTD_NAND=y
> CONFIG_MTD_NAND_VERIFY_WRITE=y
> CONFIG_MTD_NAND_NETVIA=y # the name of my board
> CONFIG_MTD_NAND_IDS=y
>
> I intend to use JFFS2 which I used in a previous
> design with a NOR flash.
>
> Mounting an NFS root from a shell on the target...
>
> Erasing seems to go well.
>
> > root$ eraseall -j /dev/mtd0
> Erasing 16 Kibyte @ 1ffc000 -- 99 % complete. Cleanmarker written at 
> 1ffc000
>
> Making a test jffs2 image (size 540672 bytes)
>
> > root$ mkfs.jffs2 -e16384 -b -p -v -d /root/ -o /tmp/root.jffs2.image
>
> Copying the image to the NAND.
>
> > root$ fcp -v /tmp/root.jffs2.image /dev/mtd0
> > Erasing blocks: 33/33 (100%)
> > Writing data: 528k/528k (100%)
> > Verifying data: 20k/528k (3%)File does not seem to match flash data. 
> First mismatch at 0x00002800-0x00005000
>
> We have the first warning that something is amiss.
> Still no warning or error at syslog.
>
> Now things get interesting...
>
> > root$ mount -t jffs2 /dev/mtdblock0 /mnt/
>
> Mount takes 30 seconds to finish, and during that time the board does not
> respond to any external stimulus. This is caused I believe from the 
> scaning
> of the NAND, which I take it is normal.
>
> The contents of the files match what was written to the image.
>
> But when I try to write by copying a small file the write fails
> and I get the following to the syslog.
>
> nand_write_page: Failed write verify, page 0x0000040b <5>Write of 68 
> bytes at 0x00081774 failed. returned -5, retlen 0
> Mar 10 21:44:22 netvia-ppc kernel: Not marking the space at 0x00081774 
> as dirty because the flash driver returned retlen zero
>
> Any ideas how to proceed?
>
> Regards
>
> Pantelis
>
>
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>
>
I hate to reply to myself, but the problem appears to be the NAND verify
code. When I removed it everything works fine. Should I be worried though?

Regards

Pantelis

Re: NAND write verify failed problem

[Thomas Gleixner]

On Monday 02 June 2003 13:04, Pantelis Antoniou wrote:
>
>  > root$ fcp -v /tmp/root.jffs2.image /dev/mtd0
>  > Erasing blocks: 33/33 (100%)
>  > Writing data: 528k/528k (100%)
>  > Verifying data: 20k/528k (3%)File does not seem to match flash data.
Are you writing with ECC ? If not use nandwrite from mtd/utils

> Mount takes 30 seconds to finish, and during that time the board does not
> respond to any external stimulus. This is caused I believe from the scaning
> of the NAND, which I take it is normal.
Should be much faster with current MTD CVS code


> nand_write_page: Failed write verify, page 0x0000040b <5>Write of 68
> bytes at 0x00081774 failed. returned -5, retlen 0
> Mar 10 21:44:22 netvia-ppc kernel: Not marking the space at 0x00081774
> as dirty because the flash driver returned retlen zero
> Any ideas how to proceed?

Yes, update nand driver from MTD-CVS. It's fixed.

-- 
Thomas
________________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx@linutronix.de

Re: NAND write verify failed problem

[Pantelis Antoniou]

Thomas Gleixner wrote:

>On Monday 02 June 2003 13:04, Pantelis Antoniou wrote:
>  
>
>> > root$ fcp -v /tmp/root.jffs2.image /dev/mtd0
>> > Erasing blocks: 33/33 (100%)
>> > Writing data: 528k/528k (100%)
>> > Verifying data: 20k/528k (3%)File does not seem to match flash data.
>>    
>>
>Are you writing with ECC ? If not use nandwrite from mtd/utils
>
>  
>
>>Mount takes 30 seconds to finish, and during that time the board does not
>>respond to any external stimulus. This is caused I believe from the scaning
>>of the NAND, which I take it is normal.
>>    
>>
>Should be much faster with current MTD CVS code
>
>
>  
>
>>nand_write_page: Failed write verify, page 0x0000040b <5>Write of 68
>>bytes at 0x00081774 failed. returned -5, retlen 0
>>Mar 10 21:44:22 netvia-ppc kernel: Not marking the space at 0x00081774
>>as dirty because the flash driver returned retlen zero
>>Any ideas how to proceed?
>>
>
>Yes, update nand driver from MTD-CVS. It's fixed.
>  
>

I ran into problems by trying to use a vanilla 2.4.21-rc7 with utils 
from the MTD latest snapshot.

Patching the kernel with the MTD-CVS fixed everything.

BTW, is there something anologous to CRAMFS for NAND flash?
I have a need for a compressed read-only filesystem on NAND
but CRAMFS has no concept of bad blocks.

Regards and thanks for the reply.

Pantelis

Re: NAND write verify failed problem -->cramfs

[Charles Manning]

> BTW, is there something anologous to CRAMFS for NAND flash?
> I have a need for a compressed read-only filesystem on NAND
> but CRAMFS has no concept of bad blocks.

You could use loop mounting. ie. store the CRAMFS  image using a normal NAND 
file system (YAFFS or JFFS2) and loop mount it with cramfs.

-- CHarles

Re: NAND write verify failed problem -->cramfs

[Kevin Liao]

Sorry I am new to this list and I have two questions as below:

1. To loop mount a CRAMFS (root file system) image on one JFFS2 partition, we should mount that partition first, shouldn't we? But
how can we mount that JFFS2 partition without mounting the root file system?

2. Currently I use NAND flash with ramdisk image on /dev/mtdblock1 as the root file system. Usually I write the ramdisk image using
the command "nandwrite /dev/mtdblock1 ramdisk.gz". So far everything works fine. But I am wondering whether the kernel can still
load the ramdisk image if there are some bad blocks on /dev/mtdblock1?

Thanks a lot for the help.

Regards,
Kevin

----- Original Message ----- 
From: "Charles Manning" <manningc2@actrix.gen.nz>
To: "Pantelis Antoniou" <panto@intracom.gr>; <tglx@linutronix.de>
Cc: <linux-mtd@lists.infradead.org>
Sent: Friday, June 06, 2003 5:10 AM
Subject: Re: NAND write verify failed problem -->cramfs



> BTW, is there something anologous to CRAMFS for NAND flash?
> I have a need for a compressed read-only filesystem on NAND
> but CRAMFS has no concept of bad blocks.

You could use loop mounting. ie. store the CRAMFS  image using a normal NAND
file system (YAFFS or JFFS2) and loop mount it with cramfs.

-- CHarles

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: NAND write verify failed problem -->cramfs

[Charles Manning]

On Friday 06 June 2003 21:54, you wrote:
> Sorry I am new to this list and I have two questions as below:
>
> 1. To loop mount a CRAMFS (root file system) image on one JFFS2 partition,
> we should mount that partition first, shouldn't we? But how can we mount
> that JFFS2 partition without mounting the root file system?

Doing this with a root file system makes it a bit more challenging... I don't 
know if that can be done.
>
> 2. Currently I use NAND flash with ramdisk image on /dev/mtdblock1 as the
> root file system. Usually I write the ramdisk image using the command
> "nandwrite /dev/mtdblock1 ramdisk.gz". So far everything works fine. But I
> am wondering whether the kernel can still load the ramdisk image if there
> are some bad blocks on /dev/mtdblock1?

You could perhaps use a cut-down version of YAFFS (like is used in the YAFFS 
bootloader) to store a CRAMFS image. This is relatively simple and quite a 
few people do this for booting.

Do you have enough RAM to load the image into RAM at boot? That would make it 
even easier.

-- CHarles

>
> Thanks a lot for the help.
>
> Regards,
> Kevin
>
> ----- Original Message -----
> From: "Charles Manning" <manningc2@actrix.gen.nz>
> To: "Pantelis Antoniou" <panto@intracom.gr>; <tglx@linutronix.de>
> Cc: <linux-mtd@lists.infradead.org>
> Sent: Friday, June 06, 2003 5:10 AM
> Subject: Re: NAND write verify failed problem -->cramfs
>
> > BTW, is there something anologous to CRAMFS for NAND flash?
> > I have a need for a compressed read-only filesystem on NAND
> > but CRAMFS has no concept of bad blocks.
>
> You could use loop mounting. ie. store the CRAMFS  image using a normal
> NAND file system (YAFFS or JFFS2) and loop mount it with cramfs.
>
> -- CHarles
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>
>
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/