Re: Erasebug on AMD flashes

public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed

* Re: Erasebug on AMD flashes
       [not found] <E1B3wBv-0005HA-9d@pentafluge.infradead.org>
@ 2004-03-18 22:02 ` dkey
  2004-03-19 10:20   ` David Vrabel
  0 siblings, 1 reply; 4+ messages in thread
From: dkey @ 2004-03-18 22:02 UTC (permalink / raw)
  To: linux-mtd, dvrabel

here is a picture of the flashes
http://www.dietmar-h.net/img/nokia_2xAMD_Pin12.jpg
and their configuration
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/21534.pdf

greets


On Thursday 18 March 2004 13:00, linux-mtd-request@lists.infradead.org wrote:
> Message: 4
> Date: Thu, 18 Mar 2004 10:25:17 +0000
> From: David Vrabel <dvrabel@arcom.com>
> Subject: Re: Erasebug on AMD flashes
> To: linux-mtd@lists.infradead.org
> Message-ID: <4059790D.4020904@arcom.com>
> Content-Type: text/plain; charset=us-ascii; format=flowed
>
> dkey wrote:
> > we are using jffs2 on the dbox2 and AMD flash chips, but since rev. 1.96
> > of cfi_cmdset_0002.c we can't erase the flashes. rev. 1.94 works without
> > problems.
>
> "since 1.96" doesn't make sense.  Any breakage would be from 1.95.
>
> > here are some debug infos, tell me if you need more!
>
> Part numbers of the flash chips and their configuration (interleaved etc.).
>
> > would be please if anybody can take a look over the code or revert
> > revision of cfi_cmdset_0002.c to 1.94.
>
> There's no reason why you can't revert to 1.94 yourself.
>
> FWIW, I'm now of the opinion that chip_status() is definately broken for
> interleaved chips and probably cannot be made to work without ending up
> with a mess.
>
> I would suggest using the data polling algorithm instead (where
> applicable).
>
> Also, ignoring the internal flash timeout (DQ5 toggling) and instead
> relying on the software timeout might be acceptable.  However, a
> repeatedly suspended erase keeps getting its software timeout extended
> and thus there is a possibility of the software timeout never occuring.
>   Hmmm.  An internal timeout requires a chip reset and thus we can't
> actually suspend an internally timed-out erase so the software timeout
> won't be extended.
>
> David Vrabel
> --
> David Vrabel, Design Engineer
>
> Arcom, Clifton Road           Tel: +44 (0)1223 411200 ext. 3233
> Cambridge CB1 7EA, UK         Web: http://www.arcom.com/
>
>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 18 Mar 2004 11:56:47 +0100
> From: Thomas Gleixner <tglx@linutronix.de>
> Subject: Re: Bug in nand_select_chip?
> To: llandre <r&d@wawnet.biz>, David Woodhouse <dwmw2@infradead.org>
> Cc: Andrea Scian <andrea.scian@wawnet.biz>
> Message-ID: <200403181156.47289.tglx@linutronix.de>
> Content-Type: text/plain; charset=iso-8859-1
>
> On Thursday 18 March 2004 10:56, llandre wrote:
> > >That's correct, but you unfortunaly relied on code, which was in a heavy
> > >modifciation phase. If you use leading edge code, be aware, that things
> > > might be broken from time to time. The fix for this was committed 10
> > > days after the first rework.
> >
> > Ok, thanks for the advice.
> > To avoid such problems, is it possible to download "stable" releases? Are
> > they tagged in the CVS repository?
>
> Yep, but the NAND stuff is quite new and not always up to date in the
> stable versions.
>
> You can subscribe on the CVS mailinglist, which informs you of all changes
> in the repository.
> http://lists.infradead.org/mailman/listinfo/linux-mtd-cvs

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Erasebug on AMD flashes
  2004-03-18 22:02 ` Erasebug on AMD flashes dkey
@ 2004-03-19 10:20   ` David Vrabel
  2004-03-19 12:27     ` Re[2]: " barthezz
  0 siblings, 1 reply; 4+ messages in thread
From: David Vrabel @ 2004-03-19 10:20 UTC (permalink / raw)
  To: linux-mtd

>> Part numbers of the flash chips and their configuration (interleaved etc.).
> [AM29DL322D]

Okay.  Are there two chips in parallel forming a 32 bit data bus (i.e. 
interleaved); or two chips in series forming a 16 bit data bus (i.e. 
non-interleaved); or some other weird scheme?

David Vrabel
-- 
David Vrabel, Design Engineer

Arcom, Clifton Road           Tel: +44 (0)1223 411200 ext. 3233
Cambridge CB1 7EA, UK         Web: http://www.arcom.com/

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re[2]: Erasebug on AMD flashes
  2004-03-19 10:20   ` David Vrabel
