* Problem with mxc_nand driver @ 2009-09-28 6:41 Jernej Turnsek 2009-09-28 7:39 ` Eric Bénard 0 siblings, 1 reply; 8+ messages in thread From: Jernej Turnsek @ 2009-09-28 6:41 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply related [flat|nested] 8+ messages in thread
* Problem with mxc_nand driver 2009-09-28 6:41 Problem with mxc_nand driver Jernej Turnsek @ 2009-09-28 7:39 ` Eric Bénard 2009-09-28 8:56 ` Jernej Turnsek 0 siblings, 1 reply; 8+ messages in thread From: Eric Bénard @ 2009-09-28 7:39 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Problem with mxc_nand driver 2009-09-28 7:39 ` Eric Bénard @ 2009-09-28 8:56 ` Jernej Turnsek 2009-09-28 9:20 ` Eric Bénard 0 siblings, 1 reply; 8+ messages in thread From: Jernej Turnsek @ 2009-09-28 8:56 UTC (permalink / raw) To: linux-arm-kernel 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 > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Problem with mxc_nand driver 2009-09-28 8:56 ` Jernej Turnsek @ 2009-09-28 9:20 ` Eric Bénard 2009-09-28 9:41 ` Jernej Turnsek 0 siblings, 1 reply; 8+ messages in thread From: Eric Bénard @ 2009-09-28 9:20 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Problem with mxc_nand driver 2009-09-28 9:20 ` Eric Bénard @ 2009-09-28 9:41 ` Jernej Turnsek 2009-09-28 9:43 ` Eric Bénard 2009-09-30 10:07 ` Rabin Vincent 0 siblings, 2 replies; 8+ messages in thread From: Jernej Turnsek @ 2009-09-28 9:41 UTC (permalink / raw) To: linux-arm-kernel 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 > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Problem with mxc_nand driver 2009-09-28 9:41 ` Jernej Turnsek @ 2009-09-28 9:43 ` Eric Bénard 2009-09-28 10:30 ` Jernej Turnsek 2009-09-30 10:07 ` Rabin Vincent 1 sibling, 1 reply; 8+ messages in thread From: Eric Bénard @ 2009-09-28 9:43 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Problem with mxc_nand driver 2009-09-28 9:43 ` Eric Bénard @ 2009-09-28 10:30 ` Jernej Turnsek 0 siblings, 0 replies; 8+ messages in thread From: Jernej Turnsek @ 2009-09-28 10:30 UTC (permalink / raw) To: linux-arm-kernel 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 > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Problem with mxc_nand driver 2009-09-28 9:41 ` Jernej Turnsek 2009-09-28 9:43 ` Eric Bénard @ 2009-09-30 10:07 ` Rabin Vincent 1 sibling, 0 replies; 8+ messages in thread From: Rabin Vincent @ 2009-09-30 10:07 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2009-09-30 10:07 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2009-09-28 6:41 Problem with mxc_nand driver Jernej Turnsek 2009-09-28 7:39 ` Eric Bénard 2009-09-28 8:56 ` Jernej Turnsek 2009-09-28 9:20 ` Eric Bénard 2009-09-28 9:41 ` Jernej Turnsek 2009-09-28 9:43 ` Eric Bénard 2009-09-28 10:30 ` Jernej Turnsek 2009-09-30 10:07 ` Rabin Vincent
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).