Re: Problem overwriting default kernel config values

[Bruce Ashfield <bruce.ashfield@windriver.com>]

On 2015-07-18 11:53 PM, Bruce Ashfield wrote:
> On 2015-07-17 9:35 PM, Ryan Soussan wrote:
>> Hello,
>> We're having a problem overwriting the default linux kernel config
>> values.  We tried adding our own .cfg file to our layer and appending it
>> to the source url of the linux-yocto bitbake file.  The variable in our
>> case is not getting overwritten though (changing CONFIG_ATH5K=m to =y).
>> Here's some relevant output from mismatch.txt:
>> Value requested for CONFIG_ATH5K not in final .config
>>        Requested value:  CONFIG_ATH5K=y
>>                  Actual value:     CONFIG_ATH5K=m
>>
>> And basically the same error message in missing_required.cfg.  So it
>> looks like yocto is seeing our request but ignoring it.  The source code
>> for these messages is located here:
>> http://git.yoctoproject.org/cgit/cgit.cgi/yocto-kernel-tools/tree/tools/kconf_check
>>
>>
>> We were following the instructions for editing the config file located
>> in the linux directory of the meta-skeleton layer in poky.   Any help
>> would be appreciated!
>>
>
> What release/branch are you using ? This is a test case that I run
> ever release (and use every day), so the overrides do work.
>
> The kernel configuration system doesn't have the opportunity to
> ignore settings. They are consolidated and then passed to the kernel's
> config subsystem and then the results audited.
>
> I'll run a similar test here, since if something else later in the
> configuration is selecting that driver as a module, or another constraint
> is kicking in .. you will end up with a module, no matter what you
> set in your fragment.

And yes, it was a contraint in the end. I needed this in my fragment to
flip ATH5K to =y

CONFIG_ATH5K=y
CONFIG_ATH_CARDS=y
CONFIG_ATH_COMMON=y
CONFIG_CFG80211=y
CONFIG_R8723AU=y
CONFIG_MAC80211=y

I'm working on some diagnostics and symbol lookups that will help with
this in the future .. but it is much more challenging than you'd expect!

Cheers,

Bruce

>
> Bruce
>
>> Thanks,
>> Ryan
>>
>>
>