[U-Boot] [PATCH V2] Add Boundary Devices Nitrogen6X boards
Eric Nelson
eric.nelson at boundarydevices.com
Sun Mar 10 16:09:18 CET 2013
Hi Wolfgang,
On 03/10/2013 12:59 AM, Wolfgang Denk wrote:
> Dear Eric,
>
> In message <1362873856-14785-1-git-send-email-eric.nelson at boundarydevices.com> you wrote:
>>
>> +Eric Nelson <eric.nelson at 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
More information about the U-Boot
mailing list