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

[Eric Nelson]

Thanks Wolfgang,

On 03/10/2013 03:03 PM, Wolfgang Denk wrote:
> Dear Eric,
>
> In message <513CB3F2.6080604 at 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).
>

I understand the point, but think the pain is manageable and
mostly ours.

While we'd like to snap our fingers and have a "does everything
right" boot loader, that will take a while ;)

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

Well, at least the use of i.MX plugins to do the job. The general
response was something along the lines of:

	**if** we want to support multiple CPU variants in
	a single binary, then it should be done with SPL.

While I believe this can be done, it hasn't yet, and will
likely require some of the same changes to allow sets of
register values to be expressed as data instead of code.

It appeared that the NAK stemmed from a desire for less
complexity.

This patch set is the simplest implementation we can think
of that still allows a single board file and directory to
support multiple CPU options and memory configurations.

>> which is what prompted me to this architecture of multiple CPU
>> configurations.
>
> But this doesn't scale.
>

It scales better than where we were: having a single blob of
hex data in board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg.

This step has broken things up into parts so that we
**can** express multiple memory configurations within
a single board directory, and I hope it moves the ball
forward a step or two.

Our hope in getting this main-lined was that other upcoming
Solo and Dual-Lite platforms could share some of the bits.

>>> 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 addition of get_ram_size() was in response to your
comment about the Wandboard submission, which does build upon
the .cfg file structure of the nitrogen6x.

I guess that's what I get for adding it on the day of submission:
it looked harmless though not very useful.

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

I guess I misunderstood then.

> 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 :-)
>

I'm sorry if I sound frustrated.

This is feedback I'd hoped to get to the RFC version back in January,
and it will be some time before we're in a position to add SPL into the mix.

I'll wait for further feedback before determining if a V3 patch
is warranted.

Regards,


Eric