* [FRC] [PATCH] MTD: nand_base.c: Enable support for Samsung E-die SLC NAND @ 2014-06-20 10:12 David Jander 2014-06-22 12:06 ` Ted Juan 0 siblings, 1 reply; 13+ messages in thread From: David Jander @ 2014-06-20 10:12 UTC (permalink / raw) To: linux-mtd; +Cc: sjhill, tglx, Brian Norris, David Woodhouse, 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 ^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: [FRC] [PATCH] MTD: nand_base.c: Enable support for Samsung E-die SLC NAND 2014-06-20 10:12 [FRC] [PATCH] MTD: nand_base.c: Enable support for Samsung E-die SLC NAND David Jander @ 2014-06-22 12:06 ` Ted Juan 2014-06-23 4:05 ` Gupta, Pekon 0 siblings, 1 reply; 13+ messages in thread From: Ted Juan @ 2014-06-22 12:06 UTC (permalink / raw) To: David Jander, Gupta, Pekon Cc: sjhill, tglx, Brian Norris, linux-mtd, David Woodhouse 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/ ^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: [FRC] [PATCH] MTD: nand_base.c: Enable support for Samsung E-die SLC NAND 2014-06-22 12:06 ` Ted Juan @ 2014-06-23 4:05 ` Gupta, Pekon 2014-06-23 8:15 ` Ted Juan 0 siblings, 1 reply; 13+ messages in thread From: Gupta, Pekon @ 2014-06-23 4:05 UTC (permalink / raw) To: Ted Juan, David Jander Cc: sjhill, tglx, Brian Norris, linux-mtd, David Woodhouse 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [FRC] [PATCH] MTD: nand_base.c: Enable support for Samsung E-die SLC NAND 2014-06-23 4:05 ` Gupta, Pekon @ 2014-06-23 8:15 ` Ted Juan 2014-06-25 6:17 ` Ted Juan 0 siblings, 1 reply; 13+ messages in thread From: Ted Juan @ 2014-06-23 8:15 UTC (permalink / raw) To: Gupta, Pekon Cc: linux-mtd, David Jander, sjhill, tglx, Brian Norris, David Woodhouse 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [FRC] [PATCH] MTD: nand_base.c: Enable support for Samsung E-die SLC NAND 2014-06-23 8:15 ` Ted Juan @ 2014-06-25 6:17 ` Ted Juan 2014-06-25 10:04 ` Gupta, Pekon 0 siblings, 1 reply; 13+ messages in thread From: Ted Juan @ 2014-06-25 6:17 UTC (permalink / raw) To: Gupta, Pekon Cc: linux-mtd, David Jander, sjhill, tglx, Brian Norris, David Woodhouse 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: [FRC] [PATCH] MTD: nand_base.c: Enable support for Samsung E-die SLC NAND 2014-06-25 6:17 ` Ted Juan @ 2014-06-25 10:04 ` Gupta, Pekon 2014-06-25 11:31 ` David Jander 2014-06-26 4:02 ` Ted Juan 0 siblings, 2 replies; 13+ messages in thread From: Gupta, Pekon @ 2014-06-25 10:04 UTC (permalink / raw) To: Ted Juan Cc: linux-mtd, David Jander, sjhill, tglx, Brian Norris, David Woodhouse 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [FRC] [PATCH] MTD: nand_base.c: Enable support for Samsung E-die SLC NAND 2014-06-25 10:04 ` Gupta, Pekon @ 2014-06-25 11:31 ` David Jander 2014-06-25 11:55 ` Gupta, Pekon 2014-06-26 4:02 ` Ted Juan 1 sibling, 1 reply; 13+ messages in thread From: David Jander @ 2014-06-25 11:31 UTC (permalink / raw) To: Gupta, Pekon Cc: linux-mtd, Ted Juan, sjhill, tglx, Brian Norris, David Woodhouse 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: [FRC] [PATCH] MTD: nand_base.c: Enable support for Samsung E-die SLC NAND 2014-06-25 11:31 ` David Jander @ 2014-06-25 11:55 ` Gupta, Pekon 2014-06-25 12:11 ` David Jander 0 siblings, 1 reply; 13+ messages in thread From: Gupta, Pekon @ 2014-06-25 11:55 UTC (permalink / raw) To: David Jander Cc: linux-mtd, Ted Juan, sjhill, tglx, Brian Norris, David Woodhouse 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [FRC] [PATCH] MTD: nand_base.c: Enable support for Samsung E-die SLC NAND 2014-06-25 11:55 ` Gupta, Pekon @ 2014-06-25 12:11 ` David Jander 2014-06-30 11:06 ` Gupta, Pekon 0 siblings, 1 reply; 13+ messages in thread From: David Jander @ 2014-06-25 12:11 UTC (permalink / raw) To: Gupta, Pekon, Brian Norris Cc: Ted Juan, sjhill, tglx, linux-mtd, David Woodhouse 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: [FRC] [PATCH] MTD: nand_base.c: Enable support for Samsung E-die SLC NAND 2014-06-25 12:11 ` David Jander @ 2014-06-30 11:06 ` Gupta, Pekon 0 siblings, 0 replies; 13+ messages in thread From: Gupta, Pekon @ 2014-06-30 11:06 UTC (permalink / raw) To: David Jander, Brian Norris Cc: Ted Juan, sjhill, tglx, linux-mtd, David Woodhouse 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [FRC] [PATCH] MTD: nand_base.c: Enable support for Samsung E-die SLC NAND 2014-06-25 10:04 ` Gupta, Pekon 2014-06-25 11:31 ` David Jander @ 2014-06-26 4:02 ` Ted Juan 2014-06-27 9:13 ` Ted Juan 1 sibling, 1 reply; 13+ messages in thread From: Ted Juan @ 2014-06-26 4:02 UTC (permalink / raw) To: Gupta, Pekon Cc: linux-mtd, David Jander, sjhill, tglx, Brian Norris, David Woodhouse 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [FRC] [PATCH] MTD: nand_base.c: Enable support for Samsung E-die SLC NAND 2014-06-26 4:02 ` Ted Juan @ 2014-06-27 9:13 ` Ted Juan 2014-06-27 10:03 ` Gupta, Pekon 0 siblings, 1 reply; 13+ messages in thread From: Ted Juan @ 2014-06-27 9:13 UTC (permalink / raw) To: Gupta, Pekon Cc: linux-mtd, David Jander, sjhill, tglx, Brian Norris, David Woodhouse 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: [FRC] [PATCH] MTD: nand_base.c: Enable support for Samsung E-die SLC NAND 2014-06-27 9:13 ` Ted Juan @ 2014-06-27 10:03 ` Gupta, Pekon 0 siblings, 0 replies; 13+ messages in thread From: Gupta, Pekon @ 2014-06-27 10:03 UTC (permalink / raw) To: Ted Juan Cc: linux-mtd, David Jander, sjhill, tglx, Brian Norris, David Woodhouse 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2014-06-30 11:07 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-06-20 10:12 [FRC] [PATCH] MTD: nand_base.c: Enable support for Samsung E-die SLC NAND David Jander 2014-06-22 12:06 ` Ted Juan 2014-06-23 4:05 ` Gupta, Pekon 2014-06-23 8:15 ` Ted Juan 2014-06-25 6:17 ` Ted Juan 2014-06-25 10:04 ` Gupta, Pekon 2014-06-25 11:31 ` David Jander 2014-06-25 11:55 ` Gupta, Pekon 2014-06-25 12:11 ` David Jander 2014-06-30 11:06 ` Gupta, Pekon 2014-06-26 4:02 ` Ted Juan 2014-06-27 9:13 ` Ted Juan 2014-06-27 10:03 ` Gupta, Pekon
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.