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

Wolfgang Denk
2013-03-11T11:15:30Z

Dear Eric,

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.

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