• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 98 subscribers
  • Views 898 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.

AM3358: DDR3 boot issues

Michael Taliaferro
Prodigy 70 points

Part Number: AM3358

Hello,

We have custom boards based on the BeagleBone Black AM3358.  We appear to be experiencing DDR3 boot issues in that we never make it out of the Secondary Program Loader (SPL).  We are able to JTAG via an XDS200.  However, we will seemingly & randomly be vectoring to the following snippet of code in vectors.S:

We have found several other threads that are similar and have gone through the following suggested links:

After following the the AM335x DDR Calculation Tool, we input the changed numbers into our built SPL from the TI-SDK (04.02.00.09) u-boot in ddr_defs.h but this did not help.  Note: since we do not have an on-board I2C EEPROM to determine board id, we added our own board name to the source in u-Boot to insure we are getting the EMIF/DDR register values we want.  This was verified via JTAG by looking at the EMIF0 registers and confirming they match what we set them to.

Our Memory Part #: MT41K256M16TW-107

BBB Memory Part #:MT41K256M16HA-125

One big question we have is that we do not come up with the same calculated/generated numbers from the DDR Calculation Tool with what resides in the u-Boot source (ddr_defs.h) for the BBB???  This does not give us confidence that the numbers we input and generate in the DDR Calculation Tool are correct.  

Any further suggestions or ideas to help troubleshoot this would be greatly appreciated.

Thank you!

-Mike T

  • 0
    Prodigy 70 points
    I wanted to quickly followup on the root cause of our problem before anyone spent too much time looking into this issue.

    Turns out our issue was related to a board identification problem. On our custom board we did not populate the i2c eeprom part as in the BBB. When we were debugging the BBB we mistakenly believed the BBB was identifying itself as the ICE board (different Industrial Communication Engine am335x board). So, we set our board to look like the ICE board in the u-boot board.c. Once we changed our identification to match the BBB, which was/is AM335BNLT (for bone light?), our memory was fine and we are now booting past u-boot and into the kernel!

    Cheers,

    -Mike T
  • 0 in reply to Michael Taliaferro
    TI__Guru**** 393215 points
    Thanks for updating the thread.