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.

Reset DDR3 subsystem and memory configuration autodetection

We need to implement SDRAM autodetection in U-Boot. Assuming a list of supported memory configurations is available, the algorithm should look like this:

1. reset all the DDR3 subsystem (EMIF controller, DDR3 memory etc.)

2. initialize EMIF controller, DDR3 memory, PHY

3. test memory

4. if test passed exit else move to next configuration in the list

5. go to step 1

It is not clear how to perform step 1. Is it availbale a code snippet showing this?

Thank you.

  • Llandre,

    Why are you trying this? What is your use case? 

    You can reset the DDR controller by turning the controller OFF and ON from the PRCM module.

  • Renjith Thomas said:

    Why are you trying this?

    Because I suspect it is not safe changing EMIF/DDR3 configuration without resetting the whole subsystem.

    Renjith Thomas said:

    What is your use case? 

    As described before, I'd like to have one U-Boot SPL binary image for all supported DDR3 memories. So I need ti implement an autodetection algorithm to figure out actual configuration.

    Renjith Thomas said:

    You can reset the DDR controller by turning the controller OFF and ON from the PRCM module.

    I think you are referring to bits MODULEMODE of register CM_PER_EMIF_CLKCTRL, are not you?

    Regards,

    llandre

  • llandre,

    I meant "why are you trying dynamic detection of DDR by trial and error method". I think it will waste a lot of time during boot, as the supported DDR list grows. 

    Generally in PC they use a protocol called "serial presence detect" where the configuration of the DIMM module will be stored in an I2C EEPROM which is also part of the module. By reading the info, you can get the parameters of the memory attached. 

    http://www.softnology.biz/pdf/SPDSDRAM1.2a.pdf

  • The solution you suggest is undoubtedly a good option to consider. However, since EEPROM might not be populated in our product (it is a mount option that the customer may choose to drop in order to reduce BOM cost), I'd like to implement a solution that works in any case.

  • What is the current time taken for each of the algorithm to run?

    How many different DDR types are you planning to support? If there are not many types, then you can give the input using some BTMODE pin configuration or inputting a HIGH/LOW combination on few GPIOs depending on the number. I guess that will be a better way out.

  • Renjith Thomas said:

    What is the current time taken for each of the algorithm to run?

    I don't have precise figures yet, however I think it does not affect overall boot time significantly.

    Renjith Thomas said:

    How many different DDR types are you planning to support?

    At this time, 3 different models need to be supported in order to have 128 MByte, 256 MByte and 512 MByte options. However I'm afraid chips from different vendors will be added in the future.

    Renjith Thomas said:

    If there are not many types, then you can give the input using some BTMODE pin configuration or inputting a HIGH/LOW combination on few GPIOs depending on the number. I guess that will be a better way out.

    I'll consider these options too.

    Regards,

    llandre