Re: Incorrect detection of Micron MT29F32G08

[Andrei Andreyanau <a.andreyanau@sam-solutions.com>]

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