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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox