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

Tue Mar 13 19:40:07 PDT 2012

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.

>
>> > +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!

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

-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"