From: Darren Hart <dvhart@linux.intel.com>
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: Tue, 24 May 2011 11:23:54 -0700 [thread overview]
Message-ID: <4DDBF7BA.2000706@linux.intel.com> (raw)
In-Reply-To: <20110524172330.GC18086@sakrah.homelinux.org>
On 05/24/2011 10:23 AM, Khem Raj wrote:
> On (24/05/11 09:36), Darren Hart wrote:
>> I've started pulling in the 15 or so patches to u-boot from meta-ti. In
>
> why ? its a BSP recipe and bsp layer is best place for it IMO unless you
> want to have some of those machines in a different layer.
The underlying goal here is to improve the Beagleboard support in
meta-yocto, without unnecessarily duplicating work. It was suggested at
ELC that we modify the u-boot and linux-yocto recipes/sources to include
the beagleboard specific changes from meta-ti. Once the boot loader and
kernel were in place, we would look to using the still-under-discussion
layer tooling to integrate the rest of meta-ti.
>
>> doing so I've come across some questions I'd like you thoughts on.
>> Specifically, where to put these changes. Some points of context:
>>
>> 1) oe-core is intended to support emulated machines only
>> 2) oe-core has a "virgin" u-boot recipe (no patches)
>> 3) meta-yocto does not have a u-boot recipe (no bbappend either)
>> 4) meta-ti has it's own u-boot recipe with per-machine patches
>>
>> A stated goal was to bring the Yocto Project's u-boot support for the
>> Beagleboard in line with that in meta-ti. There are several ways I can
>> go about this.
>>
>> a) create a bbappend in meta-yocto and duplicate the meta-ti
>> modifications in bbappend form.
>> b) Modify the oe-core recipe directly
>>
>> While a) is the most direct approach to accomplish our goal, it requires
>> continual maintenance and duplicates effort. I don't care for this
>> approach. b) has the potential to consolidate all beagleboard u-boot
>> recipe work into a single place. It could simplify the meta-ti and
>> eliminate the need for a bbappend in the meta-yocto layer.
>>
>> The question of whether bootloaders have a place in oe-core should
>> probably be addressed. While they aren't needed for the emulated
>> machines, they are a highly reusable component for real systems, and
>> that seems justify keeping them in oe-core. Does anyone disagree with
>> this assessment?
>>
>> I propose pulling the necessary changes to u-boot from meta-ti into
>> oe-core. My initial scan suggested the beagleboard patches are mostly
>> contained to beagle specific source files. I would prefer to pull in all
>> the patches for all machines into the SRC_URI, rather than divide them
>> up by machine. This reduces complexity considerably. For the couple of
>> patches that collide, we would keep those as machine specific.
>>
>> As a final part of the work, I would include my beagleboard patch status
>> audit in the included patches and continue to work on reducing the
>> patches in the recipe for the beagleboard.
>>
>> Thoughts?
>
> Well I am in similar boat where I wanted to build atom-pc for angstrom
> but I was thinking using meta-intel layer instead of pulling stuff out
> and stuffing it elsewhere and certainly not oe-core
I think the difference I'm seeing is that u-boot is a common recipe (it
exists in oe-core) and ideally it would track the upstream git
repository. If the recipe in oe-core is not intended to be used for any
real machines and isn't used as a base for bbappends in layers like
meta-ti (meta-ti has a complete uboot_git.bb), then it should just be
removed entirely.
I believe that there is value in not duplicating this recipe and
consolidating the modifications to it in a single place makes sense. The
fact that it needs so many non-upstream patches I think is something
that also needs to be addressed.
The second part is that we want to ensure the linux-yocto recipe and
kernel have complete support for the Beagleboard. This isn't something
we can do by just reusing a layer. The linux-yocto recipe takes a
different approach to managing BSP specific source and config changes. I
believe it reduces duplication of effort for things like bug fixing,
security fixes, and config fragment management.
Thanks,
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
next prev parent reply other threads:[~2011-05-24 18:26 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 [this message]
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
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=4DDBF7BA.2000706@linux.intel.com \
--to=dvhart@linux.intel.com \
--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 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.