All of lore.kernel.org
 help / color / mirror / Atom feed
From: Juergen Borleis <jbe@pengutronix.de>
To: linux-mtd@lists.infradead.org
Cc: Richard Weinberger <richard@nod.at>,
	"jlauruhn@micron.com" <jlauruhn@micron.com>,
	Ricard Wanderlof <ricard.wanderlof@axis.com>,
	"tlinder@codeaurora.org" <tlinder@codeaurora.org>
Subject: Re: [RFC/PATCH 0/5 v2] mtd:ubi: Read disturb and Data retention handling
Date: Mon, 10 Nov 2014 14:42:51 +0100	[thread overview]
Message-ID: <201411101442.51441.jbe@pengutronix.de> (raw)
In-Reply-To: <alpine.DEB.2.02.1411101404180.23184@lnxricardw1.se.axis.com>

Hi Ricard,

On Monday 10 November 2014 14:13:27 Ricard Wanderlof wrote:
> [...]
> These are interesting figures. I must admit I've never seen anything quite
> so bad before.

That leads me to the question if I have done the test in a correct way.

> We use 128 MiB and 256 MiB SLC NAND chips in our products, and as part of
> the device qualification we run a test on a couple of samples where we
> repeatedly read the first four blocks of the flash in an endless loop, and
> measure the number of correctable and uncorrectable errors that occur.
>
> Normally, we can read millions of times before even getting a single bit
> flip. I've currently had a Macronix 128 MiB flash under test, which
> according to the data sheet requires 4-bit ECC, but after 68 million reads
> of the type just mentioned is still performing well with only single-bit
> errors in various places in the test area. (The fact that errors do start
> to occur after a while puts any suspicions of unexpected read caching to
> rest). Admittedly, this is all at room temperature, etc, and only a single
> sample, but it still is quite far from 200 000 reads. Other chips of the
> same sizes that we use which specify 1-bit ECC have a similar performance.
>
> The fact that 512 MiB is worse than 256 MiB is not too surprising, there
> could well be a technology jump between those sizes, with smaller bit
> cells for the larger flash.

I have no idea how the two boards were programmend I run these two tests on. 
Maybe the NAND programming was done in a wrong way which leads to this bad 
result.
On these boards the first 4 MiB area is the 'bootloader area', which must have 
a special layout to enable the ROM code to load the bootloader from it.

I have a bunch of boards here with 128/256/512 MiB NANDs where I can repeat the 
tests. Any recommendations how to setup the NAND before to do the tests again?

jbe

-- 
Pengutronix e.K.                              | Juergen Borleis             |
Industrial Linux Solutions                    | Phone: +49-5121-206917-5128 |
Peiner Str. 6-8, 31137 Hildesheim, Germany    | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686              | http://www.pengutronix.de/  |

  reply	other threads:[~2014-11-10 13:42 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <201411101307.03225.jbe@pengutronix.de>
2014-11-10 12:35 ` [RFC/PATCH 0/5 v2] mtd:ubi: Read disturb and Data retention handling Richard Weinberger
2014-11-10 13:12   ` Juergen Borleis
2014-11-11  9:23     ` Richard Weinberger
2014-11-10 13:13   ` Ricard Wanderlof
2014-11-10 13:42     ` Juergen Borleis [this message]
2014-11-10 13:52       ` Ricard Wanderlof
2014-10-26 13:49 Tanya Brokhman
2014-10-26 13:49 ` Tanya Brokhman
2014-10-26 20:39 ` Richard Weinberger
2014-10-26 20:39   ` Richard Weinberger
2014-10-27  8:41   ` Tanya Brokhman
2014-10-27  8:41     ` Tanya Brokhman
2014-10-27  8:56     ` Richard Weinberger
2014-10-27  8:56       ` Richard Weinberger
2014-10-29 11:03       ` Tanya Brokhman
2014-10-29 12:00         ` Richard Weinberger
2014-10-31 13:12           ` Tanya Brokhman
2014-10-31 15:34             ` Richard Weinberger
2014-10-31 15:39               ` Richard Weinberger
2014-10-31 22:55                 ` Jeff Lauruhn (jlauruhn)
2014-11-02 13:30                   ` Tanya Brokhman
2014-11-07  9:21                     ` Artem Bityutskiy
2014-11-07  9:21                       ` Artem Bityutskiy
2014-11-02 13:25                 ` Tanya Brokhman
2014-11-06  8:07                   ` Artem Bityutskiy
2014-11-06  8:07                     ` Artem Bityutskiy
2014-11-06 12:16                     ` Tanya Brokhman
2014-11-07  8:55                       ` Artem Bityutskiy
2014-11-07  8:58                       ` Artem Bityutskiy
2014-11-11 20:36                         ` Tanya Brokhman
2014-11-11 20:36                           ` Tanya Brokhman
2014-11-11 21:39                           ` Richard Weinberger
2014-11-11 21:39                             ` Richard Weinberger
2014-11-12 12:07                             ` Artem Bityutskiy
2014-11-12 12:07                               ` Artem Bityutskiy
2014-11-12 13:01                               ` Richard Weinberger
2014-11-12 13:01                                 ` Richard Weinberger
2014-11-12 13:32                                 ` Artem Bityutskiy
2014-11-12 13:32                                   ` Artem Bityutskiy
2014-11-12 15:37                                   ` Richard Weinberger
2014-11-12 15:37                                     ` Richard Weinberger
2014-11-12 11:55                           ` Artem Bityutskiy
2014-11-12 11:55                             ` Artem Bityutskiy
2014-11-13 12:13                             ` Tanya Brokhman
2014-11-13 12:13                               ` Tanya Brokhman
2014-11-13 13:36                               ` Artem Bityutskiy
2014-11-13 13:36                                 ` Artem Bityutskiy
2014-11-23  8:13                                 ` Tanya Brokhman
2014-11-23  8:13                                   ` Tanya Brokhman
2014-11-02 13:23               ` Tanya Brokhman
2014-11-02 13:54                 ` Richard Weinberger
2014-11-02 14:12                   ` Tanya Brokhman
2014-11-02 17:02                     ` Richard Weinberger
2014-11-02 17:18                       ` Tanya Brokhman

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=201411101442.51441.jbe@pengutronix.de \
    --to=jbe@pengutronix.de \
    --cc=jlauruhn@micron.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=ricard.wanderlof@axis.com \
    --cc=richard@nod.at \
    --cc=tlinder@codeaurora.org \
    /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 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.