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

[Stefano Babic <sbabic@denx.de>]

On 11/03/2013 12:15, Wolfgang Denk wrote:
> Dear Eric,
> 

Hi Wolfgang, hi Eric,

sorry to jump late in the discussion.

> In message <513D18F3.2010802@boundarydevices.com> you wrote:
>>
>> I understand the point, but think the pain is manageable and
>> mostly ours.
> 
> When I say it doesn't scale, I'm not only thinking about yourown
> efforts, and your customers.
> 
> I also think about things like the increase of build and test time for
> _everybody_ who performs tests on U-Boot - instead of one board, we
> now have to build - how many? 6? - configurations.  If we allow this
> now, others will copy this approach (and we cannot really reject it
> then). I really would like to avoid setting such a precedent here.
> 
>> While we'd like to snap our fingers and have a "does everything
>> right" boot loader, that will take a while ;)
> 
> I'm well aware of this.
> 
>> 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.
> 
> This may or mayu not make sense.  It certainly depends on the specific
> requirements of the SoC / architecture in question.
> 
>> 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.
> 
> I agree that supporting multiple SoCs indeed adds complexity.
> However, supporting different memory sizes has been supported by
> U-Boot (and actually already by PPCBoot) since day one, so this is not
> really considered rocket science.  Also, SPL is not exactly new
> technology any more.

Firstly I sumarize something from your previous posting in this thread.
As remark about first Wolfgangs's post, there is an issue that does not
allow to use get_ram_size() to tune the RAM settings, as we are usual to
do with other architectures. In fact, the processor itself reads these
headers (in i.MX jargon the DCD tables) at the beginning of the image
and sets itself the RAM controller, copying at the end u-boot from
storage to RAM - without any intervention by U-Boot code. When
get_ram_size() is called, the code already runs from RAM - this is has
nothing to do with relocation.

This is why Eric pushes several configuration files, whose changes are
due to the different RAM chips.

The way Troy / Eric tried to manage this was to add the "plugin"
facility to the imximage. However, as you have already read in the
thread, this adds not only complexity, but it is also *very* special for
the i.MX, and cannot be reused at all for other processors. I do not
like that i.MX becomes an island in the U-Boot world and I have
discouraged the usage of i.MX plugins vs SPL.

The roadmap for me is that this complexity can be easy managed (and also
having different SOCs with a single image, if desired) using SPL. This
is now a well known technology and can add some important features
borrowed by other SOCs (falcon mode, booting from different storages,
etc.).

This at the end to explain Wolfgang why I was against adding "plugins"
when the RFC patchset was set - without you have to read the whole
discussion, that was pretty long ;-).


> 
>> 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.
> 
> It does.  But source base is one thing.  Havnig to deal with a large
> number of configurations to build and test is another one, and here
> you put additional burdon on a large number of prople.
> 
>> Our hope in getting this main-lined was that other upcoming
>> Solo and Dual-Lite platforms could share some of the bits.
> 
> Understood and appreciated.  But I also see this ias a strong reason
> to come up with a clean design, and not create bad examples which
> others without doubt will interpret as persuasive precedent.
> 
>> I'm sorry if I sound frustrated.
> 
> You don't, and if you did I could very well understand how you feel.
> 
> I hope you can understand my position, too.
> 
>> This is feedback I'd hoped to get to the RFC version back in January,
> 
> Sorry I missed it then.
> 
>> 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.
> 
> I would also apprciate if others could comment - Stefano? Albert? Tom?
> 

As set previously, my position is, since RFC patches were pushed in
January, that some kind of complexity can be well managed with SPL
instead of with very SOC specific code. However, in the meantime I said
explicitely that I was not against the current patchset in the form Eric
posted now. I understand this can be seen as a temporary solution, but
let's increase the number of users using these boards, and taking into
account that some other pending patches can help to switch to SPL.

In fact, there also other patchsets that I hope will be merged soon and
will make the swicth to SPL easier - I mean Benoit's patches regarding
NAND on MX5 and dropping old spl code from some boards.

Best regards,
Stefano Babic


-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================