All of lore.kernel.org
 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>,
	 Koen Kooi <koen@dominion.thruhere.net>
Subject: Updating u-boot for oe-core or meta-yocto
Date: Tue, 24 May 2011 09:36:45 -0700	[thread overview]
Message-ID: <4DDBDE9D.5000709@linux.intel.com> (raw)

I've started pulling in the 15 or so patches to u-boot from meta-ti. In
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?

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel



             reply	other threads:[~2011-05-24 16:39 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-24 16:36 Darren Hart [this message]
2011-05-24 17:13 ` Updating u-boot for oe-core or meta-yocto 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
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=4DDBDE9D.5000709@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.