Patchwork Test for multi-bit error correction

login
register
mail settings
Submitter Iwo Mergler
Date Aug. 30, 2012, 10:59 p.m.
Message ID <6871BC8982B258468985EE735D2C57524E269AFB60@ntcex01.corp.netcomm.com.au>
Download mbox | patch
Permalink /patch/180877/
State New
Headers show

Comments

Iwo Mergler - Aug. 30, 2012, 10:59 p.m.
This tests ECC biterror recovery on a single NAND page. Mostly intended
to test ECC hardware and low-level NAND driver.

There are two test modes:

    0 - artificially inserting bit errors until the ECC fails
        This is the default method and fairly quick. It should
        be independent of the quality of the FLASH.

    1 - re-writing the same pattern repeatedly until the ECC fails.
        This method relies on the physics of NAND FLASH to eventually
        generate '0' bits if '1' has been written sufficient times. Depending
        on the NAND, the first bit errors will appear after 1000 or
        more writes and then will usually snowball, reaching the limits
        of the ECC quickly.

The test stops after 10000 cycles, should your FLASH be exceptionally
good and not generate bit errors before that. Try a different page
offset in that case.

Please note that neither of these tests will significantly 'use up' any FLASH
endurance. Only a maximum of two erase operations will be performed.

Signed-off-by: Iwo Mergler <Iwo.Mergler@netcommwireless.com.au>
---
 drivers/mtd/tests/Makefile          |    1 +
 drivers/mtd/tests/mtd_nandbiterrs.c |  460 +++++++++++++++++++++++++++++++++++
 2 files changed, 461 insertions(+), 0 deletions(-)
 create mode 100644 drivers/mtd/tests/mtd_nandbiterrs.c
