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

[Eric Nelson <eric.nelson@boundarydevices.com>]

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>