Incorrect detection of Micron MT29F32G08

DISCUSSION Andrei Andreyanau 2 participants 6 messages Sep 17, 2013 – Sep 20, 2013 Memory technology devices (MTD)

Share & tools

Andrei Andreyanau

author

2013-09-17 07:05 UTC #0 lore raw

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

Gupta, Pekon

2013-09-17 12:31 UTC #1 lore raw

Quoted 18 lines

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

Andrei Andreyanau

author

2013-09-20 10:49 UTC #2 lore raw

Hi, Pekon
17.09.2013 15:30, Gupta, Pekon пишет:

Quoted 6 lines

Quoted 5 lines
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

Gupta, Pekon

2013-09-20 11:23 UTC #3 lore raw

Quoted 40 lines

Hi, Pekon
17.09.2013 15:30, Gupta, Pekon пишет:
Quoted 1 line
Quoted 1 line
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
Quoted 1 line
Quoted 1 line
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
Quoted 1 line
Quoted 1 line
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
Quoted 1 line
Quoted 1 line
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
Quoted 1 line
Quoted 1 line
NAND doesn't contain what are the values from NAND-device registers
mean (or I missed something). Could you please suggest where to dig?
Quoted 1 line
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-
Quoted 1 line
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)

Quoted 10 lines

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

Andrei Andreyanau

author

2013-09-20 11:49 UTC #4 lore raw

Hi, Pekon,
20.09.2013 14:23, Gupta, Pekon пишет:

Quoted 49 lines

Quoted 39 lines
Hi, Pekon
17.09.2013 15:30, Gupta, Pekon пишет:
Quoted 1 line
Quoted 1 line
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
Quoted 1 line
Quoted 1 line
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
Quoted 1 line
Quoted 1 line
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
Quoted 1 line
Quoted 1 line
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
Quoted 1 line
Quoted 1 line
NAND doesn't contain what are the values from NAND-device registers
mean (or I missed something). Could you please suggest where to dig?
Quoted 1 line
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-
Quoted 1 line
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)
Quoted 10 lines
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

Quoted 7 lines

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

Quoted 7 lines

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.

Quoted 7 lines

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

Gupta, Pekon

2013-09-20 13:25 UTC #5 lore raw

Quoted 64 lines

Hi, Pekon,
20.09.2013 14:23, Gupta, Pekon пишет:
Quoted 9 lines
Quoted 9 lines
Hi, Pekon
17.09.2013 15:30, Gupta, Pekon пишет:
Quoted 1 line
Quoted 1 line
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
Quoted 1 line
Quoted 1 line
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
Quoted 1 line
Quoted 1 line
4GiBs device, but when I'm trying formatting the largest partition (I
have 4
Quoted 1 line
Quoted 1 line
partitions - barebox, env, kernel, rootfs <- the largest) - it drops an I/O
error
Quoted 2 lines
Quoted 2 lines
about bad blocks (I did scan and mark
Quoted 1 line
Quoted 1 line
all bad blocks before)... It seems to me that the amount of pages per
lun
Quoted 5 lines
Quoted 5 lines
is not detected correctly which leads to incorrect detection of device's size etc. Bad thing is that the datasheet for a/m
Quoted 1 line
Quoted 1 line
NAND doesn't contain what are the values from NAND-device registers
mean (or I missed something). Could you please suggest where to dig?
Quoted 1 line
You can try printing values of following towards end of nand_scan_tail()
in
Quoted 3 lines
Quoted 3 lines
drivers/mtd/nand/nand_base.c - mtd->writesize - mtd->erasesize - mtd-
Quoted 1 line
oobsize
Here it is what the kernel givewithout any modifications (I mean - with
ONFI-
Quoted 29 lines
Quoted 19 lines
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)
Quoted 10 lines
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
Quoted 7 lines
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;

Quoted 9 lines

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

Quoted 1 line

Quoted 1 line
0x000000e00000-0x000080000000 : "filesystem"

- with ONFI detection disabled

Quoted 1 line

Quoted 1 line
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.

Quoted 14 lines

Quoted 7 lines
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.
Quoted 7 lines
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/

Quoted 10 lines

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