Artem Bityutskiy - Sept. 3, 2012, 3:25 p.m.
On Fri, 2012-08-31 at 08:59 +1000, Iwo Mergler wrote:
> This tests ECC biterror recovery on a single NAND page. Mostly intended
> to test ECC hardware and low-level NAND driver.
> 
> There are two test modes:
> 
>     0 - artificially inserting bit errors until the ECC fails
>         This is the default method and fairly quick. It should
>         be independent of the quality of the FLASH.
> 
>     1 - re-writing the same pattern repeatedly until the ECC fails.
>         This method relies on the physics of NAND FLASH to eventually
>         generate '0' bits if '1' has been written sufficient times. Depending
>         on the NAND, the first bit errors will appear after 1000 or
>         more writes and then will usually snowball, reaching the limits
>         of the ECC quickly.
> 
> The test stops after 10000 cycles, should your FLASH be exceptionally
> good and not generate bit errors before that. Try a different page
> offset in that case.
> 
> Please note that neither of these tests will significantly 'use up' any FLASH
> endurance. Only a maximum of two erase operations will be performed.
> 
> Signed-off-by: Iwo Mergler <Iwo.Mergler@netcommwireless.com.au>
> ---
>  drivers/mtd/tests/Makefile          |    1 +
>  drivers/mtd/tests/mtd_nandbiterrs.c |  460 +++++++++++++++++++++++++++++++++++
>  2 files changed, 461 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/mtd/tests/mtd_nandbiterrs.c
> 
> diff --git a/drivers/mtd/tests/Makefile b/drivers/mtd/tests/Makefile
> index b44dcab..bd0065c 100644
> --- a/drivers/mtd/tests/Makefile
> +++ b/drivers/mtd/tests/Makefile
> @@ -6,3 +6,4 @@ obj-$(CONFIG_MTD_TESTS) += mtd_stresstest.o
>  obj-$(CONFIG_MTD_TESTS) += mtd_subpagetest.o
>  obj-$(CONFIG_MTD_TESTS) += mtd_torturetest.o
>  obj-$(CONFIG_MTD_TESTS) += mtd_nandecctest.o
> +obj-$(CONFIG_MTD_TESTS) += mtd_nandbiterrs.o
> diff --git a/drivers/mtd/tests/mtd_nandbiterrs.c b/drivers/mtd/tests/mtd_nandbiterrs.c
> new file mode 100644
> index 0000000..94e908e
> --- /dev/null
> +++ b/drivers/mtd/tests/mtd_nandbiterrs.c
> @@ -0,0 +1,460 @@
> +/*
> + * (C)2012 NetCommWireless
> + * Iwo Mergler <Iwo.Mergler@netcommwireless.com.au>
> + *
> + * Test for multi-bit error recovery on a NAND page This mostly tests the
> + * ECC controller / driver.
> + *
> + * There are two test modes:
> + *
> + *	0 - artificially inserting bit errors until the ECC fails
> + *	    This is the default method and fairly quick. It should
> + *	    be independent of the quality of the FLASH.
> + *
> + *	1 - re-writing the same pattern repeatedly until the ECC fails.
> + *	    This method relies on the physics of NAND FLASH to eventually
> + *	    generate '0' bits if '1' has been written sufficient times.
> + *	    Depending on the NAND, the first bit errors will appear after
> + *	    1000 or more writes and then will usually snowball, reaching the
> + *	    limits of the ECC quickly.
> + *
> + *	    The test stops after 10000 cycles, should your FLASH be
> + *	    exceptionally good and not generate bit errors before that. Try
> + *	    a different page in that case.

So basically you test that ECC works, and you are trying to be
independent on the NAND HW and the ECC type. Right?

How about mtd_nandecc test? How is it different? Do we need 2 tests?
Why?

Akinobu - you recently sent a large patch-set for mtd_nandecctest, could
you please also comment on the above questions?

Basically, I would like to understand why we need 2 tests, and if we
really need 2, have the differences be documented, at least in the
commentaries.
Akinobu Mita - Sept. 4, 2012, 8:16 a.m.
2012/9/4 Artem Bityutskiy <dedekind1@gmail.com>:
> On Fri, 2012-08-31 at 08:59 +1000, Iwo Mergler wrote:
>> This tests ECC biterror recovery on a single NAND page. Mostly intended
>> to test ECC hardware and low-level NAND driver.
>>
>> There are two test modes:
>>
>>     0 - artificially inserting bit errors until the ECC fails
>>         This is the default method and fairly quick. It should
>>         be independent of the quality of the FLASH.
>>
>>     1 - re-writing the same pattern repeatedly until the ECC fails.
>>         This method relies on the physics of NAND FLASH to eventually
>>         generate '0' bits if '1' has been written sufficient times. Depending
>>         on the NAND, the first bit errors will appear after 1000 or
>>         more writes and then will usually snowball, reaching the limits
>>         of the ECC quickly.
>>
>> The test stops after 10000 cycles, should your FLASH be exceptionally
>> good and not generate bit errors before that. Try a different page
>> offset in that case.
>>
>> Please note that neither of these tests will significantly 'use up' any FLASH
>> endurance. Only a maximum of two erase operations will be performed.
>>
>> Signed-off-by: Iwo Mergler <Iwo.Mergler@netcommwireless.com.au>
>> ---
>>  drivers/mtd/tests/Makefile          |    1 +
>>  drivers/mtd/tests/mtd_nandbiterrs.c |  460 +++++++++++++++++++++++++++++++++++
>>  2 files changed, 461 insertions(+), 0 deletions(-)
>>  create mode 100644 drivers/mtd/tests/mtd_nandbiterrs.c
>>
>> diff --git a/drivers/mtd/tests/Makefile b/drivers/mtd/tests/Makefile
>> index b44dcab..bd0065c 100644
>> --- a/drivers/mtd/tests/Makefile
>> +++ b/drivers/mtd/tests/Makefile
>> @@ -6,3 +6,4 @@ obj-$(CONFIG_MTD_TESTS) += mtd_stresstest.o
>>  obj-$(CONFIG_MTD_TESTS) += mtd_subpagetest.o
>>  obj-$(CONFIG_MTD_TESTS) += mtd_torturetest.o
>>  obj-$(CONFIG_MTD_TESTS) += mtd_nandecctest.o
>> +obj-$(CONFIG_MTD_TESTS) += mtd_nandbiterrs.o
>> diff --git a/drivers/mtd/tests/mtd_nandbiterrs.c b/drivers/mtd/tests/mtd_nandbiterrs.c
>> new file mode 100644
>> index 0000000..94e908e
>> --- /dev/null
>> +++ b/drivers/mtd/tests/mtd_nandbiterrs.c
>> @@ -0,0 +1,460 @@
>> +/*
>> + * (C)2012 NetCommWireless
>> + * Iwo Mergler <Iwo.Mergler@netcommwireless.com.au>
>> + *
>> + * Test for multi-bit error recovery on a NAND page This mostly tests the
>> + * ECC controller / driver.
>> + *
>> + * There are two test modes:
>> + *
>> + *   0 - artificially inserting bit errors until the ECC fails
>> + *       This is the default method and fairly quick. It should
>> + *       be independent of the quality of the FLASH.
>> + *
>> + *   1 - re-writing the same pattern repeatedly until the ECC fails.
>> + *       This method relies on the physics of NAND FLASH to eventually
>> + *       generate '0' bits if '1' has been written sufficient times.
>> + *       Depending on the NAND, the first bit errors will appear after
>> + *       1000 or more writes and then will usually snowball, reaching the
>> + *       limits of the ECC quickly.
>> + *
>> + *       The test stops after 10000 cycles, should your FLASH be
>> + *       exceptionally good and not generate bit errors before that. Try
>> + *       a different page in that case.
>
> So basically you test that ECC works, and you are trying to be
> independent on the NAND HW and the ECC type. Right?
>
> How about mtd_nandecc test? How is it different? Do we need 2 tests?
> Why?
>
> Akinobu - you recently sent a large patch-set for mtd_nandecctest, could
> you please also comment on the above questions?

I think the test mtd_nandbiterrs is trying to do is useful and it is
different from mtd_nandecctest.  So they can coexist.

The mtd_nandecctest tests ECC function itself in nand_ecc.ko without
actual mtd devices.  Tests for nand_bch.ko may be added to
mtd_nandecctest in the future. But it should be done without actual
device as it has been.  It doesn't need to warry about losing important
data by human error.  BTW, my patch set for mtd_nandecctest attempts to
cover all type of corruption patterns.

On the other hand, mtd_nandbiterrs tests ECC functionality by poking
real mtd devices which may not be using ECC functions provided by
nand_ecc.ko.  It is more realistic and its test coverage spreads wider
range of mtd code than mtd_nandecctest can.

> Basically, I would like to understand why we need 2 tests, and if we
> really need 2, have the differences be documented, at least in the
> commentaries.

I'll add commentaries described above in nandecctest.c.
Iwo Mergler - Sept. 5, 2012, 8:28 a.m.
On Tue, 4 Sep 2012 01:25:18 +1000
Artem Bityutskiy <dedekind1@gmail.com> wrote:
>
> So basically you test that ECC works, and you are trying to be
> independent on the NAND HW and the ECC type. Right?
> 
> How about mtd_nandecc test? How is it different? Do we need 2 tests?
> Why?
> 

Akinobu already said it - mtd_nandecc tests the implementation for
software ECC, while mtd_nandbiterrs pokes holes into real NAND
FLASH pages until the ECC (software or hardware) falls over.

It's a test for the NAND driver, rather than the ECC implementation.
The pattern I'm using is not sufficient to guarantee that all possible
error constellations are caught. There is not enough endurance
in the FLASH or indeed time in the universe to do that. :-)

But it will tell you how many '1'->'0' bit errors it could introduce into
every subpage full of random data, before the whole page comes
back as uncorrectable.

In a nutshell, I got fed up by having to fix yet another vendor-supplied
NAND driver which claimed to support BCH8 hardware ECC but in
reality considered a single bit error as 'uncorrectable'.

So I submitted my test code in the hope that NAND driver authors
can use it to validate the ECC handling.


Best regards,

Iwo
Brian Norris - Sept. 5, 2012, 6:19 p.m.
On Thu, Aug 30, 2012 at 3:59 PM, Iwo Mergler
<Iwo.Mergler@netcommwireless.com> wrote:
> This tests ECC biterror recovery on a single NAND page. Mostly intended
> to test ECC hardware and low-level NAND driver.
>
> There are two test modes:

Why does this test even need to be in the kernel? Can't it be done
easily in userspace? I think it could even be a simple script that
utilizes flash_erase + nandwrite / nanddump with the -n (no ECC)
option. And anything that's lacking in nandwrite for this
functionality could easily be added there (for instance, support
erasure in nandwrite, rather than having to use flash_erase).

I would also note that this test doesn't explicitly test for bad
blocks, although it should fail when running the erase command.

> diff --git a/drivers/mtd/tests/mtd_nandbiterrs.c b/drivers/mtd/tests/mtd_nandbiterrs.c
> new file mode 100644
> index 0000000..94e908e
> --- /dev/null
> +++ b/drivers/mtd/tests/mtd_nandbiterrs.c
> @@ -0,0 +1,460 @@
...
> +static unsigned page_offset;
> +module_param(page_offset, uint, S_IRUGO);
> +MODULE_PARM_DESC(page_offset, "Page number relative to dev start");

Why use a page number? For erase, we'll be affecting many adjacent
pages, so this might be an unclear parameter to the user. Is there a
good reason not to use an entire eraseblock as the unit of test? Also,
is there a reason to use page number vs. eraseblock number vs. offset
as the input parameter?

> +static loff_t   offset;     /* Offset of the page we're using. */
> +static unsigned eraseblock; /* Eraseblock number for our page. */
> +
> +/* We assume that the ECC can correct up to a certain number
> + * of biterrors per subpage. */
> +static unsigned subsize;  /* Size of subpages */
> +static unsigned subcount; /* Number of subpages per page */
> +
> +static struct mtd_info *mtd;   /* MTD device */
> +
> +static uint8_t *wbuffer; /* One page write / compare buffer */
> +static uint8_t *rbuffer; /* One page read buffer */

Why are all of these globals? It seems like the read_page(),
write_page(), and rewrite_page() functions would be more sensible (and
safely extendible) if they had an extra parameter for the address. And
do you really need to represent the same value (offset) in three
different ways (offset, page offset, eraseblock)? In fact,

> +static int erase_block(void)

This isn't a very intuitive function prototype; I would normally
expect an address or block number parameter. Ditto for the following.
But this is just part of the argument of whether everything should be
provided as global variables...

> +/* Writes wbuffer to page */
> +static int write_page(int log)
...
> +/* Re-writes the data area while leaving the OOB alone. */
> +static int rewrite_page(int log)
...
> +/* Reads page into rbuffer. Returns number of corrected bit errors (>=0)
> + * or error (<0) */
> +static int read_page(int log)
...
> +/* Verifies rbuffer against random sequence */
> +static int verify_page(int log)

Brian
Iwo Mergler - Sept. 6, 2012, 3:37 a.m.
Hi Brian,

thanks for commenting.

Please be aware that this test aims at MTD driver developers,
so I expect the 'users' to know all about their flash geometries
and not be surprised by whole block erases and such. :-)

More answers below.


Best regards,

Iwo

On Thu, 6 Sep 2012 04:19:57 +1000
Brian Norris <computersforpeace@gmail.com> wrote:
> On Thu, Aug 30, 2012 at 3:59 PM, Iwo Mergler
> <Iwo.Mergler@netcommwireless.com> wrote:
> > This tests ECC biterror recovery on a single NAND page. Mostly intended
> > to test ECC hardware and low-level NAND driver.
> >
> > There are two test modes:
> 
> Why does this test even need to be in the kernel? Can't it be done
> easily in userspace? I think it could even be a simple script that
> utilizes flash_erase + nandwrite / nanddump with the -n (no ECC)
> option. And anything that's lacking in nandwrite for this
> functionality could easily be added there (for instance, support
> erasure in nandwrite, rather than having to use flash_erase).

