[yocto] Configuration fragments not making it into kernel configuration

Jonathan Haws Jonathan.Haws at sdl.usu.edu
Mon Oct 2 08:05:28 PDT 2017


On Mon, 2017-10-02 at 10:54 -0400, Bruce Ashfield wrote:
> On 09/30/2017 11:22 PM, Jonathan Haws wrote:
> > 
> > All,
> > 
> > I've created a bbappend that appends to the linux-yocto-rt recipe
> > to
> > simply apply configuration fragments.  I've been using this recipe
> > for
> > some time (through many releases) but since I moved to the morty
> > branch
> > my fragments aren't getting applied to the actual kernel
> > configuration.
> >   The kernel_configcheck task doesn't catch the error either.
> > 
> > What I'm trying to do in a nutshell is disable the in-kernel IGB
> > driver
> > and use my own, patched version.  The configuration fragments are
> > installed by my recipe in:
> > 
> > <build>/tmp/work/corei7-64-intel-common-sigma-linux/linux-yocto-
> > rt/4.8.3+gitAUTOINC+6d028d2818_4057556c04-r0/
> > 
> > However the .config file at:
> > 
> >   <build>/tmp/work/corei7-64-intel-common-sigma-linux/linux-yocto-
> > rt/4.8.3+gitAUTOINC+6d028d2818_4057556c04-r0/linux-corei7-64-intel-
> > common-preempt-rt-build/.config
> > 
> > doesn't have the necessary configuration - it still has the
> > default.
> > 
> > I know I can fix this by simply doing a menuconfig, but that isn't
> > the
> > proper way to do it - I have multiple BSP layers that do the same
> > thing
> > and they all behave in the same way.
> > 
> > What am I doing wrong?  I've attached my layer that contains the
> > recipe.  If the fragments are getting installed I think the recipe
> > is
> > working right - but is there something in the lower-level class
> > that
> > isn't working or do I have a configuration that is breaking it?
> I did a build with morty and your BSP, and I'm not seeing
> the same results.
> 
> One notable difference is that if you are using the tip of
> the morty branches, you should get 4.8.17, not 4.8.3.
> 
> I did zero extra configuration, just added your layer, meta-intel
> and then bitbaked linux-yocto-rt.

I just noticed that my meta-intel layer was a few commits behind, a
likely culprit for what I'm seeing.  I'm rebuilding to see what I get.
I'll report back when I have something.

If this doesn't solve my issue, would you recommend wiping my sstate?
I've already wiped out tmp without success.

> Maybe I'm misunderstanding what I see in the BSP layer, but I
> did get IGB disabled:
> 
> :~/poky/build/tmp/work/corei7-64-intel-common-poky-linux/linux-yocto-
> rt/4.8.17+gitAUTOINC+bb6984f46b_9c4f52cb2b-r0/linux-corei7-64-intel-
> common-preempt-rt-build$ 
> grep CONFIG_IGB .config
> # CONFIG_IGB is not set
> CONFIG_IGBVF=m
> 
> And I did get a warning during the build:
> 
> ---------- CONFIG_IGB_DCA -----------------
> Config: CONFIG_IGB_DCA
> From: 
> /home/bruce/poky/build/tmp/work-shared/xpedite7570/kernel-
> source/.kernel-meta/configs/standard/preempt-
> rt/intel/features/dca/dca.cfg
> Requested value:  CONFIG_IGB_DCA=y
> Actual value:
> 
> Config 'IGB_DCA' has the following conditionals:
>    IGB && DCA && !(IGB = y && DCA = m) (value: "n")
> IGB && DCA && !(IGB = y && DCA = m) (value: "n")
> Dependency values are:
>    y [y] m [m] IGB [n] DCA [y]
> 
> --------------------
> 
> Which explains why CONFIG_IGB_DCA didn't make it into the final
> .config
> 
> Can you clarify what you were looking to get for final configuration
> settings ?

The three fragments should disable the Intel IGB driver (CONFIG_IGB not
set), enable some GPIO I2C drivers, and enable direct cache access.

I'm guessing CONFIG_IGB_DCA was set in the original config and
CONFIG_IGB is not being set, so IGB_DCA is getting unset causing the
warning.  I'll adjust my IGB fragment to explicity disable
CONFIG_IGB_DCA as well.

> > 
> > 
> > Any help or direction is appreciated.  This has been really
> > frustrating
> > since I know I've done this before and all the threads I've found
> > on
> > the lists from before haven't really given an answer - maybe I just
> > missed the golden thread?
> > 
> > Thanks!
> > Jon
> > 
> > 
> > 


More information about the yocto mailing list