Problem with mxc_nand driver

Problem with mxc_nand driver

[Jernej Turnsek]

Hi,

Yesterday I have updated my linux kernel for ARM MX27 platform from
git repository and I have observed some strange behaviour regarding
nand driver.
I have a jffs2 partition on Samsung K9F1G08U0B and when I load a root
fs for the first time, it works, but after another reset I got
messages: "Bad erase block %d at"...
These messages are only for the blocks which are still empty.

After investigating problem I found that mxc_nand.c file was changed:

---
diff --git a/drivers/mtd/nand/mxc_nand.c b/drivers/mtd/nand/mxc_nand.c
index 76beea4..65b26d5 100644
--- a/drivers/mtd/nand/mxc_nand.c
+++ b/drivers/mtd/nand/mxc_nand.c
@@ -857,6 +857,17 @@ static void mxc_nand_command(struct mtd_info
*mtd, unsigned command,
     }
 }

+/* Define some generic bad / good block scan pattern which are used
+ * while scanning a device for factory marked good / bad blocks. */
+static uint8_t scan_ff_pattern[] = { 0xff, 0xff };
+
+static struct nand_bbt_descr smallpage_memorybased = {
+    .options = NAND_BBT_SCAN2NDPAGE,
+    .offs = 5,
+    .len = 1,
+    .pattern = scan_ff_pattern
+};
+
 static int __init mxcnd_probe(struct platform_device *pdev)
 {
     struct nand_chip *this;
@@ -973,7 +984,10 @@ static int __init mxcnd_probe(struct platform_device *pdev)
         goto escan;
     }

