* Incorrect detection of Micron MT29F32G08 @ 2013-09-17 7:02 Andrei Andreyanau 2013-09-17 12:30 ` Gupta, Pekon 0 siblings, 1 reply; 6+ messages in thread From: Andrei Andreyanau @ 2013-09-17 7:02 UTC (permalink / raw) To: linux-mtd Hi, I've faced a problem with the Micron NAND MT29F32G08, which is 4GiBs, 8K blocks per LUN, 224b OOB, 512K erase size, has two planes 4k blocks each. In the kernel (I use v3.0.35) it is detected as 2GiB device. Only when I disable part of the code which belongs to ONFI detection, add definition for this device in nand_ids.c (device has id=0x48), add 224b OOB table, I can see that it's a 4GiBs device, but when I'm trying formatting the largest partition (I have 4 partitions - barebox, env, kernel, rootfs <- the largest) - it drops an I/O error about bad blocks (I did scan and mark all bad blocks before)... It seems to me that the amount of pages per lun is not detected correctly which leads to incorrect detection of device's size etc. Bad thing is that the datasheet for a/m NAND doesn't contain what are the values from NAND-device registers mean (or I missed something). Could you please suggest where to dig? Thanks in advance, Andrei Andreyanau ^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: Incorrect detection of Micron MT29F32G08 2013-09-17 7:02 Incorrect detection of Micron MT29F32G08 Andrei Andreyanau @ 2013-09-17 12:30 ` Gupta, Pekon 2013-09-20 10:47 ` Andrei Andreyanau 0 siblings, 1 reply; 6+ messages in thread From: Gupta, Pekon @ 2013-09-17 12:30 UTC (permalink / raw) To: Andrei Andreyanau; +Cc: linux-mtd > > Hi, > I've faced a problem with the Micron NAND MT29F32G08, > which is 4GiBs, 8K blocks per LUN, 224b OOB, 512K erase size, > has two planes 4k blocks each. In the kernel (I use v3.0.35) > it is detected as 2GiB device. Only when I disable part of the > code which belongs to ONFI detection, add definition for this > device in nand_ids.c (device has id=0x48), add 224b OOB table, > I can see that it's a 4GiBs device, but when I'm trying formatting > the largest partition (I have 4 partitions - barebox, env, kernel, > rootfs <- the largest) - it drops an I/O error about bad blocks > (I did scan and mark all bad blocks before)... > It seems to me that the amount of pages per lun is not detected > correctly which leads to incorrect detection of device's size etc. Bad > thing is that the datasheet for a/m NAND doesn't contain what > are the values from NAND-device registers mean (or I missed something). > Could you please suggest where to dig? > You can try printing values of following towards end of nand_scan_tail() in drivers/mtd/nand/nand_base.c - mtd->writesize - mtd->erasesize - mtd->oobsize Too many bad block on new device usually happen due to: (1) wrong ecc.layout in nand driver Use following command to dump ecc.layout 'nanddump -p -N -n -s <offset> -l <page_size> </dev/mtdx> (2) incorrect pin-mux (like muxing only AD[7:0] instead of AD[15:0] (usually case with x16 devices, but yours is x8) However, once bad-blocks are detected, they are marked permanently, So you need to use 'nand scrub' command at u-boot to clear off all Bad-block markers before testing next time. with regards, pekon ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Incorrect detection of Micron MT29F32G08 2013-09-17 12:30 ` Gupta, Pekon @ 2013-09-20 10:47 ` Andrei Andreyanau 2013-09-20 11:23 ` Gupta, Pekon 0 siblings, 1 reply; 6+ messages in thread From: Andrei Andreyanau @ 2013-09-20 10:47 UTC (permalink / raw) To: Gupta, Pekon; +Cc: linux-mtd Hi, Pekon 17.09.2013 15:30, Gupta, Pekon пишет: >> Hi, I've faced a problem with the Micron NAND MT29F32G08, which is 4GiBs, 8K blocks per LUN, 224b OOB, 512K erase size, has two planes 4k blocks each. In the kernel (I use v3.0.35) it is detected >> as 2GiB device. Only when I disable part of the code which belongs to ONFI detection, add definition for this device in nand_ids.c (device has id=0x48), add 224b OOB table, I can see that it's a >> 4GiBs device, but when I'm trying formatting the largest partition (I have 4 partitions - barebox, env, kernel, rootfs <- the largest) - it drops an I/O error about bad blocks (I did scan and mark >> all bad blocks before)... It seems to me that the amount of pages per lun is not detected correctly which leads to incorrect detection of device's size etc. Bad thing is that the datasheet for a/m >> NAND doesn't contain what are the values from NAND-device registers mean (or I missed something). Could you please suggest where to dig? > You can try printing values of following towards end of nand_scan_tail() in drivers/mtd/nand/nand_base.c - mtd->writesize - mtd->erasesize - mtd->oobsize Here it is what the kernel givewithout any modifications (I mean - with ONFI-support enabled): ... ONFI flash detected ONFI param page 0 valid NAND device: Manufacturer ID: 0x2c, Chip ID: 0x48 (Micron MT29F32G08AFACAWP) =============nand_scan_tail============= - writesize=4096 - erasesize=524288 - oobsize=224 gpmi-nand imx6q-gpmi-nand.0: enable asynchronous EDO mode 5 Bad block table not found for chip 0 Creating 4 MTD partitions on "gpmi-nand": 0x000000000000-0x000000200000 : "bootloader" 0x000000200000-0x000000600000 : "env" 0x000000600000-0x000000e00000 : "kernel" 0x000000e00000-0x000080000000 : "filesystem" GPMI NAND driver registered. (IMX) mtd_debug output (for "filesystem"): $mtd_debug info /dev/mtd5 mtd.type = MTD_NANDFLASH mtd.flags = MTD_WRITEABLE mtd.size = 2132803584 (1G) mtd.erasesize = 524288 (512K) mtd.writesize = 4096 (4K) mtd.oobsize = 224 regions = 0 What I get when I disable ONFI detection: GPIO NAND driver, © 2004 Simtec Electronics NAND device: Manufacturer ID: 0x2c, Chip ID: 0x48 (Micron NAND 4GiB 3,3V 8-bit) =============nand_scan_tail============= - writesize=4096 - erasesize=524288 - oobsize=224 Bad block table not found for chip 0 Creating 4 MTD partitions on "gpmi-nand": 0x000000000000-0x000000200000 : "bootloader" 0x000000200000-0x000000600000 : "env" 0x000000600000-0x000000e00000 : "kernel" 0x000000e00000-0x000100000000 : "filesystem" GPMI NAND driver registered. (IMX) mtd_debug output (for "filesystem"): $mtd_debug info /dev/mtd5 mtd.type = MTD_NANDFLASH mtd.flags = MTD_WRITEABLE mtd.size = 4280287232 (3G) mtd.erasesize = 524288 (512K) mtd.writesize = 4096 (4K) mtd.oobsize = 224 regions = 0 What do you think? Thanks in advance, Andrei ^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: Incorrect detection of Micron MT29F32G08 2013-09-20 10:47 ` Andrei Andreyanau @ 2013-09-20 11:23 ` Gupta, Pekon 2013-09-20 11:46 ` Andrei Andreyanau 0 siblings, 1 reply; 6+ messages in thread From: Gupta, Pekon @ 2013-09-20 11:23 UTC (permalink / raw) To: Andrei Andreyanau; +Cc: Huang Shijie (b32955@freescale.com), linux-mtd > > Hi, Pekon > 17.09.2013 15:30, Gupta, Pekon пишет: > >> Hi, I've faced a problem with the Micron NAND MT29F32G08, which is > 4GiBs, 8K blocks per LUN, 224b OOB, 512K erase size, has two planes 4k > blocks each. In the kernel (I use v3.0.35) it is detected > >> as 2GiB device. Only when I disable part of the code which belongs to > ONFI detection, add definition for this device in nand_ids.c (device has > id=0x48), add 224b OOB table, I can see that it's a > >> 4GiBs device, but when I'm trying formatting the largest partition (I have 4 > partitions - barebox, env, kernel, rootfs <- the largest) - it drops an I/O error > about bad blocks (I did scan and mark > >> all bad blocks before)... It seems to me that the amount of pages per lun > is not detected correctly which leads to incorrect detection of device's size > etc. Bad thing is that the datasheet for a/m > >> NAND doesn't contain what are the values from NAND-device registers > mean (or I missed something). Could you please suggest where to dig? > > You can try printing values of following towards end of nand_scan_tail() in > drivers/mtd/nand/nand_base.c - mtd->writesize - mtd->erasesize - mtd- > >oobsize > Here it is what the kernel givewithout any modifications (I mean - with ONFI- > support enabled): > ... > ONFI flash detected > ONFI param page 0 valid > NAND device: Manufacturer ID: 0x2c, Chip ID: 0x48 (Micron > MT29F32G08AFACAWP) > =============nand_scan_tail============= > - writesize=4096 > - erasesize=524288 > - oobsize=224 > gpmi-nand imx6q-gpmi-nand.0: enable asynchronous EDO mode 5 > Bad block table not found for chip 0 > Creating 4 MTD partitions on "gpmi-nand": > 0x000000000000-0x000000200000 : "bootloader" > 0x000000200000-0x000000600000 : "env" > 0x000000600000-0x000000e00000 : "kernel" > 0x000000e00000-0x000080000000 : "filesystem" > GPMI NAND driver registered. (IMX) > > mtd_debug output (for "filesystem"): > $mtd_debug info /dev/mtd5 > mtd.type = MTD_NANDFLASH > mtd.flags = MTD_WRITEABLE > mtd.size = 2132803584 (1G) > mtd.erasesize = 524288 (512K) > mtd.writesize = 4096 (4K) > mtd.oobsize = 224 > regions = 0 > Data above is correct ... Your "filesystem" partition size = (0x80000000 - 0xe00000) which is "mtd.size = 2132803584" mtd->size is the size of the partition, not the complete size of NAND device. It’s the nand_chip->chipsize, which gives complete storage density of the NAND device. And nand_chip->chipsize = lun_count * blocks_per_lun * erasesize; Now question remains about why you are seeing bad-blocks, even after running 'nand scrub' command from u-boot. So there can be two reasons for it. (1) these are actual badblocks (which are identified again) (2) these are fictitious bad blocks due to some problem in your NAND flashing utility or nand driver in 3.0.35 kernel version. For (2) you have to check Freescale support as you are using GPMI based driver, or debug using 'nand dump -N' in kernel. With regards, pekon ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Incorrect detection of Micron MT29F32G08 2013-09-20 11:23 ` Gupta, Pekon @ 2013-09-20 11:46 ` Andrei Andreyanau 2013-09-20 13:24 ` Gupta, Pekon 0 siblings, 1 reply; 6+ messages in thread From: Andrei Andreyanau @ 2013-09-20 11:46 UTC (permalink / raw) To: Gupta, Pekon; +Cc: linux-mtd Hi, Pekon, 20.09.2013 14:23, Gupta, Pekon пишет: >> Hi, Pekon >> 17.09.2013 15:30, Gupta, Pekon пишет: >>>> Hi, I've faced a problem with the Micron NAND MT29F32G08, which is >> 4GiBs, 8K blocks per LUN, 224b OOB, 512K erase size, has two planes 4k >> blocks each. In the kernel (I use v3.0.35) it is detected >>>> as 2GiB device. Only when I disable part of the code which belongs to >> ONFI detection, add definition for this device in nand_ids.c (device has >> id=0x48), add 224b OOB table, I can see that it's a >>>> 4GiBs device, but when I'm trying formatting the largest partition (I have 4 >> partitions - barebox, env, kernel, rootfs <- the largest) - it drops an I/O error >> about bad blocks (I did scan and mark >>>> all bad blocks before)... It seems to me that the amount of pages per lun >> is not detected correctly which leads to incorrect detection of device's size >> etc. Bad thing is that the datasheet for a/m >>>> NAND doesn't contain what are the values from NAND-device registers >> mean (or I missed something). Could you please suggest where to dig? >>> You can try printing values of following towards end of nand_scan_tail() in >> drivers/mtd/nand/nand_base.c - mtd->writesize - mtd->erasesize - mtd- >>> oobsize >> Here it is what the kernel givewithout any modifications (I mean - with ONFI- >> support enabled): >> ... >> ONFI flash detected >> ONFI param page 0 valid >> NAND device: Manufacturer ID: 0x2c, Chip ID: 0x48 (Micron >> MT29F32G08AFACAWP) >> =============nand_scan_tail============= >> - writesize=4096 >> - erasesize=524288 >> - oobsize=224 >> gpmi-nand imx6q-gpmi-nand.0: enable asynchronous EDO mode 5 >> Bad block table not found for chip 0 >> Creating 4 MTD partitions on "gpmi-nand": >> 0x000000000000-0x000000200000 : "bootloader" >> 0x000000200000-0x000000600000 : "env" >> 0x000000600000-0x000000e00000 : "kernel" >> 0x000000e00000-0x000080000000 : "filesystem" >> GPMI NAND driver registered. (IMX) >> >> mtd_debug output (for "filesystem"): >> $mtd_debug info /dev/mtd5 >> mtd.type = MTD_NANDFLASH >> mtd.flags = MTD_WRITEABLE >> mtd.size = 2132803584 (1G) >> mtd.erasesize = 524288 (512K) >> mtd.writesize = 4096 (4K) >> mtd.oobsize = 224 >> regions = 0 >> > Data above is correct ... > Your "filesystem" partition size = (0x80000000 - 0xe00000) > which is "mtd.size = 2132803584" > mtd->size is the size of the partition, not the complete > size of NAND device. It’s the nand_chip->chipsize, which gives > complete storage density of the NAND device. And > nand_chip->chipsize = lun_count * blocks_per_lun * erasesize; Yes, I understand, but in second case (without ONFI) it has detected 4GiB (well, 3GiB remaining after partitioning by the kernel) size. Moreover, I'm confused a little bit with the fact that with ONFI detection enabled the driver detects incorrect amount of blocks per lun (4096 instead of 8192) which in fact results on the total size of the device. According to the datasheet, the device has two planes 4K blocks each, located on one LUN. So I should argue with you that the problem is within the driver... > Now question remains about why you are seeing bad-blocks, > even after running 'nand scrub' command from u-boot. > So there can be two reasons for it. > (1) these are actual badblocks (which are identified again) > (2) these are fictitious bad blocks due to some problem in your > NAND flashing utility or nand driver in 3.0.35 kernel version. > > For (2) you have to check Freescale support as you are using > GPMI based driver, or debug using 'nand dump -N' in kernel. > > With regards, pekon > ______________________________________________________ > Linux MTD discussion mailing list > http://lists.infradead.org/mailman/listinfo/linux-mtd/ So, what nanddump gave me: $nanddump --oob --bb=dumpbad /dev/mtd5 ECC failed: 0 ECC corrected: 0 Number of bad blocks: 8 Number of bbt blocks: 0 Not printing binary garbage to tty. Use '-a' or '--forcebinary' to override. (keys --oob/--bb used because it complained about deprecated params) Also, I tried both, nand scub (in barebox, as I'm using it) as well as nand -d (deregister a bad block aware device) without luck. Thanks in advance, Andrei ^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: Incorrect detection of Micron MT29F32G08 2013-09-20 11:46 ` Andrei Andreyanau @ 2013-09-20 13:24 ` Gupta, Pekon 0 siblings, 0 replies; 6+ messages in thread From: Gupta, Pekon @ 2013-09-20 13:24 UTC (permalink / raw) To: Andrei Andreyanau; +Cc: linux-mtd > > Hi, Pekon, > 20.09.2013 14:23, Gupta, Pekon пишет: > >> Hi, Pekon > >> 17.09.2013 15:30, Gupta, Pekon пишет: > >>>> Hi, I've faced a problem with the Micron NAND MT29F32G08, which is > >> 4GiBs, 8K blocks per LUN, 224b OOB, 512K erase size, has two planes 4k > >> blocks each. In the kernel (I use v3.0.35) it is detected > >>>> as 2GiB device. Only when I disable part of the code which belongs to > >> ONFI detection, add definition for this device in nand_ids.c (device has > >> id=0x48), add 224b OOB table, I can see that it's a > >>>> 4GiBs device, but when I'm trying formatting the largest partition (I > have 4 > >> partitions - barebox, env, kernel, rootfs <- the largest) - it drops an I/O > error > >> about bad blocks (I did scan and mark > >>>> all bad blocks before)... It seems to me that the amount of pages per > lun > >> is not detected correctly which leads to incorrect detection of device's size > >> etc. Bad thing is that the datasheet for a/m > >>>> NAND doesn't contain what are the values from NAND-device registers > >> mean (or I missed something). Could you please suggest where to dig? > >>> You can try printing values of following towards end of nand_scan_tail() > in > >> drivers/mtd/nand/nand_base.c - mtd->writesize - mtd->erasesize - mtd- > >>> oobsize > >> Here it is what the kernel givewithout any modifications (I mean - with > ONFI- > >> support enabled): > >> ... > >> ONFI flash detected > >> ONFI param page 0 valid > >> NAND device: Manufacturer ID: 0x2c, Chip ID: 0x48 (Micron > >> MT29F32G08AFACAWP) > >> =============nand_scan_tail============= > >> - writesize=4096 > >> - erasesize=524288 > >> - oobsize=224 > >> gpmi-nand imx6q-gpmi-nand.0: enable asynchronous EDO mode 5 > >> Bad block table not found for chip 0 > >> Creating 4 MTD partitions on "gpmi-nand": > >> 0x000000000000-0x000000200000 : "bootloader" > >> 0x000000200000-0x000000600000 : "env" > >> 0x000000600000-0x000000e00000 : "kernel" > >> 0x000000e00000-0x000080000000 : "filesystem" > >> GPMI NAND driver registered. (IMX) > >> > >> mtd_debug output (for "filesystem"): > >> $mtd_debug info /dev/mtd5 > >> mtd.type = MTD_NANDFLASH > >> mtd.flags = MTD_WRITEABLE > >> mtd.size = 2132803584 (1G) > >> mtd.erasesize = 524288 (512K) > >> mtd.writesize = 4096 (4K) > >> mtd.oobsize = 224 > >> regions = 0 > >> > > Data above is correct ... > > Your "filesystem" partition size = (0x80000000 - 0xe00000) > > which is "mtd.size = 2132803584" > > mtd->size is the size of the partition, not the complete > > size of NAND device. It’s the nand_chip->chipsize, which gives > > complete storage density of the NAND device. And > > nand_chip->chipsize = lun_count * blocks_per_lun * erasesize; > Yes, I understand, but in second case (without ONFI) it has > detected 4GiB (well, 3GiB remaining after partitioning by the kernel) size. > Moreover, I'm confused a little bit with the fact that with ONFI detection > enabled the driver detects incorrect amount of blocks per lun (4096 instead > of 8192) > which in fact results on the total size of the device. According to the > datasheet, the > device has two planes 4K blocks each, located on one LUN. > So I should argue with you that the problem is within the driver... I did notice difference in partition size - with ONFI dection enabled >> 0x000000e00000-0x000080000000 : "filesystem" - with ONFI detection disabled > > 0x000000e00000-0x0000100000000 : "filesystem" I think your device MT29F32G08 has 'dual die' and 'dual chip-selects' ? In that case, may be each of die planes are getting detected as separate NAND physical chips. Just check 'nand_chip->numchips' if such is the case, then you need to check your driver how it was handling NAND devices with multi chip-selects in your kernel version. > > Now question remains about why you are seeing bad-blocks, > > even after running 'nand scrub' command from u-boot. > > So there can be two reasons for it. > > (1) these are actual badblocks (which are identified again) > > (2) these are fictitious bad blocks due to some problem in your > > NAND flashing utility or nand driver in 3.0.35 kernel version. > > > > For (2) you have to check Freescale support as you are using > > GPMI based driver, or debug using 'nand dump -N' in kernel. > > > > With regards, pekon > > ______________________________________________________ > > Linux MTD discussion mailing list > > http://lists.infradead.org/mailman/listinfo/linux-mtd/ > So, what nanddump gave me: > $nanddump --oob --bb=dumpbad /dev/mtd5 > ECC failed: 0 > ECC corrected: 0 > Number of bad blocks: 8 > Number of bbt blocks: 0 > Not printing binary garbage to tty. Use '-a' > or '--forcebinary' to override. > (keys --oob/--bb used because it complained about deprecated params) > Use '-p' print in ASCII option to dump hex values of NAND data. This may be renamed to some other option in latest mtd-utils. With regards, pekon ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-09-20 13:25 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-09-17 7:02 Incorrect detection of Micron MT29F32G08 Andrei Andreyanau 2013-09-17 12:30 ` Gupta, Pekon 2013-09-20 10:47 ` Andrei Andreyanau 2013-09-20 11:23 ` Gupta, Pekon 2013-09-20 11:46 ` Andrei Andreyanau 2013-09-20 13:24 ` Gupta, Pekon
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox