From mboxrd@z Thu Jan  1 00:00:00 1970
From: Eric Nelson <eric.nelson@boundarydevices.com>
Date: Mon, 18 Nov 2013 07:21:41 -0700
Subject: [U-Boot] [PATCH] i.MX6: nitrogen6x: update memory configuration
 files to use macros
In-Reply-To: <5289DEA1.3050402@denx.de>
References: <1384453840-11442-1-git-send-email-eric.nelson@boundarydevices.com>
	<201311142220.38057.marex@denx.de>
	<52854083.9040401@boundarydevices.com> <5289DEA1.3050402@denx.de>
Message-ID: <528A2275.2090605@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

On 11/18/2013 02:32 AM, Stefano Babic wrote:
> Hi Eric,
>
> On 14/11/2013 22:28, Eric Nelson wrote:
>>> I dont mind either way, but just an idea for discussion:
>>>
>>> What do you say to implementing the DRAM controller programming in
>>> SPL? That
>>> way, we can even do proper DRAM calibration on boot and other such
>>> nice things.
>>> And we'd also get rid of these static magic numbers all around.
>>>
>>
>> We can (and hopefully will very soon) implement some of the
>> configuration in C under SPL, but we can't (and shouldn't) get
>> rid of all of the magic numbers.
>>
>> Some of these numbers come from testing large numbers of devices
>> under a variety of temperature conditions. The best that the
>> automagic calibration facilities can do is set things up based
>> on nominal current conditions.
>>
>> That said, I'm sure we can cut down on the total number.
>>
>> My immediate goal is simply to set the stage for SPL and
>> a single binary.
>
> I agree on this roadmap. Of course, it will be very nice to allow
> runtime DDR calibration, but we can do this in a second step.
>

Thanks Stefano,

BTW, I did some additional work yesterday to complete the compilation
of a single SPL image with multiple DDR configurations.

A V2 of this patch will be needed.

Regards,


Eric