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