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

[Wolfgang Denk]

Dear Eric,

In message <513D18F3.2010802 at 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.

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

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
I program, therefore I am.