public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: "Alex Samoutin" <samoutin@hotbox.ru>
To: <tglx@linutronix.de>, "Thayne Harbaugh" <tharbaugh@lnxi.com>
Cc: linux-mtd@lists.infradead.org
Subject: Re: Fw: corrupt my NAND flash device
Date: Wed, 2 Jul 2003 10:43:11 -0700	[thread overview]
Message-ID: <000e01c340c1$73ca2800$1a00a8c0@itc.intrinsyc.com> (raw)
In-Reply-To: 200304302013.41845.tglx@linutronix.de

Hi Thomas,



Sorry for big delay with answer – I had no hardware to test. Now I got my
CerfCube 405ep back and can play with it.

So I had two problems

  1.. Write verify sometimes fail
  2.. Write operation during erase sometimes cause data corruption


Hardware details :

- NAND chip Toshiba TC58256AFT

- ALE/CLE and CE connected to GPIO

- R/B pin connected to GPIO and I use ready function which reads it pin.

- I played with different timings – even slowest setting gets  me the same
result



1-st problem was solved by applying new MTD snapshot  (Jun 26). It’s look
like nand_deselect(); nand_select() fixes the problem.



However  after applying new MTD release the 2-nd problem still remained.
Then I comment out erase abort in nand_get_chip (as you suggested) and it
fixes my second problem!



Could you remove this erase abort from MTD source? I think it will not
affect much on efficiency.



BTW -  jedec_probe.c file has no #include <linux/init.h> . And it cause
compilation problem within my source tree.



Alex Samoutin

Intrinsyc Software.







----- Original Message -----

From: "Thomas Gleixner" <tglx@linutronix.de>

To: "Alex Samoutin" <samoutin@hotbox.ru>; "Thayne Harbaugh"
<tharbaugh@lnxi.com>

Cc: <linux-mtd@lists.infradead.org>

Sent: Wednesday, April 30, 2003 11:13 AM

Subject: Re: Fw: corrupt my NAND flash device



On Wednesday 30 April 2003 18:54, Alex Samoutin wrote:

> Yes I had absolutely the same problem. Some times first write command was
> ignored, but second always successful. However I have no problem with
erase
> operations, only write some times was ignored.
>
> (For Thomas) It’s not a bad H/W or incorrect timing. I’ve played with
> timing and result was the same. Also I have 5 boards with Toshiba NAND
chip
> and 2 of them are working fine without retry, but other 3 need retry for
> normal operation.

What timing params did you play with ?
Are CLE/ALE connected to GPIO pins ?
Do you use a ready function, which reads the R/B hardware pin ?

Can you please check the following:

1. Add a delay into nand_wait and play with the time

--- nand.c 14 Apr 2003 07:00:39 -0000 1.43
+++ nand.c 30 Apr 2003 17:05:26 -0000
@@ -226,6 +226,8 @@
  this->hwcontrol (NAND_CTL_CLRALE);
  }

+ udelay (500);
+
  /*
  * program and erase have their own busy handlers
  * status and sequential in needs no delay

2.. Report if that helps or changes anything

3. Remove the erase abort in nand_get_chip
--- nand.c 14 Apr 2003 07:00:39 -0000 1.43
+++ nand.c 30 Apr 2003 17:08:23 -0000
@@ -287,16 +287,6 @@
  return;
  }

- if (this->state == FL_ERASING) {
- if (new_state != FL_ERASING) {
- this->state = new_state;
- spin_unlock_bh (&this->chip_lock);
- nand_select (); /* select in any case */
- this->cmdfunc(mtd, NAND_CMD_RESET, -1, -1);
- return;
- }
- }
-
  set_current_state (TASK_UNINTERRUPTIBLE);
  add_wait_queue (&this->wq, &wait);
  spin_unlock_bh (&this->chip_lock);

4.. Report if that helps or changes anything

Thanks

--
Thomas

  reply	other threads:[~2003-07-02 17:44 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-22 20:03 Fw: corrupt my NAND flash device Alex Samoutin
2003-04-22 20:26 ` Jörn Engel
2003-04-22 20:59   ` Jörn Engel
2003-04-23 20:45 ` Charles Manning
2003-04-24 18:25   ` Alex Samoutin
2003-04-25 13:01     ` Jörn Engel
2003-04-25 22:23       ` Alex Samoutin
2003-04-25 23:10         ` Thayne Harbaugh
2003-04-26 10:23           ` Jörn Engel
2003-04-28 15:02             ` Thayne Harbaugh
2003-04-28 21:14               ` Charles Manning
2003-04-28 22:59                 ` Thomas Gleixner
2003-04-29  1:23                   ` Charles Manning
2003-04-29  8:03                     ` Thomas Gleixner
2003-04-29 19:37                       ` Charles Manning
2003-04-29 22:04                         ` Thomas Gleixner
2003-04-30 16:54           ` Alex Samoutin
2003-04-30 18:13             ` Thomas Gleixner
2003-07-02 17:43               ` Alex Samoutin [this message]
2003-07-02 17:53                 ` Jasmine Strong
2003-07-02 20:10                   ` Alex Samoutin
2003-07-04  1:43                   ` David Woodhouse
2003-07-03  5:44                 ` Stephan Linke
2003-07-05 15:15                   ` Thomas Gleixner
2003-07-07  9:27                     ` Stephan Linke
2003-07-07 13:48                       ` Thomas Gleixner
2003-07-08  7:50                         ` David Woodhouse
2003-04-26 10:18         ` Jörn Engel
2003-04-28  8:57           ` Thomas Gleixner
  -- strict thread matches above, loose matches on Subject: below --
2003-08-18 11:36 Eugeny Mints
2003-04-22  7:05 Paul Wong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='000e01c340c1$73ca2800$1a00a8c0@itc.intrinsyc.com' \
    --to=samoutin@hotbox.ru \
    --cc=linux-mtd@lists.infradead.org \
    --cc=tglx@linutronix.de \
    --cc=tharbaugh@lnxi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox