All of lore.kernel.org
 help / color / mirror / Atom feed
* word line disturbance
@ 2003-10-14 15:31 Magnus Mårtensson
  2003-10-14 15:46 ` Steven Scholz
                   ` (2 more replies)
  0 siblings, 3 replies; 6+ messages in thread
From: Magnus Mårtensson @ 2003-10-14 15:31 UTC (permalink / raw)
  To: linux-mtd

Hi.
I had a discussion with flash manufacturer Atmel last week regarding a phenomenon that we had seen. 
The phenomenon was called "word line disturbance" and it could occur if you tried to program only ones
to a location that already contained ones. The result could be that some bit on another address got tainted. Ex
writing 0xffff to address A could result in the content on address B changing from 0xffff to 0xfffe.

Anyway I thought of a software fix to this problem. Since it is unnecessary to write
ones to a place in flash where there already are only ones and since ones is the default bit state after an erase operation you
should simply skip that write. In our case this fix has also resulted in improvement in performance since we support firmware upgrades
over ftp and the firmware image is padded with 0xffff. The patch can be seen below (diff to 2.4.22 kernel).

Regards
/Magnus 

Index: cfi_cmdset_0002.c
===================================================================
RCS file: linux/drivers/mtd/chips/cfi_cmdset_0002.c,v
retrieving revision 1.1.1.4
diff -u -r1.1.1.4 cfi_cmdset_0002.c
--- cfi_cmdset_0002.c	17 Jun 2003 10:42:58 -0000	1.1.1.4
+++ cfi_cmdset_0002.c	14 Oct 2003 15:20:07 -0000
@@ -463,6 +463,12 @@
 	DECLARE_WAITQUEUE(wait, current);
 	int ret = 0;
 
+	/* Dont't write ones to a location that already contain ones. */	
+	if ((cfi_buswidth_is_1() && (datum == 0xff)) || 
+	    (cfi_buswidth_is_2() && (datum == 0xffff)) || 
+	    (cfi_buswidth_is_4() && (datum == 0xffffffff))) 
+		return ret;
+
  retry:
 	cfi_spin_lock(chip->mutex);
 
Index: amd_flash.c
===================================================================
RCS file: linux/drivers/mtd/chips/amd_flash.c,v
retrieving revision 1.1.1.5
diff -u -r1.1.1.5 amd_flash.c
--- amd_flash.c	17 Jun 2003 10:42:58 -0000	1.1.1.5
+++ amd_flash.c	14 Oct 2003 15:20:07 -0000
@@ -895,6 +895,12 @@
 	int ret = 0;
 	int times_left;
 
+	/* Dont't write ones to a location that already contain ones. */
+	if (((map->buswidth == 1) && (datum == 0xff)) ||
+	    ((map->buswidth == 2) && (datum == 0xffff)) ||
+	    ((map->buswidth == 4) && (datum == 0xffffffff))) 
+		return ret;
+
 retry:
 	spin_lock_bh(chip->mutex);

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

* Re: word line disturbance
  2003-10-14 15:31 word line disturbance Magnus Mårtensson
@ 2003-10-14 15:46 ` Steven Scholz
  2003-10-14 17:31 ` Thayne Harbaugh
  2003-10-15  7:20 ` "David Müller (ELSOFT AG)"
  2 siblings, 0 replies; 6+ messages in thread
From: Steven Scholz @ 2003-10-14 15:46 UTC (permalink / raw)
  To: Magnus Mårtensson; +Cc: linux-mtd

Magnus Mårtensson wrote:

> Hi.
> I had a discussion with flash manufacturer Atmel last week regarding a phenomenon that we had seen. 
> The phenomenon was called "word line disturbance" and it could occur if you tried to program only ones
> to a location that already contained ones. The result could be that some bit on another address got tainted. Ex
> writing 0xffff to address A could result in the content on address B changing from 0xffff to 0xfffe.
> ...

Which types of flash memory are effected by this interessting "feature"?

Steven

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

* Re: word line disturbance
  2003-10-14 15:31 word line disturbance Magnus Mårtensson
  2003-10-14 15:46 ` Steven Scholz
