From: Anders Darander <anders@chargestorm.se>
To: Otavio Salvador <otavio@ossystems.com.br>
Cc: Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: u-boot-fw-utils -> u-boot-fw-utils-cross
Date: Fri, 13 Sep 2013 21:29:34 +0200 [thread overview]
Message-ID: <20130913192934.GA5469@ad.chargestorm.se> (raw)
In-Reply-To: <CAP9ODKpaEDmOXK6b1KLvwOv6FYXGJ1nfZ3D4MGUa3qo-cagfyw@mail.gmail.com>
* Otavio Salvador <otavio@ossystems.com.br> [130913 21:16]:
> On Fri, Sep 13, 2013 at 3:55 PM, Anders Darander <anders@chargestorm.se> wrote:
> > Otavio Salvador <otavio@ossystems.com.br> wrote:
> >>On Fri, Sep 13, 2013 at 4:56 AM, Anders Darander
> >><anders@chargestorm.se> wrote:
> >>> As I've started to bring our internal distro and machines up to the
> >>> lates oe-core, I've got some issues with the u-boot-fw-utils to
> >>> u-boot-fw-utils-cross transition.
> >>Right.
> >>> In my old branch, I used u-boot-fw-utils_2011.06. This used to
> >>compile
> >>> and package fw_printenv(setenv) just fine.
> >>> In the new, u-boot-fw-utils-cross_2013.07.bb, fw_printenv is now
> >>built
> >>> using HOSTCC instead of the cross-compiler. The old recipe used to
> >>> include:
> >>> EXTRA_OEMAKE = 'HOSTCC="${CC}"'
> >>> as u-boot defaults to build everything under tools/ using HOSTC.
> >>Yes; this is intended to be used in the host. I can add support for
> >>use in target as well (or help you to do it).
> > Sorry that I didn't see this during the review of your patch that made this change. If u-boot-fw-utils-cross of intended to be used on the host, why did you then replace the old u-boot-fw-utils with this recipe?
> > The old u-boot-fw-utils were to create fw_printenv to be used on the _target_ not on the host. Unfortunately, I don't think this was ever mentioned during the patch review...
> Yes but this was a /bug/ in the build system. As it got HOSTCC so it
> was indeed to be used as /host/ not target.
Well, the fw_printenv is indeed mainly intended to be used on target...
Why the U-Boot maintainers insist on defaulting to use HOSTCC is a
completely different matter. I know that there's been quite a few mail
threads about that (and I've personally argued on this matter in at
least one of those threads). Thus, I don't agree with you that it was a
bug in the original recipe.
I'm doing the same thing in my patch, as I prefer to do it that way
instead of patching the Makefile.
> >>> What's the reason for this change? Currently fw_printenv is being
> >>built
> >>> for my host system, and not the target...
> >>Yes; the way to proper package it for target is from u-boot itself,
> >>not on this recipe.
> > Yep, so the commit log that makes the transition from u-boot-fw-utils to u-boot-fw-utils-cross should have mentioned that the purpose of those two packages are completely different.
> Right; I might not been clear on this.
> >>> Further more, fw_printenv does not get packaged. I can see that
> >>> fw_printenv is installed in ${WORKDIR}/image, but never moved to
> >>> ${WORKDIR}/package. I guess that this is caused by inheriting
> >>> cross.bbclass?
> >>> Am I missing something in my distro config, or have I overlooked
> >>> something else? fw_printenv doesn't really make sense for me to run
> >>on
> >>> the host, and is (in my case) rather essential on the target.
> >>> I guess that I'm doing something wrong; can anyone give me some hint
> >>on
> >>> where to look? Or do we have an issue with the u-boot-fw-utils-cross
> >>> recipe?
> >>No, you are right. I can help you to solve it (or solve it and send
> >>you the solution) if you want.
> > I've got a working u-boot-fw-utils recipe that I can submit. I'll look into this on Monday morning, to ensure that it's of enough quality to publish.
> Ahh neat! So please e-mail me and I help to clean it.
I've made a quick clean-up and submitted a patch a few moments ago.
Hopefully, I might have some review comments by Monday, which hopefully
could get the patch to a mergeable state during Monday / Tuesday.
> > Just curious, what use case do you have for fw_* the build host?
> So we can mangle environment per image ;-)
Ok. I've never tried to do that using these tools. The only times I've
created env-images, I've been using an old TCL script based on the one
Atmel supplies in their SAM-BA tool...
Cheers,
Anders
--
Anders Darander
ChargeStorm AB Tel: +46 702 44 84 36
Laxholmstorget 3 Email: anders@chargestorm.se
602 21 Norrköping Web: www.chargestorm.se
prev parent reply other threads:[~2013-09-13 19:29 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-13 7:56 u-boot-fw-utils -> u-boot-fw-utils-cross Anders Darander
2013-09-13 17:32 ` Otavio Salvador
2013-09-13 17:58 ` Hans Beckerus
2013-09-13 18:35 ` Otavio Salvador
2013-09-13 18:55 ` Anders Darander
2013-09-13 19:16 ` Otavio Salvador
2013-09-13 19:29 ` Anders Darander [this message]
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=20130913192934.GA5469@ad.chargestorm.se \
--to=anders@chargestorm.se \
--cc=openembedded-core@lists.openembedded.org \
--cc=otavio@ossystems.com.br \
/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