Linux/AM3358: NAND UBIFS error

Adam Scislowicz

Part Number: AM3358

Tool/software: Linux

I am in the process of migrating form 3.2.0 to 4.9.x. I am attempting to being up the NAND device via GPMC. I've worked through a few issues in the device tree specification and now the NAND chip is propelry detected and I do not see ECC errors. However when the MTD/UBI layer scan's for UBI volumes the mtd_block_isbad() function, which calls the nand_block_isbad() function is reproting errors which I think are not accurate.

Ive added some tracing:

[    1.931824] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xaa
[    1.938276] nand: Micron MT29F2G08ABBEAH4
[    1.942304] nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
[    1.949953] nand: using OMAP_ECC_BCH8_CODE_HW ECC scheme
[    1.955313] XXXADS mtd->_block_isbad = nand_block_isbad
[    1.960584] 1 ofpart partitions found on MTD device omap2-nand.0

[ 1.966627] Creating 1 MTD partitions on "omap2-nand.0":

[ 1.971970] 0x000000000000-0x000010000000 : "NAND Partition"

[ 1.977671] XXXADS: mtd_block_isbad(): ofs=0 mtd->size=268435456, _block_isbad=c055d9a8

[ 1.985718] XXXADS nand_block_isbad()

[ 1.989391] XXXADS nand_block_checkbad()

[    1.993326] XXXADS: nand_block_bad() bbt_options=0x00008000 chip->badblockbits=8
[    2.000784] XXXADS nand_block_bad: path B
[    2.004820] XXXADS nand_block_bad: 0xff
[    2.008669] XXXADS nand_block_bad: ofs=2048, page=1, i=1, res=0
[    2.014612] XXXADS nand_block_bad: path B
[    2.018642] XXXADS nand_block_bad: 0x30
[    2.022491] XXXADS nand_block_bad: ofs=4096, page=2, i=2, res=1
[    2.028440] XXXADS nand_block_bad: res=1

Here bbt_options is set to 0x8000 which means that NAND_BBT_SCAN2NDPAGE is set. I am not an expert on the NAND/MTD/UBI subsystem and I am not sure if this

is detected at runtime or set via the device tree. When I boot the same NAND device using 3.2.x the UBI volules are detected and most bocks aren't marked as bad. With

4.9.x in the current configuration I think just about every block is looking bad.

Any guidance appreciated.

Regards,

Adam

over 7 years ago

0 Steve Kipisz over 7 years ago

TI__Genius 15510 points

Are you using a NAND that was written with 3.2.0 and now you are trying to read with 4.9.x? If so, can you erase the NAND from 4.9.x and re-flash it from there?

Steve K.

0 Adam Scislowicz over 7 years ago in reply to Steve Kipisz

Prodigy 55 points

Hi Steve.

Indeed I am. I'd like to try to get 4.9.x to inter-operate with a 3.2.0 generated NAND if possible. I'm adding more detailed trace to 3.2.0 and 4.9.x to try to get to the bottom of the current issue. Here are my current traces (of two PEB OOB reads).

Quick summary. 4.9.x by default was treating the bbt_options 0x8000 differently as 4.9.x is sensitive to the ~READ2NDPAGE flag while 3.2.0 wasn't. I've modified 4.9.x to have a 3.2.0 compat. option here but it looks like for som readon the nand_command_lp() function (which I've run two ways. 4.9.69 and 4.9.69 with minimal 3.2.0_COMPAT changes Ive made) always get back 0x30 from the READOOB (which is converted into a READ0 w/ a column of 2048(page_size)) instead of the 0xff it is expecting (and gets when using 3.2.0).

4.9.x detailed log

[ 1.980877] XXXADS: mtd_block_isbad(): ofs=0 mtd->size=268435456, _block_isbad=c055d8c8^M
[ 1.988926] XXXADS nand_block_isbad()^M
[ 1.992598] XXXADS nand_block_checkbad()^M
[ 1.996547] XXXADS: nand_block_bad() bbt_options=0x00008000 chip->badblockbits=8 chip->options=0x10101 ofs=0 page=0^M
[ 2.007038] XXXADS nand_command_lp(command=80, column=0, page_addr=0)^M
[ 2.013503] XXXADS nand_command_lp(command=0, column=2048, page_addr=0)^M
[ 2.020175] XXXADS nand_block_bad: path B^M
[ 2.024197] XXXADS nand_block_bad: 0xff^M
[ 2.028053] XXXADS nand_block_bad: res=0^M
[ 2.031994] XXXADS: mtd_block_isbad(): ofs=131072 mtd->size=268435456, _block_isbad=c055d8c8^M
[ 2.040473] XXXADS nand_block_isbad()^M
[ 2.044144] XXXADS nand_block_checkbad()^M
[ 2.048091] XXXADS: nand_block_bad() bbt_options=0x00008000 chip->badblockbits=8 chip->options=0x10101 ofs=131072 page=64^H
[ 2.059101] XXXADS nand_command_lp(command=80, column=0, page_addr=64)^M
[ 2.065661] XXXADS nand_command_lp(command=0, column=2048, page_addr=64)^M
[ 2.072389] XXXADS nand_block_bad: path B^M
[ 2.076420] XXXADS nand_block_bad: 0x30^M
[ 2.080266] XXXADS nand_block_bad: res=1^M

3.2.0 detailed log

[ 3.309539] XXXADS nand_block_checkbad()^M
[ 3.313659] XXXADS nand_block_bad() chip->badblockbits=8 chip->bbt_options=0x8000 ofs=0 chip->options=0x10101 page=0 getchip=1^M
[ 3.325592] XXXADS nand_command_lp(command=80, column=0, page_addr=0)^M
[ 3.332336] XXXADS nand_command_lp(command=0, column=2048, page_addr=0)^M
[ 3.339294] XXXADS nand_block_bad() res=0x0 bad=0xff^M
[ 3.344512] XXXADS nand_block_checkbad()^M
[ 3.348602] XXXADS nand_block_bad() chip->badblockbits=8 chip->bbt_options=0x8000 ofs=131072 chip->options=0x10101 page=64 getchip=1^M
[ 3.361053] XXXADS nand_command_lp(command=80, column=0, page_addr=64)^M
[ 3.367889] XXXADS nand_command_lp(command=0, column=2048, page_addr=64)^M
[ 3.374969] XXXADS nand_block_bad() res=0x0 bad=0xff^M

0 Adam Scislowicz over 7 years ago in reply to Adam Scislowicz

Prodigy 55 points

This turned out to be related to timing. On the current board we use relaxed timings for the GPMC w/ 3.2.0. For 4.9.x I needed to use even more relaxed timings. Looking into this as a hardware issue. Regards -ADS

Processors

Processors forum

Linux/AM3358: NAND UBIFS error