Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Arnout Vandecappelle <arnout@mind.be>
To: buildroot@busybox.net
Subject: [Buildroot] uboot-tools and uboot being separate
Date: Wed, 13 Feb 2013 23:57:03 +0100	[thread overview]
Message-ID: <511C1A3F.2080804@mind.be> (raw)
In-Reply-To: <20130213212002.25c976ca@skate>

On 13/02/13 21:20, Thomas Petazzoni wrote:
> 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?

  I've had the same issue once: a patch to add some functionality to 
mkimage that I needed both on the host and on the target.

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

  Unless some feature has been added or removed.

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

  This will be the way to go - and much easier as soon as the out-of-tree 
build is there. But it still requires more infrastructural change, since 
currently there is no way to specify that a package doesn't have a source 
itself, but the source comes from another package.

  There are actually a few other packages out there that have or could 
have the same "shared source, separate build" issue: kernel-headers, 
udev, perf.


  Regards,
  Arnout

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


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

  reply	other threads:[~2013-02-13 22:57 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
2013-02-13 22:57   ` Arnout Vandecappelle [this message]
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=511C1A3F.2080804@mind.be \
    --to=arnout@mind.be \
    --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