[yocto] Configuration fragments not making it into kernel configuration

[Bruce Ashfield]

On 2017-10-02 11:23 AM, Jonathan Haws wrote:
>>>> 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.
> 
> Issue resolved.  Fragments now making it into the kernel configuration
> correctly.  Thanks, Bruce!
> 
>>>
>>> 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.
> 
> I get the same warning, and I believe it is because that setting is
> only available if CONFIG_IGB is 'y' or 'm'.  Since I'm removing
> CONFIG_IGB, CONFIG_IGB_DCA isn't even an option.  If I add "#
> CONFIG_IGB_DCA is not set" to my fragment, I get the following warning:
> ---------- CONFIG_IGB_DCA -----------------
> Config: CONFIG_IGB_DCA
> From: /opt/yocto/poky/build-teisit/tmp/work-shared/xpedite7570/kernel-
> source/.kernel-meta/configs/standard/preempt-
> rt/intel/features/dca/dca.cfg /opt/yocto/poky/build-teisit/tmp/work-
> shared/xpedite7570/kernel-source/.kernel-meta/configs/standard/preempt-
> rt/intel/Remove_Intel_IGB_driver.cfg
> Requested value:  # CONFIG_IGB_DCA is not set
> 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]
> 
> What is the best way to clean up this type of warning - one where the
> setting is a conditional option and is enabled in the default
> configuration but a fragment removes the parent option?

This actually shoots through a gap in the audit code. Not a bug,
but due to a historical way that the options are flagged.

Only mismatches in 'hardware' options are reported, since that could
cause a boot failure or other similary severe issue with a board.

The option in question is tagged as 'hardware' by the upper layers
and there's currently no way to undo that tag.

The warning you are getting indicates that while the option was
set to a value, it wasn't in the final .config at all .. i.e. in this
case a dependency is gone so the option doesn't make it in at all
(off or non).

Since it is only a warning, and we understand it, it can be
ignored. I'm going to add a method in master that would allow that
hardware tag of the option to be cleared, and then it wouldn't be
in the final .config.

Cheers,

Bruce


>