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

[Eric Nelson]

Hi Wolfgang,

On 03/10/2013 08:45 AM, Wolfgang Denk wrote:
> Dear Eric Nelson,
>
> In message <513CA21E.1040608 at boundarydevices.com> you wrote:
>>
>>> 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.
>
> Well, of course.  Different memory types / sizes will require
> different initialization.  But this you already have in place.  Now go
> the final step and auto-select the configuration instead of having the
> user (and manufacturer, and service, etc.) all suffer from the pain of
> always needing to know which exact configuration is needed on some
> board.
>

What we don't have is auto-detection and implementing this logic
requires that we execute code outside of DDR (i.e. through SPL
in internal RAM).

There's no question that a (more) universal binary would be helpful,
but in practice, checking the DDR parts isn't that different from
double-checking the CPU variant populated on a board.

Troy's attempt at handling the CPU portion of things was nacked,
which is what prompted me to this architecture of multiple CPU
configurations.

>> 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.
>
> This is wrong then and needs to be fixed.  get_ram_size() should be
> used before relocation into RAM.
>

Either you or I are missing something.

As it stands, there is no "execute before relocation into RAM".
The CPU's ROM boot loader processes the settings in the DCD
(essentially a set of register writes) and then copies the
U-Boot code into DDR for execution.

The register writes need to configure the DDR before the copy.

The only way to change this is to use a first level loader that
executes code within the internal RAM so the setup can be
conditional.

Are you saying that submissions of board files that don't
support SPL will be nacked, or only boards that want to
support multiple memory configurations without SPL?

Please advise,


Eric