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.
Hi
We recently updated the DDR3 RAM on our design from ISSI model IS43TR16128A to model IS43TR16128C because of obsolescence issues (they have the same specifications).
The DDR3 runs at 1333MHz and the old model "A" had no problems to correctly initialize.
The new model "C" however has a problem to re-configure the DDR3 memory after a warm restart. The first time the memory is configured it works fine. (It also works fine if it gets configured via a GEL file from CCS).
On a warm restart we also have active the PLL_REINIT_WORKAROUND in the IBL. In this scenario the PLLs get reconfigured before the DDR controller is reconfigured.
In this scenario the partial automatic leveling fails and the DDR_STATUS register returns 0x40000064, which indicates that the read DQS gate training and read data eye training timed out.
When the DDR3 PLL is lowered to operate at 1066MHz, the model "C" also start to work correctly without any errors.
We would like the DDR3 RAM to reliably operate at 1333MHz and not need to fall back to 1066MHz.
Do you any have advice for where to look for a solution?
Should we look at the leveling initialization values or is there some issue with re-configuring the PLLs before doing the DDR3 configuration?
Is there a method to hard reset the DDR3 memory controller and DDR3 RAM from software so that after the PLLs are configured the memory controller can be completely restarted?
Leon,
I cannot think of a cause for the behavior that you are seeing. I can only speculate that their is some marginality in your design that has now appeared when using the faster devices. I recommend that you first recheck the design validation steps that would have been done when the board design was first commissioned with DDR3. The steps are summarized on the following Wiki page:
Tom
Hi
Thanks for the reply.
We already did recheck the validation steps, but it didn't improve operation.
We will use the fallback option to 1066MHz for now.
Regards,
Leon
Leon,
Please post your completed PHY_CALC and REG_CALC worksheets for review. Also, please post your report showing that the length matching rules were met.
Tom
Leon,
I have not seen a response for 2 weeks. Can I close this ticket?
Tom
Hi
Sorry for not responding earlier, everyone here is still on leave at the moment.
I hope to get the information you require during next week.
Regards,
Leon
Hi Tom
Please find attached the two worksheets for 667 MHz.
Some of the DQS lines are marginal, but what does not make sense to us is the fact that:
- The DDR3 configures correctly the the GEL file @ 667 MHz
- The DDR3 configures correctly after power-on @ 667 MHz
Are we missing something?
Please advise
Kind regards
Piet
Piet,
I cannot draw conclusions from just the REG_CALC sheets. I need to receive the length matching report and the PHY CALC sheets as well.
Tom
Piet,
Sorry, I did not see the PHY_CALC sheet previously. I believe that the DQS lengths have been recorded wrong. They are not normally the same length as the fly-by nets (length matched to the clock pair). The DQS pairs and their associated byte group lengths are normally all of similar length. Please provide a length matching report for comparison.
Tom
Piet,
This thread has not had a response for 2 weeks. Is this still open?
Tom
Hi Tom
We noted something interesting.
The DDR initialization error only occurs when rebooting in Linux.
When we reboot from our Board Management then it does not happen.
See Linux reboot code below. Any ideas or something missing in this reboot sequence ?
Kind regards
Piet
void keystone_reset(void)
/* Only master core is allowed to reboot the board */
if (get_coreid() == get_master_coreid()) {
u32 val;
val = pll1_get_reg(RSTCTRL);
val &= 0xffff0000;
val |= 0x5a69;
pll1_set_reg(RSTCTRL, val);
val = pll1_get_reg(RSTCTRL);
val &= 0xfffe0000;
pll1_set_reg(RSTCTRL, val);
}
machine_halt();
Piet,
Please confirm that the same PLL and DDR configuration occurs whether executed from UBOOT or Linux.
Tom
Piet,
I contacted our linux support team regarding your question. We do not recognize this code in a supported code-base for C6678. Is this part of an older vertical market product line? If so, you will need to work through your FAE to get support from that team. Alternately, if this is a new product, you should be using ProcSDK.
Below is comment from the linux team where they researched the function keystone_reset():
I actually dug in the code and found ddr3 was initialized at 1333 using an array of fixed M/D/OD values, not from register read. I didn’t see the M/D/OD in DDR3PLLCTL0 got configured by IBL which I think it should. Theoretically, DDR3 should be configured by U-boot, or IBL in linux-c6x case, and stays as what was configured when linux comes up. I don’t think Linux needs to reprogram it, but not sure in DSP linux case. I did see MAINPLL got reprogrammed in linux-c6x kernel, but not sure if DDR3 should need to be done as well.
Tom
Piet,
Independent of Linux, repeated configuration of the DDR interface should be robust. You should be able to update your GEL file with the timing parameters and other DDR configuration parameters. You should then be able to prove that repeated configurations result in a functional DDR3 interface.
Tom
Hi,
To clarify, this is not for an ARM+C6678 board, this is for a standalone C6678 that runs ucLinux as from the old "abandoned" http://linux-c6x.org/.
There is no U-boot, only an IBL that directly boots the ucLinux image from flash.
The ucLinux doesn't reconfigure the DDR3 controller, it completely depends on the IBL to set it up correctly beforehand.
Leon
Leon,
I was correct in my assessment that this was part of a special software release that was from a specific team. If you need direct support of this software then you will need to work through an FAE.
Regarding use of IBL code to configure the DDR controller on C6678, same exists in the ProcSDK but not with Linux. Please refer to these examples. Similarly, my previous recommendation for testing repeated re-configurations using the GEL is a valid means to prove this is valid and to debug the code.
Tom