[yocto] [PATCH 1/2] meta-crownbay: switch to linux-yocto-3.2 kernel

Darren Hart dvhart at linux.intel.com
Tue Mar 13 21:05:09 PDT 2012 


On 03/13/2012 08:08 PM, Bruce Ashfield wrote:
> On 12-03-13 11:03 PM, Tom Zanussi wrote:
>> On Tue, 2012-03-13 at 22:40 -0400, Bruce Ashfield wrote:
>>> On Tue, Mar 13, 2012 at 3:44 PM, Tom Zanussi<tom.zanussi at intel.com>  wrote:
>>>> On Tue, 2012-03-13 at 12:30 -0700, Darren Hart wrote:
>>>>> Hi Tom,
>>>>>
>>>>> Some thoughts on this with respect to cleaning up and simplifying the
>>>>> recipes per our earlier discussions.
>>>>>
>>>>> On 03/12/2012 09:37 PM, tom.zanussi at intel.com wrote:
>>>>>> From: Tom Zanussi<tom.zanussi at intel.com>
>>>>>>
>>>>>> Switch crownbay and crownbay-noemgd to the 3.2 kernel.
>>>>>>
>>>>>> Signed-off-by: Tom Zanussi<tom.zanussi at intel.com>
>>>>>> ---
>>>>>>   meta-crownbay/conf/machine/crownbay-noemgd.conf    |    2 ++
>>>>>>   meta-crownbay/conf/machine/crownbay.conf           |    2 ++
>>>>>>   .../linux/linux-yocto-rt_3.2.bbappend              |   20 ++++++++++++++++++++
>>>>>>   .../recipes-kernel/linux/linux-yocto_3.2.bbappend  |   17 +++++++++++++++++
>>>>>>   4 files changed, 41 insertions(+), 0 deletions(-)
>>>>>>   create mode 100644 meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.2.bbappend
>>>>>>   create mode 100644 meta-crownbay/recipes-kernel/linux/linux-yocto_3.2.bbappend
>>>>>>
>>>>>> diff --git a/meta-crownbay/conf/machine/crownbay-noemgd.conf b/meta-crownbay/conf/machine/crownbay-noemgd.conf
>>>>>> index 2c80bd8..af85b00 100644
>>>>>> --- a/meta-crownbay/conf/machine/crownbay-noemgd.conf
>>>>>> +++ b/meta-crownbay/conf/machine/crownbay-noemgd.conf
>>>>>> @@ -4,6 +4,8 @@
>>>>>>   #@DESCRIPTION: Machine configuration for Crown Bay systems, without Intel-proprietary graphics bits
>>>>>>   # i.e. E660 + EG20T
>>>>>>
>>>>>> +PREFERRED_VERSION_linux-yocto ?= "3.2%"
>>>>>> +
>>>>>>   require conf/machine/include/tune-atom.inc
>>>>>>   require conf/machine/include/ia32-base.inc
>>>>>>
>>>>>> diff --git a/meta-crownbay/conf/machine/crownbay.conf b/meta-crownbay/conf/machine/crownbay.conf
>>>>>> index 2c1ef3d..1458bff 100644
>>>>>> --- a/meta-crownbay/conf/machine/crownbay.conf
>>>>>> +++ b/meta-crownbay/conf/machine/crownbay.conf
>>>>>> @@ -4,6 +4,8 @@
>>>>>>   #@DESCRIPTION: Machine configuration for Crown Bay systems
>>>>>>   # i.e. E660 + EG20T
>>>>>>
>>>>>> +PREFERRED_VERSION_linux-yocto ?= "3.2%"
>>>>>> +
>>>>>>   require conf/machine/include/tune-atom.inc
>>>>>>   require conf/machine/include/ia32-base.inc
>>>>>>
>>>>>> diff --git a/meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.2.bbappend b/meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.2.bbappend
>>>>>> new file mode 100644
>>>>>> index 0000000..dee9bce
>>>>>> --- /dev/null
>>>>>> +++ b/meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.2.bbappend
>>>>>> @@ -0,0 +1,20 @@
>>>>>> +FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>>>>>> +
>>>>>> +COMPATIBLE_MACHINE_crownbay-noemgd = "crownbay-noemgd"
>>>>>> +KMACHINE_crownbay-noemgd = "crownbay"
>>>>>> +
>>>>>> +KERNEL_FEATURES_append_crownbay-noemgd += " cfg/smp.scc"
>>>>>
>>>>> I think we start putting cfg/smp.scc in the BSP scc file directly rather
>>>>> than in the recipe itself. This can be a follow-on patch, or just with
>>>>> the next kernel release even. But I wanted to point it out.
>>>>>
>>>>
>>>> Yeah, I saw that and agree - I just don't want to spend the time to do
>>>> all that now.  I basically have this week to get them all moved over
>>>> into a basically functional state and will submit patches to do this and
>>>> the below as follow-ons once the basics are out of the way.
>>>>
>>>>>> +
>>>>>> +COMPATIBLE_MACHINE_crownbay = "crownbay"
>>>>>> +KMACHINE_crownbay = "crownbay"
>>>>>> +
>>>>>> +KERNEL_FEATURES_append_crownbay += " cfg/smp.scc"
>>>>>> +
>>>>>> +# Update the following to use a different BSP branch or meta SRCREV
>>>>>> +#KBRANCH_crownbay-noemgd = "yocto/standard/preempt-rt/base"
>>>>>> +#SRCREV_machine_pn-linux-yocto-rt_crownbay-noemgd ?= XXXX
>>>>>> +#SRCREV_meta_pn-linux-yocto-rt_crownbay-noemgd ?= XXXX
>>>>>> +
>>>>>> +#KBRANCH_crownbay = "yocto/standard/preempt-rt/base"
>>>>>> +#SRCREV_machine_pn-linux-yocto-rt_crownbay ?= XXXX
>>>>>> +#SRCREV_meta_pn-linux-yocto-rt_crownbay ?= XXXX
>>>>>> diff --git a/meta-crownbay/recipes-kernel/linux/linux-yocto_3.2.bbappend b/meta-crownbay/recipes-kernel/linux/linux-yocto_3.2.bbappend
>>>>>> new file mode 100644
>>>>>> index 0000000..3b02076
>>>>>> --- /dev/null
>>>>>> +++ b/meta-crownbay/recipes-kernel/linux/linux-yocto_3.2.bbappend
>>>>>> @@ -0,0 +1,17 @@
>>>>>> +FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>>>>>> +
>>>>>> +COMPATIBLE_MACHINE_crownbay = "crownbay"
>>>>>> +KMACHINE_crownbay  = "crownbay"
>>>>>> +KBRANCH_crownbay  = "standard/default/crownbay"
>>>>>
>>>>> I believe crownbay no longer requires special patches right? Can we just
>>>>> use the standard/default/base branch here and squash the crownbay branch?
>>>>>
>>>>
>>>> At the moment it doesn't, and I'll probably submit a patch to do that
>>>> for everything that it make sense for again after things are functional
>>>> with the simple changes first.
>>>
>>> There's one catch with this. We currently have the graphics drivers staged as
>>> topic branches so they can be in tree, and be kept pristine. The BSPs merge
>>> the graphics topic branch they want, and we can leverage common commits
>>> across all the users.
>>>
>>> If you drop the BSP branch, then the graphics changes need to be universally
>>> safe for all similar BSPs, since that merge will now be to a shared branch.
>>> That's normally fine, but for the case where we have multiple emgd versions,
>>> it can break things.
>>>
>>> We have complete flexibility to how we stage the branches, and how we
>>> generate the content that is built, so this can change .. but that's
>>> how we currently
>>> have it setup. Those graphics merges are board specific changes and require
>>> a branch.
>>>
>>
>> That's fine, I'm perfectly happy to have per-BSP machine branches.
>> They're cheap, and I don't really see the reason to be so parsimonious
>> with them.  Also, they're always there, so if we do need to have a place
>> to put the odd machine-specific patch now and then we don't have to add
>> a new branch when we need to add those patches, or remove them once
>> they're gone.  I guess the system was kind of designed for that (machine
>> branches, even if empty)?
> 
> Exactly. We can collapse them where it makes sense, and keep there where
> we need them. A machine branch is just that, a topic branch for development
> and implicit documentation of a supported board. If a board may be extended
> in the future .. a branch is nice to have.
> 
> I'm in favour of keeping the count in control, but see no need to collapse
> them down completely. That and I spent an hour trying to figure out
> how to do some fancy merge logic and while it could be done, it just
> makes things more complex. I'd prefer branches to overly complex
> branch management logic.
> 

