Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Cc: Koen Kooi <koen@dominion.thruhere.net>
Subject: Re: Updating u-boot for oe-core or meta-yocto
Date: Wed, 25 May 2011 22:51:05 +0100	[thread overview]
Message-ID: <1306360265.27470.71.camel@rex> (raw)
In-Reply-To: <BANLkTim8VzrP7Zd4yDRaa75X0gXUL7wC=g@mail.gmail.com>

On Wed, 2011-05-25 at 09:36 -0700, Khem Raj wrote:
> On Wed, May 25, 2011 at 8:51 AM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> > I did a little research and I'd like to try and help us move forward.
> >
> > The "problem" at the moment is both oe-core and meta-ti have u-boot
> > recipes. If Yocto were to merge in the meta-ti recipe to meta-yocto it
> > would overshadow the oe-core recipe. I believe Yocto wants to encourage
> > sharing a core on codebases like u-boot which are receptive and working
> > to facilitate collaboration (not unlike Yocto itself).
> >
> > Valid questions are therefore:
> >
> > a) What can we do to the u-boot recipe in core to make it customisable
> > from layers like meta-ti
> >
> > b) Is it possible for the u-boot recipe in meta-ti to be a .bbappend
> > rather than a recipe which overwrites the default.
> >
> > For a), I know Darren has some patches which drop the COMPATIBLE_MACHINE
> > usage for example and instead raise the skip parsing exception when
> > UBOOT_MACHINE isn't set which is a step in the right direction. If we
> > find other issues, lets fix them.
> >
> > For b), I talked to Koen and he's going to see how feasible this is
> > although as always with this kind of issue there are various
> > complicating factors.
> >
> > Hopefully if we work both sides of the problem we can get this resolved.
> > Darren, if you could send out some of your patches so far (e.g. for
> > COMPATIBLE_MACHINE) that might be helpful.
> >
> > If the ultimate answer is that no, meta-ti has so many changes or
> > specific requirements that mean it needs to stay a .bb file then lets
> > cross that bridge if we come to it but I think this discussion makes
> > sense before reaching that conclusion. Its possible the last release of
> > u-boot has sufficient beagle support for yocto's needs and we could use
> > that instead.
> >
> > Just on a more general note, the agreement on resolving the beagleboard
> > issue stands as is. The plan is to make beagleboard support in
> > meta-yocto as near a copy of the meta-ti pieces as possible with the
> > exception of the kernel where linux-yocto will import the needed patches
> > to demo the kernel tooling functionality. The layer tooling under
> > development will automate the process of syncing those pieces. I think
> > everyone is happy with the agreement and we just need to address some
> > corner cases like u-boot.
> >
> 
> so is it just a question of beagleboard support or a broader support
> for all machines ?

I'm hoping there are some machines out there which have merged support
into the upstream so simply setting UBOOT_MACHINE = "xxx" in the machine
config file is enough to get them working.

Basing the system on the premise that every bootloader needs to be
custom isn't really where we want to be :/.

> I know various boards use very different versions
> of u-boot so is oe-core going to bring that support
> to u-boot in oe-core and maintain that ?

No, the idea would be to make it easy to add missing pieces in
a .bbappend though.

> IMO keeping oe-core relatively free of machine dependent stuff would be better.

I'm still in agreement with this.

Cheers,

Richard




  parent reply	other threads:[~2011-05-25 21:54 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-24 16:36 Updating u-boot for oe-core or meta-yocto Darren Hart
2011-05-24 17:13 ` Koen Kooi
2011-05-24 18:04   ` Darren Hart
2011-05-24 17:23 ` Khem Raj
2011-05-24 17:51   ` adding meta-intel layers breaks parsing, was " Koen Kooi
2011-05-24 18:07     ` Tom Zanussi
2011-05-25 14:28       ` Tom Zanussi
2011-05-25 14:31         ` Koen Kooi
2011-05-25 14:38         ` Phil Blundell
2011-05-25 14:52           ` Tom Zanussi
2011-05-25 18:56           ` Darren Hart
2011-05-25 19:11             ` Phil Blundell
2011-05-25 20:04               ` Darren Hart
2011-05-25 21:31                 ` Richard Purdie
2011-05-25 23:18                   ` Darren Hart
2011-05-24 18:23   ` Darren Hart
2011-05-24 18:35     ` Khem Raj
2011-05-24 18:48       ` Phil Blundell
2011-05-24 19:33       ` Darren Hart
2011-05-24 17:33 ` Martin Jansa
2011-05-25 15:51 ` Richard Purdie
2011-05-25 16:36   ` Khem Raj
2011-05-25 16:49     ` Henning Heinold
2011-05-25 18:40       ` Darren Hart
2011-05-26  6:12         ` Anders Darander
2011-05-26 13:54           ` Darren Hart
2011-05-25 21:51     ` Richard Purdie [this message]
2011-05-25 23:31       ` Jason Kridner
2011-05-26 18:07         ` Darren Hart
2011-05-27  5:36           ` Anders Darander

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=1306360265.27470.71.camel@rex \
    --to=richard.purdie@linuxfoundation.org \
    --cc=koen@dominion.thruhere.net \
    --cc=openembedded-core@lists.openembedded.org \
    /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