Openembedded Core Discussions
 help / color / mirror / Atom feed
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



  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox