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

[Wolfgang Denk <wd@denx.de>]

Dear Eric,

In message <513CB3F2.6080604@boundarydevices.com> you wrote:
>
> 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).

Correct.

> 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.

I'm not sure what you want to tell me here.  The thing is that you
don't want to maintain a dozen of different configurations, resulting
in a number of different, incompatible binary images, and you and
your users will always live in fear they might install the wrong image
and brick a system (OK, when you can boot from SDCard or similar
recovery will be less painful, but you still suffer from the
maintenance efforts).

> Troy's attempt at handling the CPU portion of things was nacked,

I don't remember this.  But I guess the reason was in the
implementation, not in the idea?

> which is what prompted me to this architecture of multiple CPU
> configurations.

But this doesn't scale.

> > 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.

In any case I'm missing time to provide longer explanations...

> 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.

I understand this, and I'm trying to point out that this is an
approach that is not useful in cases like yours where you have to
support a large number of different configurations.

I probably should point out that with such a setup you MUST NOT use
get_ram_size(), as it will write and modify the memory you are
executing from, so depending on a number of things it may happily
crash your system.  get_ram_size() has always to be used before
running any code from the RAM that is going to be tested.

> 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.

Correct.  In your situation this is the approach that shouldbe taken.

> 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 note that I did not NAK anything.  I'm just trying to point out
deficiencies (and in my opinion prety major deficiencies) in the
submitted code, and to provide suggestions how to fix these.  In my
experience, it is easier to get such fixes done before the code goes
into mainline - once it's in, both your own motivation and any backing
you can get from management levels for the required efforts for such a
rework will be in a much poorer state.

So I'm just aking suggestions.  Do you by chancew feel you heard me
use that sweet, innocent tone of voice before?  Well, then I can stop
here :-)

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
What is research but a blind date with knowledge?      -- Will Harvey