Additional / new BSP collection?

Additional / new BSP collection?

[Kumar Gala]

Who is the best person to ask about adding new BSPs into yocto.  What I mean by this is having a meta layer hosted on git.yoctoproject.org like meta-intel and the mechanics associated with this (getting new repo on git server, autobuilder support, webpage details, etc.).

- k

Re: Additional / new BSP collection?

[Richard Purdie]

On Wed, 2011-07-27 at 00:21 -0500, Kumar Gala wrote:
> Who is the best person to ask about adding new BSPs into yocto.  What
> I mean by this is having a meta layer hosted on git.yoctoproject.org
> like meta-intel and the mechanics associated with this (getting new
> repo on git server, autobuilder support, webpage details, etc.).

This list is as good a place as any! :)

Its relatively easy to arrange for a git repository. The main things we
ask are that it has clearly defined maintainership (a clear maintainer
and submission process) and a clear scope. Do you have any specific BSPs
in mind?

The wiki is available to host information and we can work out links on
the website as the specific needs come up. Autobuilder support is
something we need to figure out since its a finite resource but we can
likely figure something out there once we understand what kind of BSPs
we're talking about.

Beth Flanagan <elizabeth.flanagan@intel.com> is the person who'd handle
the mechanics of setting up the repository, the name is likely the
hardest bit!

Cheers,

Richard

Re: Additional / new BSP collection?

[Kumar Gala]

On Jul 27, 2011, at 3:45 AM, Richard Purdie wrote:

> On Wed, 2011-07-27 at 00:21 -0500, Kumar Gala wrote:
>> Who is the best person to ask about adding new BSPs into yocto.  What
>> I mean by this is having a meta layer hosted on git.yoctoproject.org
>> like meta-intel and the mechanics associated with this (getting new
>> repo on git server, autobuilder support, webpage details, etc.).
> 
> This list is as good a place as any! :)
> 
> Its relatively easy to arrange for a git repository. The main things we
> ask are that it has clearly defined maintainership (a clear maintainer
> and submission process) and a clear scope. Do you have any specific BSPs
> in mind?

Maintainership would be straight forward.  Not sure about submissions process, what is done for meta-intel today?

BSP would be for Freescale PowerPC SoC and the reference designs produced by FSL for them.

> The wiki is available to host information and we can work out links on
> the website as the specific needs come up. Autobuilder support is
> something we need to figure out since its a finite resource but we can
> likely figure something out there once we understand what kind of BSPs
> we're talking about.
> 
> Beth Flanagan <elizabeth.flanagan@intel.com> is the person who'd handle
> the mechanics of setting up the repository, the name is likely the
> hardest bit!

meta-fsl-ppc ;)

- k

Re: Additional / new BSP collection?

[Bruce Ashfield]

On 07/27/11 08:40, Kumar Gala wrote:
>
> On Jul 27, 2011, at 3:45 AM, Richard Purdie wrote:
>
>> On Wed, 2011-07-27 at 00:21 -0500, Kumar Gala wrote:
>>> Who is the best person to ask about adding new BSPs into yocto.  What
>>> I mean by this is having a meta layer hosted on git.yoctoproject.org
>>> like meta-intel and the mechanics associated with this (getting new
>>> repo on git server, autobuilder support, webpage details, etc.).
>>
>> This list is as good a place as any! :)
>>
>> Its relatively easy to arrange for a git repository. The main things we
>> ask are that it has clearly defined maintainership (a clear maintainer
>> and submission process) and a clear scope. Do you have any specific BSPs
>> in mind?
>
> Maintainership would be straight forward.  Not sure about submissions process, what is done for meta-intel today?
>
> BSP would be for Freescale PowerPC SoC and the reference designs produced by FSL for them.

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

>
>> The wiki is available to host information and we can work out links on
>> the website as the specific needs come up. Autobuilder support is
>> something we need to figure out since its a finite resource but we can
>> likely figure something out there once we understand what kind of BSPs
>> we're talking about.
>>
>> Beth Flanagan<elizabeth.flanagan@intel.com>  is the person who'd handle
>> the mechanics of setting up the repository, the name is likely the
>> hardest bit!
>
> meta-fsl-ppc ;)
>
> - k
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Re: Additional / new BSP collection?

[Richard Purdie]

On Wed, 2011-07-27 at 09:30 -0400, Bruce Ashfield wrote:
> 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).

