DM6467T Bad Block Boot Error Messages

Hi Jeff,

I am seeing this behavior as well and will check with the team if this is common occurrence.

Attached is my boot up log. Can you please share boot up log of your board as well? Thanks.

This means your nand has lots of bad blocks. If not too many, that is normal. But if there are too many and if it keeps increasing, which may mean the uboot and kernel may not match each other. The layout in uboot maybe different from the layout in kernel.

The concern is not the errors but number of bad blocks that are in errors. Considering this has been seen on two EVM boards, I would like to check if there are any other EVM boards that have experienced this. These many number of errors were not common in older DM6467 boards. You bring up a good point with regards to uboot and kernel layout. This would require further confirmation that uboot 2009 version and kernel 2.6.32-rc2 has the same NAND layout or not. My understanding is they do. Thanks.

I just checked my old log for dm6467t. The uboot version is 2009.08 and the kernel is 2.6.32-rc2-davinci1. I do not see the bad block error. So, they are match. I upload the log here. 0383.dm6467t-booting-log.txt

Hi Prateek,

Here is the log for our board. I restored the HDD to the lastest version from the web: dvsdk_3_10_00_12.

Jeff,

Can you send full boot log right from uboot level? Thanks.

Prateek,

Attached is our full boot log for the 6467T board.

Jeff

Hi, guys,

We have the same problems on the bad blocks, there are many of them, my linux kernel version is: 2.6.32-rc2-davinci1

In addition, I can't run the decode demo from command line, by starting:

./decode -v data/videos/davincieffect_1080p_60fps.264 -y 7 -k --fhd,

there would be some output:

Error: Failed to create display device

Error: Failed to create Infra Red Objet.

I wonder if this is caused by the bad blocks?

Regards

Wang Ning

Jeff, Prateek and Wang,

Can you please verify what revision of the DM6467T EVM each of you have for us?  We're trying to discern if this issue is only being seen on a certain revision of the board or multiple revisions.

Thanks for your help.

Out of curiosity, have any of you tried the latest Beta drop of the DVSDK 3.10 and still seen the issues after using the NAND flash utils through CCS to reflash your boards? 

You can download it from here:

http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/dvsdk/DVSDK_3_10/latest/index_FDS.html

Hi Jeff,

I see this issue with the latest drop of DVSDK v3.10.00.16 release as well. Here are more details on what I tried -

 - DM6467T EVM Rev C silicon

 - NAND part # on my EVM is NAND01GW3B2CZA6. I believe some of older EVMs had older NAND part REV NAND01GW3B2BZA6. I can not confirm if this is an issue with NAND silicon revision. Would be great if we can get this confirmation.

 - I am seeing a different set of bad blocks every time I boot up and about 30-40% of blocks shows up as bad at the time of boot up.

- I also tested Spectrum Digital nandflash.pjt setting reduce_test flash to 0. The NAND device passes these tests -

                        01  Testing NAND Flash...

  128 MBytes

  1024 Blocks

  65536 Pages

  Erasing Flash [0-1023] blocks

  Writing Flash [0-65535] pages

  Reading Flash [0-65535] pages

  Erasing Flash [0-1023] blocks

    PASS

***ALL Tests Passed*

Jeff and Prateek,

We have the Rev-C version of the board/chip from Spectrum Digital. I don't know if that correlates to a board revision or silicon revision. As there is a heat sink on the chip, I am unable to read the part number.

We have not tested the board with the latest release of the DVSDK. We have been using 3_10_00_12 for most of our testing.

We are currently using a custom built 2.6.32 R2 kernel, and it also has the same Bad Block errors. 

Hope that helps,

Jeff

Prateek,

You are talking about RevC version of Silicon. What about the revision of the Revision of the EVM board?

As you pointed out RevB EVM is using "NAND01GW3B2BZA6" and RevC EVM "NAND01GW3B2CZA6". I suspect some difference between these two NAND parts that to be handled in the Software.

Regards, Srirami.

Srirami,

I am talking about Revision of the EVM board - Rev C and Rev B. I dont know silicon version as there is heat sink on the device. Based on DM6467T EVM silicon errata document, my understanding is there is only one silicon revision Rev 3.0 available on DM6467T

http://www.ti.com/litv/pdf/sprz307

I agree it could be an issue with differences between two NAND parts. Do we know the changes between the two NAND revisions? Below is the datasheet of NAND Rev B part.

http://www.numonyx.com/Documents/Datasheets/NAND01G-B2B_NAND02G-B2C.pdf

Rev C part datasheet is below http://www.numonyx.com/Documents/Datasheets/NAND01G-B2C.pdf

Prateek

Mine is Rev C version EVM.

Hello,

I have rev.C of DM6467T DVEVM, running DVSDK 3.10.00.16, U-Boot version 2009.08. I am observing the same behaviour with a lot of bad blocks reported by the kernel even though U-Boot itself only reports 4 bad blocks, writes uImage to the NAND and boots that image without problems. nandflash test through CCS passes as well.

flash_eraseall -j /dev/mtd3 also results in a lot of bad block messages (~40% of the blocks), and attempt to mount this block as JFFS file system fails. nandtest shows 366 bad blocks and ECC fails at different addresses.

It looks like there are issues with the mtd kernel driver.

Alex

Alex,

I am waiting to get hold of a Rev C EVM to see what is going wrong there. There is a difference in NAND part between Rev B and Rev C, but I cant see how that could be causing this behavior. Meanwhile, it will be be good if you can try the following patch and let me know if you see any change in behavior:

Here I have eliminated the WAIT pin monitoring that was present in the driver. The wait pin on the EVM is selected through a 'PCI detect' pin coming out of an FPGA. Not sure if anything changed there (U-Boot uses the same mechanism, but still..). Also, I have eliminated the buffered reads/writes that were present in the driver to simplify the read path.

Thanks,

Sekhar

diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
index 58b2107..0d00290 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -600,7 +600,7 @@ static int __init nand_davinci_probe(struct platform_device *pdev)

        info->chip.IO_ADDR_R    = vaddr;
        info->chip.IO_ADDR_W    = vaddr;
-       info->chip.chip_delay   = 0;
+       info->chip.chip_delay   = 25;
        info->chip.select_chip  = nand_davinci_select_chip;

        /* options such as NAND_USE_FLASH_BBT or 16-bit widths */
@@ -621,11 +621,6 @@ static int __init nand_davinci_probe(struct platform_device *pdev)

        /* Set address of hardware control function */
        info->chip.cmd_ctrl     = nand_davinci_hwcontrol;
-       info->chip.dev_ready    = nand_davinci_dev_ready;
-
-       /* Speed up buffer I/O */
-       info->chip.read_buf     = nand_davinci_read_buf;
-       info->chip.write_buf    = nand_davinci_write_buf;

        /* Use board-specific ECC config */
        ecc_mode                = pdata->ecc_mode;

Hello Sekhar,

Replacing the WAIT pin monitoring with the 25us delay has definitely helped, now the kernel sees only 4 bad blocks like the U-boot and I can format an write to NAND. U-Boot uses the same mechanism, but the implementation of nand_wait_ready() is different. Not sure why this function does not work in the kernel and what the difference between rev.B and C of DVEVM is, would let you to figure it out :-)

Thanks for your help.

Alex

Configuring stricter timings on AEMIF has led to this issue going away. 'nandtest' passes too.

Here is the patch: http://arago-project.org/git/projects/?p=linux-davinci.git;a=commit;h=8ea27c8a86d9e5da55e9564a5d00ecf804fb6831

The RevC EVM actually has a different NAND part with stricter timing requirements than RevB EVM.

Thanks,

Sekhar

Hi guys

How do i fix bad sectors that have been already marked?

Sergi,

You can't "fix" a bad block in NAND.  If it is being incorrectly marked as "bad", as was happening in the above, that's a differnet story, but the patch noted above fixes this particular issue.  See the following for a better understanding of "bad blocks" as they relate to NAND flash memory:

http://download.micron.com/pdf/technotes/nand/tn2917.pdf

Hi Jeff,

Are those bad sectors reported by the nandtest utility those marked by the manufacturer?

Now  nandtest reports 183 bad sectors and are the same as those reported by "nand bad" command in u-boot. So everything looks fine now.

I wonder why "nand bad" in u-boot reported nothing before I started "playing" with nand memory while using the previous kernel version. After running some tests and ereses with the non patched kernel, "nand bad" in uboot did  report those bad sectors.

Sergi,

Are you seeing this behavior and running this on the DM6467T EVM?  How many bad blocks did you see before applying the patch?  183 bad blocks seems VERY high and I'd be inclined to believe that the patch was not applied correctly or there is some other software issue.

Hi Jeff,

Yes, you are corerct. I use de DM6467T EVM.

I use the last uImage released in de DVSDK 3.10.00.19. I understad the patch is already applied since the kernel was built after the patch was committed.

With earlier kernel versions I got 441 bad blocks and Input/Ouput errors when exeuting nandtest.

This is a previous message I posted before running into this thread. You can see the first lines of "nandtest".

I can successfully write a file system image in nand because there are too many bad sectors and it's size is too large too fit in

I've executed :nandtest

root@dm6467t-evm:~# nandtest /dev/mtd3
ECC corrections: 0
ECC failures   : 0
Bad blocks     : 441
BBT blocks     : 0
Bad block at 0x00000000
Bad block at 0x00020000
Bad block at 0x00040000
00060000: writing...
write: Input/output error
00080000: writing...
write: Input/output error
Bad block at 0x000a0000
000c0000: writing...
write: Input/output error

 441 bad sectors seems to many to me. Maybe I had something wrong and nandwrite or flash_eraseall marked incorrecly some sectors as bad.

I can successfully write ubl, u-boot and the kernel image using sfh_dm646x utility and nand commands while in u-boot.

 Any suggestions?? How I can erase the Bad sector table? Is that a good idea?

Thank you

Hi Sergi,

Sergi Creus said:

I use the last uImage released in de DVSDK 3.10.00.19. I understad the patch is already applied since the kernel was built after the patch was committed.

With earlier kernel versions I got 441 bad blocks and Input/Ouput errors when exeuting nandtest.

This suggests the patch did have an effect. The number of bad blocks reduced from 441 to 183 after the patch applied.

Can you confirm you are using a RevC EVM?

Sergi Creus said:

Any suggestions?? How I can erase the Bad sector table? Is that a good idea?

If you suspect the blocks were mistakenly marked bad, it is possible to erase NAND without regard to bad blocks marking using U-Boot 'nand scrub' command. If the block is really bad, accessing it again will likely lead to marking it bad again.

This however should not be done in production systems.

 Do you have other EVMs where you can check if you see the same issue?

Thanks,

Sekhar

Hi Sekhar,

Yes my EVM is a revision C kit.

I performed a nand scrub as you sugested and now I have 0 bad blocks

After a nandtest there are still 0 bad blocks marked. u-boot reports also 0 bad blocks.

I'm a bit worried but everything seems to work fine for now.

thank you all for your help.

Hello,

With nand scrub you have erased all NAND blocks without regard to bad block information.

You should keep using the nand and see if bad blocks come-up and how many. The blocks which are actually bad will be again marked bad because write or erase of those blocks will fail.

As I said in earlier post, nand scrub should not be used in production systems since it erases all bad block data.

Thanks,

Sekhar

I just thought that with nandtest all bad blocks were going to be marked.