[U-Boot] [PATCH 1/6] imx: mx6q DDR3 init: Fix tMRD

["Benoît Thébaudeau" <benoit.thebaudeau@advansee.com>]

Hi Eric,

On Friday, February 1, 2013 7:28:05 PM, Eric Nelson wrote:
> Hi Beno?t,
> 
> On 01/31/2013 04:25 PM, Beno?t Th?baudeau wrote:
> > On Friday, February 1, 2013 12:14:53 AM, Eric Nelson wrote:
> >> On 01/30/2013 02:19 PM, Beno?t Th?baudeau wrote:
> >>> MMDC1_MDCFG1.tMRD should be set to max(tMRD, tMOD) for DDR3.
> >>>
> >>> For all DDR3 speed bins:
> >>>     tMRD(min) = 4 nCK
> >>>     tMOD(min) = max(12 nCK, 15 ns)
> >>>
> >>> Hence, MMDC1_MDCFG1.tMRD should be set to max(12 nCK, 15 ns), which is 12
> >>> nCK
> >>> at 532 MHz, encoded as 0xB in the bit-field MMDC1_MDCFG1[8:5].
> >>>
> >>> Signed-off-by: Beno?t Th?baudeau <benoit.thebaudeau@advansee.com>
> >>
> >> Hi Beno?t,
> >>
> >> I've been able to confirm operation of this complete patch set
> >> on a SABRE Lite here, but only that (boots normally).
> >
> > Great.
> >
> >> I'll try to scare up a board we can place on an extended burn-in.
> >
> > That'd be good.
> >
> 
> I tested one board overnight running a Linux-based memory test
> and things worked perfectly.
> 
> I also tested using CONFIG_SYS_ALT_MEMTEST and measured the
> performance difference between
> 
> Nitrogen6x board (old memory timings):
> 	U-Boot > time mtest 10000000 10400000 0 10
> 	Testing 10000000 ... 10400000:
> 	Tested 16 iteration(s) with 0 errors.
> 
> 	time: 1 minutes, 11.311 seconds, 71311 ticks
> 
> SABRE Lite board (new memory timings):
> 	MX6QSABRELITE U-Boot > dcache off
> 	MX6QSABRELITE U-Boot > time mtest 10000000 10400000 0 10
> 	Testing 10000000 ... 10400000:
> 	Tested 16 iteration(s) with 0 errors.
> 
> 	time: 1 minutes, 10.143 seconds, 70143 ticks
> 
> I also tested with cache enabled and things worked perfectly.
> 
> >> What prompted you to walk the list? Was there a specific failure
> >> that this addressed?
> >
> > No specific failure. The only issue that I get from time to time is errors
> > in
> > the Linux SD driver, but this is probably unrelated.
> >
> > The only reason was that I was looking for possible better performance on
> > the
> > RAM side because I am working on very intensive RAM accessing applications.
> > So I
> > checked the init code to see if it was optimal, and I found these issues
> > besides
> > the small possible performance gain.
> >
> > So far, the default mtest passed on my board. The alternate mtest and more
> > Linux
> > stress tests might be interesting too.
> >
> For the series:
> 
> Tested-by: Eric Nelson <eric.nelson@boundarydevices.com>

Thank you very much for your thorough tests!

Best regards,
Beno?t