• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 98 subscribers
  • Views 385 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Programming NAND flash

Brendan Cassidy
Intellectual 335 points

This appears to be a common problem on the DM355, and having followed the various threads I still find myself at a loss.

We have a new board which is based on (i.e. virtual cut and paste) the DM355.

The one significant difference is the flash device, we are using a 29F16G08DAA

The DAA part has new geometry, but essentially the page size has doubled.

The differences seen at by diagnostic code are that page size goes from 0x800 to 0x1000 and spare bytes goes from 0x40 to 0xDA.

 

Now when I run the flash utilities from a WinXP box it all seems to go OK, I won't post the output from the screen, but in summary I see:

                 Pages used
                 EVM                            My Hardware

UBL               8                                     4

Uboot            64                                   32

From the output I see, it seems that all is well and the flash has indeed been programmed.

But when I try to boot the hardware, the green LED flashes a about 4HZ, suggesting a NAND boot failure - but no O/P on the serial terminal.
The hardware has been thoroughly checked and appears to be fine, we have used jtag to test the flash and that appears to be fine.

So I installed Cygwin and the Alchemy tools and was able to start tweaking the UBL to see what's occurring.

I added some diagnostic code to the UBL and ran it from IRAM using the slh_DM3X.exe utility.

I added code to dump the NAND flash parameters and to try to read the first page of block 0.

The read fails, digging in a bit further and adding more and more debug prints I get to the point where it seems that the nand read fails on an ECC test of the page data.

This is in nand.c in the function NAND_readPage()

So my guess is that the data is being read by the RBL, failing ECC and so the boot just fails.

This is odd, because (again thanks to lost of debug prints) I can see that when the data is being written to flash it is verified by the same NAND_readPage function.

Can anyone shed any light on this?

Has anyone used this flash device succesfully?  I question thsi as the new page geometry may be causing the problem (complete guess)!

  • 0
    TI__Mastermind 37340 points

    The new page geometry could certainly be a factor.  The RBL only supports a limited set of NAND devices and unlike the UBL, u-boot or Linux kernel, it cannot be changed to expand support for other parts.  This means that the first thing you should do if you plan on using NAND device for booting is to make sure your NAND device is supported by RBL (see Table 11-3 on http://focus.ti.com/lit/ug/sprufb3/sprufb3.pdf  for details.

    If your device is supported by RBL, then changing the UBL to support your device may be all you need.

  • 0 in reply to Juan Gonzales
    Intellectual 335 points

    Oh Joy!

    The device ID id 0xD3, not on the table.

    EVM device: 29F16G08AAW
    our device: 29F16G08DAA

    But the device on the EVM reports 0xD3, but as luck would have it, it suites the default geometry.

    We have found some alternate devices so I am going to try one of these.

    Thanks for the pointer to the obvious, I had seen that table, but assumed that because the AAW part worked and was supposed to be compatible.

    Re-reading the data in the document highlighted the default geometry expected by the RBL.

    Thanks for the input, will keep you posted on my progress.

  • 0 in reply to Brendan Cassidy
    Intellectual 335 points

    Here's a thought:

    The DAA part has a 4k page size, the RBL expects a 2K page with ECC being in the spare bytes.

    If we were to frig the writing of the UBL to the flash such that we forced a 2K page boundry.

    The RBL would then get the code from flash in 2K chunks.

    The big question is the ECC data, is it lierally the 2049th byte in the flash or is access to the spare bytes handled in a special way?

    Once the UBL is loaded, we can then revert to 4K page access.

    Does anyone know if this is worth persuing?

     

  • 0 in reply to Brendan Cassidy
    TI__Mastermind 37340 points

    RBL does handle spare bytes in a special manner and tries to do some error correction.  I have asked someone more familiar with the RBL to see if he can make any additional comments on this approach. 

  • 0 in reply to Juan Gonzales
    Intellectual 335 points

    Juan

    Thank you for your response.

    I looked at the code for the low lwvel driver and have seen the trick used to access the spare bytes on a page.  So it is now clear that my idea will not work.

    We have fitted an FAA part to the board and now have a booting system.

    Note that we have to pull GIO 0 high for nand boot to work, this is mentioned in other posts.

    So note to other users, the 29F16G08DAA part is NOT suitable for use with this processor.

    We were told by Micron and out distributor that these parts are compatible, which at a higher level is mostly correct.

    Anyone want to buy some NAND chips.....

    Thanks again for the response

    Brendan

  • 0 in reply to Brendan Cassidy
    TI__Mastermind 37340 points

    Brendan,

    Thank you for posting your findings back to the community; there are many customers having issues with DAA parts and it seems you have solved the mistery.  I am sure many users of this forum will benefit from your findings.