On Mi, 2017-09-13 at 08:40 +0200, Matthijs van Duin wrote:
Hi,
Not quite... a DLL (Delay Locked Loop) is a way to create fine- grained timing from a reference clock signal. The DLL inside the memory locks onto the bus clock (ck-nck) provided by the memory controller and is used to make its outputs line up right to the bus clock. Specifically, this affects the alignment (relative to bus clock) of:
- memory's dq (data) and dqs outputs (data clock) during reads;
- changes to its termination resistors in response to the ODT signal
(synchronous ODT) and/or during writes (dynamic ODT).
When the memory DLL is on, the alignment of these relative to the bus clock is tightly specified by jedec. When the DLL is off, they no longer are.
For some reason JEDEC also forbids use of ODT whatsoever in DLL-off mode. I have no idea why. I would have expected that ODT in DLL-off mode simply follows the "asynchronous ODT" rules which also apply when the memory is in self-refresh (at which time the DLL is implicitly disabled).
Note btw that although JEDEC specifies various aspects of DLL-off mode, is entirely optional for memory to support DLL-off mode in the first place.
Thanks for the detailed explanation. Hmm. But then it doesn't really sound like we have noise-issues - these should also have an effect when the internal timing is disabled, as both relay on the same reference clock.
What frequency is tCKDLL_OFF in our setup?
JEDEC specifies tCK(DLL_OFF)(min) to be 8ns, i.e. the max clock frequency specified for DLL-off mode is 125 MHz.
And what is it when it's switched on?
We're running the memory bus at 532 MHz, i.e. tCK = 1.88 ns.
Ah - so the memory is running faster when DLL is enabled?
Running with DLL off at that frequency is therefore waay outside JEDEC-specified territory.
Well, yes and no. JEDEC specifies in the documentation that the timings are different when DLL is off and also specifies that DLL should always been on.
So the timings specified by JEDEC are DLL On timings.
--> So CL and CWL are the same and different to the setup in DLL
on?
Tony only toggled the DLL-off bit, he didn't change any timings. Since the memory is still being run at high frequency, using the normal CL and CWL values is the right thing to do.
Well, now I'm confused... I thought with DLL off it's running with 125MHz and with DLL on it's 532MHz?
Or are we actually running with 532MHz and DLL Off?
- DLL off also disables ODT.
There's nothing saying it disables ODT. Rather, JEDEC says you're supposed to refrain from using ODT in DLL-off mode. Using it anyway would be undefined behaviour, but my suspicion would be that it behaves like asynchronous ODT in practice.
- One thing that still puzzles me: According to the information I
found, the timings need to be setup SPECIFICALLY for the memory chips you use. Even the JEDEC standard mentions sometimes that the specific timings need to be taken from the datasheet of the manufacturer.
Where exactly? I'm pretty sure this isn't true, and it would completely defeat the purpose of standardized speed bins.
Well, the TI information I sent two weeks ago says that you need to change the EMIF depending on the exact specifications found in the datasheet of the memory chip you use.
The JEDEC Standard documentation says in chapter 3.4.2:
"The mode register MR0 stores the data for controlling various operating modes of DDR3 SDRAM. It controls burst length, read burst type, CAS latency, test mode, DLL reset, WR and DLL control for precharge Power-Down, which include various vendor specific options to make DDR3 SDRAM useful for various applications."
That also sounds like they have some standards but fine-tuning settings need to be gotten from the vendors datasheet. I'm not sure WHAT they mean though.
I just checked: There ARE standard speed bins in the JEDEC document as well - but they are identical to the speed bins listed in the Samsung memory chip.
However, JEDEC has multiple timings for DDR3-1066 (E, F, G, F(Optional), and so on), which are all different.
The Samsung datasheet only has ONE DDR3-1066, which seems to be DDR3- 1066F.
Are those the timings we're using? Or could it be we're using the ones from DDR3-1066E or G, for example?
Are we sure there's NOTHING that simply powers a part of the Pyra for 10 seconds after it has been switched off?
Pretty sure yes.
Hm, but the battery chip ALSO seems to remember some stuff. You can't boot with AC Adaptor only and without battery for the first time, but it seems it works when you have at least booted once with battery.
I will test this further, but that's what aTc mentioned. And I think you can even fully remove the power for a while and it keeps that setting for a few seconds.
Could it be the PALMAS (or we?) do have some supercap included that keeps the settings for a few settings (so you can replace the battery, for example)?
According to the OMAP5 document, hardware levelling must be triggered by the software, so what happens if we never trigger hardware levelling?
It would use the reset default values and fail spectacularly. Using software-provided leveling values should be possible though. Here's what I said about this on irc a few days ago:
<@zmatt> notaz/tmlind: btw, in case you want to try manual leveling... I think the procedure is: <@zmatt> 1. set the appropriate values in ext phy control 2-13 ( https://goo.gl/bDV8js ) instead of the seed values being written currently. you should be able to use the values obtained from a successful hw leveling. <@zmatt> 2. skip the hw leveling procedure (obviously) <@zmatt> and the step 3 that I was missing when I tried this a while back: <@zmatt> 3. reset the phy to latch the config registers into the phy. This is done by setting bit 10 of the "iodft_tlgc" register at offset 0x60. You can find it in the dra7 trm, it's omitted from the omap5 trm.
Ah, okay. Hs anyone already tried that?