[U-Boot] [PATCH V2] Add Boundary Devices Nitrogen6X boards

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

Hi Wolfgang,

On 03/10/2013 12:59 AM, Wolfgang Denk wrote:
> Dear Eric,
>
> In message <1362873856-14785-1-git-send-email-eric.nelson@boundarydevices.com> you wrote:
>>
>> +Eric Nelson <eric.nelson@boundarydevices.com>
>> +	nitrogen6dl		i.MX6DL		1GB
>> +	nitrogen6dl2g		i.MX6DL		2GB
>> +	nitrogen6q		i.MX6Q/6D	1GB
>> +	nitrogen6q2g    	i.MX6Q/6D	2GB
>> +	nitrogen6s		i.MX6S		512MB
>> +	nitrogen6s1g		i.MX6S		1GB
>
> Why do we need different configurations for example for nitrogen6dl
> and nitrogen6dl2g?  My understanding is that the difference is mainly
> the RAM size on the boards?
>

The difference is entirely the RAM size.

More specifically, it's the difference in the DDR density populated
on the board.

> In this case it should be possible to configure U-Boot for the maximum
> possible RAM size (2 GB here?), then have get_ram_size() detect the
> actual available amount, and then adjust settings as needed.
>

I'm not certain.

The JEDEC spec for the DDR devices we're using have quite different
settings in a couple of areas. In particular, the tRFC value is
quite different between densities.

They do appear to be minimums though, so we may be able to
configure for the slowest value, run get_ram_size(), then
reset that value once we determine whether the larger
or smaller parts were populated on the board.

> At least this is how U-Boot ius supposed to work.
>
> It is a maintenance nightmare if each and every configuration requires
> a separate U-Boot image.  We don't want to have this.
>
Well...

That throws a wrinkle into the whole patch set, since all of
this code presumes that we're running from DDR and other
calibration data was also gathered based on the actual parts
used.

If this is a hard requirement, I don't see a solution that
doesn't require the use of SPL, which will clearly take
a while.

Please advise,


Eric