From mboxrd@z Thu Jan  1 00:00:00 1970
From: Eric Nelson <eric.nelson@boundarydevices.com>
Date: Wed, 20 Feb 2013 07:20:19 -0700
Subject: [U-Boot] Memory timings for SABRE Lite/SABRE SD
Message-ID: <5124DBA3.7050504@boundarydevices.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Hi all,

While investigating some CPU Frequency scaling issues on the
latest i.MX6DQ silicon, we discovered that the memory timings
in mx6q_4x_mt41j128.cfg.

In particular, these values of MX6_MMDC_Px_MPWLDECTRLy are wrong
for SABRE Lite and probably SABRE SD.

DATA 4 0x021b080c 0x001F001F
DATA 4 0x021b0810 0x001F001F

DATA 4 0x021b480c 0x00440044
DATA 4 0x021b4810 0x00440044

These are write-leveling delay lines, and our calibration showed
measured values in the range of 0x7..0x1b for these fields.

The 0x44 values are shown in AN4467.pdf as an example of
what might be used in a fly-by topology.

	http://cache.freescale.com/files/32bit/doc/app_note/AN4467.pdf

The SABRE Lite design doesn't use fly-by, and I suspect
that SABRE SD doesn't either.

When adding Nitrogen6x support, we went through an extensive
calibration process on a large set of boards, but the values
above showed the greatest variance from mx6q_4x_mt41j128.cfg.

Also note that in the 2009.08 code base, these values are
set to 0x1f for SABRE SD, which appears not to be a measured
delay, but is much more sane.
	http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git/tree/board/freescale/mx6q_sabresd/flash_header.S?h=imx_v2009.08_1.1.0#n248

In that code base, SABRE Lite appears wrong:
	http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git/tree/board/freescale/mx6q_sabrelite/flash_header.S?h=imx_v2009.08_1.1.0#n161

Regards,


Eric