From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] What's the buildroot attitude to u-boot building?
Date: Sat, 22 Feb 2014 00:13:09 +0100 [thread overview]
Message-ID: <20140222001309.143e02f7@skate> (raw)
In-Reply-To: <CAE21AQqMQmKKL0=Q55P2zQhV8+iBdpX416xK+SgZd3+ONi8Mgg@mail.gmail.com>
Dear Charles Manning,
On Fri, 21 Feb 2014 14:53:06 +1300, Charles Manning wrote:
> I am having a look at adding some stuff to generate a signed pre-loader for
> the SoCFPGA architecture.
As you can see, some people are already working on supporting the
SoCKit platform, which uses the SoCFPGA architecture.
> There seem to be two options to doing this:
> 1) Have it fall out of building u-boot (probably the best option once the
> patches I'm pushing into u-vboot have settled down)
> 2) Make an independent build like xloader (probably a better interum
> solution), since for now the SocFPGA preloader building is still somewhat
> haphazard and needs a magic version of u-boot.
I'm not sure to understand here. A defconfig for a SoCFPGA platform was
submitted today, and a single build of U-Boot produces both the
pre-loader and the real U-Boot image.
> For instance, why are there things like BR2_TARGET_UBOOT_ETHADDR?
> Overriding elements of the u-boot config header by patching over them from
> a complete different config system (buildroot) seems to be asking for
> trouble.
Why is this asking for trouble?
Anyway, I agree that these tuning options for U-Boot are a bit weird.
Since in U-Boot there is no separation between the configuration and
the definition of the hardware platform, most people should patch
U-Boot if they want to change their configuration.
Options such as BR2_TARGET_UBOOT_ETHADDR have been here for many many
years, and we have simply kept them over time. It was added back in
June 2007.
While I don't find it particularly pretty, I kind of fail to see what
troubles you think it could cause. Could you give more details about
this?
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
next prev parent reply other threads:[~2014-02-21 23:13 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-21 1:53 [Buildroot] What's the buildroot attitude to u-boot building? Charles Manning
2014-02-21 14:49 ` Grant Edwards
2014-02-21 23:04 ` Thomas Petazzoni
2014-02-22 20:45 ` Grant Edwards
2014-02-23 0:05 ` Mike Zick
2014-02-23 10:18 ` Thomas Petazzoni
2014-02-23 18:50 ` Grant Edwards
2014-02-23 19:56 ` Mike Zick
2014-02-21 23:13 ` Thomas Petazzoni [this message]
2014-02-24 1:33 ` Charles Manning
2014-02-24 8:37 ` Peter Korsgaard
2014-03-18 5:21 ` Thomas Petazzoni
2014-03-18 8:05 ` Peter Korsgaard
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=20140222001309.143e02f7@skate \
--to=thomas.petazzoni@free-electrons.com \
--cc=buildroot@busybox.net \
/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.