From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Kumar Gala <galak@kernel.crashing.org>
Cc: Yocto discussion list <yocto@yoctoproject.org>
Subject: Re: Additional / new BSP collection?
Date: Wed, 27 Jul 2011 15:23:24 +0100 [thread overview]
Message-ID: <1311776604.2344.376.camel@rex> (raw)
In-Reply-To: <E7A956EE-C5D1-49A9-902B-9A0F8973688C@kernel.crashing.org>
On Wed, 2011-07-27 at 08:55 -0500, Kumar Gala wrote:
> > Hi Kumar,
> >
> > As you know, I've been working on several kernel efforts
> > around the FSL parts as well (in particular the ones that
> > have enough pieces upstream to work out of the box). I
> > definitely don't want to overlap in a way that doesn't
> > create complimentary efforts.
> >
> > What are your current thoughts around kernels and the
> > (nearly religious) kernel version question ? It would be
> > great to get some alignment on features (-rt, tracing,
> > boot, footprint reduction, etc, etc) and save some effort
> > on maintenance and validation. Also if we want to create
> > some yocto reference BSPs, having a kernel version and feature
> > set match is important as well (i.e. what we've done for
> > the intel ones).
> >
> > To that end, do you have an thoughts about using linux-yocto
> > as a base to any BSP work ? That statement doesn't do it
> > justice though, since when I say 'use linux-yocto as a base',
> > it really means that linux-yocto uses your BSPs as an
> > upstream/official reference and can pull support for them
> > into branches, and have the configuration and other tooling
> > get them any functionality that is being developed.
> >
> > No control over BSP content, or anything like this, is being
> > suggested or asserted here. Just looking to all push in the
> > same direction (embedded features and BSPs to upstream) and
> > re-use the work of BSPs available in the community. If the
> > base is the same (and hence kernel version), then this relationship
> > and workflow is very simple.
> >
> > ... and as a bonus, if the workflow doesn't work easily, then
> > there's a problem with it and we can work on something that
> > is suitable (change tools, etc).
> >
> > Thanks,
> >
> > Bruce
>
> What I'm envisioning as a start is we'd offer a meta layer on yocto
> sites for the upstream supported boards & feature set.
>
> I'm still looking at what we do for a FSL delivered BSP (via
> freescale.com) that would be based on that. My initial concerns are
> that the yocto community will probably move and change things too
> frequently for our customer base (kernel version, toolchain version,
> etc). Thus my thinking of de-coupling the two a bit. The yocto
> versions of BSPs would track yocto development. The FSL delivered
> BSPs would probably track to an older yocto version & slower update
> cycle.
Just for reference, this is exactly what meta-intel intends to do. The
released versions of the code there are based on a specific release of
Yocto/OE-Core. When new BSPs are developed they are likely developed on
the last stable release of Yocto, not bleeding edge master unless there
is some pressing reason to do so.
This is where we start to see major benefits of the layer model.
Cheers,
Richard
next prev parent reply other threads:[~2011-07-27 14:23 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-27 5:21 Additional / new BSP collection? Kumar Gala
2011-07-27 8:45 ` Richard Purdie
2011-07-27 12:40 ` Kumar Gala
2011-07-27 13:30 ` Bruce Ashfield
2011-07-27 13:52 ` Richard Purdie
2011-07-27 13:55 ` Kumar Gala
2011-07-27 14:23 ` Richard Purdie [this message]
2011-07-27 14:58 ` Bruce Ashfield
2011-07-27 13:50 ` Tom Zanussi
2011-07-27 13:53 ` Kumar Gala
2011-07-27 14:06 ` Tom Zanussi
2011-07-27 14:13 ` Kumar Gala
2011-07-27 14:33 ` Cherry, John
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=1311776604.2344.376.camel@rex \
--to=richard.purdie@linuxfoundation.org \
--cc=galak@kernel.crashing.org \
--cc=yocto@yoctoproject.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.