From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] uboot-tools and uboot being separate
Date: Wed, 13 Feb 2013 21:20:02 +0100 [thread overview]
Message-ID: <20130213212002.25c976ca@skate> (raw)
In-Reply-To: <511BCBEE.5040704@siganos.org>
Dear Dimitrios Siganos,
On Wed, 13 Feb 2013 17:22:54 +0000, Dimitrios Siganos wrote:
> I have a query regarding uboot and uboot-tools. Currently they are
> separate packages.
>
> However, if I am building both the uboot bootloader and the uboot tools
> would it not be reasonable to expect to use the same sources for
> compiling both? At the moment, I am in a situation where I am building
> uboot with one set of files and uboot-tools (e.g. fw_printenv) with another.
>
> Is the recommended solution to point both uboot and uboot-tools to the
> same package version and apply the same patches to both? And have two
> parallel builds (uboot, uboot-tools) that should be identical?
No. You don't have to have identical uboot-tools and uboot. Basically
uboot-tools provide one tool to create U-Boot images (mkimage) and
tools to manipulate the U-Boot environment from Linux (fw_printenv,
fw_setenv). Those tools are backward compatible, and so you can
perfectly use the tools from U-Boot 2010.x with a running U-Boot 2012.x
or 2013.x.
There is really no need to have the same source code base for both
uboot and uboot-tools.
> I have also being thinking along these lines:
>
> 1) Edit the uboot-tools makefile to not use its own build directory but
> use uboot's build instead (silly idea idea I admit, but you never know...).
>
> 2) Edit the uboot package to optionally compile and install the
> uboot-tools as well (this seems to me to be the most logical way).
>
> Can I have your feedback?
Basically, no, there's a good reason why we wanted two separate
packages: we wanted to be able to build the U-Boot tools sometimes for
the host (mkimage), sometimes for the target (fw_printenv, fw_setenv).
The host-uboot-tools package is also used as a dependency of the Linux
kernel package, and it is much simpler to depend on host-uboot-tools
that to depend on the uboot package itself.
So really, the current way things are done for uboot vs. uboot-tools
has proven to work really well, and for now I don't see a compelling
reason to change that.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
next prev parent reply other threads:[~2013-02-13 20:20 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-13 17:22 [Buildroot] uboot-tools and uboot being separate Dimitrios Siganos
2013-02-13 20:20 ` Thomas Petazzoni [this message]
2013-02-13 22:57 ` Arnout Vandecappelle
2013-02-13 23:14 ` Thomas Petazzoni
2013-02-13 23:21 ` Arnout Vandecappelle
2013-02-14 2:15 ` Dimitrios Siganos
2013-02-14 7:57 ` Thomas Petazzoni
2013-02-14 16:18 ` Dimitrios Siganos
2013-02-14 0:09 ` Dimitrios Siganos
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=20130213212002.25c976ca@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.