Hi Eric, On Wednesday, February 20, 2013 1:05:04 PM, Benoît Thébaudeau wrote: > 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.
I don't know if that's clear enough, but here I mean that tXS and tXPR are intrinsic RAM timings, and that there is no way tRFC(MMDC) can interfere with either tXS/XPR(DDR3) or tXS/XPR(MMDC), so there is no reason to take tRFC(MMDC) into account to determine tXS or tXPR. Only tRFC(min) should be used here. > 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. Best regards, Benoît _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