@ 2003-10-14 17:31 ` Thayne Harbaugh
  2003-10-14 21:39   ` Charles Manning
  2003-10-15  7:20 ` "David Müller (ELSOFT AG)"
  2 siblings, 1 reply; 6+ messages in thread
From: Thayne Harbaugh @ 2003-10-14 17:31 UTC (permalink / raw)
  To: Magnus Mårtensson; +Cc: linux-mtd

On Tue, 2003-10-14 at 09:31, Magnus Mårtensson wrote:
> Hi.
> I had a discussion with flash manufacturer Atmel last week regarding
>  a phenomenon that we had seen. 
> The phenomenon was called "word line disturbance" and it could occur
>  if you tried to program only ones
> to a location that already contained ones. The result could be that
>  some bit on another address got tainted. Ex
> writing 0xffff to address A could result in the content on address B
>  changing from 0xffff to 0xfffe.

I'll add this to the list of broken flash chips.  I'm doing some major
rework of jedec_probe.c and cfi_cmdset_0002.c so that chips with
different "features" can be handled in a sane way.  What are the
identifiers of these Atmel chips and are they CFI or are they probed
with jedec_probe?

> Anyway I thought of a software fix to this problem. Since it is
>  unnecessary to write
> ones to a place in flash where there already are only ones and since
>  ones is the default bit state after an erase operation you
> should simply skip that write.

Simple enough.

>  In our case this fix has also resulted
>  in improvement in performance since we support firmware upgrades
> over ftp and the firmware image is padded with 0xffff. The patch can
>  be seen below (diff to 2.4.22 kernel).

Sounds reasonable enough to not even be a special case.  The patch makes
the assumption that there are already ones written to the address.  A
more correct method would be to read the address and compare against the
datum - if they are equal then the function should return.

I'll see about rolling this into some of the changes I'm making.  Right
now I've seen more flash chips with problems than chips that function
correctly.

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

* Re: word line disturbance
  2003-10-14 17:31 ` Thayne Harbaugh
@ 2003-10-14 21:39   ` Charles Manning
  0 siblings, 0 replies; 6+ messages in thread
From: Charles Manning @ 2003-10-14 21:39 UTC (permalink / raw)
  To: tharbaugh, Magnus Mårtensson; +Cc: linux-mtd

I'm using the flash embedded in a AT91FR4042 (single chip ARM7-based micro + 
512kB flash + 256kB RAM).  The flash is essentially an AT49xV4096A.

This device has 4 sectors: 1x16kB "boot", 2x8kB "parameter" and 1x480kB 
"application". The datasheet/appnote warns that  reprogramming the boot can 
impact other sectors. Also, reprogramming the application area  can disturb 
the parameter areas.

At first I just blew this off as just a theoretical possibility, but found 
that these disturbances do occur on a regular basis (seen on 5 out of 5 proto 
devices) - particularly upgrading the application area corrupting the 
parameter areas.

-- Charles

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

* Re: word line disturbance
  2003-10-14 15:31 word line disturbance Magnus Mårtensson
  2003-10-14 15:46 ` Steven Scholz
  2003-10-14 17:31 ` Thayne Harbaugh
@ 2003-10-15  7:20 ` "David Müller (ELSOFT AG)"
  2003-10-16 19:34   ` Charles Manning
  2 siblings, 1 reply; 6+ messages in thread
From: "David Müller (ELSOFT AG)" @ 2003-10-15  7:20 UTC (permalink / raw)
  To: linux-mtd

Hello

Magnus Mårtensson wrote:
> Hi.
> I had a discussion with flash manufacturer Atmel last week regarding a phenomenon that we had seen. 
> The phenomenon was called "word line disturbance" and it could occur if you tried to program only ones
> to a location that already contained ones. The result could be that some bit on another address got tainted. Ex
> writing 0xffff to address A could result in the content on address B changing from 0xffff to 0xfffe.
> 

Does anybody know more about the technical background of this "it's not
a bug, it's a feature" problem? Or is it just a manager driven decision
to save some money at the wrong place?


Dave

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

* Re: word line disturbance
  2003-10-15  7:20 ` "David Müller (ELSOFT AG)"
@ 2003-10-16 19:34   ` Charles Manning
  0 siblings, 0 replies; 6+ messages in thread
From: Charles Manning @ 2003-10-16 19:34 UTC (permalink / raw)
  To: David Müller (ELSOFT AG), linux-mtd

On Wednesday 15 October 2003 20:20, David Müller (ELSOFT AG) wrote:
> Hello
>
> Magnus Mårtensson wrote:
> > Hi.
> > I had a discussion with flash manufacturer Atmel last week regarding a
> > phenomenon that we had seen. The phenomenon was called "word line
> > disturbance" and it could occur if you tried to program only ones to a
> > location that already contained ones. The result could be that some bit
> > on another address got tainted. Ex writing 0xffff to address A could
> > result in the content on address B changing from 0xffff to 0xfffe.
>
> Does anybody know more about the technical background of this "it's not
> a bug, it's a feature" problem? Or is it just a manager driven decision
> to save some money at the wrong place?
>

This is likely to be the result of a compromise to simplify the flash 
internals to save cost. Some of these compromises are acceptable for certain 
usage scenarios, but not others. Atmel do this sort of thing a lot.

Atmel design their DataFlash range of parts for data use and their other 
parts for code storage. If the problem showed up in their Dataflash parts I'd 
consider it a true bug.

-- Charles

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

end of thread, other threads:[~2003-10-16 19:30 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-10-14 15:31 word line disturbance Magnus Mårtensson
2003-10-14 15:46 ` Steven Scholz
2003-10-14 17:31 ` Thayne Harbaugh
2003-10-14 21:39   ` Charles Manning
2003-10-15  7:20 ` "David Müller (ELSOFT AG)"
2003-10-16 19:34   ` Charles Manning

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.