From: Marek Vasut <marex@denx.de>
To: Otavio Salvador <otavio.salvador@ossystems.com.br>
Cc: Tom Rini <trini@konsulko.com>,
Otavio Salvador <otavio@ossystems.com.br>,
Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH] u-boot: Update to 2016.01 release
Date: Wed, 13 Jan 2016 21:35:10 +0100 [thread overview]
Message-ID: <201601132135.10606.marex@denx.de> (raw)
In-Reply-To: <CAP9ODKrfxXs2pZDGU+5xq41-NKSss1CiDWa1czTTmC8juNp+bQ@mail.gmail.com>
On Wednesday, January 13, 2016 at 06:56:36 PM, Otavio Salvador wrote:
> On Wed, Jan 13, 2016 at 3:42 PM, Marek Vasut <marex@denx.de> wrote:
> > On Wednesday, January 13, 2016 at 06:16:01 PM, Otavio Salvador wrote:
> >> On Wed, Jan 13, 2016 at 3:09 PM, Marek Vasut <marex@denx.de> wrote:
> >> > On Wednesday, January 13, 2016 at 05:40:20 PM, Otavio Salvador wrote:
> >> >> On Wed, Jan 13, 2016 at 2:30 PM, Marek Vasut <marex@denx.de> wrote:
> >> >> > On Wednesday, January 13, 2016 at 04:55:56 PM, Otavio Salvador wrote:
> >> >> >> On Wed, Jan 13, 2016 at 1:53 PM, Marek Vasut <marex@denx.de> wrote:
> >> >> >> > On Wednesday, January 13, 2016 at 04:39:53 PM, Otavio Salvador
wrote:
> >> >> >> >> On Wed, Jan 13, 2016 at 12:34 PM, Marek Vasut <marex@denx.de>
wrote:
> >> >> >> >> > On Wednesday, January 13, 2016 at 01:04:31 PM, Otavio
> >> >> >> >> > Salvador
> >
> > wrote:
> >> >> >> >> >> On Wed, Jan 13, 2016 at 1:36 AM, Marek Vasut <marex@denx.de>
> >
> > wrote:
> >> >> >> >> >> > Upgrade U-Boot to latest version and drop upstreamed
> >> >> >> >> >> > patches.
> >> >> >> >> >> >
> >> >> >> >> >> > Repair configuration of U-Boot during build. It is no
> >> >> >> >> >> > longer possible to run "make foomachine" in U-Boot.
> >> >> >> >> >> > Instead, it is necessary to do "make foomachine_defconfig
> >> >> >> >> >> > ; make". Fix this in u-boot.inc and u-boot-fw-utils*.bb .
> >> >> >> >> >>
> >> >> >> >> >> Please drop this config suffix, from u-boot.inc. The config
> >> >> >> >> >> value should be used as is and the respective BSP ought to
> >> >> >> >> >> be fixed to change _config to _defconfig.
> >> >> >> >> >
> >> >> >> >> > If I don't have the _defconfig there AND I define
> >> >> >> >> > UBOOT_MACHINE in my machine file, it will call "make
> >> >> >> >> > machine", which no longer works.
> >> >> >> >>
> >> >> >> >> I know and the right fix is to use the right value to
> >> >> >> >> UBOOT_MACHINE as we do for KERNEL_DEVICETREE.
> >> >> >> >
> >> >> >> > So what is the right value ? UBOOT_MACHINE := "foo_defconfig" ?
> >> >> >> > This does not sound right at all.
> >> >> >> >
> >> >> >> > And what is the right value of UBOOT_CONFIG then ?
> >> >> >>
> >> >> >> foo_defconfig.
> >> >> >>
> >> >> >> This is what we pass for make to configure the board and should be
> >> >> >> the given value.
> >> >> >
> >> >> > OK, that makes sense. You didn't answer my question about
> >> >> > UBOOT_MACHINE though. Any thoughts on that ?
> >> >>
> >> >> If using UBOOT_MACHINE = "foo_defconfig" will work just fine.
> >> >
> >> > This makes no sense at all, does it ? How can UBOOT_MACHINE contain
> >> > _defconfig ? This sounds like a crude hack, not a systematic solution.
> >>
> >> I think it makes more sense than it adding _defconfig suffix behind
> >> the scenes...
> >
> > The machine is just that, the name of the machine. For machine foo, the
> > UBOOT_MACHINE should be foo , not foo_defconfig . The _defconfig should
> > be added by the recipe, but certainly not by the user, since that would
> > be a dirty hack and confusing as hell. The "foo_defconfig" string would
> > only be sensible for UBOOT_CONFIG variable, but no way for UBOOT_MACHINE.
>
> UBOOT_CONFIG is different on this context; it is more like PACKAGECONFIG.
>
> You can see, for example:
>
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/tree/conf/machine/im
> x6qsabresd.conf#n14
>
> So I understand it is a little confusing but it is indeed how it has been
> done.
Just because some variable is misused in some metalayer doesn't make it right,
does it ?
next prev parent reply other threads:[~2016-01-13 20:51 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-13 3:36 [PATCH] u-boot: Update to 2016.01 release Marek Vasut
2016-01-13 4:49 ` Khem Raj
2016-01-13 5:01 ` Marek Vasut
2016-01-13 6:42 ` Khem Raj
2016-01-13 12:04 ` Otavio Salvador
2016-01-13 14:34 ` Marek Vasut
2016-01-13 15:39 ` Otavio Salvador
2016-01-13 15:53 ` Marek Vasut
2016-01-13 15:55 ` Otavio Salvador
2016-01-13 16:30 ` Marek Vasut
2016-01-13 16:40 ` Otavio Salvador
2016-01-13 17:09 ` Marek Vasut
2016-01-13 17:16 ` Otavio Salvador
2016-01-13 17:42 ` Marek Vasut
2016-01-13 17:56 ` Otavio Salvador
2016-01-13 20:35 ` Marek Vasut [this message]
2016-01-13 20:57 ` Otavio Salvador
2016-01-13 22:09 ` Tom Rini
2016-01-14 20:43 ` Otavio Salvador
2016-01-14 21:15 ` Marek Vasut
2016-01-14 21:37 ` Otavio Salvador
2016-01-14 21:41 ` Marek Vasut
2016-01-14 23:42 ` Otavio Salvador
2016-01-15 1:07 ` Marek Vasut
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=201601132135.10606.marex@denx.de \
--to=marex@denx.de \
--cc=openembedded-core@lists.openembedded.org \
--cc=otavio.salvador@ossystems.com.br \
--cc=otavio@ossystems.com.br \
--cc=trini@konsulko.com \
/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