@ 2004-03-19 12:27     ` barthezz
  2004-03-22 10:41       ` David Vrabel
  0 siblings, 1 reply; 4+ messages in thread
From: barthezz @ 2004-03-19 12:27 UTC (permalink / raw)
  To: linux-mtd

Hallo David,

Friday, March 19, 2004, 11:20:57 AM, du hast geschrieben:

>>> Part numbers of the flash chips and their configuration (interleaved etc.).
>> [AM29DL322D]

DV> Okay.  Are there two chips in parallel forming a 32 bit data bus (i.e. 
DV> interleaved); or two chips in series forming a 16 bit data bus (i.e. 
DV> non-interleaved); or some other weird scheme?

DV> David Vrabel

There are two chips in parallel forming a 32 bit data bus (i.e. interleaved)

Mit freundlichen Grüssen,
 barthezz

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Erasebug on AMD flashes
  2004-03-19 12:27     ` Re[2]: " barthezz
@ 2004-03-22 10:41       ` David Vrabel
  0 siblings, 0 replies; 4+ messages in thread
From: David Vrabel @ 2004-03-22 10:41 UTC (permalink / raw)
  To: linux-mtd

[-- Attachment #1: Type: text/plain, Size: 515 bytes --]

> There are two AM29DL322D chips in parallel forming a 32 bit data bus (i.e. interleaved)

It's as I suspected.  Someone with interleaved AMD chips will have to 
fix the status checking code.

[30 mins later]

Find a patch attached.  It's not been tested or even been passed through 
a compiler. Let me know if it works or doesn't work, please.

David Vrabel
-- 
David Vrabel, Design Engineer

Arcom, Clifton Road           Tel: +44 (0)1223 411200 ext. 3233
Cambridge CB1 7EA, UK         Web: http://www.arcom.com/

[-- Attachment #2: mtd-interleaved-amd-chip-status-fix.patch --]
[-- Type: text/plain, Size: 5433 bytes --]

Index: drivers/mtd/chips/cfi_cmdset_0002.c
===================================================================
RCS file: /home/cvs/mtd/drivers/mtd/chips/cfi_cmdset_0002.c,v
retrieving revision 1.97
diff -u -B -p -r1.97 cfi_cmdset_0002.c
--- drivers/mtd/chips/cfi_cmdset_0002.c	24 Feb 2004 13:50:21 -0000	1.97
+++ drivers/mtd/chips/cfi_cmdset_0002.c	22 Mar 2004 10:37:32 -0000
@@ -451,6 +451,16 @@ static int chip_status(struct map_info *
 	return CHIP_ERROR;
 }
 
+static int chip_ready(struct map_info *map, unsigned long addr)
+{
+    cf_word d, t;
+
+    d = cfi_read(map, addr);
+    t = d ^ cfi_read(map, addr);
+
+    return t == 0;
+}
+
 static int get_chip(struct map_info *map, struct flchip *chip, unsigned long adr, int mode)
 {
 	DECLARE_WAITQUEUE(wait, current);
@@ -465,7 +475,7 @@ static int get_chip(struct map_info *map
 
 	case FL_STATUS:
 		for (;;) {
-			if (chip_status(map, adr) == CHIP_READY)
+			if (chip_ready(map, adr))
 				break;
 
 			if (time_after(jiffies, timeo)) {
@@ -506,7 +516,7 @@ static int get_chip(struct map_info *map
 		chip->state = FL_ERASE_SUSPENDING;
 		chip->erase_suspended = 1;
 		for (;;) {
-			if (chip_status(map, adr) == CHIP_READY)
+			if (chip_ready(map, adr))
 				break;
 
 			if (time_after(jiffies, timeo)) {
@@ -821,8 +831,11 @@ static int do_write_oneword(struct map_i
 			continue;
 		}
 
-		if ((status = chip_status(map, adr)) != CHIP_BUSY)
-			break;
+		if (chip_ready(map, adr))
+                        goto op_done;
+
+                if (time_after(jiffies, timeo))
+                        break;
 
 		/* Latency issues. Drop the lock, wait a while and retry */
 		cfi_spin_unlock(chip->mutex);
@@ -830,18 +843,8 @@ static int do_write_oneword(struct map_i
 		cfi_spin_lock(chip->mutex);
 	}
 
-	if (status == CHIP_READY)
-		goto op_done;
-
-	if (status == CHIP_TIMEDOUT)
-		printk(KERN_WARNING "MTD %s(): flash internal timeout\n",
-		       __func__);
-	else if (ta)
-		printk(KERN_WARNING "MTD %s(): software timeout\n",
-		       __func__ );
-	else
-		printk(KERN_WARNING "MTD %s(): unexpected failure.  status = %d\n",
-			__func__, status);
+        printk(KERN_WARNING "MTD %s(): software timeout\n",
+               __func__ );
 
  op_failed:
 	/* reset on all failures. */
@@ -1185,10 +1188,11 @@ static inline int do_write_buffer(struct
 			continue;
 		}
 
-		if( (status = chip_status(map, adr)) != CHIP_BUSY
-		    || ( ta = time_after(jiffies, timeo)) ) {
+		if (chip_ready(map, adr))
+                        goto op_done;
+                    
+		if( time_after(jiffies, timeo))
 			break;
-		}
 
 		/* Latency issues. Drop the lock, wait a while and retry */
 		cfi_spin_unlock(chip->mutex);
@@ -1196,20 +1200,8 @@ static inline int do_write_buffer(struct
 		cfi_spin_lock(chip->mutex);
 	}
 
-
-	if (status == CHIP_READY)
-		goto op_done;
-
-	if (status == CHIP_TIMEDOUT) {
-		printk(KERN_WARNING "MTD %s(): flash internal timeout\n",
-		       __func__);
-	}
-	else if (ta)
-		printk(KERN_WARNING "MTD %s(): software timeout\n",
-		       __func__ );
-	else
-		printk(KERN_WARNING "MTD %s(): unexpected failure.  status = %d\n",
-			__func__, status);
+        printk(KERN_WARNING "MTD %s(): software timeout\n",
+               __func__ );
 
  op_failed:
 	/* reset on all failures. */
@@ -1356,10 +1348,12 @@ static inline int do_erase_chip(struct m
 			chip->erase_suspended = 0;
 		}
 
-		if ((status = chip_status(map, adr)) != CHIP_BUSY
-		    || ( ta = time_after(jiffies, timeo)) )
+		if (chip_ready(map, adr))
+                        goto op_done;
+
+                if (time_after(jiffies, timeo))
 			break;
-		
+
 		/* Latency issues. Drop the lock, wait a while and retry */
 		cfi_spin_unlock(chip->mutex);
 		set_current_state(TASK_UNINTERRUPTIBLE);
@@ -1367,18 +1361,8 @@ static inline int do_erase_chip(struct m
 		cfi_spin_lock(chip->mutex);
 	}
 
-	if (status == CHIP_READY)
-		goto op_done;
-
-	if (status == CHIP_TIMEDOUT)
-		printk(KERN_WARNING "MTD %s(): flash internal timeout\n",
-		       __func__);
-	else if (ta)
-		printk(KERN_WARNING "MTD %s(): software timeout\n",
-		       __func__ );
-	else
-		printk(KERN_WARNING "MTD %s(): unexpected failure.  status = %d\n",
-		       __func__, status);
+        printk(KERN_WARNING "MTD %s(): software timeout\n",
+               __func__ );
 
  op_failed:
 	/* reset on all failures. */
@@ -1546,8 +1530,10 @@ static inline int do_erase_oneblock(stru
 			chip->erase_suspended = 0;
 		}
 
-		if ((status = chip_status(map, adr)) != CHIP_BUSY
-		    || ( ta = time_after(jiffies, timeo)) )
+		if (chip_ready(map, adr))
+                        goto op_done;
+
+                if (time_after(jiffies, timeo))
 			break;
 		
 		/* Latency issues. Drop the lock, wait a while and retry */
@@ -1556,20 +1542,10 @@ static inline int do_erase_oneblock(stru
 		schedule_timeout(1);
 		cfi_spin_lock(chip->mutex);
 	}
-
-	if (status == CHIP_READY)
-		goto op_done;
-
-	if (status == CHIP_TIMEDOUT)
-		printk(KERN_WARNING "MTD %s(): flash internal timeout\n",
-		       __func__);
-	else if (ta)
-		printk(KERN_WARNING "MTD %s(): software timeout\n",
-		       __func__ );
-	else
-		printk(KERN_WARNING "MTD %s(): unexpected failure.  status = %d\n",
-		       __func__, status);
-
+        
+        printk(KERN_WARNING "MTD %s(): software timeout\n",
+               __func__ );
+        
  op_failed:
 	/* reset on all failures. */
 	cfi_write( map, CMD(0xF0), chip->start );

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2004-03-22 10:41 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <E1B3wBv-0005HA-9d@pentafluge.infradead.org>
2004-03-18 22:02 ` Erasebug on AMD flashes dkey
2004-03-19 10:20   ` David Vrabel
2004-03-19 12:27     ` Re[2]: " barthezz
2004-03-22 10:41       ` David Vrabel

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox