[FRC] [PATCH] MTD: nand_base.c: Enable support for Samsung E-die SLC NAND

[FRC] [PATCH] MTD: nand_base.c: Enable support for Samsung E-die SLC NAND

[David Jander]

Samsung E-die SLC NAND doesn't support partial writes anymore and there
seems to be no other way of detecting this than looking at bits 0 & 1
of the 5th ID byte. Those bits were "reserved" and 00 for all older
chips. On E-die chips, "01" seems to indicate 21nm feature size. This
patch assumes that all later revisions (if they will ever come) will have
this characteristic as well and disables sub-page writes in this case.

Signed-off-by: David Jander <david@protonic.nl>
---
 drivers/mtd/nand/nand_base.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 41167e9..e68e0c7 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -3468,6 +3468,16 @@ static void nand_decode_ext_id(struct mtd_info *mtd, struct nand_chip *chip,
 			mtd->oobsize = 32 * mtd->writesize >> 9;
 		}
 
+		/*
+		 * Samsung E-die SLC NAND doesn't support partial writes
+		 * anymore. The only way to distinguish this die-revision
+		 * is by checking bits 0 and 1 of id_data[4], which seem
+		 * to indicate feature size (previous => 00, 21nm => 01).
+		 */
+		if (id_data[0] == NAND_MFR_SAMSUNG && nand_is_slc(chip) &&
+				(id_data[4] & 0x03) /* 21nm or newer */) {
+			chip->options |= NAND_NO_SUBPAGE_WRITE;
+		}
 	}
 }
 
-- 
1.9.1

Re: [FRC] [PATCH] MTD: nand_base.c: Enable support for Samsung E-die SLC NAND

[Ted Juan]

Hi All,
   I recently do the power cut test with this Samsung NAND flash
K9F1G08U0E with TI AM3352 chip.
I have set the NAND_NO_SUBPAGE_WRITE parameter and checked all the
flash timing that are all correct.
But it still happened uncorrectable error that bit-flip more than 8
bits no matter erase page or not.
The below is the wrong data with erase page that bit-flip more than 8 bits .

Does anyone have the same experience?

PS. The Samsung D-die SLC NAND is test OK in the same environment. And
the TI driver code is base on the latest l2-mtd git tree.

regards,
Ted


[    7.129791] [0x0000] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
[    7.136138] [0x0010] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
[    7.142486] [0x0020] 0xfbfdffff 0xffffffff 0xffffffff 0xffffffff
[    7.148864] [0x0030] 0xffbfffff 0xffff7fff 0xffffffff 0xffffffff
[    7.155212] [0x0040] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
[    7.161590] [0x0050] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
[    7.167938] [0x0060] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
[    7.174316] [0x0070] 0xf7ffffff 0xfffffcff 0xffffffff 0xffffffff
[    7.180664] [0x0080] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
[    7.187042] [0x0090] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
[    7.193389] [0x00a0] 0xffbfffff 0xffffffff 0xffffffff 0xffffffff
[    7.199737] [0x00b0] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
[    7.206115] [0x00c0] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
[    7.212463] [0x00d0] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
[    7.218841] [0x00e0] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
[    7.225189] [0x00f0] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
[    7.231567] [0x0100] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
[    7.237915] [0x0110] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
[    7.244293] [0x0120] 0xffdfffff 0xffffffff 0xffffffff 0xffffffff
[    7.250640] [0x0130] 0xffffffff 0xffff7fff 0xffffffff 0xffffffff
[    7.256988] [0x0140] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
[    7.263366] [0x0150] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
[    7.269714] [0x0160] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
[    7.276092] [0x0170] 0xffffffff 0xffffffdf 0xffffffff 0xffffffff
[    7.282440] [0x0180] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
[    7.288818] [0x0190] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
[    7.295166] [0x01a0] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
[    7.301544] [0x01b0] 0xffffffff 0xffffdfff 0xffffffff 0xffffffff
[    7.307891] [0x01c0] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
[    7.314270] [0x01d0] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
[    7.320617] [0x01e0] 0xbfffffff 0xffffffff 0xffffffff 0xffffffff
[    7.326995] [0x01f0] 0xffffffff 0xfffff7af 0xffffffff 0xffffffff

2014-06-20 18:12 GMT+08:00 David Jander <david@protonic.nl>:
> Samsung E-die SLC NAND doesn't support partial writes anymore and there
> seems to be no other way of detecting this than looking at bits 0 & 1
> of the 5th ID byte. Those bits were "reserved" and 00 for all older
> chips. On E-die chips, "01" seems to indicate 21nm feature size. This
> patch assumes that all later revisions (if they will ever come) will have
> this characteristic as well and disables sub-page writes in this case.
>
> Signed-off-by: David Jander <david@protonic.nl>
> ---
>  drivers/mtd/nand/nand_base.c | 10 ++++++++++
>  1 file changed, 10 insertions(+)
>
> diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
> index 41167e9..e68e0c7 100644
> --- a/drivers/mtd/nand/nand_base.c
> +++ b/drivers/mtd/nand/nand_base.c
> @@ -3468,6 +3468,16 @@ static void nand_decode_ext_id(struct mtd_info *mtd, struct nand_chip *chip,
>                         mtd->oobsize = 32 * mtd->writesize >> 9;
>                 }
>
> +               /*
> +                * Samsung E-die SLC NAND doesn't support partial writes
> +                * anymore. The only way to distinguish this die-revision
> +                * is by checking bits 0 and 1 of id_data[4], which seem
> +                * to indicate feature size (previous => 00, 21nm => 01).
> +                */
> +               if (id_data[0] == NAND_MFR_SAMSUNG && nand_is_slc(chip) &&
> +                               (id_data[4] & 0x03) /* 21nm or newer */) {
> +                       chip->options |= NAND_NO_SUBPAGE_WRITE;
> +               }
>         }
>  }
>
> --
> 1.9.1
>
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

RE: [FRC] [PATCH] MTD: nand_base.c: Enable support for Samsung E-die SLC NAND

[Gupta, Pekon]

Hi Ted,

>Hi All,
>   I recently do the power cut test with this Samsung NAND flash
>K9F1G08U0E with TI AM3352 chip.
>I have set the NAND_NO_SUBPAGE_WRITE parameter and checked all the
>flash timing that are all correct.
>But it still happened uncorrectable error that bit-flip more than 8
>bits no matter erase page or not.
>The below is the wrong data with erase page that bit-flip more than 8 bits .
>
>Does anyone have the same experience?
>
>PS. The Samsung D-die SLC NAND is test OK in the same environment. And
>the TI driver code is base on the latest l2-mtd git tree.
>
>regards,
>Ted
>
>
>[    7.129791] [0x0000] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>[    7.136138] [0x0010] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>[    7.142486] [0x0020] 0xfbfdffff 0xffffffff 0xffffffff 0xffffffff
>[    7.148864] [0x0030] 0xffbfffff 0xffff7fff 0xffffffff 0xffffffff
>[    7.155212] [0x0040] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>[    7.161590] [0x0050] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>[    7.167938] [0x0060] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>[    7.174316] [0x0070] 0xf7ffffff 0xfffffcff 0xffffffff 0xffffffff
>[    7.180664] [0x0080] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>[    7.187042] [0x0090] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>[    7.193389] [0x00a0] 0xffbfffff 0xffffffff 0xffffffff 0xffffffff
>[    7.199737] [0x00b0] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>[    7.206115] [0x00c0] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>[    7.212463] [0x00d0] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>[    7.218841] [0x00e0] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>[    7.225189] [0x00f0] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>[    7.231567] [0x0100] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>[    7.237915] [0x0110] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>[    7.244293] [0x0120] 0xffdfffff 0xffffffff 0xffffffff 0xffffffff
>[    7.250640] [0x0130] 0xffffffff 0xffff7fff 0xffffffff 0xffffffff
>[    7.256988] [0x0140] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>[    7.263366] [0x0150] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>[    7.269714] [0x0160] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>[    7.276092] [0x0170] 0xffffffff 0xffffffdf 0xffffffff 0xffffffff
>[    7.282440] [0x0180] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>[    7.288818] [0x0190] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>[    7.295166] [0x01a0] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>[    7.301544] [0x01b0] 0xffffffff 0xffffdfff 0xffffffff 0xffffffff
>[    7.307891] [0x01c0] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>[    7.314270] [0x01d0] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>[    7.320617] [0x01e0] 0xbfffffff 0xffffffff 0xffffffff 0xffffffff
>[    7.326995] [0x01f0] 0xffffffff 0xfffff7af 0xffffffff 0xffffffff
>
Is this the dump of an erased page (with ECC correction),
I mean NAND raw read with ECC correction suppressed ?
If yes, 
then if seems that the page was not properly erased, as so many
bit-flips should not be seen on a freshly erasing a block. plz check
device datasheet for "max possible bit-flips per page or block".

If no,
Then this can be bit-flips introduced due to incorrect interpretation
of ECC syndrome, for that can you plz use below command to
dump raw page using below command.
nand dump -N -l <page_size> -f <output_file> <device>


with regards, pekon

Re: [FRC] [PATCH] MTD: nand_base.c: Enable support for Samsung E-die SLC NAND

[Ted Juan]

Dear Pekon,

Thanks help me to debug the issue.

I need some time to reproduce the problem again since the NAND flash
data have been covered.

I add the test code to dump the data, so the data should be not the raw data.
The dump data of last mail is erase page since I confirmed the value
of the read_ecc2[].
The problem not only happen in erase page, but also in some data page.
The erase page is easily to observed for me.
I'll try to read the raw data next time to verify the issue. Thanks much.


@@ -1298,12 +1307,16 @@ static int omap_elm_correct_data(struct
mtd_info *mtd, u_char *data,
        enum omap_bch_ecc type;
        bool is_error_reported = false;
        int err,bitflip_count;
+        char read_ecc2[52];
+        char calc_ecc2[52];
+
+        memcpy(read_ecc2, read_ecc, 52);
+        memcpy(calc_ecc2, calc_ecc, 52);

@@ -1395,24 +1406,31 @@ static int omap_elm_correct_data(struct
mtd_info *mtd, u_char *data,
        err = 0;
        for (i = 0; i < eccsteps; i++) {
        if (err_vec[i].error_uncorrectable) {
+#if 1 // debug
+                          u_char *dat = &data[0];
+                          int k=0;
+                          for (k = 0; k < 512 ; k+=16)
+                                        printk("[0x%04x] 0x%08x
0x%08x 0x%08x 0x%08x \n",
+                                                k, *(int *)&dat[k],
*(int *)&dat[k+4], *(int *)&dat[k+8], *(int *)&dat[k+0xc]);
+
+                                printk("i=%d read_ecc2=0x%08x 0x%08x
0x%08x calc_ecc2=0x%08x 0x%08x 0x%08x\n",
+                                        i, *(int
*)&read_ecc2[i*0xc+0], *(int *)&read_ecc2[i*0xc+4], *(int
*)&read_ecc2[i*0xc+8],
+                                        *(int *)&calc_ecc2[i*0xc+0],
*(int *)&calc_ecc2[i*0xc+4], *(int *)&calc_ecc2[i*0xc+8]);
+                                printk("nand: uncorrectable bit-flips
found\n");
+#endif
                          err = -EBADMSG;
                 } else if (err_vec[i].error_reported) {


2014-06-23 12:05 GMT+08:00 Gupta, Pekon <pekon@ti.com>:
> Hi Ted,
>
>>Hi All,
>>   I recently do the power cut test with this Samsung NAND flash
>>K9F1G08U0E with TI AM3352 chip.
>>I have set the NAND_NO_SUBPAGE_WRITE parameter and checked all the
>>flash timing that are all correct.
>>But it still happened uncorrectable error that bit-flip more than 8
>>bits no matter erase page or not.
>>The below is the wrong data with erase page that bit-flip more than 8 bits .
>>
>>Does anyone have the same experience?
>>
>>PS. The Samsung D-die SLC NAND is test OK in the same environment. And
>>the TI driver code is base on the latest l2-mtd git tree.
>>
>>regards,
>>Ted
>>
>>
>>[    7.129791] [0x0000] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>>[    7.136138] [0x0010] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>>[    7.142486] [0x0020] 0xfbfdffff 0xffffffff 0xffffffff 0xffffffff
>>[    7.148864] [0x0030] 0xffbfffff 0xffff7fff 0xffffffff 0xffffffff
>>[    7.155212] [0x0040] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>>[    7.161590] [0x0050] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>>[    7.167938] [0x0060] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>>[    7.174316] [0x0070] 0xf7ffffff 0xfffffcff 0xffffffff 0xffffffff
>>[    7.180664] [0x0080] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>>[    7.187042] [0x0090] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>>[    7.193389] [0x00a0] 0xffbfffff 0xffffffff 0xffffffff 0xffffffff
>>[    7.199737] [0x00b0] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>>[    7.206115] [0x00c0] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>>[    7.212463] [0x00d0] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>>[    7.218841] [0x00e0] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>>[    7.225189] [0x00f0] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>>[    7.231567] [0x0100] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>>[    7.237915] [0x0110] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>>[    7.244293] [0x0120] 0xffdfffff 0xffffffff 0xffffffff 0xffffffff
>>[    7.250640] [0x0130] 0xffffffff 0xffff7fff 0xffffffff 0xffffffff
>>[    7.256988] [0x0140] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>>[    7.263366] [0x0150] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>>[    7.269714] [0x0160] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>>[    7.276092] [0x0170] 0xffffffff 0xffffffdf 0xffffffff 0xffffffff
>>[    7.282440] [0x0180] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>>[    7.288818] [0x0190] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>>[    7.295166] [0x01a0] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>>[    7.301544] [0x01b0] 0xffffffff 0xffffdfff 0xffffffff 0xffffffff
>>[    7.307891] [0x01c0] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>>[    7.314270] [0x01d0] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>>[    7.320617] [0x01e0] 0xbfffffff 0xffffffff 0xffffffff 0xffffffff
>>[    7.326995] [0x01f0] 0xffffffff 0xfffff7af 0xffffffff 0xffffffff
>>
> Is this the dump of an erased page (with ECC correction),
> I mean NAND raw read with ECC correction suppressed ?
> If yes,
> then if seems that the page was not properly erased, as so many
> bit-flips should not be seen on a freshly erasing a block. plz check
> device datasheet for "max possible bit-flips per page or block".
>
> If no,
> Then this can be bit-flips introduced due to incorrect interpretation
> of ECC syndrome, for that can you plz use below command to
> dump raw page using below command.
> nand dump -N -l <page_size> -f <output_file> <device>
>
>
> with regards, pekon

Re: [FRC] [PATCH] MTD: nand_base.c: Enable support for Samsung E-die SLC NAND

[Ted Juan]

Dear Pekon,

I backup the raw data to data2[] before doing elm_decode_bch_error_page();
Dump  code is as below. The raw data is the same with the correction
data that all more than 8 bit-flips.

The full data log is put as below but include some useless dump data.
https://drive.google.com/file/d/0BwVGpNFs7l22RmZXTHhJWXFYYWs/edit?usp=sharing


The K9F1G08U0E datasheet is also put as below.
https://drive.google.com/file/d/0BwVGpNFs7l22SUwtc3BPYTVyLWM/edit?usp=sharing


The datasheet say ECC requirement : 1 bit / 528bytes but I doubt what it say.



+static char data2[2048];
@@ -1298,12 +1308,17 @@ static int omap_elm_correct_data(struct
mtd_info *mtd, u_char *data,
        enum omap_bch_ecc type;
        bool is_error_reported = false;
        int err,bitflip_count;
+        char read_ecc2[52];
+        char calc_ecc2[52];
+
+        memcpy(read_ecc2, read_ecc, 52);
+        memcpy(calc_ecc2, calc_ecc, 52);
+        memcpy(data2, data, 2048);

@@ -1395,24 +1408,37 @@ static int omap_elm_correct_data(struct
mtd_info *mtd, u_char *data,
        err = 0;
        for (i = 0; i < eccsteps; i++) {
        if (err_vec[i].error_uncorrectable) {

+                          u_char *dat = &data[0];
+                          int k=0;
+                          for (k = 0; k < 512 ; k+=16)
+                                        printk("[0x%04x] 0x%08x
0x%08x 0x%08x 0x%08x \n",
+                                                k, *(int *)&dat[k],
*(int *)&dat[k+4], *(int *)&dat[k+8], *(int *)&dat[k+0xc]);
+
+                          dat = &data2[i*512];
+                          for (k = 0; k < 512 ; k+=16)
+                                        printk("[0x%04x] 0x%08x
0x%08x 0x%08x 0x%08x \n",
+                                                k, *(int *)&dat[k],
*(int *)&dat[k+4], *(int *)&dat[k+8], *(int *)&dat[k+0xc]);
+
                          printk("nand: uncorrectable bit-flips found\n");
                          err = -EBADMSG;
                 } else if (err_vec[i].error_reported) {


========after correction data (data[])

[    5.842346] [0x0000] 0xffffffff 0xffffefbf 0xffffffff 0xffffffff
[    5.848999] [0x0010] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
[    5.855651] [0x0020] 0xffffffff 0xffffffff 0xffffffff 0xfffffbef
[    5.862274] [0x0030] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
[    5.868927] [0x0040] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
[    5.875579] [0x0050] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
[    5.882232] [0x0060] 0xffffffff 0xffffffff 0xffffffff 0xfffff7ff
[    5.888854] [0x0070] 0xffffffff 0xffffffff 0xfffffffe 0xffffffff
[    5.895507] [0x0080] 0xffffffff 0xfffff7df 0xffffffff 0xffffffff
[    5.902160] [0x0090] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
[    5.908813] [0x00a0] 0xffffffff 0xffffffff 0xffffffff 0xffffbfff
[    5.915466] [0x00b0] 0xffffffff 0xffffffff 0xfffff7ff 0xffffffff
[    5.922088] [0x00c0] 0xffffffff 0xfffffffe 0xffffffff 0xffffffff
[    5.928741] [0x00d0] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
[    5.935394] [0x00e0] 0xffffffff 0xffffffff 0xffffffff 0xffffffbf
[    5.942016] [0x00f0] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
[    5.948669] [0x0100] 0xffffffff 0xffffffeb 0xffffffff 0xffffffff
[    5.955322] [0x0110] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
[    5.961975] [0x0120] 0xffffffff 0xffffffff 0xffffffff 0xfffffefd
[    5.968627] [0x0130] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
[    5.975280] [0x0140] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
[    5.982025] [0x0150] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
[    5.988739] [0x0160] 0xffffffff 0xffffffff 0xffffffff 0xffff3fff
[    5.995391] [0x0170] 0xffffffff 0xffffffff 0xffffff7f 0xffffffff
[    6.002014] [0x0180] 0xffffffff 0xfffffdff 0xffffffff 0xffffffff
[    6.008666] [0x0190] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
[    6.015319] [0x01a0] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
[    6.021972] [0x01b0] 0xffffffff 0xffffffff 0xffffefff 0xffffffff
[    6.028625] [0x01c0] 0xffffffff 0xfffffeff 0xefffffff 0xffffffff
[    6.035278] [0x01d0] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
[    6.041900] [0x01e0] 0xffffffff 0xffffffff 0xffffffff 0xffffff7f
[    6.048553] [0x01f0] 0xffffffff 0xffffffff 0xffffffff 0xffffffff

=======raw data (data2[]) , before correction

[    6.065338] [0x0000] 0xffffffff 0xffffefbf 0xffffffff 0xffffffff
[    6.071960] [0x0010] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
[    6.078613] [0x0020] 0xffffffff 0xffffffff 0xffffffff 0xfffffbef
[    6.085266] [0x0030] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
[    6.091918] [0x0040] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
[    6.098571] [0x0050] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
[    6.105224] [0x0060] 0xffffffff 0xffffffff 0xffffffff 0xfffff7ff
[    6.111846] [0x0070] 0xffffffff 0xffffffff 0xfffffffe 0xffffffff
[    6.118499] [0x0080] 0xffffffff 0xfffff7df 0xffffffff 0xffffffff
[    6.125152] [0x0090] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
[    6.131774] [0x00a0] 0xffffffff 0xffffffff 0xffffffff 0xffffbfff
[    6.138427] [0x00b0] 0xffffffff 0xffffffff 0xfffff7ff 0xffffffff
[    6.145080] [0x00c0] 0xffffffff 0xfffffffe 0xffffffff 0xffffffff
[    6.151763] [0x00d0] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
[    6.158416] [0x00e0] 0xffffffff 0xffffffff 0xffffffff 0xffffffbf
[    6.165069] [0x00f0] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
[    6.171691] [0x0100] 0xffffffff 0xffffffeb 0xffffffff 0xffffffff
[    6.178375] [0x0110] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
[    6.185028] [0x0120] 0xffffffff 0xffffffff 0xffffffff 0xfffffefd
[    6.191680] [0x0130] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
[    6.198364] [0x0140] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
[    6.205017] [0x0150] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
[    6.211639] [0x0160] 0xffffffff 0xffffffff 0xffffffff 0xffff3fff
[    6.218292] [0x0170] 0xffffffff 0xffffffff 0xffffff7f 0xffffffff
[    6.224945] [0x0180] 0xffffffff 0xfffffdff 0xffffffff 0xffffffff
[    6.231597] [0x0190] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
[    6.238250] [0x01a0] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
[    6.244873] [0x01b0] 0xffffffff 0xffffffff 0xffffefff 0xffffffff
[    6.251525] [0x01c0] 0xffffffff 0xfffffeff 0xefffffff 0xffffffff
[    6.258178] [0x01d0] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
[    6.264831] [0x01e0] 0xffffffff 0xffffffff 0xffffffff 0xffffff7f
[    6.271453] [0x01f0] 0xffffffff 0xffffffff 0xffffffff 0xffffffff

2014-06-23 16:15 GMT+08:00 Ted Juan <ted.juan@gmail.com>:
> Dear Pekon,
>
> Thanks help me to debug the issue.
>
> I need some time to reproduce the problem again since the NAND flash
> data have been covered.
>
> I add the test code to dump the data, so the data should be not the raw data.
> The dump data of last mail is erase page since I confirmed the value
> of the read_ecc2[].
> The problem not only happen in erase page, but also in some data page.
> The erase page is easily to observed for me.
> I'll try to read the raw data next time to verify the issue. Thanks much.
>
>
> @@ -1298,12 +1307,16 @@ static int omap_elm_correct_data(struct
> mtd_info *mtd, u_char *data,
>         enum omap_bch_ecc type;
>         bool is_error_reported = false;
>         int err,bitflip_count;
> +        char read_ecc2[52];
> +        char calc_ecc2[52];
> +
> +        memcpy(read_ecc2, read_ecc, 52);
> +        memcpy(calc_ecc2, calc_ecc, 52);
>
> @@ -1395,24 +1406,31 @@ static int omap_elm_correct_data(struct
> mtd_info *mtd, u_char *data,
>         err = 0;
>         for (i = 0; i < eccsteps; i++) {
>         if (err_vec[i].error_uncorrectable) {
> +#if 1 // debug
> +                          u_char *dat = &data[0];
> +                          int k=0;
> +                          for (k = 0; k < 512 ; k+=16)
> +                                        printk("[0x%04x] 0x%08x
> 0x%08x 0x%08x 0x%08x \n",
> +                                                k, *(int *)&dat[k],
> *(int *)&dat[k+4], *(int *)&dat[k+8], *(int *)&dat[k+0xc]);
> +
> +                                printk("i=%d read_ecc2=0x%08x 0x%08x
> 0x%08x calc_ecc2=0x%08x 0x%08x 0x%08x\n",
> +                                        i, *(int
> *)&read_ecc2[i*0xc+0], *(int *)&read_ecc2[i*0xc+4], *(int
> *)&read_ecc2[i*0xc+8],
> +                                        *(int *)&calc_ecc2[i*0xc+0],
> *(int *)&calc_ecc2[i*0xc+4], *(int *)&calc_ecc2[i*0xc+8]);
> +                                printk("nand: uncorrectable bit-flips
> found\n");
> +#endif
>                           err = -EBADMSG;
>                  } else if (err_vec[i].error_reported) {
>
>
> 2014-06-23 12:05 GMT+08:00 Gupta, Pekon <pekon@ti.com>:
>> Hi Ted,
>>
>>>Hi All,
>>>   I recently do the power cut test with this Samsung NAND flash
>>>K9F1G08U0E with TI AM3352 chip.
>>>I have set the NAND_NO_SUBPAGE_WRITE parameter and checked all the
>>>flash timing that are all correct.
>>>But it still happened uncorrectable error that bit-flip more than 8
>>>bits no matter erase page or not.
>>>The below is the wrong data with erase page that bit-flip more than 8 bits .
>>>
>>>Does anyone have the same experience?
>>>
>>>PS. The Samsung D-die SLC NAND is test OK in the same environment. And
>>>the TI driver code is base on the latest l2-mtd git tree.
>>>
>>>regards,
>>>Ted
>>>
>>>
>>>[    7.129791] [0x0000] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>>>[    7.136138] [0x0010] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>>>[    7.142486] [0x0020] 0xfbfdffff 0xffffffff 0xffffffff 0xffffffff
>>>[    7.148864] [0x0030] 0xffbfffff 0xffff7fff 0xffffffff 0xffffffff
>>>[    7.155212] [0x0040] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>>>[    7.161590] [0x0050] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>>>[    7.167938] [0x0060] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>>>[    7.174316] [0x0070] 0xf7ffffff 0xfffffcff 0xffffffff 0xffffffff
>>>[    7.180664] [0x0080] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>>>[    7.187042] [0x0090] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>>>[    7.193389] [0x00a0] 0xffbfffff 0xffffffff 0xffffffff 0xffffffff
>>>[    7.199737] [0x00b0] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>>>[    7.206115] [0x00c0] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>>>[    7.212463] [0x00d0] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>>>[    7.218841] [0x00e0] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>>>[    7.225189] [0x00f0] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>>>[    7.231567] [0x0100] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>>>[    7.237915] [0x0110] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>>>[    7.244293] [0x0120] 0xffdfffff 0xffffffff 0xffffffff 0xffffffff
>>>[    7.250640] [0x0130] 0xffffffff 0xffff7fff 0xffffffff 0xffffffff
>>>[    7.256988] [0x0140] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>>>[    7.263366] [0x0150] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>>>[    7.269714] [0x0160] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>>>[    7.276092] [0x0170] 0xffffffff 0xffffffdf 0xffffffff 0xffffffff
>>>[    7.282440] [0x0180] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>>>[    7.288818] [0x0190] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>>>[    7.295166] [0x01a0] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>>>[    7.301544] [0x01b0] 0xffffffff 0xffffdfff 0xffffffff 0xffffffff
>>>[    7.307891] [0x01c0] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>>>[    7.314270] [0x01d0] 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>>>[    7.320617] [0x01e0] 0xbfffffff 0xffffffff 0xffffffff 0xffffffff
>>>[    7.326995] [0x01f0] 0xffffffff 0xfffff7af 0xffffffff 0xffffffff
>>>
>> Is this the dump of an erased page (with ECC correction),
>> I mean NAND raw read with ECC correction suppressed ?
>> If yes,
>> then if seems that the page was not properly erased, as so many
>> bit-flips should not be seen on a freshly erasing a block. plz check
>> device datasheet for "max possible bit-flips per page or block".
>>
>> If no,
>> Then this can be bit-flips introduced due to incorrect interpretation
>> of ECC syndrome, for that can you plz use below command to
>> dump raw page using below command.
>> nand dump -N -l <page_size> -f <output_file> <device>
>>
>>
>> with regards, pekon

RE: [FRC] [PATCH] MTD: nand_base.c: Enable support for Samsung E-die SLC NAND

[Gupta, Pekon]

Hi Ted,

>From: Ted Juan [mailto:ted.juan@gmail.com]
>Dear Pekon,
>
>I backup the raw data to data2[] before doing elm_decode_bch_error_page();
>Dump  code is as below. The raw data is the same with the correction
>data that all more than 8 bit-flips.
>
(a) In that case you should contact the Flash vendor here.
Fresh NAND device from factory should not violate the spec.
I don't suspect a driver issue here, because the raw data read itself
has random bit-flips.

(b) Also, it may be the case that there few particular blocks which has gone
bad and those are is showing again and again at each boot. However, If it
was such a case that only some handful blocks on NAND device have gone
bad, then UBI torture test [1] should have detected them and marked them
bad. And those should not re-appear in next time.
- You can check (b) by scrubbing all bad-blocks from u-boot
  #u-boot> nand scrub.chip all
  #u-boot> nand bad  (should report 0 bad blocks)
- Then, re-boot and let UBI detect bad-blocks on its own using torture-test
- And then again reset the system 2nd time and check newly detected bad-blocks
  #u-boot> nand bad  (should report [n] bad blocks)

(c) You can also check, if you are seeing bit-flips only during erased-pages ?
You can identify this by adding prints in u-boot.
There is slight difference in u-boot and kernel omap-gpmc NAND drivers,
- u-boot: simply ignores erased-pages and does not check for bit-flips in them.
- kernel: counts number of bit-flips in erased-pages also.
 

>The full data log is put as below but include some useless dump data.
>https://drive.google.com/file/d/0BwVGpNFs7l22RmZXTHhJWXFYYWs/edit?usp=sharing
>
There will be no correction done if 'un-correctable error' flag is raised by ELM.
Therefore pre-correction and post-correction data matches in below dump.
Bit-flip correction will _only_ happen if the number of bit-flips are within
correctable range (that is <=8 for BCH8 ECC scheme).


[1] $kernel/drivers/mtd/ubi/io.c @@ torture_peb()

with regards, pekon

Re: [FRC] [PATCH] MTD: nand_base.c: Enable support for Samsung E-die SLC NAND

[David Jander]

Dear Pekon,

On Wed, 25 Jun 2014 10:04:11 +0000
"Gupta, Pekon" <pekon@ti.com> wrote:

> Hi Ted,
> 
> >From: Ted Juan [mailto:ted.juan@gmail.com]
> >Dear Pekon,
> >
> >I backup the raw data to data2[] before doing elm_decode_bch_error_page();
> >Dump  code is as below. The raw data is the same with the correction
> >data that all more than 8 bit-flips.
> >
> (a) In that case you should contact the Flash vendor here.
> Fresh NAND device from factory should not violate the spec.
> I don't suspect a driver issue here, because the raw data read itself
> has random bit-flips.

Sorry to interrupt, but this does sound serious. Are you absolutely sure your
hardware is OK? Is the power-supply clean and well enough decoupled? Timings
within specs?
If electrical specifications are not met, this could explain the bit-flips. It
is possible that Samsung is at fault here (they screwed up the specs for this
version anyway), but double checking the hardware looks like a good idea
here...

> (b) Also, it may be the case that there few particular blocks which has gone
> bad and those are is showing again and again at each boot. However, If it
> was such a case that only some handful blocks on NAND device have gone
> bad, then UBI torture test [1] should have detected them and marked them
> bad. And those should not re-appear in next time.
> - You can check (b) by scrubbing all bad-blocks from u-boot
>   #u-boot> nand scrub.chip all
>   #u-boot> nand bad  (should report 0 bad blocks)
> - Then, re-boot and let UBI detect bad-blocks on its own using torture-test
> - And then again reset the system 2nd time and check newly detected
> bad-blocks #u-boot> nand bad  (should report [n] bad blocks)
> 
> (c) You can also check, if you are seeing bit-flips only during
> erased-pages ? You can identify this by adding prints in u-boot.
> There is slight difference in u-boot and kernel omap-gpmc NAND drivers,
> - u-boot: simply ignores erased-pages and does not check for bit-flips in
> them.
> - kernel: counts number of bit-flips in erased-pages also.
>  
> 
> >The full data log is put as below but include some useless dump data.
> >https://drive.google.com/file/d/0BwVGpNFs7l22RmZXTHhJWXFYYWs/edit?usp=sharing
> >
> There will be no correction done if 'un-correctable error' flag is raised by
> ELM. Therefore pre-correction and post-correction data matches in below dump.
> Bit-flip correction will _only_ happen if the number of bit-flips are within
> correctable range (that is <=8 for BCH8 ECC scheme).
> 
> 
> [1] $kernel/drivers/mtd/ubi/io.c @@ torture_peb()

Best regards,

-- 
David Jander
Protonic Holland.

RE: [FRC] [PATCH] MTD: nand_base.c: Enable support for Samsung E-die SLC NAND

[Gupta, Pekon]

Hi David,

>From: David Jander [mailto:david.jander@protonic.nl]
>>"Gupta, Pekon" <pekon@ti.com> wrote:
>> >From: Ted Juan [mailto:ted.juan@gmail.com]
>> >Dear Pekon,
>> >
>> >I backup the raw data to data2[] before doing elm_decode_bch_error_page();
>> >Dump  code is as below. The raw data is the same with the correction
>> >data that all more than 8 bit-flips.
>> >
>> (a) In that case you should contact the Flash vendor here.
>> Fresh NAND device from factory should not violate the spec.
>> I don't suspect a driver issue here, because the raw data read itself
>> has random bit-flips.
>
>Sorry to interrupt, but this does sound serious. Are you absolutely sure your
>hardware is OK? Is the power-supply clean and well enough decoupled? Timings
>within specs? If electrical specifications are not met, this could explain the bit-flips.
>
I don't have the hardware (board), I'm just  helping Ted as I'm actively
involved with OMAP NAND drivers from TI side. Ted is the original developer
working on this board.
However, I don't suspect this to be board supply or noise issue because:
(1) A timing mis-match would cause read-failure for whole word,
  not just few bits in the word.
(2) Also, power-supply noise would not cause bit-flips in erased-page,
 Because erase operation inside flash is usually driver by charged-pumps
 so a dynamic supply noise may not cause random bit-flips. Though it can
can erase-failures, which will be detected on reading STATUS register.

> It is possible that Samsung is at fault here (they screwed up the specs for this
>version anyway), but double checking the hardware looks like a good idea
>here...
>
Agree. But hardware issue will be difficult to identify and debug.

Ted,
Plz relax timing by 10-20% and check if that makes a difference.


with regards, pekon

Re: [FRC] [PATCH] MTD: nand_base.c: Enable support for Samsung E-die SLC NAND

[David Jander]

Dear Pekon,

On Wed, 25 Jun 2014 11:55:26 +0000
"Gupta, Pekon" <pekon@ti.com> wrote:

> Hi David,
> 
> >From: David Jander [mailto:david.jander@protonic.nl]
> >>"Gupta, Pekon" <pekon@ti.com> wrote:
> >> >From: Ted Juan [mailto:ted.juan@gmail.com]
> >> >Dear Pekon,
> >> >
> >> >I backup the raw data to data2[] before doing
> >> >elm_decode_bch_error_page(); Dump  code is as below. The raw data is the
> >> >same with the correction data that all more than 8 bit-flips.
> >> >
> >> (a) In that case you should contact the Flash vendor here.
> >> Fresh NAND device from factory should not violate the spec.
> >> I don't suspect a driver issue here, because the raw data read itself
> >> has random bit-flips.
> >
> >Sorry to interrupt, but this does sound serious. Are you absolutely sure
> >your hardware is OK? Is the power-supply clean and well enough decoupled?
> >Timings within specs? If electrical specifications are not met, this could
> >explain the bit-flips.
> >
> I don't have the hardware (board), I'm just  helping Ted as I'm actively
> involved with OMAP NAND drivers from TI side. Ted is the original developer
> working on this board.

Ok.

> However, I don't suspect this to be board supply or noise issue because:
> (1) A timing mis-match would cause read-failure for whole word,
>   not just few bits in the word.

Yes that would be the most probable effect of a timing issue. Just a few
bit-flips in a word is unlikely (but not impossible!) to be caused by timing
issues.

> (2) Also, power-supply noise would not cause bit-flips in erased-page,
>  Because erase operation inside flash is usually driver by charged-pumps
>  so a dynamic supply noise may not cause random bit-flips. Though it can
> can erase-failures, which will be detected on reading STATUS register.

Please bear in mind that the erase can be successful for the first few
(milli-)seconds. If the power supply was out of specs during erase, it is
perfectly possible that a few random bits flip back to "programmed" state after
a while. That would not be caught by the status check.

> > It is possible that Samsung is at fault here (they screwed up the specs
> > for this
> >version anyway), but double checking the hardware looks like a good idea
> >here...
> >
> Agree. But hardware issue will be difficult to identify and debug.
> 
> Ted,
> Plz relax timing by 10-20% and check if that makes a difference.

That is a good idea to check, but I would also try to influence the
power-supply or -decoupling to see if that is sensible variable.
Do you have cold-spray? Try to use it and see if it affects the result.

Best regards,

P.S.: Anyone care to give comment on my patch? Not that you two effectively
hijacked this thread for only slightly tangentially related issues... ;-)

-- 
David Jander
Protonic Holland.

Re: [FRC] [PATCH] MTD: nand_base.c: Enable support for Samsung E-die SLC NAND

[Ted Juan]

Hi Pekon and David,

Thanks your help and suggestions.

Sorry David, hijacked your thread.

The E-die 21nm  SLC NOP=1 , not 4.
It means it doesn't support partial write.

Anyone give any comment for the patch,please.


2014-06-25 18:04 GMT+08:00 Gupta, Pekon <pekon@ti.com>:
> Hi Ted,
>
>>
> (a) In that case you should contact the Flash vendor here.
> Fresh NAND device from factory should not violate the spec.
> I don't suspect a driver issue here, because the raw data read itself
> has random bit-flips.
>

OK, I'll try to contact Flash vendor to get more clue.


> (b) Also, it may be the case that there few particular blocks which has gone
> bad and those are is showing again and again at each boot. However, If it
> was such a case that only some handful blocks on NAND device have gone
> bad, then UBI torture test [1] should have detected them and marked them
> bad. And those should not re-appear in next time.
> - You can check (b) by scrubbing all bad-blocks from u-boot
>   #u-boot> nand scrub.chip all
>   #u-boot> nand bad  (should report 0 bad blocks)
> - Then, re-boot and let UBI detect bad-blocks on its own using torture-test
> - And then again reset the system 2nd time and check newly detected bad-blocks
>   #u-boot> nand bad  (should report [n] bad blocks)
>

I'll do the torture test later. Does it mean torture test just can
seriously filter the bad block, but erase command cannot?


> (c) You can also check, if you are seeing bit-flips only during erased-pages ?
> You can identify this by adding prints in u-boot.
> There is slight difference in u-boot and kernel omap-gpmc NAND drivers,
> - u-boot: simply ignores erased-pages and does not check for bit-flips in them.
> - kernel: counts number of bit-flips in erased-pages also.
>

  for (i = 0; i < blockCnt; i++) {
    /* check if any ecc error */
    eccflag = 0;
    for (j = 0; (j < eccsize) && (eccflag == 0); j++)
      if (calc_ecc[j] != 0)
        eccflag = 1;

    if (eccflag == 1) {
      eccflag = 0;
      for (j = 0; (j < eccsize) && (eccflag == 0); j++)
        if (read_ecc[j] != 0xFF)
          eccflag = 1;
    }
   if (eccflag == 1) {
       count = decode_bch(mode, calc_ecc, err_loc);


The above code is cut from uboot.
In this case, it should enter the decode_bch(), and decode fail, right?


>
> There will be no correction done if 'un-correctable error' flag is raised by ELM.
> Therefore pre-correction and post-correction data matches in below dump.
> Bit-flip correction will _only_ happen if the number of bit-flips are within
> correctable range (that is <=8 for BCH8 ECC scheme).
>

I see. thanks.


>> Plz relax timing by 10-20% and check if that makes a difference.

The below is my gpmc register value dump from kernel.
gpmc cs[0] config1 = 0x00600800
gpmc cs[0] config2 = 0x00050500
gpmc cs[0] config3 = 0x00050401
gpmc cs[0] config4 = 0x04010601
gpmc cs[0] config5 = 0x00070808
gpmc cs[0] config6 = 0x04000000
gpmc cs[0] config7 = 0x00000f48


The link is Flash timing report according the above config.
https://drive.google.com/file/d/0BwVGpNFs7l22bkhmQ2FFcVZXQk0/edit?usp=sharing

I also tried to use chip->delay=50 to replace R/B wait, but the result
is the same.

K9F1G08U0E vs K9F1G08U0D Timing is a little difference.

                          　 tR t         PROG       tBERS NOP
K9F1G08U0E Max. 40us Max. 900us Max. 16ms 1
K9F1G08U0D Max. 40us Max. 750us Max. 10ms 4

We test the D-die that never happen this issue.


>>Please bear in mind that the erase can be successful for the first few
>>(milli-)seconds. If the power supply was out of specs during erase, it is
>>perfectly possible that a few random bits flip back to "programmed" state after
>>a while. That would not be caught by the status check.
>>That is a good idea to check, but I would also try to influence the
>>power-supply or -decoupling to see if that is sensible variable.
>>Do you have cold-spray? Try to use it and see if it affects the result.

Thanks. But the D-die is in this environment is ok. BTW, I'll double
check with HW guy.

regards,

Ted

Re: [FRC] [PATCH] MTD: nand_base.c: Enable support for Samsung E-die SLC NAND

[Ted Juan]

Dear Pekon,


>
>> (b) Also, it may be the case that there few particular blocks which has gone
>> bad and those are is showing again and again at each boot. However, If it
>> was such a case that only some handful blocks on NAND device have gone
>> bad, then UBI torture test [1] should have detected them and marked them
>> bad. And those should not re-appear in next time.
>> - You can check (b) by scrubbing all bad-blocks from u-boot
>>   #u-boot> nand scrub.chip all
>>   #u-boot> nand bad  (should report 0 bad blocks)
>> - Then, re-boot and let UBI detect bad-blocks on its own using torture-test
>> - And then again reset the system 2nd time and check newly detected bad-blocks
>>   #u-boot> nand bad  (should report [n] bad blocks)
>>

I do the torture test in uboot.

Some block data was not correct as below , and it should be pattern '0x55'.

This block is not mask the bad, and sometimes the same block pass the
torture test.
Several blocks also have the same phenomenon.

So it seems the Nand Flash problem?

regards,
Ted

nand dump 6560000
Page 06560000 dump:
ff ff ff ff ff ff ff ff  ff ff 55 55 ff ff ff ff
01 55 55 55 55 55 ff ff  ff ff 55 55 ff ff ff ff
55 55 55 55 ff ff ff ff  ff ff 55 55 ff ff 55 55
ff ff 55 55 ff ff ff ff  ff ff ff ff 55 55 55 55
ff ff ff ff ff ff ff ff  ff ff 55 55 ff ff ff ff
55 51 55 55 55 55 ff ff  ff ff 55 55 ff ff ff ff
55 55 55 55 ff ff ff ff  ff ff 55 55 ff ff 55 55
ff ff 55 55 ff ff ff ff  ff ff ff ff 55 55 55 55
ff ff ff ff ff ff ff ff  ff ff 55 55 ff ff ff ff
55 55 55 55 55 55 ff ff  ff ff 55 55 ff ff ff ff
55 55 55 55 ff ff ff ff  ff ff 55 55 ff ff 55 55
ff ff 55 55 ff ff ff ff  ff ff ff ff 55 55 55 55
ff ff ff ff ff ff ff ff  ff ff 55 55 ff ff ff ff
55 54 55 55 45 51 ff ff  ff ff 55 55 ff ff ff ff
55 55 55 55 ff ff ff ff  ff ff 55 55 ff ff 55 55
ff ff 55 55 ff ff ff ff  ff ff ff ff 55 55 55 55
ff ff ff ff ff ff ff ff  ff ff 55 55 ff ff ff ff
55 55 55 55 55 55 ff ff  ff ff 55 55 ff ff ff ff
55 55 55 55 ff ff ff ff  ff ff 55 55 ff ff 55 55
ff ff 55 55 ff ff ff ff  ff ff ff ff 55 55 55 55
ff ff ff ff ff ff ff ff  ff ff 55 55 ff ff ff ff
45 55 55 55 55 55 ff ff  ff ff 55 55 ff ff ff ff
55 55 55 55 ff ff ff ff  ff ff 55 55 ff ff 55 55
ff ff 55 55 ff ff ff ff  ff ff ff ff 55 55 55 15
ff ff ff ff ff ff ff ff  ff ff 55 55 ff ff ff ff
55 55 55 55 55 51 ff ff  ff ff 55 55 ff ff ff ff
55 55 55 55 ff ff ff ff  ff ff 55 55 ff ff 55 55
ff ff 55 55 ff ff ff ff  ff ff ff ff 55 55 55 55
ff ff ff ff ff ff ff ff  ff ff 55 55 ff ff ff ff
55 51 55 55 55 55 ff ff  ff ff 55 55 ff ff ff ff
55 55 55 55 ff ff ff ff  ff ff 55 55 ff ff 55 55
ff ff 55 55 ff ff ff ff  ff ff ff 7f 55 55 55 55
55 55 ff ff 55 55 ff ff  ff ff ff ff 55 55 ff ff
ff ff ff ff 55 55 ff ff  ff ff ff ff ff ff ff ff
55 55 ff ff 55 55 55 55  55 55 55 55 55 55 ff ff
55 55 55 55 ff ff ff ff  55 55 ff ff 55 55 55 55
55 55 ff ff 55 55 ff ff  ff ff ff ff 55 55 ff ff
ff ff ff ff 55 55 ff ff  ff ff ff ff ff ff ff ff
55 55 ff ff 55 55 55 55  55 55 55 55 55 55 ff ff
55 55 55 55 ff ff ff ff  55 55 ff ff 55 55 55 55
55 55 ff ff 55 55 ff ff  ff ff ff ff 55 55 ff ff
ff ff ff ff 55 55 ff ff  ff ff ff ff ff ff ff ff
55 55 ff ff 55 55 55 55  55 55 55 55 55 55 ff ff
55 55 55 55 ff ff ff ff  55 55 ff ff 55 55 55 55
55 55 ff ff 55 55 ff ff  ff ff ff ff 55 55 ff ff
ff ff ff ff 55 55 ff ff  ff ff ff ff ff ff ff ff
55 55 ff ff 55 55 55 55  55 55 55 55 55 55 ff ff
55 55 55 55 ff ff ff ff  55 55 ff ff 55 55 55 55
55 55 ff ff 55 55 ff ff  ff ff ff ff 55 55 ff ff
ff ff ff ff 55 55 ff ff  ff ff ff ff ff ff ff ff
55 55 ff ff 55 55 55 55  55 55 55 55 55 55 ff ff
55 55 55 55 ff ff ff ff  55 55 ff ff 55 55 55 55
55 55 7f ff 55 55 ff ff  ff ff ff ff 55 55 ff ff
7f ff ff ff 55 55 ef ff  ff ff ff ff ff ff 7f ff
55 55 ff ff 55 55 55 55  55 55 55 55 55 55 ff ff
55 55 55 55 ff ff ff ff  55 55 ff ff 55 55 55 55
55 55 ff ff 55 55 ff ff  ff ff 7f ff 55 55 ff ff
ff ff ff ff 55 55 ff ff  7f ff ff ff ff ff ff ff
55 55 ff ff 55 55 55 55  55 55 55 55 55 55 ff ff
55 55 55 55 7f ff ff ff  55 55 ff ff 55 55 55 55
55 55 ff ff 55 55 ff ff  ff ff f7 ff 55 55 ff ff
ff ff ff ff 55 55 ff ff  f7 ff ff ff ff fb ff ff
55 55 ff ff 55 55 55 55  55 55 55 55 55 55 ff ff
55 55 55 55 f7 ff ff ff  55 55 ff ff 55 55 55 55
ff ff ff ff ff ff 55 55  ff ff 55 55 55 55 55 55
55 55 55 55 ff ff 55 55  ff ff ff ff 55 55 55 55
55 55 ff ff ff ff ff ff  55 55 55 55 ff ff ff ff
ff ff ff ff ff ff ff ff  55 55 55 55 55 55 ff ff
ff ff ff ff ff ff 55 55  ff ff 55 55 55 55 55 55
55 55 55 55 ff ff 55 55  ff ff ff ff 55 55 55 55
55 55 ff ff ff ff ff ff  55 55 55 55 ff ff ff ff
ff ff ff ff ff ff ff ff  55 55 55 55 55 55 ff ff
ff ff ff ff ff ff 55 55  ff ff 55 55 55 55 55 55
55 55 55 55 ff ff 55 55  ff ff ff ff 55 55 55 55
55 55 ff ff ff ff ff ff  55 55 55 55 ff ff ff ff
ff ff ff ff ff ff ff ff  55 55 55 55 55 55 ff ff
ff ff ff ff ff ff 55 55  ff ff 55 55 55 55 55 55
55 55 55 55 ff ff 55 55  ff ff ff ff 55 55 55 55
55 55 ff ff ff ff ff ff  55 55 55 55 ff ff ff ff
ff ff ff ff ff ff ff ff  55 55 55 55 55 55 ff ff
ff ff ff ff ff ff 55 55  ff ff 55 55 55 55 55 55
55 55 55 55 ff ff 55 55  ff ff ff ff 55 55 55 55
55 55 ff ff ff ff ff ff  55 55 55 55 ff ff ff ff
ff ff ff ff ff ff ff ff  55 55 55 55 55 55 ff ff
ff ff ff ff ff ff 55 55  ff ff 55 55 55 55 55 55
55 55 55 55 ff ff 55 55  ff ff ff ff 55 55 55 55
55 55 ff ff ff ff ff ff  55 55 55 55 ff ff ff ff
ff ff ff ff ff ff ff ff  55 55 55 55 55 55 ff ff
ff ff ff ff ff ff 55 55  ff ff 55 55 55 55 55 55
55 55 55 55 ff ff 55 55  ff ff ff ff 55 55 55 55
55 55 ff ff ff ff ff ff  55 55 55 55 ff ff ff ff
ff ff ff ff ff ff ff ff  55 55 55 55 55 55 ff ff
ff ff ff ff ff ff 55 55  ff ff 55 55 55 55 55 55
55 55 55 55 ff ff 55 55  ff ff ff ff 55 55 55 55
55 55 ff ff ff ff ff ff  55 55 55 55 ff ff ff ff
ff ff ff ff ff ff ff ff  55 55 55 55 55 55 ff ff
55 55 55 55 ff ff 55 55  55 55 55 55 ff ff 55 55
55 55 ff ff ff ff ff ff  55 55 ff ff ff ff 55 55
ff ff ff ff ff ff ff ff  55 55 55 55 55 55 55 55
ff ff ff ff 55 55 ff ff  55 55 ff ff ff ff 55 55
55 55 55 55 ff ff 55 55  55 55 55 55 ff ff 55 55
55 55 ff ff ff ff ff ff  55 55 ff ff ff ff 55 55
ff ff ff ff ff ff ff ff  55 55 55 55 55 55 55 55
ff ff ff ff 55 55 ff ff  55 55 ff ff ff ff 55 55
55 55 55 55 ff ff 55 55  55 55 55 55 ff ff 55 55
55 55 ff ff ff ff ff ff  55 55 ff ff ff ff 55 55
ff ff ff ff ff ff ff ff  55 55 55 55 55 55 55 55
ff ff ff ff 55 55 ff ff  55 55 ff ff ff ff 55 55
55 55 55 55 ff ff 55 55  55 55 55 55 ff ff 75 55
55 55 ff ff ff ff ff ff  55 55 ff ff ff ff 55 55
ff ff ff ff ff ff ff ff  55 55 55 55 55 55 55 55
ff ff ff ff 55 55 ff ff  55 55 ff ff ff ff 55 55
55 55 55 55 ff ff 55 55  15 55 55 55 ff ff 55 55
55 55 ff ff ff ff ff ff  55 55 ff ff ff ff 55 55
ff ff ff ff ff ff ff ff  55 55 55 55 55 55 55 55
ff ff ff ff 55 55 ff ff  55 55 ff ff ff ff 55 55
55 55 55 55 ff ff 55 55  55 55 55 55 ff ff 55 55
55 55 ff ff ff ff ff ff  55 55 ff ff ff ff 55 55
ff ff ff ff ff ff ff ff  55 55 55 55 55 55 55 55
ff ff ff ff 55 55 ff ff  55 55 ff ff ff ff 55 55
55 55 55 55 ff ff 55 55  55 55 55 55 ff ff 55 55
55 55 ff ff ff ff ff ff  55 55 ff ff ff ff 55 55
ff ff ff ff ff ff ff ff  55 55 55 55 55 55 55 55
ff ff ff ff 55 55 ff ff  55 55 ff ff ff ff 55 55
55 55 55 55 ff ff 55 55  55 55 55 55 ff ff 55 55
55 55 ff ff ff ff ff ff  55 55 ff ff ff ff 55 55
ff ff ff ff ff ff ff ff  55 55 55 55 55 55 55 55
ff ff ff ff 55 55 ff ff  55 55 ff ff ff ff 55 55
OOB:
ff ff ff dd 57 ff ff df
ff 7d ef 3e f5 ea ff 00
fe cd eb af d8 ff ff eb
ff 7f bf ff ff aa ff cd
43 af fa ff d7 ff f7 ff
f5 e0 27 00 fd dd eb 5d
dd ff d2 ff ff 7f ff ff
05 00 ff ff ff ff ff ff

RE: [FRC] [PATCH] MTD: nand_base.c: Enable support for Samsung E-die SLC NAND

[Gupta, Pekon]

Hi Ted,

>From: Ted Juan [mailto:ted.juan@gmail.com]

>>> (b) Also, it may be the case that there few particular blocks which has gone
>>> bad and those are is showing again and again at each boot. However, If it
>>> was such a case that only some handful blocks on NAND device have gone
>>> bad, then UBI torture test [1] should have detected them and marked them
>>> bad. And those should not re-appear in next time.
>>> - You can check (b) by scrubbing all bad-blocks from u-boot
>>>   #u-boot> nand scrub.chip all
>>>   #u-boot> nand bad  (should report 0 bad blocks)
>>> - Then, re-boot and let UBI detect bad-blocks on its own using torture-test
>>> - And then again reset the system 2nd time and check newly detected bad-blocks
>>>   #u-boot> nand bad  (should report [n] bad blocks)
>>>
>
>I do the torture test in uboot.
>
>Some block data was not correct as below , and it should be pattern '0x55'.
>
>This block is not mask the bad, and sometimes the same block pass the
>torture test.
>Several blocks also have the same phenomenon.
>
>So it seems the Nand Flash problem?
>
If the same block fails and passes torture_test inconsistently, then
its mostly the problem with NAND part. As I also see that there are good
number of bit-flips (non 0xff and non 0x55 data) in the below dump,
which should _not_ be the case with fresh NAND. This is violation of
datasheet which say max allowable bit-flips = 1bit/528bytes.

Also, if you see only countable number of such blocks giving inconsistent
result, then you manually mark them bad using following command.
       u-boot>  nand markbad <block-offset>
And re-run your regression tests.
If after marking these blocks as bad, you don't see any issue for long time
That means these bad blocks were not caught during factory tests, And
there is some gap in factory test at the vendor's end, due to which these
blocks weren't caught during factory production.

>regards,
>Ted
>

with regards, pekon



>nand dump 6560000
>Page 06560000 dump:
>ff ff ff ff ff ff ff ff  ff ff 55 55 ff ff ff ff
>01 55 55 55 55 55 ff ff  ff ff 55 55 ff ff ff ff  <--- (01)
>55 55 55 55 ff ff ff ff  ff ff 55 55 ff ff 55 55
>ff ff 55 55 ff ff ff ff  ff ff ff ff 55 55 55 55
>ff ff ff ff ff ff ff ff  ff ff 55 55 ff ff ff ff
>55 51 55 55 55 55 ff ff  ff ff 55 55 ff ff ff ff
>55 55 55 55 ff ff ff ff  ff ff 55 55 ff ff 55 55
>ff ff 55 55 ff ff ff ff  ff ff ff ff 55 55 55 55
>ff ff ff ff ff ff ff ff  ff ff 55 55 ff ff ff ff
>55 55 55 55 55 55 ff ff  ff ff 55 55 ff ff ff ff
>55 55 55 55 ff ff ff ff  ff ff 55 55 ff ff 55 55
>ff ff 55 55 ff ff ff ff  ff ff ff ff 55 55 55 55
>ff ff ff ff ff ff ff ff  ff ff 55 55 ff ff ff ff
>55 54 55 55 45 51 ff ff  ff ff 55 55 ff ff ff ff  <--- (54) (45) (51)
>55 55 55 55 ff ff ff ff  ff ff 55 55 ff ff 55 55
>ff ff 55 55 ff ff ff ff  ff ff ff ff 55 55 55 55
>ff ff ff ff ff ff ff ff  ff ff 55 55 ff ff ff ff
>55 55 55 55 55 55 ff ff  ff ff 55 55 ff ff ff ff
>55 55 55 55 ff ff ff ff  ff ff 55 55 ff ff 55 55
>ff ff 55 55 ff ff ff ff  ff ff ff ff 55 55 55 55
>ff ff ff ff ff ff ff ff  ff ff 55 55 ff ff ff ff
>45 55 55 55 55 55 ff ff  ff ff 55 55 ff ff ff ff
>55 55 55 55 ff ff ff ff  ff ff 55 55 ff ff 55 55
>ff ff 55 55 ff ff ff ff  ff ff ff ff 55 55 55 15
>ff ff ff ff ff ff ff ff  ff ff 55 55 ff ff ff ff
>55 55 55 55 55 51 ff ff  ff ff 55 55 ff ff ff ff
>55 55 55 55 ff ff ff ff  ff ff 55 55 ff ff 55 55
>ff ff 55 55 ff ff ff ff  ff ff ff ff 55 55 55 55
>ff ff ff ff ff ff ff ff  ff ff 55 55 ff ff ff ff
>55 51 55 55 55 55 ff ff  ff ff 55 55 ff ff ff ff
>55 55 55 55 ff ff ff ff  ff ff 55 55 ff ff 55 55
>ff ff 55 55 ff ff ff ff  ff ff ff 7f 55 55 55 55
>55 55 ff ff 55 55 ff ff  ff ff ff ff 55 55 ff ff
>ff ff ff ff 55 55 ff ff  ff ff ff ff ff ff ff ff
>55 55 ff ff 55 55 55 55  55 55 55 55 55 55 ff ff
>55 55 55 55 ff ff ff ff  55 55 ff ff 55 55 55 55
>55 55 ff ff 55 55 ff ff  ff ff ff ff 55 55 ff ff
>ff ff ff ff 55 55 ff ff  ff ff ff ff ff ff ff ff
>55 55 ff ff 55 55 55 55  55 55 55 55 55 55 ff ff
>55 55 55 55 ff ff ff ff  55 55 ff ff 55 55 55 55
>55 55 ff ff 55 55 ff ff  ff ff ff ff 55 55 ff ff
>ff ff ff ff 55 55 ff ff  ff ff ff ff ff ff ff ff
>55 55 ff ff 55 55 55 55  55 55 55 55 55 55 ff ff
>55 55 55 55 ff ff ff ff  55 55 ff ff 55 55 55 55
>55 55 ff ff 55 55 ff ff  ff ff ff ff 55 55 ff ff
>ff ff ff ff 55 55 ff ff  ff ff ff ff ff ff ff ff
>55 55 ff ff 55 55 55 55  55 55 55 55 55 55 ff ff
>55 55 55 55 ff ff ff ff  55 55 ff ff 55 55 55 55
>55 55 ff ff 55 55 ff ff  ff ff ff ff 55 55 ff ff
>ff ff ff ff 55 55 ff ff  ff ff ff ff ff ff ff ff
>55 55 ff ff 55 55 55 55  55 55 55 55 55 55 ff ff
>55 55 55 55 ff ff ff ff  55 55 ff ff 55 55 55 55
>55 55 7f ff 55 55 ff ff  ff ff ff ff 55 55 ff ff
>7f ff ff ff 55 55 ef ff  ff ff ff ff ff ff 7f ff
>55 55 ff ff 55 55 55 55  55 55 55 55 55 55 ff ff
>55 55 55 55 ff ff ff ff  55 55 ff ff 55 55 55 55
>55 55 ff ff 55 55 ff ff  ff ff 7f ff 55 55 ff ff
>ff ff ff ff 55 55 ff ff  7f ff ff ff ff ff ff ff
>55 55 ff ff 55 55 55 55  55 55 55 55 55 55 ff ff
>55 55 55 55 7f ff ff ff  55 55 ff ff 55 55 55 55
>55 55 ff ff 55 55 ff ff  ff ff f7 ff 55 55 ff ff
>ff ff ff ff 55 55 ff ff  f7 ff ff ff ff fb ff ff
>55 55 ff ff 55 55 55 55  55 55 55 55 55 55 ff ff
>55 55 55 55 f7 ff ff ff  55 55 ff ff 55 55 55 55
>ff ff ff ff ff ff 55 55  ff ff 55 55 55 55 55 55
>55 55 55 55 ff ff 55 55  ff ff ff ff 55 55 55 55
>55 55 ff ff ff ff ff ff  55 55 55 55 ff ff ff ff
>ff ff ff ff ff ff ff ff  55 55 55 55 55 55 ff ff
>ff ff ff ff ff ff 55 55  ff ff 55 55 55 55 55 55
>55 55 55 55 ff ff 55 55  ff ff ff ff 55 55 55 55
>55 55 ff ff ff ff ff ff  55 55 55 55 ff ff ff ff
>ff ff ff ff ff ff ff ff  55 55 55 55 55 55 ff ff
>ff ff ff ff ff ff 55 55  ff ff 55 55 55 55 55 55
>55 55 55 55 ff ff 55 55  ff ff ff ff 55 55 55 55
>55 55 ff ff ff ff ff ff  55 55 55 55 ff ff ff ff
>ff ff ff ff ff ff ff ff  55 55 55 55 55 55 ff ff
>ff ff ff ff ff ff 55 55  ff ff 55 55 55 55 55 55
>55 55 55 55 ff ff 55 55  ff ff ff ff 55 55 55 55
>55 55 ff ff ff ff ff ff  55 55 55 55 ff ff ff ff
>ff ff ff ff ff ff ff ff  55 55 55 55 55 55 ff ff
>ff ff ff ff ff ff 55 55  ff ff 55 55 55 55 55 55
>55 55 55 55 ff ff 55 55  ff ff ff ff 55 55 55 55
>55 55 ff ff ff ff ff ff  55 55 55 55 ff ff ff ff
>ff ff ff ff ff ff ff ff  55 55 55 55 55 55 ff ff
>ff ff ff ff ff ff 55 55  ff ff 55 55 55 55 55 55
>55 55 55 55 ff ff 55 55  ff ff ff ff 55 55 55 55
>55 55 ff ff ff ff ff ff  55 55 55 55 ff ff ff ff
>ff ff ff ff ff ff ff ff  55 55 55 55 55 55 ff ff
>ff ff ff ff ff ff 55 55  ff ff 55 55 55 55 55 55
>55 55 55 55 ff ff 55 55  ff ff ff ff 55 55 55 55
>55 55 ff ff ff ff ff ff  55 55 55 55 ff ff ff ff
>ff ff ff ff ff ff ff ff  55 55 55 55 55 55 ff ff
>ff ff ff ff ff ff 55 55  ff ff 55 55 55 55 55 55
>55 55 55 55 ff ff 55 55  ff ff ff ff 55 55 55 55
>55 55 ff ff ff ff ff ff  55 55 55 55 ff ff ff ff
>ff ff ff ff ff ff ff ff  55 55 55 55 55 55 ff ff
>55 55 55 55 ff ff 55 55  55 55 55 55 ff ff 55 55
>55 55 ff ff ff ff ff ff  55 55 ff ff ff ff 55 55
>ff ff ff ff ff ff ff ff  55 55 55 55 55 55 55 55
>ff ff ff ff 55 55 ff ff  55 55 ff ff ff ff 55 55
>55 55 55 55 ff ff 55 55  55 55 55 55 ff ff 55 55
>55 55 ff ff ff ff ff ff  55 55 ff ff ff ff 55 55
>ff ff ff ff ff ff ff ff  55 55 55 55 55 55 55 55
>ff ff ff ff 55 55 ff ff  55 55 ff ff ff ff 55 55
>55 55 55 55 ff ff 55 55  55 55 55 55 ff ff 55 55
>55 55 ff ff ff ff ff ff  55 55 ff ff ff ff 55 55
>ff ff ff ff ff ff ff ff  55 55 55 55 55 55 55 55
>ff ff ff ff 55 55 ff ff  55 55 ff ff ff ff 55 55
>55 55 55 55 ff ff 55 55  55 55 55 55 ff ff 75 55
>55 55 ff ff ff ff ff ff  55 55 ff ff ff ff 55 55
>ff ff ff ff ff ff ff ff  55 55 55 55 55 55 55 55
>ff ff ff ff 55 55 ff ff  55 55 ff ff ff ff 55 55
>55 55 55 55 ff ff 55 55  15 55 55 55 ff ff 55 55
>55 55 ff ff ff ff ff ff  55 55 ff ff ff ff 55 55
>ff ff ff ff ff ff ff ff  55 55 55 55 55 55 55 55
>ff ff ff ff 55 55 ff ff  55 55 ff ff ff ff 55 55
>55 55 55 55 ff ff 55 55  55 55 55 55 ff ff 55 55
>55 55 ff ff ff ff ff ff  55 55 ff ff ff ff 55 55
>ff ff ff ff ff ff ff ff  55 55 55 55 55 55 55 55
>ff ff ff ff 55 55 ff ff  55 55 ff ff ff ff 55 55
>55 55 55 55 ff ff 55 55  55 55 55 55 ff ff 55 55
>55 55 ff ff ff ff ff ff  55 55 ff ff ff ff 55 55
>ff ff ff ff ff ff ff ff  55 55 55 55 55 55 55 55
>ff ff ff ff 55 55 ff ff  55 55 ff ff ff ff 55 55
>55 55 55 55 ff ff 55 55  55 55 55 55 ff ff 55 55
>55 55 ff ff ff ff ff ff  55 55 ff ff ff ff 55 55
>ff ff ff ff ff ff ff ff  55 55 55 55 55 55 55 55
>ff ff ff ff 55 55 ff ff  55 55 ff ff ff ff 55 55
>OOB:
>ff ff ff dd 57 ff ff df
>ff 7d ef 3e f5 ea ff 00
>fe cd eb af d8 ff ff eb
>ff 7f bf ff ff aa ff cd
>43 af fa ff d7 ff f7 ff
>f5 e0 27 00 fd dd eb 5d
>dd ff d2 ff ff 7f ff ff
>05 00 ff ff ff ff ff ff

RE: [FRC] [PATCH] MTD: nand_base.c: Enable support for Samsung E-die SLC NAND

[Gupta, Pekon]

Hi David,

>From: David Jander [mailto:david.jander@protonic.nl]
[...]
>
>P.S.: Anyone care to give comment on my patch? Not that you two effectively
>hijacked this thread for only slightly tangentially related issues... ;-)
>
Sorry for diverting from the main patch discussion, somehow I'm unable to
find the original PATCH email from mtd-list.
As per Samsung Device (K9F1G08U0E) datasheet, which is
"1Gb E-die SLC NAND Flash". This device support 'Random Input' (0x85) command.
This means driver can change the column-address during page-program
operation and write to any partial page in between. Isn't that sufficient
to support subpage writes ?

Earlier implementation of nand_write_subpage_hwecc() has some limitations,
I have recently sent a patch-series [1] which uses alternate approach, can you
check if subpage writes work with this.
Also which controller driver are you using for this device ? There may be some
controller limitation too, prohibiting use of subpages.


with regards, pekon

[1] http://lists.infradead.org/pipermail/linux-mtd/2014-June/054446.html