Incorrect detection of Micron MT29F32G08

Gupta, Pekon pekon at ti.com
Fri Sep 20 09:24:44 EDT 2013


> 
> 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


More information about the linux-mtd mailing list