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