-    host->pagesize_2k = (mtd->writesize == 2048) ? 1 : 0;
+    if (mtd->writesize == 2048) {
+        host->pagesize_2k = 1;
+        this->badblock_pattern = &smallpage_memorybased;
+    }

     if (this->ecc.mode == NAND_ECC_HW) {
         switch (mtd->oobsize) {

---

I found a bit strange to set badblock_pattern parameter to
smallpage_memorybased although pagesize is 2k. Or am I wrong?

When I revert this patch, everything works as it should.

BR,
Jernej

Problem with mxc_nand driver

[Eric Bénard]

Hi Jernej,

Jernej Turnsek a ?crit :
> I found a bit strange to set badblock_pattern parameter to
> smallpage_memorybased although pagesize is 2k. Or am I wrong?
> 
> When I revert this patch, everything works as it should.
> 
on my iMX27 board, I have the opposite case with a MT29F4G08ABC : it 
works only with this patch. This code came from the original Freescale 
BSP. I'm going to investigate more on this problem on my board and let 
you know.

Eric

Problem with mxc_nand driver

[Jernej Turnsek]

Hi,

are you using HW ECC on your chip? I suspect that HW ECC is writting
something into space provided for the clean markers. I will
investigate to.

BR,
Jernej

On Mon, Sep 28, 2009 at 9:39 AM, Eric B?nard <eric@eukrea.com> wrote:
> Hi Jernej,
>
> Jernej Turnsek a ?crit :
>>
>> I found a bit strange to set badblock_pattern parameter to
>> smallpage_memorybased although pagesize is 2k. Or am I wrong?
>>
>> When I revert this patch, everything works as it should.
>>
> on my iMX27 board, I have the opposite case with a MT29F4G08ABC : it works
> only with this patch. This code came from the original Freescale BSP. I'm
> going to investigate more on this problem on my board and let you know.
>
> Eric
>

Problem with mxc_nand driver

[Eric Bénard]

Hi,

Jernej Turnsek a ?crit :
> are you using HW ECC on your chip? I suspect that HW ECC is writting
> something into space provided for the clean markers. I will
> investigate to.
> 
yes, I'm using HW ECC.
static struct mxc_nand_platform_data eukrea_cpuimx27_nand_board_info = {
	.width = 1,
	.hw_ecc = 1,
};

In fact, maybe the change to the NAND driver should test hw_ecc as it 
shouldn't be necessary for software ecc.

Eric

Problem with mxc_nand driver

[Jernej Turnsek]

Hi,

after writing root fs image into nand partition, running the image and
then checking the first empty block I've got following OOB data which
is suspicious to me:

OOB:
	ff ff 85 19 03 20 ff ff
	ff 65 02 08 00 00 00 ff
	ff ff ff ff ff ff ff ff
	ff ff 03 ff ff ff ff ff
	ff ff ff ff ff ff ff ff
	ff ff 03 ff ff ff ff ff
	ff ff ff ff ff ff ff ff
	ff ff 03 ff ff ff ff ff

One can see that bytes on offset 2 to 5 are not empty and when using
the smallpage_memorybased badblock_pattern byte 6 is not FF like it
should be.

Anyone knows what is going on here?

PS: for the not empty pages all first 6 bytes are FF.

BR,
Jernej

On Mon, Sep 28, 2009 at 11:20 AM, Eric B?nard <eric@eukrea.com> wrote:
> Hi,
>
> Jernej Turnsek a ?crit :
>>
>> are you using HW ECC on your chip? I suspect that HW ECC is writting
>> something into space provided for the clean markers. I will
>> investigate to.
>>
> yes, I'm using HW ECC.
> static struct mxc_nand_platform_data eukrea_cpuimx27_nand_board_info = {
> ? ? ? ?.width = 1,
> ? ? ? ?.hw_ecc = 1,
> };
>
> In fact, maybe the change to the NAND driver should test hw_ecc as it
> shouldn't be necessary for software ecc.
>
> Eric
>

Problem with mxc_nand driver

[Eric Bénard]

Hi,

Jernej Turnsek a ?crit :
> after writing root fs image into nand partition, running the image and
> then checking the first empty block I've got following OOB data which
> is suspicious to me:
> 
> OOB:
> 	ff ff 85 19 03 20 ff ff
> 	ff 65 02 08 00 00 00 ff
> 	ff ff ff ff ff ff ff ff
> 	ff ff 03 ff ff ff ff ff
> 	ff ff ff ff ff ff ff ff
> 	ff ff 03 ff ff ff ff ff
> 	ff ff ff ff ff ff ff ff
> 	ff ff 03 ff ff ff ff ff
> 
> One can see that bytes on offset 2 to 5 are not empty and when using
> the smallpage_memorybased badblock_pattern byte 6 is not FF like it
> should be.
> 
> Anyone knows what is going on here?
> 
which configuration are you using ? SW ECC + without the commit ?

Eric

Problem with mxc_nand driver

[Jernej Turnsek]

static struct mxc_nand_platform_data nand_board_info = {
	.width = 1,
	.hw_ecc = 1,
};

Isn't number 85 19 something from jffs2? Magic or something.

Jernej

On Mon, Sep 28, 2009 at 11:43 AM, Eric B?nard <eric@eukrea.com> wrote:
> Hi,
>
> Jernej Turnsek a ?crit :
>>
>> after writing root fs image into nand partition, running the image and
>> then checking the first empty block I've got following OOB data which
>> is suspicious to me:
>>
>> OOB:
>> ? ? ? ?ff ff 85 19 03 20 ff ff
>> ? ? ? ?ff 65 02 08 00 00 00 ff
>> ? ? ? ?ff ff ff ff ff ff ff ff
>> ? ? ? ?ff ff 03 ff ff ff ff ff
>> ? ? ? ?ff ff ff ff ff ff ff ff
>> ? ? ? ?ff ff 03 ff ff ff ff ff
>> ? ? ? ?ff ff ff ff ff ff ff ff
>> ? ? ? ?ff ff 03 ff ff ff ff ff
>>
>> One can see that bytes on offset 2 to 5 are not empty and when using
>> the smallpage_memorybased badblock_pattern byte 6 is not FF like it
>> should be.
>>
>> Anyone knows what is going on here?
>>
> which configuration are you using ? SW ECC + without the commit ?
>
> Eric
>

Problem with mxc_nand driver

[Rabin Vincent]

On Mon, Sep 28, 2009 at 11:41:39AM +0200, Jernej Turnsek wrote:
> after writing root fs image into nand partition, running the image and
> then checking the first empty block I've got following OOB data which
> is suspicious to me:
> 
> OOB:
> 	ff ff 85 19 03 20 ff ff
> 	ff 65 02 08 00 00 00 ff
> 	ff ff ff ff ff ff ff ff
> 	ff ff 03 ff ff ff ff ff
> 	ff ff ff ff ff ff ff ff
> 	ff ff 03 ff ff ff ff ff
> 	ff ff ff ff ff ff ff ff
> 	ff ff 03 ff ff ff ff ff
> 
> One can see that bytes on offset 2 to 5 are not empty and when using
> the smallpage_memorybased badblock_pattern byte 6 is not FF like it
> should be.
> 
> Anyone knows what is going on here?

85 19 03 20 08 00 00 00 is the JFFS2 cleanmarker; it's written to
indicate that the block is empty.  This is being stored in the OOB area
in the positions specified by oobfree in your ecclayout.

Your ecclayout has this:

static struct nand_ecclayout nand_hw_eccoob_64 = {
	.eccbytes = 20,
	.eccpos = {6, 7, 8, 9, 10, 22, 23, 24, 25, 26,
		   38, 39, 40, 41, 42, 54, 55, 56, 57, 58},
	.oobfree = {{2, 4}, {11, 10}, {27, 10}, {43, 10}, {59, 5}, }
};

The {2, 4} element in oobfree says that 4 bytes from position 2 (i.e,
positions 2, 3, 4, 5) are free to be used to store any OOB data.

If bad block information is supposed to be in position 5, that position
should not be included in oobfree.

Rabin