From: Eric Nelson <eric.nelson@boundarydevices.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH V2] Add Boundary Devices Nitrogen6X boards
Date: Mon, 11 Mar 2013 06:37:38 -0700 [thread overview]
Message-ID: <513DDE22.4090605@boundarydevices.com> (raw)
In-Reply-To: <20130311111530.B709220013A@gemini.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
next prev parent reply other threads:[~2013-03-11 13:37 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-10 0:04 [U-Boot] [PATCH V2] Add Boundary Devices Nitrogen6X boards Eric Nelson
2013-03-10 0:49 ` Troy Kisky
2013-03-10 8:02 ` Wolfgang Denk
2013-03-10 14:15 ` Eric Nelson
2013-03-10 7:59 ` Wolfgang Denk
2013-03-10 15:09 ` Eric Nelson
2013-03-10 15:45 ` Wolfgang Denk
2013-03-10 16:25 ` Eric Nelson
2013-03-10 22:03 ` Wolfgang Denk
2013-03-10 23:36 ` Eric Nelson
2013-03-11 11:15 ` Wolfgang Denk
2013-03-11 12:04 ` Stefano Babic
2013-03-11 13:18 ` Fabio Estevam
2013-03-11 13:44 ` Stefano Babic
2013-03-11 13:54 ` Fabio Estevam
2013-03-11 14:02 ` Eric Nelson
2013-03-11 14:30 ` Stefano Babic
2013-03-11 14:39 ` Tom Rini
2013-03-11 13:37 ` Eric Nelson [this message]
2013-03-11 16:48 ` Wolfgang Denk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=513DDE22.4090605@boundarydevices.com \
--to=eric.nelson@boundarydevices.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.