• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 98 subscribers
  • Views 600 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.

DM355 Rev A support for MT29F2G08ABAEAWP NAND

Frank Hunleth
Prodigy 90 points

I am trying to find out whether the DM355 Rev A will support MT29F2G08ABAEAWP NAND. This product had previously used a MT29F2G08AADWP NAND Flash part, but that part is no longer available. I am currently unable to get the product to boot with the new part, but I am unsure why it does not boot. The Micron TN-29-52 migration guide indicates that the parts have the following differences:

  1. Requires 4-bit ECC instead of 1-bit ECC
  2. Requires a reset command be sent on power up
  3. Has a different Manufacturer ID. (The device Flash ID is still 0xDA)
The reset command requirement concerns me since I cannot tell from the DM355 specification whether RBL 1.1 sends this command. I do not believe that the other two changes are preventing UBL from being loaded and run. We have tried manually programming the new NAND part with an external programmer and by running a program on the DM355 to burn it (booted via UART) with no success.
Two questions: First, is it known whether the MT29F2G08AADWP part works with a DM355 Rev A? If it won't work, are there any options that don't involve respinning the PCB?
Thanks,
Frank 
  • 0
    Guru 31670 points

    Frank,

    I think the device should work without any issues. I have checked both the datasheets.

    1. 4-bit ecc can be supported in both devices (64 bytes spare area).

    2. The reset command (0xFF) is required for the MT29F2G08AADWP also.

    3. The manufacturer ID is same for both the devices. 0x2C. Only device ID is different, which shouldn't be a problem.

    How did you flash the NAND using external programmer? Is it using the same ECC algorithm that the bootrom needs? Is your programmer able to do a write and read back properly?

    Have you tried using the CCS application NANDWriter for flashing the image?

  • 0 in reply to Renjith Thomas
    Prodigy 90 points

    Thanks for the quick response. I had thought that the device should work too.

    Regarding the device ID, they both should be 0xDA according to the datasheet, right? I agree that I don't think that this is a problem, though, since 0xDA is in the RBL's supported device table.

    For the external programmer, the exact same ECC was used as before. No changes were made, but I can always double check.

    I am using the commandline utility sfh_DM35x.exe to program the Flash via the UART. I've tried a couple boards with the new Flash. The sfh_DM35x utility completes successfully for both like normal, but neither board shows the UBL or u-boot messages via the UART when they boot. If the new Flash part is unsoldered and an old Flash part put in its place, everything works perfectly.

    The only change is the Flash part. I made no changes to any other part of the programming process or anything else. If I need to change something, then that's my probably my issue, but I don't see anything to change. I'm at a loss as to why the new Flash part doesn't work, but I don't believe that it is due to a flaw in the programming process since I have been rechecking everything with the old Flash part. I've also tried multiple new parts.

    Could there be an issue with the DM355 Rev A that's causing the problem? This board uses the old version so we still have to use the legacy ECC layout.

    Thanks,
    Frank 

  • 0 in reply to Frank Hunleth
    Guru 31670 points

    Frank,

    There is one more thing. Have you checked the internal ECC support in the new NAND? You have to disable the internal ECC while writing and booting. I'm not sure whether internal ECC is enabled by default. 

    Another point to note is that ONFI support will not work if internal ECC is enabled. You can check both of these points. 

    What I'll suggest is to use the NANDwriter.out CCS tool to flash the binaries. You can get the source code for the same. You can also verify the data by modifying the code to read back and verify the contents. This will give you greater flexibility in debugging.

  • 0 in reply to Renjith Thomas
    Prodigy 90 points

    Renjith,

    We finally were able to make sure that internal ECC support was disabled with the external programmer. We're still seeing the same result. The Flash appears to program successfully, but the DM355 still will not boot from it. As far as we can tell, the Flash contents are exactly the same between the new and old Flash parts.

    Do you have any other ideas? I'm still worried that this may be a Rev A issue. Could you check on whether something could have been fixed between Rev A and whatever the latest DM355 revision is?

    Thanks,
    Frank 

  • 0 in reply to Frank Hunleth
    Guru 31670 points

    I am not sure about the Rev A and newer version difference. It could be possible. 

    How did you disable ECC support using external programmer? Is it done by sending SET_FEATURE command? If so, can you check whether this feature is set by default? Then there is a possibility that this is enabled during bootup and which can be cause the failure. Can you try reading back the data of the page-0 and see what are the values in spare area? Can you compare the same with the page-0 of the older NAND?

    If you have an oscilloscope or logic analyzer, can you try to see how many pages of data does the BOOT ROM reads? If its reading just one or max 4 pages, we can safely assume that there is some issue with the ECC logic itself.