This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

NAND Problems

We are using a DM6446 with a Micron 2Gb NAND device, p/n MT29F2G08ABD. The processor is booting uBoot (ver 1.3.3) from NAND successfully. We are having a problem when running the kernel where any block that is written to becomes a bad block. Have you seen any problems related to this? Can you tell me if this particular NAND was ever tested with the DM6446? Also, do you have any software that can be used to test the entire flash?

  • If you can load u-boo successfully, you should be ok from a hardware perspective (RBL limits NAND devices which can be used for boot purposes).  From a software perspective, you may need to add support for your NAND device to the Linux kernel drivers.

  • There is a NAND SCRUB command in uBoot that is labeled as UNSAFE. Is there a reason why it is UNSAFE other than causing more failures to NAND?

  • I believe the NAND Scrub command is unsafe because it wipes out the bad block table (which is put in at nand production), meaning you would have to reflash the NAND with U-Boot and rely on U-Boot to detect all of the bad blocks which may be risky, but I have heard works.

  • FYI, This is part of the original u-boot open source code, not something added by TI; to answer your question, it appears this command tries to erase bad blocks in NAND and therefore it is not safe (since blocks are suspected to be bad)

  • We are using the 1.3.3 version of u-boot that supports this version of the NAND and we are using a patched version of the kernel 2.6.10 from Monta Vista that also supports this chip.  It seems to work for a while, but then it stops working.  It stops working after a hard power-on reset.

  • Are you positive the problem is with the NAND part?  If so, how did you arrive at this conclusion

    I assume you are testing on your custom hardware, if so I have the following things to consider

    1) If this issue is reproducible in our DVEVM, than the issue is likely on the software stack

    2) If the issue is only reproducible on your custom hardware setup, then there is still the question if this is a hardware issue or software issue.  Since it appears to work part of the time, I am leaning towards software, but I still question if this is specific to this NAND part. 

    It would be great if you can try and reproduce this on our EVM.