You are right. The same can be said about most of the other
tests too.

Personally, I appreciate these tests being where they are
because they are most useful to driver developers and as
such are more accessible in the kernel than in userspace.

On new embedded systems, we often have to develop MTD drivers
before we have a rootfs, since the rootfs is supposed to live in the MTD.
MTD is often the first hardware driver to get ported / written for a new
system.

With the current test arrangement I can, with minimal edits,
run any test from within the MTD driver under development.

> I would also note that this test doesn't explicitly test for bad
> blocks, although it should fail when running the erase command.

Fair enough. Usually, by the time I need this test, I know the
locations of all bad block by heart. :-)

> > +static unsigned page_offset;
> > +module_param(page_offset, uint, S_IRUGO);
> > +MODULE_PARM_DESC(page_offset, "Page number relative to dev start");
> 
> Why use a page number? For erase, we'll be affecting many adjacent
> pages, so this might be an unclear parameter to the user. Is there a
> good reason not to use an entire eraseblock as the unit of test? Also,
> is there a reason to use page number vs. eraseblock number vs. offset
> as the input parameter?

Mostly because loff_t isn't supported as a parameter type, so I can't
specify offsets beyond 4G.

Erase block number would work as well. There isn't much to be learned
from applying the test to all pages of a block, but in rare circumstances
I'd like to be able to control which page of the block to test anyway.

It would of course be possible to specify the offset  as separate
erase block numbers and page numbers. I don't have a strong
preference either way.

> 
> > +static loff_t   offset;     /* Offset of the page we're using. */
> > +static unsigned eraseblock; /* Eraseblock number for our page. */
> > +
> > +/* We assume that the ECC can correct up to a certain number
> > + * of biterrors per subpage. */
> > +static unsigned subsize;  /* Size of subpages */
> > +static unsigned subcount; /* Number of subpages per page */
> > +
> > +static struct mtd_info *mtd;   /* MTD device */
> > +
> > +static uint8_t *wbuffer; /* One page write / compare buffer */
> > +static uint8_t *rbuffer; /* One page read buffer */
> 
> Why are all of these globals? It seems like the read_page(),
> write_page(), and rewrite_page() functions would be more sensible (and
> safely extendible) if they had an extra parameter for the address. And
> do you really need to represent the same value (offset) in three
> different ways (offset, page offset, eraseblock)? In fact,
> 

I had to force myself ;-). My excuse is that I copied the style of
the other tests, because of a probably misguided sense of consistency.
Brian Norris - Sept. 17, 2012, 6:42 p.m.
Hi Iwo,

On Wed, Sep 5, 2012 at 8:37 PM, Iwo Mergler
<Iwo.Mergler@netcommwireless.com> wrote:
> Please be aware that this test aims at MTD driver developers,
> so I expect the 'users' to know all about their flash geometries
> and not be surprised by whole block erases and such. :-)

Duly noted. I agree, but I also think we can do our best to make
things as easy to understand as possible.

> On Thu, 6 Sep 2012 04:19:57 +1000
> Brian Norris <computersforpeace@gmail.com> wrote:
>> On Thu, Aug 30, 2012 at 3:59 PM, Iwo Mergler
>> <Iwo.Mergler@netcommwireless.com> wrote:
>> > This tests ECC biterror recovery on a single NAND page. Mostly intended
>> > to test ECC hardware and low-level NAND driver.
>> >
>> > There are two test modes:
>>
>> Why does this test even need to be in the kernel? Can't it be done
>> easily in userspace? I think it could even be a simple script that
>> utilizes flash_erase + nandwrite / nanddump with the -n (no ECC)
>> option. And anything that's lacking in nandwrite for this
>> functionality could easily be added there (for instance, support
>> erasure in nandwrite, rather than having to use flash_erase).
>
> You are right. The same can be said about most of the other
> tests too.

Yeah, I suppose so. I don't know about all the tests, but one
exception I was thinking of: the oobtest doesn't just use user-visible
interfaces to test sanity, it tries to use the MTD interfaces
(mtd_read_oob / mtd_write_oob) to stress the driver in ways that might
not be exposed to the user normally.

> Personally, I appreciate these tests being where they are
> because they are most useful to driver developers and as
> such are more accessible in the kernel than in userspace.
>
> On new embedded systems, we often have to develop MTD drivers
> before we have a rootfs, since the rootfs is supposed to live in the MTD.
> MTD is often the first hardware driver to get ported / written for a new
> system.
>
> With the current test arrangement I can, with minimal edits,
> run any test from within the MTD driver under development.

Fair enough.

>> > +static unsigned page_offset;
>> > +module_param(page_offset, uint, S_IRUGO);
>> > +MODULE_PARM_DESC(page_offset, "Page number relative to dev start");
>>
>> Why use a page number? For erase, we'll be affecting many adjacent
>> pages, so this might be an unclear parameter to the user. Is there a
>> good reason not to use an entire eraseblock as the unit of test? Also,
>> is there a reason to use page number vs. eraseblock number vs. offset
>> as the input parameter?
>
> Mostly because loff_t isn't supported as a parameter type, so I can't
> specify offsets beyond 4G.
>
> Erase block number would work as well. There isn't much to be learned
> from applying the test to all pages of a block, but in rare circumstances
> I'd like to be able to control which page of the block to test anyway.
>
> It would of course be possible to specify the offset  as separate
> erase block numbers and page numbers. I don't have a strong
> preference either way.

I don't have a strong preference either. In the absence of a portable
module-parameter for "loff_t" address, then a page_offset or eb_offset
param is fine with me.

>> > +static loff_t   offset;     /* Offset of the page we're using. */
>> > +static unsigned eraseblock; /* Eraseblock number for our page. */
>> > +
>> > +/* We assume that the ECC can correct up to a certain number
>> > + * of biterrors per subpage. */
>> > +static unsigned subsize;  /* Size of subpages */
>> > +static unsigned subcount; /* Number of subpages per page */
>> > +
>> > +static struct mtd_info *mtd;   /* MTD device */
>> > +
>> > +static uint8_t *wbuffer; /* One page write / compare buffer */
>> > +static uint8_t *rbuffer; /* One page read buffer */
>>
>> Why are all of these globals? It seems like the read_page(),
>> write_page(), and rewrite_page() functions would be more sensible (and
>> safely extendible) if they had an extra parameter for the address. And
>> do you really need to represent the same value (offset) in three
>> different ways (offset, page offset, eraseblock)? In fact,
>
> I had to force myself ;-). My excuse is that I copied the style of
> the other tests, because of a probably misguided sense of consistency.

Yeah, I don't know if I can speak for anyone else, but I would
recommend focusing on writing clean, maintainable code and leave
consistency with other tests' style as a secondary objective. I think
it's useful for read_page(), etc., to have at least one parameter (not
global variable) for the offset (or similar; e.g., page number). The
other globals are up to you, I suppose. When a value really is a
global that won't change, it's fine to be global (e.g., the mtd_info
struct, subpage info).

Thanks for your efforts and for addressing my comments. For a v2, I
think there are some things to address in code (bad block checking,
function parameters vs. global decisions) while other issues just need
a little bit better explanation (e.g., usefulness of mtd_nandbiterrs
vs mtd_nandecctest, explaining how this can be used to generically
test real bit error correction on real MTDs).

Regards,
Brian
Artem Bityutskiy - Sept. 23, 2012, 1:41 p.m.
On Thu, 2012-09-06 at 13:37 +1000, Iwo Mergler wrote:
> I had to force myself ;-). My excuse is that I copied the style of
> the other tests, because of a probably misguided sense of consistency.

Oh, please, next time feel free better do things properly, then fix
other code for consistency.
>
Artem Bityutskiy - Sept. 23, 2012, 1:42 p.m.
On Fri, 2012-08-31 at 08:59 +1000, Iwo Mergler wrote:
> This tests ECC biterror recovery on a single NAND page. Mostly intended
> to test ECC hardware and low-level NAND driver.

Pushed to l2-mtd.git, thanks!

Patch

