meta-yocto-bsp changes and 3.14

meta-yocto-bsp changes and 3.14

[Richard Purdie]

I've merged Bruce's 3.14 patches into master-next. With the yocto-bsp
parts that I could pull together, there seemed to be some pieces
missing, specifically:

* the yocto-linux-dev.bbappend was underpopulated
* the yocto-linux-3.14.bbappend was missing
* no removal of beagleboard
* no addition to the README for beaglebone
* local.conf.sample needs updates
* missing edgerouter configuration in linux-yocto*
* should we be removing a mips BSP?
* need a layer version bump so beth can handle this on the autobuilder

I added commits for some of these, the 3.14 kernel bbappend is missing
SRCREVs though for example. The state of where I got to is:

http://git.yoctoproject.org/cgit.cgi/meta-yocto/log/?h=master-next

Beth: Your AR is to figure out the autobuilder side of this and build
the two new replacement BSPs (beaglebone and edgerouter) instead of the
old ones. When that and the current build on the AB is done, can we run
a build of master-next please?

Denys: I'm hoping you can help out with the README

Bruce: can you look at the linux-yocto-* changes, particularly the 3.14
SRCREVs and that linux-yocto-dev looks right?

Cheers,

Richard

Re: meta-yocto-bsp changes and 3.14

[Bruce Ashfield]

On 14-03-28 02:24 PM, Richard Purdie wrote:
> I've merged Bruce's 3.14 patches into master-next. With the yocto-bsp
> parts that I could pull together, there seemed to be some pieces
> missing, specifically:
>
> * the yocto-linux-dev.bbappend was underpopulated
> * the yocto-linux-3.14.bbappend was missing

I have one of these, I was hoping the BSP developers would submit
it, but I can commit and send mine.

> * no removal of beagleboard

I was keeping this around, for the 3.10 and older trees.

> * no addition to the README for beaglebone

Denys and I talked about this, one should be pending.

> * local.conf.sample needs updates
> * missing edgerouter configuration in linux-yocto*

Hmm. no, it's definitely there, so I'm not sure

> * should we be removing a mips BSP?

Nope. Same as for the beagle, this was on purpose.

> * need a layer version bump so beth can handle this on the autobuilder
>
> I added commits for some of these, the 3.14 kernel bbappend is missing
> SRCREVs though for example. The state of where I got to is:
>
> http://git.yoctoproject.org/cgit.cgi/meta-yocto/log/?h=master-next
>
> Beth: Your AR is to figure out the autobuilder side of this and build
> the two new replacement BSPs (beaglebone and edgerouter) instead of the
> old ones. When that and the current build on the AB is done, can we run
> a build of master-next please?
>
> Denys: I'm hoping you can help out with the README
>
> Bruce: can you look at the linux-yocto-* changes, particularly the 3.14
> SRCREVs and that linux-yocto-dev looks right?

I'll send you my commits, I have them here already. Want them on the
branch, or email ?

Bruce

>
> Cheers,
>
> Richard
>
>

Re: meta-yocto-bsp changes and 3.14

[Bruce Ashfield]

On 14-03-28 02:27 PM, Bruce Ashfield wrote:
> On 14-03-28 02:24 PM, Richard Purdie wrote:
>> I've merged Bruce's 3.14 patches into master-next. With the yocto-bsp
>> parts that I could pull together, there seemed to be some pieces
>> missing, specifically:
>>
>> * the yocto-linux-dev.bbappend was underpopulated
>> * the yocto-linux-3.14.bbappend was missing
>
> I have one of these, I was hoping the BSP developers would submit
> it, but I can commit and send mine.
>
>> * no removal of beagleboard
>
> I was keeping this around, for the 3.10 and older trees.
>
>> * no addition to the README for beaglebone
>
> Denys and I talked about this, one should be pending.
>
>> * local.conf.sample needs updates
>> * missing edgerouter configuration in linux-yocto*
>
> Hmm. no, it's definitely there, so I'm not sure

I forgot to finish this. This is all here for me, what exactly are you
seeing that is missing ?

Bruce

>
>> * should we be removing a mips BSP?
>
> Nope. Same as for the beagle, this was on purpose.
>
>> * need a layer version bump so beth can handle this on the autobuilder
>>
>> I added commits for some of these, the 3.14 kernel bbappend is missing
>> SRCREVs though for example. The state of where I got to is:
>>
>> http://git.yoctoproject.org/cgit.cgi/meta-yocto/log/?h=master-next
>>
>> Beth: Your AR is to figure out the autobuilder side of this and build
>> the two new replacement BSPs (beaglebone and edgerouter) instead of the
>> old ones. When that and the current build on the AB is done, can we run
>> a build of master-next please?
>>
>> Denys: I'm hoping you can help out with the README
>>
>> Bruce: can you look at the linux-yocto-* changes, particularly the 3.14
>> SRCREVs and that linux-yocto-dev looks right?
>
> I'll send you my commits, I have them here already. Want them on the
> branch, or email ?
>
> Bruce
>
>>
>> Cheers,
>>
>> Richard
>>
>>
>

Re: meta-yocto-bsp changes and 3.14

[Bruce Ashfield]

On 14-03-28 02:30 PM, Denys Dmytriyenko wrote:
> On Fri, Mar 28, 2014 at 06:24:07PM +0000, Richard Purdie wrote:
>> I've merged Bruce's 3.14 patches into master-next. With the yocto-bsp
>> parts that I could pull together, there seemed to be some pieces
>> missing, specifically:
>>
>> * the yocto-linux-dev.bbappend was underpopulated
>> * the yocto-linux-3.14.bbappend was missing
>> * no removal of beagleboard
>> * no addition to the README for beaglebone
>> * local.conf.sample needs updates
>> * missing edgerouter configuration in linux-yocto*
>> * should we be removing a mips BSP?
>> * need a layer version bump so beth can handle this on the autobuilder
>>
>> I added commits for some of these, the 3.14 kernel bbappend is missing
>> SRCREVs though for example. The state of where I got to is:
>>
>> http://git.yoctoproject.org/cgit.cgi/meta-yocto/log/?h=master-next
>>
>> Beth: Your AR is to figure out the autobuilder side of this and build
>> the two new replacement BSPs (beaglebone and edgerouter) instead of the
>> old ones. When that and the current build on the AB is done, can we run
>> a build of master-next please?
>>
>> Denys: I'm hoping you can help out with the README
>>
>> Bruce: can you look at the linux-yocto-* changes, particularly the 3.14
>> SRCREVs and that linux-yocto-dev looks right?
>
> Richard,
>
> Thanks for the update!
>
> I'll take a look at updating README with relevant Beaglebone pieces.
>
> As of the linux-yocto-dev.bbappend - I made that change before Bruce had the
> versioned linux-yocto recipe for 3.14, with plans to update it later. If you
> are merging all the changes together, that part needs to be fixed, indeed.

Yep. I'll dust off the version I tested with here, and send it along.

Cheers,

Bruce

>

Re: meta-yocto-bsp changes and 3.14

[Richard Purdie]

On Fri, 2014-03-28 at 14:28 -0400, Bruce Ashfield wrote:
> On 14-03-28 02:27 PM, Bruce Ashfield wrote:
> > On 14-03-28 02:24 PM, Richard Purdie wrote:
> >> I've merged Bruce's 3.14 patches into master-next. With the yocto-bsp
> >> parts that I could pull together, there seemed to be some pieces
> >> missing, specifically:
> >>
> >> * the yocto-linux-dev.bbappend was underpopulated
> >> * the yocto-linux-3.14.bbappend was missing
> >
> > I have one of these, I was hoping the BSP developers would submit
> > it, but I can commit and send mine.
> >
> >> * no removal of beagleboard
> >
> > I was keeping this around, for the 3.10 and older trees.
> >
> >> * no addition to the README for beaglebone
> >
> > Denys and I talked about this, one should be pending.
> >
> >> * local.conf.sample needs updates
> >> * missing edgerouter configuration in linux-yocto*
> >
> > Hmm. no, it's definitely there, so I'm not sure
> 
> I forgot to finish this. This is all here for me, what exactly are you
> seeing that is missing ?

Specifically, I had to add:

http://git.yoctoproject.org/cgit.cgi/meta-yocto/commit/?h=master-next&id=21f04021a62248bdb827e7d7acc103deb9136b5d

http://git.yoctoproject.org/cgit.cgi/meta-yocto/commit/?h=master-next&id=c94b1e4dc6af0848a30b4275f3cc2bc894f5e267

http://git.yoctoproject.org/cgit.cgi/meta-yocto/commit/?h=master-next&id=03bdb1421e51fa2a4da4bae42ff0b42a92c5acce

So I can't help feeling I'm missing some patches from somewhere or
something.

With regard to beagleboard, whilst the kernel may have support for it,
I'd like to remove it from meta-yocto-bsp.

Cheers,

Richard

Re: meta-yocto-bsp changes and 3.14

[Bruce Ashfield]

On 14-03-28 02:34 PM, Richard Purdie wrote:
> On Fri, 2014-03-28 at 14:28 -0400, Bruce Ashfield wrote:
>> On 14-03-28 02:27 PM, Bruce Ashfield wrote:
>>> On 14-03-28 02:24 PM, Richard Purdie wrote:
>>>> I've merged Bruce's 3.14 patches into master-next. With the yocto-bsp
>>>> parts that I could pull together, there seemed to be some pieces
>>>> missing, specifically:
>>>>
>>>> * the yocto-linux-dev.bbappend was underpopulated
>>>> * the yocto-linux-3.14.bbappend was missing
>>>
>>> I have one of these, I was hoping the BSP developers would submit
>>> it, but I can commit and send mine.
>>>
>>>> * no removal of beagleboard
>>>
>>> I was keeping this around, for the 3.10 and older trees.
>>>
>>>> * no addition to the README for beaglebone
>>>
>>> Denys and I talked about this, one should be pending.
>>>
>>>> * local.conf.sample needs updates
>>>> * missing edgerouter configuration in linux-yocto*
>>>
>>> Hmm. no, it's definitely there, so I'm not sure
>>
>> I forgot to finish this. This is all here for me, what exactly are you
>> seeing that is missing ?
>
> Specifically, I had to add:
>
> http://git.yoctoproject.org/cgit.cgi/meta-yocto/commit/?h=master-next&id=21f04021a62248bdb827e7d7acc103deb9136b5d
>
> http://git.yoctoproject.org/cgit.cgi/meta-yocto/commit/?h=master-next&id=c94b1e4dc6af0848a30b4275f3cc2bc894f5e267
>
> http://git.yoctoproject.org/cgit.cgi/meta-yocto/commit/?h=master-next&id=03bdb1421e51fa2a4da4bae42ff0b42a92c5acce
>
> So I can't help feeling I'm missing some patches from somewhere or
> something.

Aha. I thought you meant the in-kernel configuration and branch information.

Yes, those are missing, I was going to get them from the BSP creators,
but instead, I'll send mine along.

It'll be a little while though, I had to clean my builder when changing
PVs, so I need to wait full a full kernel refetch.

>
> With regard to beagleboard, whilst the kernel may have support for it,
> I'd like to remove it from meta-yocto-bsp.

ok. I had planned to just leave the compatible machine as 3.10 and leave
the support there, since there are a few people who contact me regularly
and poke with the support.

Is there a place we can put them as a "retirement" home ? versus asking
people to locally restore the support.

Bruce

>
> Cheers,
>
> Richard
>

Re: meta-yocto-bsp changes and 3.14

[Denys Dmytriyenko]

[Sorry for duplication, my reply didn't make it to the list, resending]

On Fri, Mar 28, 2014 at 06:24:07PM +0000, Richard Purdie wrote:
> I've merged Bruce's 3.14 patches into master-next. With the yocto-bsp
> parts that I could pull together, there seemed to be some pieces
> missing, specifically:
>
> * the yocto-linux-dev.bbappend was underpopulated
> * the yocto-linux-3.14.bbappend was missing
> * no removal of beagleboard
> * no addition to the README for beaglebone
> * local.conf.sample needs updates
> * missing edgerouter configuration in linux-yocto*
> * should we be removing a mips BSP?
> * need a layer version bump so beth can handle this on the autobuilder
>
> I added commits for some of these, the 3.14 kernel bbappend is missing
> SRCREVs though for example. The state of where I got to is:
>
> http://git.yoctoproject.org/cgit.cgi/meta-yocto/log/?h=master-next
>
> Beth: Your AR is to figure out the autobuilder side of this and build
> the two new replacement BSPs (beaglebone and edgerouter) instead of the
> old ones. When that and the current build on the AB is done, can we run
> a build of master-next please?
>
> Denys: I'm hoping you can help out with the README
>
> Bruce: can you look at the linux-yocto-* changes, particularly the 3.14
> SRCREVs and that linux-yocto-dev looks right?

Richard,

Thanks for the update!

I'll take a look at updating README with relevant Beaglebone pieces.

As of the linux-yocto-dev.bbappend - I made that change before Bruce had the
versioned linux-yocto recipe for 3.14, with plans to update it later. If you
are merging all the changes together, that part needs to be fixed, indeed.

-- 
Denys

Re: meta-yocto-bsp changes and 3.14

[Bruce Ashfield]

On 14-03-28 02:57 PM, Hart, Darren wrote:
> On 3/28/14, 11:38, "Bruce Ashfield" <bruce.ashfield@windriver.com> wrote:
>
>> On 14-03-28 02:34 PM, Richard Purdie wrote:
>>>
>>>
>>> With regard to beagleboard, whilst the kernel may have support for it,
>>> I'd like to remove it from meta-yocto-bsp.
>>
>> ok. I had planned to just leave the compatible machine as 3.10 and leave
>> the support there, since there are a few people who contact me regularly
>> and poke with the support.
>>
>> Is there a place we can put them as a "retirement" home ? versus asking
>> people to locally restore the support.
>
> The retirement home would be the 1.5 stable releases. Yes?

Nope. That's my point, I have 3.10 changes for the Xm in linux-yocto
3.10 that lives in 1.6. We can make it less visible, but I'd like the
configs to follow the latest versions of the tree.

Bruce

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

Re: meta-yocto-bsp changes and 3.14

[Bruce Ashfield]

On 14-03-28 03:05 PM, Hart, Darren wrote:
> On 3/28/14, 11:59, "Bruce Ashfield" <bruce.ashfield@windriver.com> wrote:
>
>> On 14-03-28 02:57 PM, Hart, Darren wrote:
>>> On 3/28/14, 11:38, "Bruce Ashfield" <bruce.ashfield@windriver.com>
>>> wrote:
>>>
>>>> On 14-03-28 02:34 PM, Richard Purdie wrote:
>>>>>
>>>>>
>>>>> With regard to beagleboard, whilst the kernel may have support for it,
>>>>> I'd like to remove it from meta-yocto-bsp.
>>>>
>>>> ok. I had planned to just leave the compatible machine as 3.10 and
>>>> leave
>>>> the support there, since there are a few people who contact me
>>>> regularly
>>>> and poke with the support.
>>>>
>>>> Is there a place we can put them as a "retirement" home ? versus asking
>>>> people to locally restore the support.
>>>
>>> The retirement home would be the 1.5 stable releases. Yes?
>>
>> Nope. That's my point, I have 3.10 changes for the Xm in linux-yocto
>> 3.10 that lives in 1.6. We can make it less visible, but I'd like the
>> configs to follow the latest versions of the tree.
>
> Isn't it just the SRCREV that matters here? Those can always just be
> applied to 1.5. RP is only asking to remove the beagle board as a
> reference BSP from the meta-yocto-bsp layer, he doesn't care if the
> linux-yocto/meta data remains in place.

We are talking past each other. I'm asking for the meta-yocto-bsp and
machine conf file to be around .. somewhere .. I don't want people
to have to scrounge them up and revive them from old releases, or
revert commits to make them available.

So this is outside of linux-yocto, I'd like a single layer than when
added, gives access to the BSPs "as they were" in the 3.10 tree, and
I'd like that layer to not be on people's local drives only.

Bruce

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

Re: meta-yocto-bsp changes and 3.14

[Denys Dmytriyenko]

On Fri, Mar 28, 2014 at 03:08:54PM -0400, Bruce Ashfield wrote:
> On 14-03-28 03:05 PM, Hart, Darren wrote:
> >On 3/28/14, 11:59, "Bruce Ashfield" <bruce.ashfield@windriver.com> wrote:
> >
> >>On 14-03-28 02:57 PM, Hart, Darren wrote:
> >>>On 3/28/14, 11:38, "Bruce Ashfield" <bruce.ashfield@windriver.com>
> >>>wrote:
> >>>
> >>>>On 14-03-28 02:34 PM, Richard Purdie wrote:
> >>>>>
> >>>>>
> >>>>>With regard to beagleboard, whilst the kernel may have support for it,
> >>>>>I'd like to remove it from meta-yocto-bsp.
> >>>>
> >>>>ok. I had planned to just leave the compatible machine as 3.10 and
> >>>>leave
> >>>>the support there, since there are a few people who contact me
> >>>>regularly
> >>>>and poke with the support.
> >>>>
> >>>>Is there a place we can put them as a "retirement" home ? versus asking
> >>>>people to locally restore the support.
> >>>
> >>>The retirement home would be the 1.5 stable releases. Yes?
> >>
> >>Nope. That's my point, I have 3.10 changes for the Xm in linux-yocto
> >>3.10 that lives in 1.6. We can make it less visible, but I'd like the
> >>configs to follow the latest versions of the tree.
> >
> >Isn't it just the SRCREV that matters here? Those can always just be
> >applied to 1.5. RP is only asking to remove the beagle board as a
> >reference BSP from the meta-yocto-bsp layer, he doesn't care if the
> >linux-yocto/meta data remains in place.
> 
> We are talking past each other. I'm asking for the meta-yocto-bsp and
> machine conf file to be around .. somewhere .. I don't want people
> to have to scrounge them up and revive them from old releases, or
> revert commits to make them available.
> 
> So this is outside of linux-yocto, I'd like a single layer than when
> added, gives access to the BSPs "as they were" in the 3.10 tree, and
> I'd like that layer to not be on people's local drives only.

3.10 EOL is projected as Sep, 2015 - do you plan to keep linux-yocto-3.10 
until then?

-- 
Denys

Re: meta-yocto-bsp changes and 3.14

[Bruce Ashfield]

On 14-03-28 03:12 PM, Denys Dmytriyenko wrote:
> On Fri, Mar 28, 2014 at 03:08:54PM -0400, Bruce Ashfield wrote:
>> On 14-03-28 03:05 PM, Hart, Darren wrote:
>>> On 3/28/14, 11:59, "Bruce Ashfield" <bruce.ashfield@windriver.com> wrote:
>>>
>>>> On 14-03-28 02:57 PM, Hart, Darren wrote:
>>>>> On 3/28/14, 11:38, "Bruce Ashfield" <bruce.ashfield@windriver.com>
>>>>> wrote:
>>>>>
>>>>>> On 14-03-28 02:34 PM, Richard Purdie wrote:
>>>>>>>
>>>>>>>
>>>>>>> With regard to beagleboard, whilst the kernel may have support for it,
>>>>>>> I'd like to remove it from meta-yocto-bsp.
>>>>>>
>>>>>> ok. I had planned to just leave the compatible machine as 3.10 and
>>>>>> leave
>>>>>> the support there, since there are a few people who contact me
>>>>>> regularly
>>>>>> and poke with the support.
>>>>>>
>>>>>> Is there a place we can put them as a "retirement" home ? versus asking
>>>>>> people to locally restore the support.
>>>>>
>>>>> The retirement home would be the 1.5 stable releases. Yes?
>>>>
>>>> Nope. That's my point, I have 3.10 changes for the Xm in linux-yocto
>>>> 3.10 that lives in 1.6. We can make it less visible, but I'd like the
>>>> configs to follow the latest versions of the tree.
>>>
>>> Isn't it just the SRCREV that matters here? Those can always just be
>>> applied to 1.5. RP is only asking to remove the beagle board as a
>>> reference BSP from the meta-yocto-bsp layer, he doesn't care if the
>>> linux-yocto/meta data remains in place.
>>
>> We are talking past each other. I'm asking for the meta-yocto-bsp and
>> machine conf file to be around .. somewhere .. I don't want people
>> to have to scrounge them up and revive them from old releases, or
>> revert commits to make them available.
>>
>> So this is outside of linux-yocto, I'd like a single layer than when
>> added, gives access to the BSPs "as they were" in the 3.10 tree, and
>> I'd like that layer to not be on people's local drives only.
>
> 3.10 EOL is projected as Sep, 2015 - do you plan to keep linux-yocto-3.10
> until then?

That's the plan. I tried to kill 3.4 before it official died and was
reminded that we'd keep LTSI support around a bit longer. I'm sure we
can bend a bit on the dates, but the general feel is correct .. the tree
will be around for a while yet.

Bruce

>

Re: meta-yocto-bsp changes and 3.14

[Bruce Ashfield]

On 14-03-28 03:22 PM, Hart, Darren wrote:
> On 3/28/14, 12:14, "Bruce Ashfield" <bruce.ashfield@windriver.com> wrote:
>
>> On 14-03-28 03:12 PM, Denys Dmytriyenko wrote:
>>> On Fri, Mar 28, 2014 at 03:08:54PM -0400, Bruce Ashfield wrote:
>>>> On 14-03-28 03:05 PM, Hart, Darren wrote:
>>>>> On 3/28/14, 11:59, "Bruce Ashfield" <bruce.ashfield@windriver.com>
>>>>> wrote:
>>>>>
>>>>>> On 14-03-28 02:57 PM, Hart, Darren wrote:
>>>>>>> On 3/28/14, 11:38, "Bruce Ashfield" <bruce.ashfield@windriver.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> On 14-03-28 02:34 PM, Richard Purdie wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> With regard to beagleboard, whilst the kernel may have support
>>>>>>>>> for it,
>>>>>>>>> I'd like to remove it from meta-yocto-bsp.
>>>>>>>>
>>>>>>>> ok. I had planned to just leave the compatible machine as 3.10 and
>>>>>>>> leave
>>>>>>>> the support there, since there are a few people who contact me
>>>>>>>> regularly
>>>>>>>> and poke with the support.
>>>>>>>>
>>>>>>>> Is there a place we can put them as a "retirement" home ? versus
>>>>>>>> asking
>>>>>>>> people to locally restore the support.
>>>>>>>
>>>>>>> The retirement home would be the 1.5 stable releases. Yes?
>>>>>>
>>>>>> Nope. That's my point, I have 3.10 changes for the Xm in linux-yocto
>>>>>> 3.10 that lives in 1.6. We can make it less visible, but I'd like the
>>>>>> configs to follow the latest versions of the tree.
>>>>>
>>>>> Isn't it just the SRCREV that matters here? Those can always just be
>>>>> applied to 1.5. RP is only asking to remove the beagle board as a
>>>>> reference BSP from the meta-yocto-bsp layer, he doesn't care if the
>>>>> linux-yocto/meta data remains in place.
>>>>
>>>> We are talking past each other. I'm asking for the meta-yocto-bsp and
>>>> machine conf file to be around .. somewhere .. I don't want people
>>>> to have to scrounge them up and revive them from old releases, or
>>>> revert commits to make them available.
>>>>
>>>> So this is outside of linux-yocto, I'd like a single layer than when
>>>> added, gives access to the BSPs "as they were" in the 3.10 tree, and
>>>> I'd like that layer to not be on people's local drives only.
>>>
>>> 3.10 EOL is projected as Sep, 2015 - do you plan to keep
>>> linux-yocto-3.10
>>> until then?
>>
>> That's the plan. I tried to kill 3.4 before it official died and was
>> reminded that we'd keep LTSI support around a bit longer. I'm sure we
>> can bend a bit on the dates, but the general feel is correct .. the tree
>> will be around for a while yet.
>
>
> Ah, but here's the thing. If someone wants to use an older kernel because
> they can't risk the change from the newer kernel, then they shouldn't be
> changing the release either. Dropping support in the next release is not
> the same as dropping support. The 1.5 series is still getting stable
> updates, and 3.10 lives on there for that BSP. This is the direction I
> drive internally as well.

That's not what I said, and not what I meant. I want to keep the support
in 3.10 AND 1.6 .. you'll note that I've never said 1.5 at any point.
I just don't want it to be the official "reference" BSP.

>
> I'm still not clear on which changes you are getting at that are relevant
> to beagle board in 1.6 that are not portable to 1.5. For example:

As I've said before, I'm not going to support 3.10 updates that I'm testing
on master on 1.5, since I'll have to prepare commits for multiple
release branches and test there.

If a -stable maintainer wants those commits, they are welcome, but
I have no bandwidth to backport and test.

I'm saying that it works in 3.10, and it works against 1.6, and that
is what I want to be available.

>
> $ git l dora..
> meta-yocto-bsp/recipes-kernel/linux/linux-yocto_3.10.bbappend
> 54c2e99 bsps: update H/W reference boards to v3.10.32
> 9688673 bsps: update to 3.10.28
> e0d8e2c linux-yocto-bsps: update reference BSPs to v3.10.25
> 8babbd1 meta-yocto-bsp: update SRCREVs for 3.10.17 and beagleboard fixes
>
>
> $ git l dora.. meta-yocto-bsp/conf/machine/beagleboard.conf
> <empty>
>
> $ git l dora.. meta/recipes-kernel/linux/linux-yocto_3.10.bb
> c7d9a07 linux-yocto/3.10: integrate latest LTSI changes
> 771803e linux-yocto/3.10: update to v3.10.32
> 4b967d9 linux-yocto/3.10: enable CONFIG_FHANDLE for standard and
> preempt-rt kernels
> 9be7acc linux-yocto/3.10: add minnow-io feature to LTSI
> 3fefbe3 linux-yocto/3.10: arbitrary write with CONFIG_X86_X32
> (CVE-2014-0038)
> 088677a linux-yocto/3.10: update to v3.10.28
> ab9c345 linux-yocto/3.10: add powermanagement config to 32 bit common-pc
> 897d13a linux-yocto/3.10: integrate LTSI
> e7f8537 linux-yocto/3.10: mohonpeak bsp config and scc files
> a166c2e linux-yocto/3.10: update to 3.10.25
> 5d90065 linux-yocto/3.10: update meta data for media fragments
> 121dcd3 linux-yocto/*: restore branch designations
> 04e3487 linux-yocto/3.10: -rt, ebtables and e1000 fixes
> 5745f59 linux/yocto-3.10: merge v3.10.19
> e1e1ee5 linux-yocto/3.10: meta: ARM: OMAP3: Add USB PHY driver for
> Beagleboard
> 89c986c linux-yocto/3.10: meta: ARM: OMAP3: Add USB PHY driver for
> Beagleboard
> e9ec153 linux-yocto/3.10: fix qemuarm boot and spurious mips build warning
> baf005b linux-yocto/3.10: common-pc: add missing dependencies for BRCMSMAC
> 1fe7bca linux-yocto/3.10: haswell-wc and crystalforest support
> a23c7e9 linux-yocto-3.10: bump to 3.10.17 and -rt11
> 56cc2f2 linux-yocto/3.10: MinnowBoard support
>
>
> All of this strikes me as either not relevant, or perfectly acceptable for
> a 1.5 point release. So the single layer you are asking for where the
> beagle board BSP exists as it was is poky/meta-yocto-bsp:dora. We won't be
> removing it from there.
>
> Am I still missing something about what you are looking for?

Yep, see above.

Bruce

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

Re: meta-yocto-bsp changes and 3.14

[Flanagan, Elizabeth]

On Fri, Mar 28, 2014 at 11:24 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> I've merged Bruce's 3.14 patches into master-next. With the yocto-bsp
> parts that I could pull together, there seemed to be some pieces
> missing, specifically:
>
> * the yocto-linux-dev.bbappend was underpopulated
> * the yocto-linux-3.14.bbappend was missing
> * no removal of beagleboard
> * no addition to the README for beaglebone
> * local.conf.sample needs updates
> * missing edgerouter configuration in linux-yocto*
> * should we be removing a mips BSP?
> * need a layer version bump so beth can handle this on the autobuilder
>
> I added commits for some of these, the 3.14 kernel bbappend is missing
> SRCREVs though for example. The state of where I got to is:
>
> http://git.yoctoproject.org/cgit.cgi/meta-yocto/log/?h=master-next
>
> Beth: Your AR is to figure out the autobuilder side of this and build
> the two new replacement BSPs (beaglebone and edgerouter) instead of the
> old ones. When that and the current build on the AB is done, can we run
> a build of master-next please?
>

RP: Ok, I'm testing the changes for this now in dev. I should have
results enough to push into production by the time the current
production build is finished. I'll kick master-next when we're
finished testing in dev.


> Denys: I'm hoping you can help out with the README
>
> Bruce: can you look at the linux-yocto-* changes, particularly the 3.14
> SRCREVs and that linux-yocto-dev looks right?
>
> Cheers,
>
> Richard
>
>



-- 
Elizabeth Flanagan
Yocto Project
Build and Release

Re: meta-yocto-bsp changes and 3.14

[Bruce Ashfield]

[-- Attachment #1: Type: text/plain, Size: 2362 bytes --]

On 14-03-28 02:24 PM, Richard Purdie wrote:
> I've merged Bruce's 3.14 patches into master-next. With the yocto-bsp
> parts that I could pull together, there seemed to be some pieces
> missing, specifically:
>
> * the yocto-linux-dev.bbappend was underpopulated
> * the yocto-linux-3.14.bbappend was missing
> * no removal of beagleboard
> * no addition to the README for beaglebone
> * local.conf.sample needs updates
> * missing edgerouter configuration in linux-yocto*
> * should we be removing a mips BSP?
> * need a layer version bump so beth can handle this on the autobuilder

After suffering through two rounds of the entire kernel being fetched,
I've confirmed that the bbappend I've been using works for the reference
BSPs on 3.14.

As I mentioned before, my plan was to leave the untested reference BSPs
on 3.10 (particularly the FSL board) and update them once I get confirmation
that they work with 3.14.

I hadn't planned on adding the linux-yocto-dev.bbappend to meta-yocto-bsps,
since the hardware reference boards (unlike qemu) have a greater carrying
cost in terms of testing. So I keep that bbappend slightly out of
sight. At this point, it shouldn't be needed since all the boards
that support 3.14, set that explicitly in their config files.

As we rambled on in the thread, I was looking for a parking lot for
the retiring BSPs that work in 1.6, with the 3.10 kernel, but are not
the first choice. I won't fight to hard from it, and we can simply
pull them out of the 3.10 bbappend if there's no better option.

Attached is the bbappend that I used for testing. If it matches yours
we are good to go.

Bruce

>
> I added commits for some of these, the 3.14 kernel bbappend is missing
> SRCREVs though for example. The state of where I got to is:
>
> http://git.yoctoproject.org/cgit.cgi/meta-yocto/log/?h=master-next
>
> Beth: Your AR is to figure out the autobuilder side of this and build
> the two new replacement BSPs (beaglebone and edgerouter) instead of the
> old ones. When that and the current build on the AB is done, can we run
> a build of master-next please?
>
> Denys: I'm hoping you can help out with the README
>
> Bruce: can you look at the linux-yocto-* changes, particularly the 3.14
> SRCREVs and that linux-yocto-dev looks right?
>
> Cheers,
>
> Richard
>
>


[-- Attachment #2: 0001-meta-yocto-bsp-populate-3.14-bbappend.patch --]
[-- Type: text/x-patch, Size: 1766 bytes --]

From 9648840031b6dc441137b7c8e9d03e5f466821ac Mon Sep 17 00:00:00 2001
From: Bruce Ashfield <bruce.ashfield@windriver.com>
Date: Fri, 28 Mar 2014 15:49:47 -0400
Subject: [PATCH] meta-yocto-bsp: populate 3.14 bbappend

The 3.14 kernel supports the generic-x86, edgerouter and beaglebone black.

All other reference BSPs stay in the 3.10 kernel until boot and regression
testing can be performed.

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
---
 .../recipes-kernel/linux/linux-yocto_3.14.bbappend      | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)
 create mode 100644 meta-yocto-bsp/recipes-kernel/linux/linux-yocto_3.14.bbappend

diff --git a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_3.14.bbappend b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_3.14.bbappend
new file mode 100644
index 000000000000..a1ed1210681f
--- /dev/null
+++ b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_3.14.bbappend
@@ -0,0 +1,17 @@
+KBRANCH_genericx86  = "standard/common-pc/base"
+KBRANCH_genericx86-64  = "standard/common-pc-64/base"
+KBRANCH_edgerouter = "standard/edgerouter"
+KBRANCH_beaglebone = "standard/beaglebone"
+
+KMACHINE_genericx86 ?= "common-pc"
+KMACHINE_genericx86-64 ?= "common-pc-64"
+
+SRCREV_machine_genericx86 ?= "fecc3fd7d31bd93766ff4f0431fecdbbfa4c3a7c"
+SRCREV_machine_genericx86-64 ?= "fecc3fd7d31bd93766ff4f0431fecdbbfa4c3a7c"
+SRCREV_machine_edgerouter ?= "fecc3fd7d31bd93766ff4f0431fecdbbfa4c3a7c"
+SRCREV_machine_beaglebone ?= "58b6d33dd898f901afbed10cfdec96b9d3148a00"
+
+COMPATIBLE_MACHINE_genericx86 = "genericx86"
+COMPATIBLE_MACHINE_genericx86-64 = "genericx86-64"
+COMPATIBLE_MACHINE_edgerouter = "edgerouter"
+COMPATIBLE_MACHINE_beaglebone = "beaglebone"
-- 
1.8.1.2

Re: meta-yocto-bsp changes and 3.14

[Bruce Ashfield]

On 14-03-28 04:37 PM, Hart, Darren wrote:
> On 3/28/14, 12:27, "Bruce Ashfield" <bruce.ashfield@windriver.com> wrote:
>
>> On 14-03-28 03:22 PM, Hart, Darren wrote:
>>> On 3/28/14, 12:14, "Bruce Ashfield" <bruce.ashfield@windriver.com>
>>> wrote:
>>>
>>>> On 14-03-28 03:12 PM, Denys Dmytriyenko wrote:
>>>>> On Fri, Mar 28, 2014 at 03:08:54PM -0400, Bruce Ashfield wrote:
>>>>>> On 14-03-28 03:05 PM, Hart, Darren wrote:
>>>>>>> On 3/28/14, 11:59, "Bruce Ashfield" <bruce.ashfield@windriver.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> On 14-03-28 02:57 PM, Hart, Darren wrote:
>>>>>>>>> On 3/28/14, 11:38, "Bruce Ashfield" <bruce.ashfield@windriver.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> On 14-03-28 02:34 PM, Richard Purdie wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> With regard to beagleboard, whilst the kernel may have support
>>>>>>>>>>> for it,
>>>>>>>>>>> I'd like to remove it from meta-yocto-bsp.
>>>>>>>>>>
>>>>>>>>>> ok. I had planned to just leave the compatible machine as 3.10
>>>>>>>>>> and
>>>>>>>>>> leave
>>>>>>>>>> the support there, since there are a few people who contact me
>>>>>>>>>> regularly
>>>>>>>>>> and poke with the support.
>>>>>>>>>>
>>>>>>>>>> Is there a place we can put them as a "retirement" home ? versus
>>>>>>>>>> asking
>>>>>>>>>> people to locally restore the support.
>>>>>>>>>
>>>>>>>>> The retirement home would be the 1.5 stable releases. Yes?
>>>>>>>>
>>>>>>>> Nope. That's my point, I have 3.10 changes for the Xm in
>>>>>>>> linux-yocto
>>>>>>>> 3.10 that lives in 1.6. We can make it less visible, but I'd like
>>>>>>>> the
>>>>>>>> configs to follow the latest versions of the tree.
>>>>>>>
>>>>>>> Isn't it just the SRCREV that matters here? Those can always just be
>>>>>>> applied to 1.5. RP is only asking to remove the beagle board as a
>>>>>>> reference BSP from the meta-yocto-bsp layer, he doesn't care if the
>>>>>>> linux-yocto/meta data remains in place.
>>>>>>
>>>>>> We are talking past each other. I'm asking for the meta-yocto-bsp and
>>>>>> machine conf file to be around .. somewhere .. I don't want people
>>>>>> to have to scrounge them up and revive them from old releases, or
>>>>>> revert commits to make them available.
>>>>>>
>>>>>> So this is outside of linux-yocto, I'd like a single layer than when
>>>>>> added, gives access to the BSPs "as they were" in the 3.10 tree, and
>>>>>> I'd like that layer to not be on people's local drives only.
>>>>>
>>>>> 3.10 EOL is projected as Sep, 2015 - do you plan to keep
>>>>> linux-yocto-3.10
>>>>> until then?
>>>>
>>>> That's the plan. I tried to kill 3.4 before it official died and was
>>>> reminded that we'd keep LTSI support around a bit longer. I'm sure we
>>>> can bend a bit on the dates, but the general feel is correct .. the
>>>> tree
>>>> will be around for a while yet.
>>>
>>>
>>> Ah, but here's the thing. If someone wants to use an older kernel
>>> because
>>> they can't risk the change from the newer kernel, then they shouldn't be
>>> changing the release either. Dropping support in the next release is not
>>> the same as dropping support. The 1.5 series is still getting stable
>>> updates, and 3.10 lives on there for that BSP. This is the direction I
>>> drive internally as well.
>>
>> That's not what I said, and not what I meant. I want to keep the support
>> in 3.10 AND 1.6 .. you'll note that I've never said 1.5 at any point.
>> I just don't want it to be the official "reference" BSP.
>>
>>>
>>> I'm still not clear on which changes you are getting at that are
>>> relevant
>>> to beagle board in 1.6 that are not portable to 1.5. For example:
>>
>> As I've said before, I'm not going to support 3.10 updates that I'm
>> testing
>> on master on 1.5, since I'll have to prepare commits for multiple
>> release branches and test there.
>>
>> If a -stable maintainer wants those commits, they are welcome, but
>> I have no bandwidth to backport and test.
>>
>> I'm saying that it works in 3.10, and it works against 1.6, and that
>> is what I want to be available.
>
>
> Yes, the 1.5 suggestion was mine in response to working with RP on
> reducing the BSPs in meta-yocto-bsp to 1 per architecture per the stated
> intent of that layer.
>
> However - that's really all the time I can spend on it :-) Not the hill I
> want to die on and all that.

Me either. Responding to the thread was more time than it took me
to test the bbappend and send it out. As you saw in my email there,
I won't fight to keep them either .. I'm just on the record saying
that I won't be testing them on 1.5 either!

I'd think a meta-yocto-old-bsps layer somewhere is all that is
needed.

Bruce

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

Re: meta-yocto-bsp changes and 3.14

[Richard Purdie]

On Fri, 2014-03-28 at 15:58 -0400, Bruce Ashfield wrote:
> On 14-03-28 02:24 PM, Richard Purdie wrote:
> > I've merged Bruce's 3.14 patches into master-next. With the yocto-bsp
> > parts that I could pull together, there seemed to be some pieces
> > missing, specifically:
> >
> > * the yocto-linux-dev.bbappend was underpopulated
> > * the yocto-linux-3.14.bbappend was missing
> > * no removal of beagleboard
> > * no addition to the README for beaglebone
> > * local.conf.sample needs updates
> > * missing edgerouter configuration in linux-yocto*
> > * should we be removing a mips BSP?
> > * need a layer version bump so beth can handle this on the autobuilder
> 
> After suffering through two rounds of the entire kernel being fetched,
> I've confirmed that the bbappend I've been using works for the reference
> BSPs on 3.14.
> 
> As I mentioned before, my plan was to leave the untested reference BSPs
> on 3.10 (particularly the FSL board) and update them once I get confirmation
> that they work with 3.14.

Ok.

> I hadn't planned on adding the linux-yocto-dev.bbappend to meta-yocto-bsps,
> since the hardware reference boards (unlike qemu) have a greater carrying
> cost in terms of testing. So I keep that bbappend slightly out of
> sight. At this point, it shouldn't be needed since all the boards
> that support 3.14, set that explicitly in their config files.

Ok, I've dropped that. It does mean we get more restricted coverage with
the -dev kernel though...

> As we rambled on in the thread, I was looking for a parking lot for
> the retiring BSPs that work in 1.6, with the 3.10 kernel, but are not
> the first choice. I won't fight to hard from it, and we can simply
> pull them out of the 3.10 bbappend if there's no better option.

I don't mind them in the bbappend of the kernel tree. My concern is that
if the machine definition is in the repository, someone will try and
build it. That means before we ship it, we need to build and test it and
we don't have resources for it. I'd ideally therefore prefer to have
only the selected machine in there.

> Attached is the bbappend that I used for testing. If it matches yours
> we are good to go.

I tried it but I had trouble on beaglebone since the referenced commit
doesn't match anything the beaglebone branch. Using
fecc3fd7d31bd93766ff4f0431fecdbbfa4c3a7c as with the others (and as per
the branch head) is hopefully going to work better.

I've also been having "fun" with the edgerouter BSP since we can't build
qt4 for mips64. I think I've come up with the right set of magic changes
to avoid the build failures with that.

One remaining issue is that u-boot may be breaking for beaglebone. I'm
hoping Denys can help there.

Cheers,

Richard

Re: meta-yocto-bsp changes and 3.14

[Richard Purdie]

On Sat, 2014-03-29 at 23:12 +0000, Richard Purdie wrote:
> One remaining issue is that u-boot may be breaking for beaglebone. I'm
> hoping Denys can help there.

http://autobuilder.yoctoproject.org/main/builders/nightly-arm/builds/21/steps/BuildImages_1/logs/stdio
http://autobuilder.yoctoproject.org/main/builders/nightly-arm-lsb/builds/21/steps/BuildImages_1/logs/stdio

Cheers,

Richard

Re: meta-yocto-bsp changes and 3.14

[Bruce Ashfield]

On 2014-03-29, 7:12 PM, Richard Purdie wrote:
> On Fri, 2014-03-28 at 15:58 -0400, Bruce Ashfield wrote:
>> On 14-03-28 02:24 PM, Richard Purdie wrote:
>>> I've merged Bruce's 3.14 patches into master-next. With the yocto-bsp
>>> parts that I could pull together, there seemed to be some pieces
>>> missing, specifically:
>>>
>>> * the yocto-linux-dev.bbappend was underpopulated
>>> * the yocto-linux-3.14.bbappend was missing
>>> * no removal of beagleboard
>>> * no addition to the README for beaglebone
>>> * local.conf.sample needs updates
>>> * missing edgerouter configuration in linux-yocto*
>>> * should we be removing a mips BSP?
>>> * need a layer version bump so beth can handle this on the autobuilder
>>
>> After suffering through two rounds of the entire kernel being fetched,
>> I've confirmed that the bbappend I've been using works for the reference
>> BSPs on 3.14.
>>
>> As I mentioned before, my plan was to leave the untested reference BSPs
>> on 3.10 (particularly the FSL board) and update them once I get confirmation
>> that they work with 3.14.
>
> Ok.
>
>> I hadn't planned on adding the linux-yocto-dev.bbappend to meta-yocto-bsps,
>> since the hardware reference boards (unlike qemu) have a greater carrying
>> cost in terms of testing. So I keep that bbappend slightly out of
>> sight. At this point, it shouldn't be needed since all the boards
>> that support 3.14, set that explicitly in their config files.
>
> Ok, I've dropped that. It does mean we get more restricted coverage with
> the -dev kernel though...

Right now the 3.14 tree and -dev are identical, which is why I'm not worried
about the bbappend. When I move -dev to 3.15, I'll send it out for
inclusion.

>
>> As we rambled on in the thread, I was looking for a parking lot for
>> the retiring BSPs that work in 1.6, with the 3.10 kernel, but are not
>> the first choice. I won't fight to hard from it, and we can simply
>> pull them out of the 3.10 bbappend if there's no better option.
>
> I don't mind them in the bbappend of the kernel tree. My concern is that
> if the machine definition is in the repository, someone will try and
> build it. That means before we ship it, we need to build and test it and
> we don't have resources for it. I'd ideally therefore prefer to have
> only the selected machine in there.

Understood. I'll figure out a good place to stash it. I was more commenting
that it wasn't a missed commit, it was on purpose .. but we can decide
that the 'on purpose' part of it was wrong :)

>
>> Attached is the bbappend that I used for testing. If it matches yours
>> we are good to go.
>
> I tried it but I had trouble on beaglebone since the referenced commit
> doesn't match anything the beaglebone branch. Using
> fecc3fd7d31bd93766ff4f0431fecdbbfa4c3a7c as with the others (and as per
> the branch head) is hopefully going to work better.

I really did mean 58b6d33dd898f901afbed10cfdec96b9d3148a00, but that was
me flipping the beagleboard and beaglebone. fecc really is the right commit
for the BBB, so your update is correct (and I've fixed my update
scripts now).

Cheers,

Bruce

>
> I've also been having "fun" with the edgerouter BSP since we can't build
> qt4 for mips64. I think I've come up with the right set of magic changes
> to avoid the build failures with that.
>
> One remaining issue is that u-boot may be breaking for beaglebone. I'm
> hoping Denys can help there.
>
> Cheers,
>
> Richard
>

Re: meta-yocto-bsp changes and 3.14

[Bruce Ashfield]

[-- Attachment #1: Type: text/plain, Size: 579 bytes --]

On 2014-03-30, 8:37 AM, Richard Purdie wrote:
> On Sat, 2014-03-29 at 23:12 +0000, Richard Purdie wrote:
>> One remaining issue is that u-boot may be breaking for beaglebone. I'm
>> hoping Denys can help there.
>
> http://autobuilder.yoctoproject.org/main/builders/nightly-arm/builds/21/steps/BuildImages_1/logs/stdio
> http://autobuilder.yoctoproject.org/main/builders/nightly-arm-lsb/builds/21/steps/BuildImages_1/logs/stdio
>

I fixed the merge issue and pushed the change to the 3.10 kernel.
Attached is the SRCREV update.

Bruce

> Cheers,
>
> Richard
>


[-- Attachment #2: 0001-linux-yocto-3.10-fix-qemuarm-build-failure.patch --]
[-- Type: application/mbox, Size: 1306 bytes --]

Re: meta-yocto-bsp changes and 3.14

[Denys Dmytriyenko]

On Sun, Mar 30, 2014 at 01:37:56PM +0100, Richard Purdie wrote:
> On Sat, 2014-03-29 at 23:12 +0000, Richard Purdie wrote:
> > One remaining issue is that u-boot may be breaking for beaglebone. I'm
> > hoping Denys can help there.
> 
> http://autobuilder.yoctoproject.org/main/builders/nightly-arm/builds/21/steps/BuildImages_1/logs/stdio
> http://autobuilder.yoctoproject.org/main/builders/nightly-arm-lsb/builds/21/steps/BuildImages_1/logs/stdio

Sorry, there appears to be a typo - I'm sending a fix shortly.

-- 
Denys

Re: meta-yocto-bsp changes and 3.14

[Denys Dmytriyenko]

On Mon, Mar 31, 2014 at 10:55:10AM -0400, Denys Dmytriyenko wrote:
> On Sun, Mar 30, 2014 at 01:37:56PM +0100, Richard Purdie wrote:
> > On Sat, 2014-03-29 at 23:12 +0000, Richard Purdie wrote:
> > > One remaining issue is that u-boot may be breaking for beaglebone. I'm
> > > hoping Denys can help there.
> > 
> > http://autobuilder.yoctoproject.org/main/builders/nightly-arm/builds/21/steps/BuildImages_1/logs/stdio
> > http://autobuilder.yoctoproject.org/main/builders/nightly-arm-lsb/builds/21/steps/BuildImages_1/logs/stdio
> 
> Sorry, there appears to be a typo - I'm sending a fix shortly.

Ok, the patch is out. I'm still working on README - will try to finish it 
shortly.
BTW, 3.14 is finally out this morning.

-- 
Denys