Agreed on the concept. What I'm not understanding is how is having to
get yocto/emgd-1.10 to merge with standard/base any different than
having to get it to merge with:

standard/default/crownbay
standard/default/common-pc-64/sugarbay
standard/default/fri2

etc.

emgd isn't premerged into these machine branches if I understand the scc
files correctly, so how is this any different? (I'm sure it is, I trust
you here, I would just like to understand what I'm missing).

--
Darren

> Cheers,
> 
> Bruce
> 
>>
>>>
>>>>
>>>>>> +KERNEL_FEATURES_append_crownbay += " cfg/smp.scc"
>>>>>> +
>>>>>> +COMPATIBLE_MACHINE_crownbay-noemgd = "crownbay-noemgd"
>>>>>> +KMACHINE_crownbay-noemgd  = "crownbay"
>>>>>> +KBRANCH_crownbay-noemgd  = "standard/default/crownbay"
>>>>>> +KERNEL_FEATURES_append_crownbay-noemgd += " cfg/smp.scc"
>>>>>> +
>>>>>> +SRCREV_machine_pn-linux-yocto_crownbay ?= "4471c11c7755727219b673cb887d8a13b8715aba"
>>>>>> +SRCREV_meta_pn-linux-yocto_crownbay ?= "64840f55ee144e9814278eaa8e3f33dd60da892c"
>>>>>> +
>>>>>> +SRCREV_machine_pn-linux-yocto_crownbay-noemgd ?= "4471c11c7755727219b673cb887d8a13b8715aba"
>>>>>> +SRCREV_meta_pn-linux-yocto_crownbay-noemgd ?= "64840f55ee144e9814278eaa8e3f33dd60da892c"
>>>>>
>>>>> The meta SRCREV shouldn't be unique from the base linux-yocto_3.2.bb
>>>>> recipe, so this can be dropped and save the effort of updating it later.
>>>>>
>>>>
>>>> I don't really want to let the meta SRCREV float - I've run into a
>>>> couple nasty problems in the past letting that happen. i.e. nobody does
>>>> runtime testing of the BSPs when they change the meta SRCREV in the base
>>>> recipe.
>>>
>>> runtime testing is the hard part. I can build them .. but can't boot them all!
>>>
>>
>> Exactly, which is why I'm happy to push the SRCREVs for a BSP once I've
>> tested it...
>>
>> Tom
>>
>>> Cheers,
>>>
>>> Bruce
>>>
>>>>
>>>>> If we use the standard/default/base branch, the machine SRCREV can also
>>>>> be dropped.
>>>>>
>>>>
>>>> Agreed, if the machine branch changes to standard/default/base, I'll
>>>> change that too.
>>>>
>>>> Tom
>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> yocto mailing list
>>>> yocto at yoctoproject.org
>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> yocto mailing list
>> yocto at yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
> 

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

More information about the yocto mailing list