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

AM3352: DDR test from U-boot

Moses Christopher Bollavarapu
Intellectual 980 points
Part Number: AM3352

Hi,

I am using a custom AM3352 based board and would like to perform DRAM tests in u-boot stage, the idea is to verify if the Hardware connections are proper.

Currently, I have enabled mtest command in u-boot and tried to execute on parts of memory and it works fine.
But, what I want to know is, how do we come to know that this is the minimum amount of DRAM size that we need to test in order to confirm that the DRAM is soldered properly on the PCB and connected to the processor ?

Currently, I've been testing the first 16MiB of 256MiB DRAM, it works fine and runs multiple iterations. I've also tried providing certain patterns and number of iterations and verified using memory display command.

Any hints on this, is highly appreciated. Thank You :-)

  • 0
    TI__Guru 69652 points

    Moses Christopher said:
    But, what I want to know is, how do we come to know that this is the minimum amount of DRAM size that we need to test in order to confirm that the DRAM is soldered properly on the PCB and connected to the processor ?

    In theory, you would want to make sure to exercise all data, address (row and bank address), and control/handshake lines which yes you may be able to do by limiting your testing to certain addresses, perhaps covering the entire memory with a specific stride.

    However for simplicity and practical reasons I would recommend testing the entire memory, this way you avoid that any assumptions made regarding connections, address mapping, device architecture/caches, etc. (which any of those could potentially be invalid) invalidate your test result. Furthermore, you probably not only want to check for connectivity, but also for shorts between signals, and other faults.

    At the end of the day you need the entire memory to work in your application also, so why not test it like this? If it is that it takes too long, maybe one way could be to simply reduce the number of iterations you run?

    Regards, Andreas

  • 0 in reply to Andreas Dannenberg
    Intellectual 980 points

    Hi Andreas,

    Thanks for the detailed clarification.