Hi Eric,
On Wednesday, February 20, 2013 12:01:15 AM, Eric Nelson wrote:
Hi Benoît,
On 02/19/2013 03:31 PM, Benoît Thébaudeau wrote:
On Tuesday, February 19, 2013 10:53:48 PM, Eric Nelson wrote:
On 02/19/2013 01:52 PM, Benoît Thébaudeau wrote:
Hi Eric,
On Tuesday, February 19, 2013 9:20:48 PM, Eric Nelson wrote: [--snip--]
diff --git a/board/boundary/nitrogen6x/1066mhz_4x128mx16.cfg b/board/boundary/nitrogen6x/1066mhz_4x128mx16.cfg new file mode 100644 index 0000000..45b8879 --- /dev/null +++ b/board/boundary/nitrogen6x/1066mhz_4x128mx16.cfg
[--snip--]
+DATA 4, MX6_MMDC_P0_MDPDC, 0x00020036 +DATA 4, MX6_MMDC_P0_MDCFG0, 0x555B7974
^A?+DATA 4, MX6_MMDC_P0_MDCFG1, 0xDB538F64 +DATA 4, MX6_MMDC_P0_MDCFG2, 0x01FF00DB +DATA 4, MX6_MMDC_P0_MDRWD, 0x000026D2 +DATA 4, MX6_MMDC_P0_MDOR, 0x005B1023
^A?+DATA 4, MX6_MMDC_P0_MDOTC, 0x09444040 +DATA 4, MX6_MMDC_P0_MDPDC, 0x00025576 +DATA 4, MX6_MMDC_P0_MDASP, 0x00000027 +DATA 4, MX6_MMDC_P0_MDCTL, 0x831A0000 +DATA 4, MX6_MMDC_P0_MDSCR, 0x04088032 +DATA 4, MX6_MMDC_P0_MDSCR, 0x00008033 +DATA 4, MX6_MMDC_P0_MDSCR, 0x00428031 +DATA 4, MX6_MMDC_P0_MDSCR, 0x19308030 +DATA 4, MX6_MMDC_P0_MDSCR, 0x04008040 +DATA 4, MX6_MMDC_P0_MPZQHWCTRL, 0xA1390003 +DATA 4, MX6_MMDC_P1_MPZQHWCTRL, 0xA1390003 +DATA 4, MX6_MMDC_P0_MDREF, 0x00005800 +DATA 4, MX6_MMDC_P0_MPODTCTRL, 0x00022227 +DATA 4, MX6_MMDC_P1_MPODTCTRL, 0x00022227 +DATA 4, MX6_MMDC_P0_MPDGCTRL0, 0x42720306 +DATA 4, MX6_MMDC_P0_MPDGCTRL1, 0x026F0266 +DATA 4, MX6_MMDC_P1_MPDGCTRL0, 0x4273030A +DATA 4, MX6_MMDC_P1_MPDGCTRL1, 0x02740240 +DATA 4, MX6_MMDC_P0_MPRDDLCTL, 0x45393B3E +DATA 4, MX6_MMDC_P1_MPRDDLCTL, 0x403A3747 +DATA 4, MX6_MMDC_P0_MPWRDLCTL, 0x40434541 +DATA 4, MX6_MMDC_P1_MPWRDLCTL, 0x473E4A3B +DATA 4, MX6_MMDC_P0_MPWLDECTRL0, 0x0011000E +DATA 4, MX6_MMDC_P0_MPWLDECTRL1, 0x000E001B +DATA 4, MX6_MMDC_P1_MPWLDECTRL0, 0x00190015 +DATA 4, MX6_MMDC_P1_MPWLDECTRL1, 0x00070018 +DATA 4, MX6_MMDC_P0_MPMUR0, 0x00000800 +DATA 4, MX6_MMDC_P1_MPMUR0, 0x00000800 +DATA 4, MX6_MMDC_P0_MDSCR, 0x00000000 +DATA 4, MX6_MMDC_P0_MAPSR, 0x00011006
[--snip--]
tXS = tXPR = 170 ns -> 91 nCK -> 91 - 1 -> 0x5A.
Thanks Benoît,
I was going to bring this up in a separate thread.
While working through the details of our 800MHz variants (Solo, Dual-Lite), and x256mx16 variants, I re-worked these numbers and it seems that we have an off-by-one issue with those fields.
Probably because it has been missed that the bit-field value is the number of clock cycles minus 1.
Right. All of these fields are plus 1.
MDCFG0.tRFC MDCFG0.tXS MDOR.tXPR
Since they're all in the same units, the requirements are: MDCFG0.tXS >= MDCFG0.tRFC + 10nS and MDOR.tXPR >= MDCFG0.tRFC + 10nS
Since we operate at ~528MHz, each clock is less than 2 nS, and we need 6 more clocks for each.
According to the JEDEC spec and data sheets, both tXS and tXPR should be 10nS greater than tRFC.
Indeed, or more precisely, max(5 nCK, tRFC + 10 ns).
Yep. I shortened because nothing approaches 5nCK.
And note that this is the minimum spec, not the target.
Since the nominal clock for i.MX6 is 528MHz (1.89nS),
I used 532 MHz because this is a more standard value, and I found several close different values in the documentation, so in the doubt, I chose the worst case. With 528 MHz, the bit-field value would be 0x59.
Either way, we need 6 clocks to get > 10nS.
this should be a delta of 6 clocks, not 5.
Delta with what?
Sorry. I meant the Delta between MDCFG0.tRFC and the other two fields.
OK, now I see what you mean and how you got these values. But I disagree.
tXS(min) and tXPR(min) are defined by the JEDEC DDR3 specification as max(5 nCK, tRFC(min) + 10 ns). tRFC(min) is used here, not tRFC.
Moreover, tXS and tXPR are timings depending on internal features of the RAM, not on external operations from the host processor. It's not as if they were the result of the combination of two external operations. E.g., see tXS on figures 14, 15 and 62 in JESD79-3F.
Hence, tXS and tXPR should not be considered as tRFC(MMDC) + 10 ns, but really as tRFC(min) + 10 ns, i.e. a single 170 ns timing (for 2-Gib density) to be converted into a number of clock cycles.
I don't feel like it's possible to interpret the specification in a different way. But perhaps I'm wrong.
This change should apply to mx6q_4x_mt41j128.cfg as well.
Sure.
There are some other things in that file that should be fixed as well. The biggest among them is the settings for P1_MPWLDECTRL0/1.
Note that in this series, I have only reviewed the register values that changed in my series, and only for 1066mhz_4x128mx16.cfg.
Thanks for that. More eyeballs are better, especially when looking at bit-fields...
Also note that these relationships make a pretty good case for having expression support in these files.
It would be nice to express tXS and tXPR as tRFC+6.
But this is a topic for another day.
Yes, it would be easier to read if all bit-fields were #defined as expression building macros.
These settings are indicative of a fly-by topology, which isn't used on SABRE Lite, and I don't think is used on SABRE SD.
DATA 4 0x021b480c 0x00440044 DATA 4 0x021b4810 0x00440044
This was the primary thing that caused crashes under stress on SABRE Lite and led to our flurry of calibration tests as discussed here:
OK. I had not looked in detail into this.
Should we take this up in a separate thread? It seems un-related to our Nitrogen6X board.
As you prefer. This is related to this series, but a very specific subject per se.
I'll start a separate thread regarding the SABRE-Lite and SABRE SD memory settings.
OK.
Best regards, Benoît