Incorrect detection of Micron MT29F32G08

Incorrect detection of Micron MT29F32G08

[Andrei Andreyanau]

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

RE: Incorrect detection of Micron MT29F32G08

[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

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

Re: Incorrect detection of Micron MT29F32G08

[Andrei Andreyanau]

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

RE: Incorrect detection of Micron MT29F32G08

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

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

Re: Incorrect detection of Micron MT29F32G08

[Andrei Andreyanau]

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

RE: Incorrect detection of Micron MT29F32G08

[Gupta, Pekon]

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