[yocto] Build external module against Yocto kernel

Bruce Ashfield bruce.ashfield at windriver.com
Thu Jan 31 20:50:52 PST 2013


On 13-01-23 10:17 AM, Patrick Turley wrote:
>
> On Jan 23, 2013, at 7:48 AM, Bruce Ashfield<bruce.ashfield at windriver.com>
>   wrote:
>> On 13-01-23 12:34 AM, Patrick Turley wrote:
>>>
>>> On Jan 22, 2013, at 11:17 PM, Bruce Ashfield<bruce.ashfield at windriver.com>  wrote:
>>>
>>>> On 13-01-23 12:14 AM, Patrick Turley wrote:
>>>>> On Jan 22, 2013, at 10:43 PM, Bruce Ashfield<bruce.ashfield at windriver.com>   wrote:
>>>>>> On 13-01-22 9:26 PM, Patrick Turley wrote:
>>
>> Argh. I'll have to just run the commands myself and stop spamming the
>> list with ideas :) It's just a matter of making lkc accept the defaults
>> (i.e. you could also use allyesconfig, or allnoconfig) or even better
>> not trigger that config check at all.
>
> You're very kind to have spent so much time on my problem already. I look forward to hearing back.

I'm not sure if you are still interested in this topic, but I took
a few minutes to look into this more today .. just to understand
exactly what is happening.

It is what was discussed on the thread already, when you invoke
make scripts, there is an explicit dependency on auto.conf and
that is what triggers the make oldconfig if the .config is newer
than it is. Technically we are safe from this, assuming that the
.config and captured auto.conf match, and that auto.conf is in the
SDK.

The other way that oldconfig is triggered in my experience (and
testing today) is what we mentioned before. If your .config was
generated with ARCH=<foo> (even ARCH=i386 the default) and you then
execute 'make scripts', you'll trigger the oldconfig.

So to avoid it, you should execute your make scripts with ARCH=<your arch>
on the command line.

As for saving ARCH in the .config, it has been considered in the past,
but never implemented. Other elements such as CROSS_COMPILE are now
saved, but not ARCH= since it isn't directly used in the .config, it's
a Makefile construct.

Cheers,

Bruce

>




More information about the yocto mailing list