So just to put what Bruce says into other words, there isn't any hard
requirement to use linux-yocto but we are asking people to try it and if
it doesn't work, at least tell us why.

I understand transitions and new ways of working take time and that
meta-fsl-ppc might be enough of a step at first without the linux-yocto
complications. That is fine but please do keep it in mind.

Cheers,

Richard

Re: Additional / new BSP collection?

[Kumar Gala]

> 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.

- k

Re: Additional / new BSP collection?

[Richard Purdie]

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

Re: Additional / new BSP collection?

[Bruce Ashfield]

On 07/27/11 10:23, Richard Purdie wrote:
> 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.

Most definitely. Having some sort of alignment on the
kernel versions is nice, but we definitely don't expect
all BSPs to follow every new kernel.

And like Richard said, the model you are thinking about
makes a lot of sense.

If we nominate some important BSPs (one of my post 1.1 tasks),
and they get into the yocto-kernel tree, you have the
advantage that when I uprev the kernel they largely get hauled
along for the ride.

Cheers,

Brice

>
> This is where we start to see major benefits of the layer model.
>
> Cheers,
>
> Richard
>
>

Re: Additional / new BSP collection?

[Tom Zanussi]

On Wed, 2011-07-27 at 05:40 -0700, Kumar Gala wrote:
> On Jul 27, 2011, at 3:45 AM, Richard Purdie wrote:
> 
> > On Wed, 2011-07-27 at 00:21 -0500, Kumar Gala wrote:
> >> Who is the best person to ask about adding new BSPs into yocto.  What
> >> I mean by this is having a meta layer hosted on git.yoctoproject.org
> >> like meta-intel and the mechanics associated with this (getting new
> >> repo on git server, autobuilder support, webpage details, etc.).
> > 
> > This list is as good a place as any! :)
> > 
> > Its relatively easy to arrange for a git repository. The main things we
> > ask are that it has clearly defined maintainership (a clear maintainer
> > and submission process) and a clear scope. Do you have any specific BSPs
> > in mind?
> 
> Maintainership would be straight forward.  Not sure about submissions process, what is done for meta-intel today?
> 

Hi Kumar,

For meta-intel, it's pretty simple and is summarized by this blurb from
the meta-intel MAINTAINERS file: 

"Please submit any patches against meta-intel BSPs to the Yocto mailing
list (yocto@yoctoproject.org)."

Basically, new patches get submitted to the mailing list, go through the
standard on-list comment and review process, and then get pulled into
master by whoever maintains the BSP when everything looks good.

Hope that helps,

Tom

> BSP would be for Freescale PowerPC SoC and the reference designs produced by FSL for them.
> 
> > The wiki is available to host information and we can work out links on
> > the website as the specific needs come up. Autobuilder support is
> > something we need to figure out since its a finite resource but we can
> > likely figure something out there once we understand what kind of BSPs
> > we're talking about.
> > 
> > Beth Flanagan <elizabeth.flanagan@intel.com> is the person who'd handle
> > the mechanics of setting up the repository, the name is likely the
> > hardest bit!
> 
> meta-fsl-ppc ;)
> 
> - k
> 
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Re: Additional / new BSP collection?

[Kumar Gala]

On Jul 27, 2011, at 8:50 AM, Tom Zanussi wrote:

> Hi Kumar,
> 
> For meta-intel, it's pretty simple and is summarized by this blurb from
> the meta-intel MAINTAINERS file: 
> 
> "Please submit any patches against meta-intel BSPs to the Yocto mailing
> list (yocto@yoctoproject.org)."
> 
> Basically, new patches get submitted to the mailing list, go through the
> standard on-list comment and review process, and then get pulled into
> master by whoever maintains the BSP when everything looks good.
> 
> Hope that helps,
> 
> Tom

Ok, same model would work for meta-fsl-ppc.  The one question I have is if it make sense to migrate such patches over to 'yocto-bsp@yoctoproject.org' list.

- k

Re: Additional / new BSP collection?

[Tom Zanussi]

