From mboxrd@z Thu Jan  1 00:00:00 1970
From: Eric Nelson <eric.nelson@boundarydevices.com>
Date: Mon, 11 Mar 2013 06:37:38 -0700
Subject: [U-Boot] [PATCH V2] Add Boundary Devices Nitrogen6X boards
In-Reply-To: <20130311111530.B709220013A@gemini.denx.de>
References: <1362873856-14785-1-git-send-email-eric.nelson@boundarydevices.com>
	<20130310075948.035BA200642@gemini.denx.de>
	<513CA21E.1040608@boundarydevices.com>
	<20130310154511.C066D2010CD@gemini.denx.de>
	<513CB3F2.6080604@boundarydevices.com>
	<20130310220352.ED5432010CD@gemini.denx.de>
	<513D18F3.2010802@boundarydevices.com>
	<20130311111530.B709220013A@gemini.denx.de>
Message-ID: <513DDE22.4090605@boundarydevices.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Thanks Wolfgang,

On 03/11/2013 04:15 AM, Wolfgang Denk wrote:
> 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.
>

Would it help if we restrict the number of boards directly in
boards.cfg?

We can easily have local patches for the non-standard memory
configurations in our repository, and this will at least allow
build tests to include the processor variants.

<snip>

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

Our hope is that the things we're adding are useful, and not
a burden.

We'll be happy to pursue the SPL route, but this won't be
something that we can devote cycles to in the next few weeks.

Regards,


Eric