diff --git a/drivers/mtd/tests/Makefile b/drivers/mtd/tests/Makefile
index b44dcab..bd0065c 100644
--- a/drivers/mtd/tests/Makefile
+++ b/drivers/mtd/tests/Makefile
@@ -6,3 +6,4 @@  obj-$(CONFIG_MTD_TESTS) += mtd_stresstest.o
 obj-$(CONFIG_MTD_TESTS) += mtd_subpagetest.o
 obj-$(CONFIG_MTD_TESTS) += mtd_torturetest.o
 obj-$(CONFIG_MTD_TESTS) += mtd_nandecctest.o
+obj-$(CONFIG_MTD_TESTS) += mtd_nandbiterrs.o
diff --git a/drivers/mtd/tests/mtd_nandbiterrs.c b/drivers/mtd/tests/mtd_nandbiterrs.c
new file mode 100644
index 0000000..94e908e
--- /dev/null
+++ b/drivers/mtd/tests/mtd_nandbiterrs.c
@@ -0,0 +1,460 @@ 
+/*
+ * (C)2012 NetCommWireless
+ * Iwo Mergler <Iwo.Mergler@netcommwireless.com.au>
+ *
+ * Test for multi-bit error recovery on a NAND page This mostly tests the
+ * ECC controller / driver.
+ *
+ * There are two test modes:
+ *
+ *	0 - artificially inserting bit errors until the ECC fails
+ *	    This is the default method and fairly quick. It should
+ *	    be independent of the quality of the FLASH.
+ *
+ *	1 - re-writing the same pattern repeatedly until the ECC fails.
+ *	    This method relies on the physics of NAND FLASH to eventually
+ *	    generate '0' bits if '1' has been written sufficient times.
+ *	    Depending on the NAND, the first bit errors will appear after
+ *	    1000 or more writes and then will usually snowball, reaching the
+ *	    limits of the ECC quickly.
+ *
+ *	    The test stops after 10000 cycles, should your FLASH be
+ *	    exceptionally good and not generate bit errors before that. Try
+ *	    a different page in that case.
+ *
+ * Please note that neither of these tests will significantly 'use up' any
+ * FLASH endurance. Only a maximum of two erase operations will be performed.
+ *
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program; see the file COPYING. If not, write to the Free Software
+ * Foundation, 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/moduleparam.h>
+#include <linux/mtd/mtd.h>
+#include <linux/err.h>
+#include <linux/mtd/nand.h>
+#include <linux/slab.h>
+
+#define msg(FMT, VA...) pr_info("mtd_nandbiterrs: "FMT, ##VA)
+
+static int dev;
+module_param(dev, int, S_IRUGO);
+MODULE_PARM_DESC(dev, "MTD device number to use");
+
+static unsigned page_offset;
+module_param(page_offset, uint, S_IRUGO);
+MODULE_PARM_DESC(page_offset, "Page number relative to dev start");
+
+static unsigned seed;
+module_param(seed, uint, S_IRUGO);
+MODULE_PARM_DESC(seed, "Random seed");
+
+static int mode;
+module_param(mode, int, S_IRUGO);
+MODULE_PARM_DESC(mode, "0=incremental errors, 1=overwrite test");
+
+static unsigned max_overwrite = 10000;
+
+static loff_t   offset;     /* Offset of the page we're using. */
+static unsigned eraseblock; /* Eraseblock number for our page. */
+
+/* We assume that the ECC can correct up to a certain number
+ * of biterrors per subpage. */
+static unsigned subsize;  /* Size of subpages */
+static unsigned subcount; /* Number of subpages per page */
+
+static struct mtd_info *mtd;   /* MTD device */
+
+static uint8_t *wbuffer; /* One page write / compare buffer */
+static uint8_t *rbuffer; /* One page read buffer */
+
+/* 'random' bytes from known offsets */
+static uint8_t hash(unsigned offset)
+{
+	unsigned v = offset;
+	unsigned char c;
+	v ^= 0x7f7edfd3;
+	v = v ^ (v >> 3);
+	v = v ^ (v >> 5);
+	v = v ^ (v >> 13);
+	c = v & 0xFF;
+	/* Reverse bits of result. */
+	c = (c & 0x0F) << 4 | (c & 0xF0) >> 4;
+	c = (c & 0x33) << 2 | (c & 0xCC) >> 2;
+	c = (c & 0x55) << 1 | (c & 0xAA) >> 1;
+	return c;
+}
+
+static int erase_block(void)
+{
+	int err;
+	struct erase_info ei;
+	loff_t addr = eraseblock * mtd->erasesize;
+
+	msg("erase_block\n");
+
+	memset(&ei, 0, sizeof(struct erase_info));
+	ei.mtd  = mtd;
+	ei.addr = addr;
+	ei.len  = mtd->erasesize;
+
+	err = mtd_erase(mtd, &ei);
+	if (err || ei.state == MTD_ERASE_FAILED) {
+		msg("error %d while erasing\n", err);
+		if (!err)
+			err = -EIO;
+		return err;
+	}
+
+	return 0;
+}
+
+/* Writes wbuffer to page */
+static int write_page(int log)
+{
+	int err = 0;
+	size_t written;
+
+	if (log)
+		msg("write_page\n");
+
+	err = mtd_write(mtd, offset, mtd->writesize, &written, wbuffer);
+	if (err || written != mtd->writesize) {
+		msg("error: write failed at %#llx\n", (long long)offset);
+		if (!err)
+			err = -EIO;
+	}
+
+	return err;
+}
+
+/* Re-writes the data area while leaving the OOB alone. */
+static int rewrite_page(int log)
+{
+	int err = 0;
+	struct mtd_oob_ops ops;
+
+	if (log)
+		msg("rewrite page\n");
+
+	ops.mode      = MTD_OPS_RAW; /* No ECC */
+	ops.len       = mtd->writesize;
+	ops.retlen    = 0;
+	ops.ooblen    = 0;
+	ops.oobretlen = 0;
+	ops.ooboffs   = 0;
+	ops.datbuf    = wbuffer;
+	ops.oobbuf    = NULL;
+
+	err = mtd_write_oob(mtd, offset, &ops);
+	if (err || ops.retlen != mtd->writesize) {
+		msg("error: write_oob failed (%d)\n", err);
+		if (!err)
+			err = -EIO;
+	}
+
+	return err;
+}
+
+/* Reads page into rbuffer. Returns number of corrected bit errors (>=0)
+ * or error (<0) */
+static int read_page(int log)
+{
+	int err = 0;
+	size_t read;
+	struct mtd_ecc_stats oldstats;
+
+	if (log)
+		msg("read_page\n");
+
+	/* Saving last mtd stats */
+	memcpy(&oldstats, &mtd->ecc_stats, sizeof(oldstats));
+
+	err = mtd_read(mtd, offset, mtd->writesize, &read, rbuffer);
+	if (err == -EUCLEAN)
+		err = mtd->ecc_stats.corrected - oldstats.corrected;
+
+	if (err < 0 || read != mtd->writesize) {
+		msg("error: read failed at %#llx\n", (long long)offset);
+		if (err >= 0)
+			err = -EIO;
+	}
+
+	return err;
+}
+
+/* Verifies rbuffer against random sequence */
+static int verify_page(int log)
+{
+	unsigned i, errs = 0;
+
+	if (log)
+		msg("verify_page\n");
+
+	for (i = 0; i < mtd->writesize; i++) {
+		if (rbuffer[i] != hash(i+seed)) {
+			msg("Error: page offset %u, expected %02x, got %02x\n",
+				i, hash(i+seed), rbuffer[i]);
+			errs++;
+		}
+	}
+
+	if (errs)
+		return -EIO;
+	else
+		return 0;
+}
+
+#define CBIT(v, n) ((v) & (1 << (n)))
+#define BCLR(v, n) ((v) = (v) & ~(1 << (n)))
+
+/* Finds the first '1' bit in wbuffer starting at offset 'byte'
+ * and sets it to '0'. */
+static int insert_biterror(unsigned byte)
+{
+	int bit;
+
+	while (byte < mtd->writesize) {
+		for (bit = 7; bit >= 0; bit--) {
+			if (CBIT(wbuffer[byte], bit)) {
+				BCLR(wbuffer[byte], bit);
+				msg("Inserted biterror @ %u/%u\n", byte, bit);
+				return 0;
+			}
+		}
+		byte++;
+	}
+	msg("biterror: Failed to find a '1' bit\n");
+	return -EIO;
+}
+
+/* Writes 'random' data to page and then introduces deliberate bit
+ * errors into the page, while verifying each step. */
+static int incremental_errors_test(void)
+{
+	int err = 0;
+	unsigned i;
+	unsigned errs_per_subpage = 0;
+
+	msg("incremental biterrors test\n");
+
+	for (i = 0; i < mtd->writesize; i++)
+		wbuffer[i] = hash(i+seed);
+
+	err = write_page(1);
+	if (err)
+		goto exit;
+
+	while (1) {
+
+		err = rewrite_page(1);
+		if (err)
+			goto exit;
+
+		err = read_page(1);
+		if (err > 0)
+			msg("Read reported %d corrected bit errors\n", err);
+		if (err < 0) {
+			msg("After %d biterrors per subpage, read reported error %d\n",
+				errs_per_subpage, err);
+			err = 0;
+			goto exit;
+		}
+
+		err = verify_page(1);
+		if (err) {
+			msg("ECC failure, read data is incorrect despite read success\n");
+			goto exit;
+		}
+
+		msg("Successfully corrected %d bit errors per subpage\n",
+			errs_per_subpage);
+
+		for (i = 0; i < subcount; i++) {
+			err = insert_biterror(i * subsize);
+			if (err < 0)
+				goto exit;
+		}
+		errs_per_subpage++;
+	}
+
+exit:
+	return err;
+}
+
+
+/* Writes 'random' data to page and then re-writes that same data repeatedly.
+   This eventually develops bit errors (bits written as '1' will slowly become
+   '0'), which are corrected as far as the ECC is capable of. */
+static int overwrite_test(void)
+{
+	int err = 0;
+	unsigned i;
+	unsigned max_corrected = 0;
+	unsigned opno = 0;
+	/* We don't expect more than this many correctable bit errors per
+	 * page. */
+	#define MAXBITS 512
+	static unsigned bitstats[MAXBITS]; /* bit error histogram. */
+
+	memset(bitstats, 0, sizeof(bitstats));
+
+	msg("overwrite biterrors test\n");
+
+	for (i = 0; i < mtd->writesize; i++)
+		wbuffer[i] = hash(i+seed);
+
+	err = write_page(1);
+	if (err)
+		goto exit;
+
+	while (opno < max_overwrite) {
+
+		err = rewrite_page(0);
+		if (err)
+			break;
+
+		err = read_page(0);
+		if (err >= 0) {
+			if (err >= MAXBITS) {
+				msg("Implausible number of bit errors corrected\n");
+				err = -EIO;
+				break;
+			}
+			bitstats[err]++;
+			if (err > max_corrected) {
+				max_corrected = err;
+				msg("Read reported %d corrected bit errors\n",
+					err);
+			}
+		} else { /* err < 0 */
+			msg("Read reported error %d\n", err);
+			err = 0;
+			break;
+		}
+
+		err = verify_page(0);
+		if (err) {
+			bitstats[max_corrected] = opno;
+			msg("ECC failure, read data is incorrect despite read success\n");
+			break;
+		}
+
+		opno++;
+	}
+
+	/* At this point bitstats[0] contains the number of ops with no bit
+	 * errors, bitstats[1] the number of ops with 1 bit error, etc. */
+	msg("Bit error histogram (%d operations total):\n", opno);
+	for (i = 0; i < max_corrected; i++)
+		msg("Page reads with %3d corrected bit errors: %d\n",
+			i, bitstats[i]);
+
+exit:
+	return err;
+}
+
+static int __init mtd_nandbiterrs_init(void)
+{
+	int err = 0;
+
+	msg("\n");
+	msg("==================================================\n");
+	msg("MTD device: %d\n", dev);
+
+	mtd = get_mtd_device(NULL, dev);
+	if (IS_ERR(mtd)) {
+		err = PTR_ERR(mtd);
+		msg("error: cannot get MTD device\n");
+		goto exit_mtddev;
+	}
+
+	if (mtd->type != MTD_NANDFLASH) {
+		msg("this test requires NAND flash\n");
+		err = -ENODEV;
+		goto exit_nand;
+	}
+
+	msg("MTD device size %llu, eraseblock=%u, page=%u, oob=%u\n",
+		(unsigned long long)mtd->size, mtd->erasesize,
+		mtd->writesize, mtd->oobsize);
+
+	subsize  = mtd->writesize >> mtd->subpage_sft;
+	subcount = mtd->writesize / subsize;
+
+	msg("Device uses %d subpages of %d bytes\n", subcount, subsize);
+
+	offset     = page_offset * mtd->writesize;
+	eraseblock = mtd_div_by_eb(offset, mtd);
+
+	msg("Using page=%u, offset=%llu, eraseblock=%u\n",
+		page_offset, offset, eraseblock);
+
+	wbuffer = kmalloc(mtd->writesize, GFP_KERNEL);
+	if (!wbuffer) {
+		err = -ENOMEM;
+		goto exit_wbuffer;
+	}
+
+	rbuffer = kmalloc(mtd->writesize, GFP_KERNEL);
+	if (!rbuffer) {
+		err = -ENOMEM;
+		goto exit_rbuffer;
+	}
+
+	err = erase_block();
+	if (err)
+		goto exit_error;
+
+	if (mode == 0)
+		err = incremental_errors_test();
+	else
+		err = overwrite_test();
+
+	if (err)
+		goto exit_error;
+
+	/* We leave the block un-erased in case of test failure. */
+	err = erase_block();
+	if (err)
+		goto exit_error;
+
+	err = -EIO;
+	msg("finished successfully.\n");
+	msg("==================================================\n");
+
+exit_error:
+	kfree(rbuffer);
+exit_rbuffer:
+	kfree(wbuffer);
+exit_wbuffer:
+	/* Nothing */
+exit_nand:
+	put_mtd_device(mtd);
+exit_mtddev:
+	return err;
+}
+
+static void __exit mtd_nandbiterrs_exit(void)
+{
+	return;
+}
+
+module_init(mtd_nandbiterrs_init);
+module_exit(mtd_nandbiterrs_exit);
+
+MODULE_DESCRIPTION("NAND bit error recovery test");
+MODULE_AUTHOR("Iwo Mergler");
+MODULE_LICENSE("GPL");