On Wed, 2011-07-27 at 06:53 -0700, Kumar Gala wrote:
> On Jul 27, 2011, at 8:50 AM, Tom Zanussi wrote:
> 
> > Hi Kumar,
> > 
> > For meta-intel, it's pretty simple and is summarized by this blurb from
> > the meta-intel MAINTAINERS file: 
> > 
> > "Please submit any patches against meta-intel BSPs to the Yocto mailing
> > list (yocto@yoctoproject.org)."
> > 
> > Basically, new patches get submitted to the mailing list, go through the
> > standard on-list comment and review process, and then get pulled into
> > master by whoever maintains the BSP when everything looks good.
> > 
> > Hope that helps,
> > 
> > Tom
> 
> Ok, same model would work for meta-fsl-ppc.  The one question I have is if it make sense to migrate such patches over to 'yocto-bsp@yoctoproject.org' list.
> 

Hmm, I completely forgot about that list, and apparently everybody else
has too (no messages in it).  It's also not linked to from anywhere on
the Yocto site that I can see e.g. Community | Mailing Lists.

Personally I'd prefer less fragmentation of lists, and think it would
get better review and exposure on the yocto list, but if it makes more
sense to people to start using the yocto-bsp list, fine with me...

Tom

> - k

Re: Additional / new BSP collection?

[Kumar Gala]

On Jul 27, 2011, at 9:06 AM, Tom Zanussi wrote:

> On Wed, 2011-07-27 at 06:53 -0700, Kumar Gala wrote:
>> On Jul 27, 2011, at 8:50 AM, Tom Zanussi wrote:
>> 
>>> Hi Kumar,
>>> 
>>> For meta-intel, it's pretty simple and is summarized by this blurb from
>>> the meta-intel MAINTAINERS file: 
>>> 
>>> "Please submit any patches against meta-intel BSPs to the Yocto mailing
>>> list (yocto@yoctoproject.org)."
>>> 
>>> Basically, new patches get submitted to the mailing list, go through the
>>> standard on-list comment and review process, and then get pulled into
>>> master by whoever maintains the BSP when everything looks good.
>>> 
>>> Hope that helps,
>>> 
>>> Tom
>> 
>> Ok, same model would work for meta-fsl-ppc.  The one question I have is if it make sense to migrate such patches over to 'yocto-bsp@yoctoproject.org' list.
>> 
> 
> Hmm, I completely forgot about that list, and apparently everybody else
> has too (no messages in it).  It's also not linked to from anywhere on
> the Yocto site that I can see e.g. Community | Mailing Lists.
> 
> Personally I'd prefer less fragmentation of lists, and think it would
> get better review and exposure on the yocto list, but if it makes more
> sense to people to start using the yocto-bsp list, fine with me...
> 
> Tom
> 
>> - k
> 

I'm good w/just using the main yocto list for now until traffic gets to a point we think it makes sense to split it off

- k

Re: Additional / new BSP collection?

[Cherry, John]

> -----Original Message-----
> From: yocto-bounces@yoctoproject.org [mailto:yocto-
> bounces@yoctoproject.org] On Behalf Of Tom Zanussi
> Sent: Wednesday, July 27, 2011 7:07 AM
> To: Kumar Gala
> Cc: Yocto discussion list
> Subject: Re: [yocto] Additional / new BSP collection?
> 
> On Wed, 2011-07-27 at 06:53 -0700, Kumar Gala wrote:
> > On Jul 27, 2011, at 8:50 AM, Tom Zanussi wrote:
> >
> > > Hi Kumar,
> > >
> > > For meta-intel, it's pretty simple and is summarized by this blurb
> from
> > > the meta-intel MAINTAINERS file:
> > >
> > > "Please submit any patches against meta-intel BSPs to the Yocto
> mailing
> > > list (yocto@yoctoproject.org)."
> > >
> > > Basically, new patches get submitted to the mailing list, go
> through the
> > > standard on-list comment and review process, and then get pulled
> into
> > > master by whoever maintains the BSP when everything looks good.
> > >
> > > Hope that helps,
> > >
> > > Tom
> >
> > Ok, same model would work for meta-fsl-ppc.  The one question I have
> is if it make sense to migrate such patches over to 'yocto-
> bsp@yoctoproject.org' list.
> >
> 
> Hmm, I completely forgot about that list, and apparently everybody else
> has too (no messages in it).  It's also not linked to from anywhere on
> the Yocto site that I can see e.g. Community | Mailing Lists.

I think the yocto-bsp list was set up in anticipation of a BSP special interest group.  As far as I know, it is not being used yet.

> 
> Personally I'd prefer less fragmentation of lists, and think it would
> get better review and exposure on the yocto list, but if it makes more
> sense to people to start using the yocto-bsp list, fine with me...
> 
> Tom
> 
> > - k
> 
> 
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto