Build external module against Yocto kernel

Build external module against Yocto kernel

[Patrick Turley]

I have to build a module from a third-party that has nothing to do with Yocto.

I want to build this module against the kernel Yocto is giving me.

The Make file for this module has a build command like this:

    make -C $(LINUX_DIR) M=`pwd` $(ENV) \
        EXTRA_CFLAGS="$(EXTRA_CFLAGS)" modules

Obviously, this command needs to connect with either the Linux source tree or something like a "kernel-headers" package.

I used the meta-toolchain-sdk recipe to produce an SDK, and I installed it. Unfortunately, I don't see a "kernel-header" equivalent in there.

This leads me to imagine I must point this command at some sub-tree within the Yocto output (probably under tmp/sysroots). And, if I want that tree available elsewhere, I have to package it up into a tarball and transport it.

Usually, Yocto is way ahead of me on these sorts of things, and there's already a graceful way to deal with this -- I just haven't figure it out yet.

What am I missing?

Re: Build external module against Yocto kernel

[Brian Lloyd]

[-- Attachment #1: Type: text/plain, Size: 1569 bytes --]

Try this in work documentation and let us know how it helps or if there
is something missing that would help more:
http://www.yoctoproject.org/docs/hart/kernel-dev/kernel-dev.html#incorporating-out-of-tree-modules

I just did the exact same thing and was happy to discover there is
support in yocto for doing just this.

Brian

On Mon, 2013-01-14 at 23:27 +0000, Patrick Turley wrote:

> I have to build a module from a third-party that has nothing to do with Yocto.
> 
> I want to build this module against the kernel Yocto is giving me.
> 
> The Make file for this module has a build command like this:
> 
>     make -C $(LINUX_DIR) M=`pwd` $(ENV) \
>         EXTRA_CFLAGS="$(EXTRA_CFLAGS)" modules
> 
> Obviously, this command needs to connect with either the Linux source tree or something like a "kernel-headers" package.
> 
> I used the meta-toolchain-sdk recipe to produce an SDK, and I installed it. Unfortunately, I don't see a "kernel-header" equivalent in there.
> 
> This leads me to imagine I must point this command at some sub-tree within the Yocto output (probably under tmp/sysroots). And, if I want that tree available elsewhere, I have to package it up into a tarball and transport it.
> 
> Usually, Yocto is way ahead of me on these sorts of things, and there's already a graceful way to deal with this -- I just haven't figure it out yet.
> 
> What am I missing?
> 
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



[-- Attachment #2: Type: text/html, Size: 2087 bytes --]

Re: Build external module against Yocto kernel

[Brian Lloyd]

[-- Attachment #1: Type: text/plain, Size: 2099 bytes --]

Or better yet, now that it is past initial, use
http://www.yoctoproject.org/docs/1.4/kernel-dev/kernel-dev.html#incorporating-out-of-tree-modules.  :)
It worked fine for 1.2 (denzil) for me, though it is written for a later
one.

Brian

On Tue, 2013-01-15 at 11:07 -0600, Brian Lloyd wrote:

> Try this in work documentation and let us know how it helps or if
> there is something missing that would help more:
> http://www.yoctoproject.org/docs/hart/kernel-dev/kernel-dev.html#incorporating-out-of-tree-modules
> 
> I just did the exact same thing and was happy to discover there is
> support in yocto for doing just this.
> 
> Brian
> 
> On Mon, 2013-01-14 at 23:27 +0000, Patrick Turley wrote: 
> 
> > I have to build a module from a third-party that has nothing to do with Yocto.
> > 
> > I want to build this module against the kernel Yocto is giving me.
> > 
> > The Make file for this module has a build command like this:
> > 
> >     make -C $(LINUX_DIR) M=`pwd` $(ENV) \
> >         EXTRA_CFLAGS="$(EXTRA_CFLAGS)" modules
> > 
> > Obviously, this command needs to connect with either the Linux source tree or something like a "kernel-headers" package.
> > 
> > I used the meta-toolchain-sdk recipe to produce an SDK, and I installed it. Unfortunately, I don't see a "kernel-header" equivalent in there.
> > 
> > This leads me to imagine I must point this command at some sub-tree within the Yocto output (probably under tmp/sysroots). And, if I want that tree available elsewhere, I have to package it up into a tarball and transport it.
> > 
> > Usually, Yocto is way ahead of me on these sorts of things, and there's already a graceful way to deal with this -- I just haven't figure it out yet.
> > 
> > What am I missing?
> > 
> > _______________________________________________
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
> 
> 
> 
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



[-- Attachment #2: Type: text/html, Size: 2881 bytes --]

Re: Build external module against Yocto kernel

[Patrick Turley]

[-- Attachment #1: Type: text/plain, Size: 3961 bytes --]

Thank you for directing me toward that documentation. As it happens, I have already read that, and it doesn't apply.

The section you mentioned begins with this text:

While it is always preferable to work with sources integrated into the Linux kernel sources, if you need an external kernel module, the hello-mod.bb recipe is available as a template from which you can create your own out-of-tree Linux kernel module recipe.

The approach here is to create a recipe that will build a module outside the kernel tree, but still within the Yocto system.

That isn't what I'm doing.

I have source code for a kernel module that is entirely outside Yocto.  I'm *not* going to write a recipe for this module and integrate it into a Yocto layer.

Here's a link to instructions on how I would do this in Ubuntu:

http://www.cyberciti.biz/tips/build-linux-kernel-module-against-installed-kernel-source-tree.html

As you can see, Ubuntu (and, of course, other major distributions) have "kernel-headers" packages that carry all the artifacts one needs to build a module "after the fact."

Does Yocto have a mechanism for packaging up the necessary artifacts and making them available *outside* the Yocto build system and long *after* the Yocto build is finished?  Does Yocto recognize the necessity of this?  The best I've been able to do is point my module build process at something like this:

LINUX_DIR=/home/pturley/yocto-mpu-build/tmp/work/dm8148_mpu-poky-linux-gnueabi/linux-ti81xx-psp-2.6.37-r0+spawnlabs+r0/git

This works but it's messy, unreliable and inconvenient.

So, my question remains: Does Yocto have a graceful way of dealing with this situation, perhaps like Ubuntu and friends?


On Jan 15, 2013, at 11:09 AM, Brian Lloyd <blloyd@familyhonor.net<mailto:blloyd@familyhonor.net>> wrote:

Or better yet, now that it is past initial, use http://www.yoctoproject.org/docs/1.4/kernel-dev/kernel-dev.html#incorporating-out-of-tree-modules. <http://www.yoctoproject.org/docs/1.4/kernel-dev/kernel-dev.html#incorporating-out-of-tree-modules.%C2%A0>  :)
It worked fine for 1.2 (denzil) for me, though it is written for a later one.

Brian

On Tue, 2013-01-15 at 11:07 -0600, Brian Lloyd wrote:
Try this in work documentation and let us know how it helps or if there is something missing that would help more:
http://www.yoctoproject.org/docs/hart/kernel-dev/kernel-dev.html#incorporating-out-of-tree-modules

I just did the exact same thing and was happy to discover there is support in yocto for doing just this.

Brian

On Mon, 2013-01-14 at 23:27 +0000, Patrick Turley wrote:

I have to build a module from a third-party that has nothing to do with Yocto.

I want to build this module against the kernel Yocto is giving me.

The Make file for this module has a build command like this:

    make -C $(LINUX_DIR) M=`pwd` $(ENV) \
        EXTRA_CFLAGS="$(EXTRA_CFLAGS)" modules

Obviously, this command needs to connect with either the Linux source tree or something like a "kernel-headers" package.

I used the meta-toolchain-sdk recipe to produce an SDK, and I installed it. Unfortunately, I don't see a "kernel-header" equivalent in there.

This leads me to imagine I must point this command at some sub-tree within the Yocto output (probably under tmp/sysroots). And, if I want that tree available elsewhere, I have to package it up into a tarball and transport it.

Usually, Yocto is way ahead of me on these sorts of things, and there's already a graceful way to deal with this -- I just haven't figure it out yet.

What am I missing?

_______________________________________________
yocto mailing list
yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>
https://lists.yoctoproject.org/listinfo/yocto



_______________________________________________
yocto mailing list
yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>
https://lists.yoctoproject.org/listinfo/yocto




[-- Attachment #2: Type: text/html, Size: 5803 bytes --]

Re: Build external module against Yocto kernel

[Bruce Ashfield]

On 13-01-15 12:54 PM, Patrick Turley wrote:
> Thank you for directing me toward that documentation. As it happens, I
> have already read that, and it doesn't apply.
>
> The section you mentioned begins with this text:
>
>     While it is always preferable to work with sources integrated into
>     the Linux kernel sources, if you need an external kernel module, the
>     |hello-mod.bb| recipe is available as a template from which you can
>     create your own out-of-tree Linux kernel module recipe.
>
>
> The approach here is to create a recipe that will build a module outside
> the kernel tree, but still within the Yocto system.
>
> That isn't what I'm doing.
>
> I have source code for a kernel module that is entirely outside Yocto.
>   I'm *not* going to write a recipe for this module and integrate it
> into a Yocto layer.
>
> Here's a link to instructions on how I would do this in Ubuntu:
>
>     http://www.cyberciti.biz/tips/build-linux-kernel-module-against-installed-kernel-source-tree.html
>
>
> As you can see, Ubuntu (and, of course, other major distributions) have
> "kernel-headers" packages that carry all the artifacts one needs to
> build a module "after the fact."
>
> Does Yocto have a mechanism for packaging up the necessary artifacts and
> making them available *outside* the Yocto build system and long *after*
> the Yocto build is finished?  Does Yocto recognize the necessity of
> this?  The best I've been able to do is point my module build process at
> something like this:
>
> LINUX_DIR=/home/pturley/yocto-mpu-build/tmp/work/dm8148_mpu-poky-linux-gnueabi/linux-ti81xx-psp-2.6.37-r0+spawnlabs+r0/git
>
> This works but it's messy, unreliable and inconvenient.
>
> So, my question remains: Does Yocto have a graceful way of dealing with
> this situation, perhaps like Ubuntu and friends?

There are ways to do this, your requirement is the same as the on-target
module building requirement. Have enough of the kernel source packaged
to build modules on the target, after it has booted.

The trick is packaging things properly to not get binary/target elements
in the SDK/native packages, and to package just enough for the build. But
the issues have been explored and there was a plan. I know that Darren
(cc'd) has looked into this more than I have recently.

I can't locate the bugzilla entries on this at the moment, but I recall
that some parts were still missing, but may be addressed in yocto 1.4,
when I find the bug numbers, I'll have a better idea.

Cheers,

Bruce



>
>
> On Jan 15, 2013, at 11:09 AM, Brian Lloyd <blloyd@familyhonor.net
> <mailto:blloyd@familyhonor.net>> wrote:
>
>> Or better yet, now that it is past initial, use
>> http://www.yoctoproject.org/docs/1.4/kernel-dev/kernel-dev.html#incorporating-out-of-tree-modules.
>> <http://www.yoctoproject.org/docs/1.4/kernel-dev/kernel-dev.html#incorporating-out-of-tree-modules.%C2%A0>
>> :)
>> It worked fine for 1.2 (denzil) for me, though it is written for a
>> later one.
>>
>> Brian
>>
>> On Tue, 2013-01-15 at 11:07 -0600, Brian Lloyd wrote:
>>> Try this in work documentation and let us know how it helps or if
>>> there is something missing that would help more:
>>> http://www.yoctoproject.org/docs/hart/kernel-dev/kernel-dev.html#incorporating-out-of-tree-modules
>>>
>>> I just did the exact same thing and was happy to discover there is
>>> support in yocto for doing just this.
>>>
>>> Brian
>>>
>>> On Mon, 2013-01-14 at 23:27 +0000, Patrick Turley wrote:
>>>> I have to build a module from a third-party that has nothing to do with Yocto.
>>>>
>>>> I want to build this module against the kernel Yocto is giving me.
>>>>
>>>> The Make file for this module has a build command like this:
>>>>
>>>>      make -C $(LINUX_DIR) M=`pwd` $(ENV) \
>>>>          EXTRA_CFLAGS="$(EXTRA_CFLAGS)" modules
>>>>
>>>> Obviously, this command needs to connect with either the Linux source tree or something like a "kernel-headers" package.
>>>>
>>>> I used the meta-toolchain-sdk recipe to produce an SDK, and I installed it. Unfortunately, I don't see a "kernel-header" equivalent in there.
>>>>
>>>> This leads me to imagine I must point this command at some sub-tree within the Yocto output (probably under tmp/sysroots). And, if I want that tree available elsewhere, I have to package it up into a tarball and transport it.
>>>>
>>>> Usually, Yocto is way ahead of me on these sorts of things, and there's already a graceful way to deal with this -- I just haven't figure it out yet.
>>>>
>>>> What am I missing?
>>>>
>>>> _______________________________________________
>>>> yocto mailing list
>>>> yocto@yoctoproject.org  <mailto:yocto@yoctoproject.org>
>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>
>>> _______________________________________________
>>> yocto mailing list
>>> yocto@yoctoproject.org  <mailto:yocto@yoctoproject.org>
>>> https://lists.yoctoproject.org/listinfo/yocto
>>
>
>
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>

Re: Build external module against Yocto kernel

[Patrick Turley]

On Jan 15, 2013, at 12:00 PM, Bruce Ashfield <bruce.ashfield@windriver.com>
 wrote:

> On 13-01-15 12:54 PM, Patrick Turley wrote:
>> Thank you for directing me toward that documentation. As it happens, I
>> have already read that, and it doesn't apply.
> 
> There are ways to do this, your requirement is the same as the on-target
> module building requirement. Have enough of the kernel source packaged
> to build modules on the target, after it has booted.

Well, I still want to cross-compile them, but I see your point.

> The trick is packaging things properly to not get binary/target elements
> in the SDK/native packages, and to package just enough for the build. But
> the issues have been explored and there was a plan. I know that Darren
> (cc'd) has looked into this more than I have recently.
> 
> I can't locate the bugzilla entries on this at the moment, but I recall
> that some parts were still missing, but may be addressed in yocto 1.4,
> when I find the bug numbers, I'll have a better idea.

As I expected, someone else has already thought about this. This isn't the most common approach so it makes sense that it's been a lower priority. The good news for me is that I know I'm not missing something, so I can stop looking for it.

Re: Build external module against Yocto kernel

[Bruce Ashfield]

On 13-01-15 01:26 PM, Patrick Turley wrote:
> On Jan 15, 2013, at 12:00 PM, Bruce Ashfield <bruce.ashfield@windriver.com>
>   wrote:
>
>> On 13-01-15 12:54 PM, Patrick Turley wrote:
>>> Thank you for directing me toward that documentation. As it happens, I
>>> have already read that, and it doesn't apply.
>>
>> There are ways to do this, your requirement is the same as the on-target
>> module building requirement. Have enough of the kernel source packaged
>> to build modules on the target, after it has booted.
>
> Well, I still want to cross-compile them, but I see your point.
>
>> The trick is packaging things properly to not get binary/target elements
>> in the SDK/native packages, and to package just enough for the build. But
>> the issues have been explored and there was a plan. I know that Darren
>> (cc'd) has looked into this more than I have recently.
>>
>> I can't locate the bugzilla entries on this at the moment, but I recall
>> that some parts were still missing, but may be addressed in yocto 1.4,
>> when I find the bug numbers, I'll have a better idea.
>
> As I expected, someone else has already thought about this. This isn't the most common approach so it makes sense that it's been a lower priority. The good news for me is that I know I'm not missing something, so I can stop looking for it.

I finally found the entries that I was recalling earlier. They are:

https://bugzilla.yoctoproject.org/show_bug.cgi?id=241
https://bugzilla.yoctoproject.org/show_bug.cgi?id=1614
https://bugzilla.yoctoproject.org/show_bug.cgi?id=2968

1614 and 2968 are the most interesting for what you are asking.

As you can see the net result of those bugs is that you can get the
right parts of the kernel tree in SDK packages, since they include
dev packages, and with what is currently in kernel-dev .. it should
be enough to build against in the SDK (perhaps with just the LDFLAGS
tweaks mentioned in the other thread). The sources should be part
of the sysroot, and hence available when that is packaged for use
outside of bitbake/yocto.

If you aren't seeing kernel-dev in the SDK image, it might be that
TOOLCHAIN_TARGET_TASK doesn't have kernel-dev by default, or something
else is different in the SDK that is being generated in your testing.

I'm only speculating about what might be missing, since I'm not 100%
familiar with the SDK, but perhaps Jessica or others can chime in if
I've led you astray :)

Cheers,

Bruce


>

Re: Build external module against Yocto kernel

[Zhang, Jessica]

Hi Patrick,

According to bug 1614, the kernel dev packages should be included in sdk images.  Please generate your toolchain using "bitbake core-image-sato-sdk -c populate_sdk" which will make the toolchain target sysroot matching your image's sysroot (this is a new feature of 1.3) as long as your image is a sdk image.  If you still run into issue(missing kernel headers, etc.), then that's a bug of the 1614 patch that we need to reopen it.

For your LDFLAGS question in another email thread, the yocto SDK is mainly produced for application developer, but seems we are hearing more usage request for it to support kernel module build as well.  As Eric pointed, can you just set LDFLAGS="" and we'll add that instruction to developer's manual?

Thanks,
Jessica

-----Original Message-----
From: yocto-bounces@yoctoproject.org [mailto:yocto-bounces@yoctoproject.org] On Behalf Of Bruce Ashfield
Sent: Tuesday, January 15, 2013 10:38 AM
To: Patrick Turley
Cc: yocto@yoctoproject.org; Darren Hart; Brian Lloyd
Subject: Re: [yocto] Build external module against Yocto kernel

On 13-01-15 01:26 PM, Patrick Turley wrote:
> On Jan 15, 2013, at 12:00 PM, Bruce Ashfield <bruce.ashfield@windriver.com>
>   wrote:
>
>> On 13-01-15 12:54 PM, Patrick Turley wrote:
>>> Thank you for directing me toward that documentation. As it happens,
>>> I have already read that, and it doesn't apply.
>>
>> There are ways to do this, your requirement is the same as the
>> on-target module building requirement. Have enough of the kernel
>> source packaged to build modules on the target, after it has booted.
>
> Well, I still want to cross-compile them, but I see your point.
>
>> The trick is packaging things properly to not get binary/target
>> elements in the SDK/native packages, and to package just enough for
>> the build. But the issues have been explored and there was a plan. I
>> know that Darren
>> (cc'd) has looked into this more than I have recently.
>>
>> I can't locate the bugzilla entries on this at the moment, but I
>> recall that some parts were still missing, but may be addressed in
>> yocto 1.4, when I find the bug numbers, I'll have a better idea.
>
> As I expected, someone else has already thought about this. This isn't the most common approach so it makes sense that it's been a lower priority. The good news for me is that I know I'm not missing something, so I can stop looking for it.

I finally found the entries that I was recalling earlier. They are:

https://bugzilla.yoctoproject.org/show_bug.cgi?id=241
https://bugzilla.yoctoproject.org/show_bug.cgi?id=1614
https://bugzilla.yoctoproject.org/show_bug.cgi?id=2968

1614 and 2968 are the most interesting for what you are asking.

As you can see the net result of those bugs is that you can get the right parts of the kernel tree in SDK packages, since they include dev packages, and with what is currently in kernel-dev .. it should be enough to build against in the SDK (perhaps with just the LDFLAGS tweaks mentioned in the other thread). The sources should be part of the sysroot, and hence available when that is packaged for use outside of bitbake/yocto.

If you aren't seeing kernel-dev in the SDK image, it might be that TOOLCHAIN_TARGET_TASK doesn't have kernel-dev by default, or something else is different in the SDK that is being generated in your testing.

I'm only speculating about what might be missing, since I'm not 100% familiar with the SDK, but perhaps Jessica or others can chime in if I've led you astray :)

Cheers,

Bruce


>

_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: Build external module against Yocto kernel

[Darren Hart]

On 01/15/2013 10:38 AM, Bruce Ashfield wrote:
> On 13-01-15 01:26 PM, Patrick Turley wrote:
>> On Jan 15, 2013, at 12:00 PM, Bruce Ashfield <bruce.ashfield@windriver.com>
>>   wrote:
>>
>>> On 13-01-15 12:54 PM, Patrick Turley wrote:
>>>> Thank you for directing me toward that documentation. As it happens, I
>>>> have already read that, and it doesn't apply.
>>>
>>> There are ways to do this, your requirement is the same as the on-target
>>> module building requirement. Have enough of the kernel source packaged
>>> to build modules on the target, after it has booted.
>>
>> Well, I still want to cross-compile them, but I see your point.
>>
>>> The trick is packaging things properly to not get binary/target elements
>>> in the SDK/native packages, and to package just enough for the build. But
>>> the issues have been explored and there was a plan. I know that Darren
>>> (cc'd) has looked into this more than I have recently.
>>>
>>> I can't locate the bugzilla entries on this at the moment, but I recall
>>> that some parts were still missing, but may be addressed in yocto 1.4,
>>> when I find the bug numbers, I'll have a better idea.
>>
>> As I expected, someone else has already thought about this. This isn't the most common approach so it makes sense that it's been a lower priority. The good news for me is that I know I'm not missing something, so I can stop looking for it.
> 
> I finally found the entries that I was recalling earlier. They are:
> 
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=241
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=1614
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=2968
> 
> 1614 and 2968 are the most interesting for what you are asking.
> 
> As you can see the net result of those bugs is that you can get the
> right parts of the kernel tree in SDK packages, since they include
> dev packages, and with what is currently in kernel-dev .. it should
> be enough to build against in the SDK (perhaps with just the LDFLAGS
> tweaks mentioned in the other thread). The sources should be part
> of the sysroot, and hence available when that is packaged for use
> outside of bitbake/yocto.
> 
> If you aren't seeing kernel-dev in the SDK image, it might be that
> TOOLCHAIN_TARGET_TASK doesn't have kernel-dev by default, or something
> else is different in the SDK that is being generated in your testing.
> 
> I'm only speculating about what might be missing, since I'm not 100%
> familiar with the SDK, but perhaps Jessica or others can chime in if
> I've led you astray :)
> 

Thanks for keeping this going Bruce. Yes, kernel-dev is the package for
the target. The only trick here is that we currently purge the host
binaries which means that you need to build scripts on the target prior
to building the module.

I think this might be missing from the new kernel manual as it isn't a
particularly common use-case, and is rather orthogonal to the way the
tooling has been designed (not to say it can't be done).

Patrick, please keep us posted if this continues to not work for you. I
will open a bug to include a section about this in the kernel
development manual.

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel

Re: Build external module against Yocto kernel

[Patrick Turley]

On Jan 16, 2013, at 11:11 AM, Darren Hart <dvhart@linux.intel.com> wrote:
> On 01/15/2013 10:38 AM, Bruce Ashfield wrote:
>> 
>> I finally found the entries that I was recalling earlier. They are:
>> 
>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=241
>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=1614
>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=2968
>> 
>> 1614 and 2968 are the most interesting for what you are asking.
>> 
>> As you can see the net result of those bugs is that you can get the
>> right parts of the kernel tree in SDK packages, since they include
>> dev packages, and with what is currently in kernel-dev .. it should
>> be enough to build against in the SDK (perhaps with just the LDFLAGS
>> tweaks mentioned in the other thread). The sources should be part
>> of the sysroot, and hence available when that is packaged for use
>> outside of bitbake/yocto.
>> 
>> If you aren't seeing kernel-dev in the SDK image, it might be that
>> TOOLCHAIN_TARGET_TASK doesn't have kernel-dev by default, or something
>> else is different in the SDK that is being generated in your testing.
>> 
>> I'm only speculating about what might be missing, since I'm not 100%
>> familiar with the SDK, but perhaps Jessica or others can chime in if
>> I've led you astray :)
>> 
> 
> Thanks for keeping this going Bruce. Yes, kernel-dev is the package for
> the target. The only trick here is that we currently purge the host
> binaries which means that you need to build scripts on the target prior
> to building the module.
> 
> I think this might be missing from the new kernel manual as it isn't a
> particularly common use-case, and is rather orthogonal to the way the
> tooling has been designed (not to say it can't be done).
> 
> Patrick, please keep us posted if this continues to not work for you. I
> will open a bug to include a section about this in the kernel
> development manual.

I got sick and was also diverted to other things, so I apologize for not responding sooner. I am very appreciative of every CPU cycle you have all spent considering this issue -- I wouldn't want you to imagine otherwise.

I will gladly have a look at those issues and absorb the information you've offered. I will also let you all know if it works for me.

Re: Build external module against Yocto kernel

[Christian Ege]

 Hi,
 I am not sure if this is the problem you are struggling with.
 I am wondering why class module.bbclass behaves completely different
 than kernel.bbclacc

>  copy the "hello-mod_0.1.bb" and "files" folder into my taget layer
> "meta-intel/meta-jasperforest/recipe-kernel", then add 
> "MACHINE_EXTRA_
> RDEPENDS += "kernel-module-hello" in the conf/local.conf
>  after build and boot, there's no "hello.ko" found in the binary 
> image
>  also there's no hello.ko in the "tmp/work/..." folder

 If you hello-mod_0.1.bb inherits module class there is no mechanism
 to create the kernel-module package. This only applies to the 
 kernel.bbclass

 http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/module.bbclass
 http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/module-base.bbclass

 Have a look at kernel.bbclass instead shows some pathon code which 
 handles the module package creation:
 http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/kernel.bbclass#n301

 I've fixed this in my layer by stealing the code from kernel.bbclass
 https://github.com/project-magpie/meta-stlinux/blob/master/recipes-bsp/tdt-driver/tdt-driver.inc

 With this you can also use the following extends with your module:
 module_autoload_aotom = "aotom"
 and
 module_conf_stmfb = "options stmfb 
 display0=1280x720-32@50:8m:pal:yuv:yuv"

 If you are only inherting from module this have not worked for me.

 The next part I had to fight against was the fact that in 
 core-image-minimal the package managment information are stripped and 
 thus no pre hooks are executet. So the module is installed in the image 
 but not loaded on boot-up unless you call update-modules by hand.

 ROOTFS_POSTPROCESS_COMMAND += "remove_packaging_data_files ; "

 To prevent this I've defined an image without the stripping:
 https://github.com/project-magpie/meta-stlinux/blob/master/recipes-core/images/core-image-base.bb

 I hope this clarify things a little bit


 regards,
 Christian

>
>  Eddy
>
> All,
>
> There is a new YP manual under development. It is a development 
> manual
> for Linux kernels in the YP. Darren Hart is the original author of 
> the
> manual as you probably know. It is still being worked on but it is in
> HTML form and now part of the yocto-docs/master branch. It is
> published at
> http://www.yoctoproject.org/docs/1.4/kernel-dev/kernel-dev.html [1].
> Feel free to access it and comment.
>
> Thanks,
>
> Scott
>
> Scott Rifenbark
>
> Intel Corporation
>
> Yocto Project Documentation
>
> 503.712.2702
>
> 503.341.0418 (cell)
>
> _______________________________________________
>
> yocto mailing list
>
> yocto@yoctoproject.org [2]
>
> https://lists.yoctoproject.org/listinfo/yocto [3]
>
>
>
> Links:
> ------
> [1] http://www.yoctoproject.org/docs/1.4/kernel-dev/kernel-dev.html
> [2] mailto:yocto@yoctoproject.org
> [3] https://lists.yoctoproject.org/listinfo/yocto
> Hi,
>
> I am reposting this to the discussion list and copying Darren Hart.
>
> Scott
>
> FROM: Eddy Lai GMail [mailto:eddy.lai.tw@gmail.com]
>  SENT: Monday, January 21, 2013 3:36 PM
>  TO: Rifenbark, Scott M
>  SUBJECT: Re: [yocto] YP Linux Kernel Development Manual
>
> hi
>
>  hi, I follow the kernel development manual "2.5. Incorporating
> Out-of-Tree Modules",
>  copy the "hello-mod_0.1.bb" and "files" folder into my taget layer
> "meta-intel/meta-jasperforest/recipe-kernel", then add 
> "MACHINE_EXTRA_
> RDEPENDS += "kernel-module-hello" in the conf/local.conf
>  after build and boot, there's no "hello.ko" found in the binary 
> image
>  also there's no hello.ko in the "tmp/work/..." folder
>
>  Eddy
>
> All,
>
> There is a new YP manual under development. It is a development 
> manual
> for Linux kernels in the YP. Darren Hart is the original author of 
> the
> manual as you probably know. It is still being worked on but it is in
> HTML form and now part of the yocto-docs/master branch. It is
> published at
> http://www.yoctoproject.org/docs/1.4/kernel-dev/kernel-dev.html [1].
> Feel free to access it and comment.
>
> Thanks,
>
> Scott
>
> Scott Rifenbark
>
> Intel Corporation
>
> Yocto Project Documentation
>
> 503.712.2702
>
> 503.341.0418 (cell)
>
> _______________________________________________
>
> yocto mailing list
>
> yocto@yoctoproject.org [2]
>
> https://lists.yoctoproject.org/listinfo/yocto [3]
>
>
>
> Links:
> ------
> [1] http://www.yoctoproject.org/docs/1.4/kernel-dev/kernel-dev.html
> [2] mailto:yocto@yoctoproject.org
> [3] https://lists.yoctoproject.org/listinfo/yocto


> On Jan 16, 2013, at 11:11 AM, Darren Hart <dvhart@linux.intel.com> 
> wrote:
>> On 01/15/2013 10:38 AM, Bruce Ashfield wrote:
>>>
>>> I finally found the entries that I was recalling earlier. They are:
>>>
>>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=241
>>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=1614
>>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=2968
>>>
>>> 1614 and 2968 are the most interesting for what you are asking.
>>>
>>> As you can see the net result of those bugs is that you can get the
>>> right parts of the kernel tree in SDK packages, since they include
>>> dev packages, and with what is currently in kernel-dev .. it should
>>> be enough to build against in the SDK (perhaps with just the 
>>> LDFLAGS
>>> tweaks mentioned in the other thread). The sources should be part
>>> of the sysroot, and hence available when that is packaged for use
>>> outside of bitbake/yocto.
>>>
>>> If you aren't seeing kernel-dev in the SDK image, it might be that
>>> TOOLCHAIN_TARGET_TASK doesn't have kernel-dev by default, or 
>>> something
>>> else is different in the SDK that is being generated in your 
>>> testing.
>>>
>>> I'm only speculating about what might be missing, since I'm not 
>>> 100%
>>> familiar with the SDK, but perhaps Jessica or others can chime in 
>>> if
>>> I've led you astray :)
>>>
>>
>> Thanks for keeping this going Bruce. Yes, kernel-dev is the package 
>> for
>> the target. The only trick here is that we currently purge the host
>> binaries which means that you need to build scripts on the target 
>> prior
>> to building the module.
>>
>> I think this might be missing from the new kernel manual as it isn't 
>> a
>> particularly common use-case, and is rather orthogonal to the way 
>> the
>> tooling has been designed (not to say it can't be done).
>>
>> Patrick, please keep us posted if this continues to not work for 
>> you. I
>> will open a bug to include a section about this in the kernel
>> development manual.
>
> I got sick and was also diverted to other things, so I apologize for
> not responding sooner. I am very appreciative of every CPU cycle you
> have all spent considering this issue -- I wouldn't want you to
> imagine otherwise.
>
> I will gladly have a look at those issues and absorb the information
> you've offered. I will also let you all know if it works for me.
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Re: Build external module against Yocto kernel

[Patrick Turley]

On Jan 15, 2013, at 1:16 PM, "Zhang, Jessica" <jessica.zhang@intel.com> wrote:

> For your LDFLAGS question in another email thread, the yocto SDK is mainly produced for application developer, but seems we are hearing more usage request for it to support kernel module build as well.  As Eric pointed, can you just set LDFLAGS="" and we'll add that instruction to developer's manual?

I *can* clear the LDFLAGS variable just before building modules against the kernel. That works.

I understand history makes this difficult, and this is a problem OE/Yocto wasn't originally *intended* to solve. My use case in an outlier, and I don't presume to know what "should" be done. On the other hand, I wouldn't want anyone to feel that putting those instructions in the documentation is a "tidy" solution.

Re: Build external module against Yocto kernel

[Patrick Turley]

On Jan 16, 2013, at 11:11 AM, Darren Hart <dvhart@linux.intel.com> wrote:
> On 01/15/2013 10:38 AM, Bruce Ashfield wrote:
>> I finally found the entries that I was recalling earlier. They are:
>> 
>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=241
>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=1614
>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=2968
>> 
>> 1614 and 2968 are the most interesting for what you are asking.
>> 
>> As you can see the net result of those bugs is that you can get the
>> right parts of the kernel tree in SDK packages, since they include
>> dev packages, and with what is currently in kernel-dev .. it should
>> be enough to build against in the SDK (perhaps with just the LDFLAGS
>> tweaks mentioned in the other thread). The sources should be part
>> of the sysroot, and hence available when that is packaged for use
>> outside of bitbake/yocto.
>> 
>> If you aren't seeing kernel-dev in the SDK image, it might be that
>> TOOLCHAIN_TARGET_TASK doesn't have kernel-dev by default, or something
>> else is different in the SDK that is being generated in your testing.
>> 
>> I'm only speculating about what might be missing, since I'm not 100%
>> familiar with the SDK, but perhaps Jessica or others can chime in if
>> I've led you astray :)

You have *not* led me astray. A fundamental problem was that I didn't comprehend the distinction/correspondence between "target image" recipes and "SDK image" recipes. I believe I get that now.

We've created a target image recipe, and an SDK image recipe that "require's" the former (this is conventional, I believe). The SDK image recipe adds all the development packages and, yes, it includes kernel-dev. So, when I install my SDK now, I certainly *do* get all the kernel header files. As you know, I do *not* get the hostprogs.

As I described in an earlier post, I am currently reaching into the "tmp" directory, pulling out the kernel work directory, and making it directly available to my external build process. This solves my problem because the work directory contains all the header files I need *and* the hostprogs. Of course, it's "bad" because it's not an intended way to use the build artifacts, and it's awkward to distribute.

With the recent improvement, I can now get the kernel header files packaged in the SDK. That's good because it's an intended mechanism and it's easy to distribute.

With regard to:

    https://bugzilla.yoctoproject.org/show_bug.cgi?id=1614

This seems a reasonable solution to the problem of building modules on the target, given the difficulties of dealing with executables. I'm not building modules on the target (I'm cross-compiling them), but this seems to apply anyway. It adds an extra step to SDK installation, but that's the least of our problems.

One problem I ran into … When I tried to execute "make scripts," I got a whole bunch of config questions that I *think* should have been answered with a .config file or something. Should I have copied out the .config file from the kernel work directory into the SDK installation before I ran that? Is that the "best" way to get around all the questions?

> Patrick, please keep us posted if this continues to not work for you. I
> will open a bug to include a section about this in the kernel
> development manual.

It's very *nearly* working for me now. See my question above.

Re: Build external module against Yocto kernel

[Bruce Ashfield]

On 13-01-22 03:28 PM, Patrick Turley wrote:
> On Jan 16, 2013, at 11:11 AM, Darren Hart <dvhart@linux.intel.com> wrote:
>> On 01/15/2013 10:38 AM, Bruce Ashfield wrote:
>>> I finally found the entries that I was recalling earlier. They are:
>>>
>>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=241
>>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=1614
>>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=2968
>>>
>>> 1614 and 2968 are the most interesting for what you are asking.
>>>
>>> As you can see the net result of those bugs is that you can get the
>>> right parts of the kernel tree in SDK packages, since they include
>>> dev packages, and with what is currently in kernel-dev .. it should
>>> be enough to build against in the SDK (perhaps with just the LDFLAGS
>>> tweaks mentioned in the other thread). The sources should be part
>>> of the sysroot, and hence available when that is packaged for use
>>> outside of bitbake/yocto.
>>>
>>> If you aren't seeing kernel-dev in the SDK image, it might be that
>>> TOOLCHAIN_TARGET_TASK doesn't have kernel-dev by default, or something
>>> else is different in the SDK that is being generated in your testing.
>>>
>>> I'm only speculating about what might be missing, since I'm not 100%
>>> familiar with the SDK, but perhaps Jessica or others can chime in if
>>> I've led you astray :)
>
> You have *not* led me astray. A fundamental problem was that I didn't comprehend the distinction/correspondence between "target image" recipes and "SDK image" recipes. I believe I get that now.
>
> We've created a target image recipe, and an SDK image recipe that "require's" the former (this is conventional, I believe). The SDK image recipe adds all the development packages and, yes, it includes kernel-dev. So, when I install my SDK now, I certainly *do* get all the kernel header files. As you know, I do *not* get the hostprogs.
>
> As I described in an earlier post, I am currently reaching into the "tmp" directory, pulling out the kernel work directory, and making it directly available to my external build process. This solves my problem because the work directory contains all the header files I need *and* the hostprogs. Of course, it's "bad" because it's not an intended way to use the build artifacts, and it's awkward to distribute.
>
> With the recent improvement, I can now get the kernel header files packaged in the SDK. That's good because it's an intended mechanism and it's easy to distribute.
>
> With regard to:
>
>      https://bugzilla.yoctoproject.org/show_bug.cgi?id=1614
>
> This seems a reasonable solution to the problem of building modules on the target, given the difficulties of dealing with executables. I'm not building modules on the target (I'm cross-compiling them), but this seems to apply anyway. It adds an extra step to SDK installation, but that's the least of our problems.
>
> One problem I ran into … When I tried to execute "make scripts," I got a whole bunch of config questions that I *think* should have been answered with a .config file or something. Should I have copied out the .config file from the kernel work directory into the SDK installation before I ran that? Is that the "best" way to get around all the questions?
>

Interesting. I haven't seen this myself, so just a couple of quick
questions:

   - without the .config, did you still get a working set of hostprogs, and
     only had to suffer the warnings ?

   - If the answer is yes, then the .config really doesn't matter for this
     and the approach of grabbing a .config should work fine or even
     having a dummy defconfig available with enough to keep the build
     happy.

Definitely sounds like something we can address and it's worth putting into
bugzilla so it doesn't get lost.

Bruce

>> Patrick, please keep us posted if this continues to not work for you. I
>> will open a bug to include a section about this in the kernel
>> development manual.
>
> It's very *nearly* working for me now. See my question above.
>

Re: Build external module against Yocto kernel

[Patrick Turley]

On Jan 22, 2013, at 2:34 PM, Bruce Ashfield <bruce.ashfield@windriver.com> wrote:
> On 13-01-22 03:28 PM, Patrick Turley wrote:
>> One problem I ran into … When I tried to execute "make scripts," I got a whole bunch of config questions that I *think* should have been answered with a .config file or something. Should I have copied out the .config file from the kernel work directory into the SDK installation before I ran that? Is that the "best" way to get around all the questions?
>> 
> 
> Interesting. I haven't seen this myself, so just a couple of quick
> questions:
> 
>  - without the .config, did you still get a working set of hostprogs, and
>    only had to suffer the warnings ?
> 
>  - If the answer is yes, then the .config really doesn't matter for this
>    and the approach of grabbing a .config should work fine or even
>    having a dummy defconfig available with enough to keep the build
>    happy.
> 
> Definitely sounds like something we can address and it's worth putting into
> bugzilla so it doesn't get lost.

Below, please find a transcript of the commands I executed.

You'll see that I installed the SDK, tried to "make scripts," and then got attacked with a storm of config questions. I cut off the transcript at the second question, but there are dozens that follow.

There *is* a .config file in the SDK directory, and it is identical to the one in our kernel build directory:

/home/pturley/yocto-mpu-build/tmp/work/dm8148_mpu-poky-linux-gnueabi/linux-ti81xx-psp-2.6.37-r0+spawnlabs+r0/git

Unfortunately, I'm still something of a n00b when it comes to building the kernel. I suspect *most* of these questions are irrelevant to hostprogs, but I can't say that *all* of them are.

If I just hold down the "Enter" key, I believe all the defaults are taken, and I eventually *do* get hostprogs that execute, but I don't know if they're appropriate to my kernel. (Again, I'm a n00b, so perhaps there's no effect at all.)

--------------------

$ pwd
/home/pturley/yocto-mpu-build/tmp/deploy/sdk

$ ls
poky-eglibc-x86_64-arm-toolchain-1.3.sh

$ sudo ./poky-eglibc-x86_64-arm-toolchain-1.3.sh 
Enter target directory for SDK (default: /opt/poky/1.3): 
You are about to install the SDK to "/opt/poky/1.3". Proceed[Y/n]?
Extracting SDK...done
Setting it up...done
SDK has been successfully set up and is ready to be used.

$ cd /opt/poky/1.3/sysroots/dm8148_mpu-poky-linux-gnueabi/usr/src/kernel

$ ls -a
.              firmware           lib             scripts
..             fs                 MAINTAINERS     security
arch           include            Makefile        sound
block          init               mm              System.map-2.6.37
.config        ipc                Module.symvers  tools
COPYING        Kbuild             net             uImage
CREDITS        Kconfig            patches         usr
crypto         kernel             README          virt
Documentation  kernel-abiversion  REPORTING-BUGS
drivers        kernel-image-name  samples

$ sudo make scripts
  HOSTCC  scripts/basic/fixdep
  HOSTCC  scripts/basic/docproc
  HOSTCC  scripts/kconfig/conf.o
  HOSTCC  scripts/kconfig/kxgettext.o
  SHIPPED scripts/kconfig/zconf.tab.c
  SHIPPED scripts/kconfig/lex.zconf.c
  SHIPPED scripts/kconfig/zconf.hash.c
  HOSTCC  scripts/kconfig/zconf.tab.o
  HOSTLD  scripts/kconfig/conf
scripts/kconfig/conf --silentoldconfig Kconfig
*
* Restart config...
*
*
* General setup
*
Prompt for development and/or incomplete code/drivers (EXPERIMENTAL) [Y/n/?] y
Cross-compiler tool prefix (CROSS_COMPILE) [] 
Local version - append to kernel release (LOCALVERSION) [] 
Automatically append version information to the version string (LOCALVERSION_AUTO) [N/y/?] n
Kernel compression mode
> 1. Gzip (KERNEL_GZIP)
  2. Bzip2 (KERNEL_BZIP2) (NEW)
  3. LZMA (KERNEL_LZMA)
  4. LZO (KERNEL_LZO)
choice[1-4?]: 
Support for paging of anonymous memory (swap) (SWAP) [N/y/?] n
System V IPC (SYSVIPC) [Y/n/?] y
POSIX Message Queues (POSIX_MQUEUE) [Y/n/?] y
BSD Process Accounting (BSD_PROCESS_ACCT) [Y/n/?] y
  BSD Process Accounting version 3 file format (BSD_PROCESS_ACCT_V3) [Y/n/?] y
Export task/process statistics through netlink (EXPERIMENTAL) (TASKSTATS) [Y/n/?] y
  Enable per-task delay accounting (EXPERIMENTAL) (TASK_DELAY_ACCT) [Y/n/?] y
  Enable extended accounting over taskstats (EXPERIMENTAL) (TASK_XACCT) [Y/n/?] y
    Enable per-task storage I/O accounting (EXPERIMENTAL) (TASK_IO_ACCOUNTING) [Y/n/?] y
Auditing support (AUDIT) [N/y/?] n
Kernel .config support (IKCONFIG) [Y/n/m/?] y
  Enable access to .config through /proc/config.gz (IKCONFIG_PROC) [Y/n/?] y
Kernel log buffer size (16 => 64KB, 17 => 128KB) (LOG_BUF_SHIFT) [17] 17
enable deprecated sysfs features to support old userspace tools (SYSFS_DEPRECATED) [N/y/?] n
Kernel->user space relay support (formerly relayfs) (RELAY) [N/y/?] n
Initial RAM filesystem and RAM disk (initramfs/initrd) support (BLK_DEV_INITRD) [Y/n/?] y
  Initramfs source file(s) (INITRAMFS_SOURCE) [] 
Optimize for size (CC_OPTIMIZE_FOR_SIZE) [Y/n/?] y
Disable heap randomization (COMPAT_BRK) [Y/n/?] y
Choose SLAB allocator
  1. SLAB (SLAB)
> 2. SLUB (Unqueued Allocator) (SLUB)
choice[1-2?]: 2
Profiling support (PROFILING) [Y/n/?] y
OProfile system profiling (OPROFILE) [M/n/y/?] m
  OProfile multiplexing support (EXPERIMENTAL) (OPROFILE_EVENT_MULTIPLEX) [N/y/?] (NEW) 

Re: Build external module against Yocto kernel

[Bruce Ashfield]

On 13-01-22 9:26 PM, Patrick Turley wrote:
> On Jan 22, 2013, at 2:34 PM, Bruce Ashfield<bruce.ashfield@windriver.com>  wrote:
>> On 13-01-22 03:28 PM, Patrick Turley wrote:
>>> One problem I ran into … When I tried to execute "make scripts," I got a whole bunch of config questions that I *think* should have been answered with a .config file or something. Should I have copied out the .config file from the kernel work directory into the SDK installation before I ran that? Is that the "best" way to get around all the questions?
>>>
>>
>> Interesting. I haven't seen this myself, so just a couple of quick
>> questions:
>>
>>   - without the .config, did you still get a working set of hostprogs, and
>>     only had to suffer the warnings ?
>>
>>   - If the answer is yes, then the .config really doesn't matter for this
>>     and the approach of grabbing a .config should work fine or even
>>     having a dummy defconfig available with enough to keep the build
>>     happy.
>>
>> Definitely sounds like something we can address and it's worth putting into
>> bugzilla so it doesn't get lost.
>
> Below, please find a transcript of the commands I executed.
>
> You'll see that I installed the SDK, tried to "make scripts," and then got attacked with a storm of config questions. I cut off the transcript at the second question, but there are dozens that follow.
>
> There *is* a .config file in the SDK directory, and it is identical to the one in our kernel build directory:
>
> /home/pturley/yocto-mpu-build/tmp/work/dm8148_mpu-poky-linux-gnueabi/linux-ti81xx-psp-2.6.37-r0+spawnlabs+r0/git
>
> Unfortunately, I'm still something of a n00b when it comes to building the kernel. I suspect *most* of these questions are irrelevant to hostprogs, but I can't say that *all* of them are.
>
> If I just hold down the "Enter" key, I believe all the defaults are taken, and I eventually *do* get hostprogs that execute, but I don't know if they're appropriate to my kernel. (Again, I'm a n00b, so perhaps there's no effect at all.)
>

This will be fine, the defaults will work. The kernel build infrastructure
is picking up what it thinks is a change source -> to config and trying
to reconcile the differences.

If you throw in a 'make oldconfig' before you do the 'make scripts', does
that quiet things down a bit ?

Cheers,

Bruce

> --------------------
>
> $ pwd
> /home/pturley/yocto-mpu-build/tmp/deploy/sdk
>
> $ ls
> poky-eglibc-x86_64-arm-toolchain-1.3.sh
>
> $ sudo ./poky-eglibc-x86_64-arm-toolchain-1.3.sh
> Enter target directory for SDK (default: /opt/poky/1.3):
> You are about to install the SDK to "/opt/poky/1.3". Proceed[Y/n]?
> Extracting SDK...done
> Setting it up...done
> SDK has been successfully set up and is ready to be used.
>
> $ cd /opt/poky/1.3/sysroots/dm8148_mpu-poky-linux-gnueabi/usr/src/kernel
>
> $ ls -a
> .              firmware           lib             scripts
> ..             fs                 MAINTAINERS     security
> arch           include            Makefile        sound
> block          init               mm              System.map-2.6.37
> .config        ipc                Module.symvers  tools
> COPYING        Kbuild             net             uImage
> CREDITS        Kconfig            patches         usr
> crypto         kernel             README          virt
> Documentation  kernel-abiversion  REPORTING-BUGS
> drivers        kernel-image-name  samples
>
> $ sudo make scripts
>    HOSTCC  scripts/basic/fixdep
>    HOSTCC  scripts/basic/docproc
>    HOSTCC  scripts/kconfig/conf.o
>    HOSTCC  scripts/kconfig/kxgettext.o
>    SHIPPED scripts/kconfig/zconf.tab.c
>    SHIPPED scripts/kconfig/lex.zconf.c
>    SHIPPED scripts/kconfig/zconf.hash.c
>    HOSTCC  scripts/kconfig/zconf.tab.o
>    HOSTLD  scripts/kconfig/conf
> scripts/kconfig/conf --silentoldconfig Kconfig
> *
> * Restart config...
> *
> *
> * General setup
> *
> Prompt for development and/or incomplete code/drivers (EXPERIMENTAL) [Y/n/?] y
> Cross-compiler tool prefix (CROSS_COMPILE) []
> Local version - append to kernel release (LOCALVERSION) []
> Automatically append version information to the version string (LOCALVERSION_AUTO) [N/y/?] n
> Kernel compression mode
>> 1. Gzip (KERNEL_GZIP)
>    2. Bzip2 (KERNEL_BZIP2) (NEW)
>    3. LZMA (KERNEL_LZMA)
>    4. LZO (KERNEL_LZO)
> choice[1-4?]:
> Support for paging of anonymous memory (swap) (SWAP) [N/y/?] n
> System V IPC (SYSVIPC) [Y/n/?] y
> POSIX Message Queues (POSIX_MQUEUE) [Y/n/?] y
> BSD Process Accounting (BSD_PROCESS_ACCT) [Y/n/?] y
>    BSD Process Accounting version 3 file format (BSD_PROCESS_ACCT_V3) [Y/n/?] y
> Export task/process statistics through netlink (EXPERIMENTAL) (TASKSTATS) [Y/n/?] y
>    Enable per-task delay accounting (EXPERIMENTAL) (TASK_DELAY_ACCT) [Y/n/?] y
>    Enable extended accounting over taskstats (EXPERIMENTAL) (TASK_XACCT) [Y/n/?] y
>      Enable per-task storage I/O accounting (EXPERIMENTAL) (TASK_IO_ACCOUNTING) [Y/n/?] y
> Auditing support (AUDIT) [N/y/?] n
> Kernel .config support (IKCONFIG) [Y/n/m/?] y
>    Enable access to .config through /proc/config.gz (IKCONFIG_PROC) [Y/n/?] y
> Kernel log buffer size (16 =>  64KB, 17 =>  128KB) (LOG_BUF_SHIFT) [17] 17
> enable deprecated sysfs features to support old userspace tools (SYSFS_DEPRECATED) [N/y/?] n
> Kernel->user space relay support (formerly relayfs) (RELAY) [N/y/?] n
> Initial RAM filesystem and RAM disk (initramfs/initrd) support (BLK_DEV_INITRD) [Y/n/?] y
>    Initramfs source file(s) (INITRAMFS_SOURCE) []
> Optimize for size (CC_OPTIMIZE_FOR_SIZE) [Y/n/?] y
> Disable heap randomization (COMPAT_BRK) [Y/n/?] y
> Choose SLAB allocator
>    1. SLAB (SLAB)
>> 2. SLUB (Unqueued Allocator) (SLUB)
> choice[1-2?]: 2
> Profiling support (PROFILING) [Y/n/?] y
> OProfile system profiling (OPROFILE) [M/n/y/?] m
>    OProfile multiplexing support (EXPERIMENTAL) (OPROFILE_EVENT_MULTIPLEX) [N/y/?] (NEW)
>

Re: Build external module against Yocto kernel

[Patrick Turley]

On Jan 22, 2013, at 10:43 PM, Bruce Ashfield <bruce.ashfield@windriver.com> wrote:
> On 13-01-22 9:26 PM, Patrick Turley wrote:
>> If I just hold down the "Enter" key, I believe all the defaults are taken, and I eventually *do* get hostprogs that execute, but I don't know if they're appropriate to my kernel. (Again, I'm a n00b, so perhaps there's no effect at all.)
> 
> This will be fine, the defaults will work. The kernel build infrastructure
> is picking up what it thinks is a change source -> to config and trying
> to reconcile the differences.
> 
> If you throw in a 'make oldconfig' before you do the 'make scripts', does
> that quiet things down a bit ?

No -- "make oldconfig" caused the very same questions (see below).

-------------------

$ cd /opt/poky/1.3/sysroots/dm8148_mpu-poky-linux-gnueabi/usr/src/kernel

$ ls
arch           drivers   Kbuild             MAINTAINERS     README          System.map-2.6.37
block          firmware  Kconfig            Makefile        REPORTING-BUGS  tools
COPYING        fs        kernel             mm              samples         uImage
CREDITS        include   kernel-abiversion  Module.symvers  scripts         usr
crypto         init      kernel-image-name  net             security        virt
Documentation  ipc       lib                patches         sound

$ sudo make oldconfig
  HOSTCC  scripts/basic/fixdep
  HOSTCC  scripts/basic/docproc
  HOSTCC  scripts/kconfig/conf.o
  HOSTCC  scripts/kconfig/kxgettext.o
  SHIPPED scripts/kconfig/zconf.tab.c
  SHIPPED scripts/kconfig/lex.zconf.c
  SHIPPED scripts/kconfig/zconf.hash.c
  HOSTCC  scripts/kconfig/zconf.tab.o
  HOSTLD  scripts/kconfig/conf
scripts/kconfig/conf --oldconfig Kconfig
*
* Restart config...
*
*
* General setup
*
Prompt for development and/or incomplete code/drivers (EXPERIMENTAL) [Y/n/?] y
Cross-compiler tool prefix (CROSS_COMPILE) [] 
Local version - append to kernel release (LOCALVERSION) [] 
Automatically append version information to the version string (LOCALVERSION_AUTO) [N/y/?] n
Kernel compression mode
> 1. Gzip (KERNEL_GZIP)
  2. Bzip2 (KERNEL_BZIP2) (NEW)
  3. LZMA (KERNEL_LZMA)
  4. LZO (KERNEL_LZO)
choice[1-4?]:

Re: Build external module against Yocto kernel

[Bruce Ashfield]

On 13-01-23 12:14 AM, Patrick Turley wrote:
> On Jan 22, 2013, at 10:43 PM, Bruce Ashfield<bruce.ashfield@windriver.com>  wrote:
>> On 13-01-22 9:26 PM, Patrick Turley wrote:
>>> If I just hold down the "Enter" key, I believe all the defaults are taken, and I eventually *do* get hostprogs that execute, but I don't know if they're appropriate to my kernel. (Again, I'm a n00b, so perhaps there's no effect at all.)
>>
>> This will be fine, the defaults will work. The kernel build infrastructure
>> is picking up what it thinks is a change source ->  to config and trying
>> to reconcile the differences.
>>
>> If you throw in a 'make oldconfig' before you do the 'make scripts', does
>> that quiet things down a bit ?
>
> No -- "make oldconfig" caused the very same questions (see below).

Aha. of course (now that I think about it), the build was simply triggering
old config automatically.

silentoldconfig is what I really should have typed :)

Bruce

>
> -------------------
>
> $ cd /opt/poky/1.3/sysroots/dm8148_mpu-poky-linux-gnueabi/usr/src/kernel
>
> $ ls
> arch           drivers   Kbuild             MAINTAINERS     README          System.map-2.6.37
> block          firmware  Kconfig            Makefile        REPORTING-BUGS  tools
> COPYING        fs        kernel             mm              samples         uImage
> CREDITS        include   kernel-abiversion  Module.symvers  scripts         usr
> crypto         init      kernel-image-name  net             security        virt
> Documentation  ipc       lib                patches         sound
>
> $ sudo make oldconfig
>    HOSTCC  scripts/basic/fixdep
>    HOSTCC  scripts/basic/docproc
>    HOSTCC  scripts/kconfig/conf.o
>    HOSTCC  scripts/kconfig/kxgettext.o
>    SHIPPED scripts/kconfig/zconf.tab.c
>    SHIPPED scripts/kconfig/lex.zconf.c
>    SHIPPED scripts/kconfig/zconf.hash.c
>    HOSTCC  scripts/kconfig/zconf.tab.o
>    HOSTLD  scripts/kconfig/conf
> scripts/kconfig/conf --oldconfig Kconfig
> *
> * Restart config...
> *
> *
> * General setup
> *
> Prompt for development and/or incomplete code/drivers (EXPERIMENTAL) [Y/n/?] y
> Cross-compiler tool prefix (CROSS_COMPILE) []
> Local version - append to kernel release (LOCALVERSION) []
> Automatically append version information to the version string (LOCALVERSION_AUTO) [N/y/?] n
> Kernel compression mode
>> 1. Gzip (KERNEL_GZIP)
>    2. Bzip2 (KERNEL_BZIP2) (NEW)
>    3. LZMA (KERNEL_LZMA)
>    4. LZO (KERNEL_LZO)
> choice[1-4?]:
>

Re: Build external module against Yocto kernel

[Patrick Turley]

On Jan 22, 2013, at 11:17 PM, Bruce Ashfield <bruce.ashfield@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@windriver.com>  wrote:
>>> On 13-01-22 9:26 PM, Patrick Turley wrote:
>>>> If I just hold down the "Enter" key, I believe all the defaults are taken, and I eventually *do* get hostprogs that execute, but I don't know if they're appropriate to my kernel. (Again, I'm a n00b, so perhaps there's no effect at all.)
>>> 
>>> This will be fine, the defaults will work. The kernel build infrastructure
>>> is picking up what it thinks is a change source ->  to config and trying
>>> to reconcile the differences.
>>> 
>>> If you throw in a 'make oldconfig' before you do the 'make scripts', does
>>> that quiet things down a bit ?
>> 
>> No -- "make oldconfig" caused the very same questions (see below).
> 
> Aha. of course (now that I think about it), the build was simply triggering
> old config automatically.
> 
> silentoldconfig is what I really should have typed :)


Nope - still doesn't work.

--------------------

$ sudo make silentoldconfig
  HOSTCC  scripts/basic/fixdep
  HOSTCC  scripts/basic/docproc
  HOSTCC  scripts/kconfig/conf.o
  HOSTCC  scripts/kconfig/kxgettext.o
  SHIPPED scripts/kconfig/zconf.tab.c
  SHIPPED scripts/kconfig/lex.zconf.c
  SHIPPED scripts/kconfig/zconf.hash.c
  HOSTCC  scripts/kconfig/zconf.tab.o
  HOSTLD  scripts/kconfig/conf
scripts/kconfig/conf --silentoldconfig Kconfig
*
* Restart config...
*
*
* General setup
*
Prompt for development and/or incomplete code/drivers (EXPERIMENTAL) [Y/n/?] y
Cross-compiler tool prefix (CROSS_COMPILE) [] 
Local version - append to kernel release (LOCALVERSION) [] 
Automatically append version information to the version string (LOCALVERSION_AUTO) [N/y/?] n
Kernel compression mode
> 1. Gzip (KERNEL_GZIP)
  2. Bzip2 (KERNEL_BZIP2) (NEW)
  3. LZMA (KERNEL_LZMA)
  4. LZO (KERNEL_LZO)
choice[1-4?]: 

Re: Build external module against Yocto kernel

[Bruce Ashfield]

On 13-01-23 12:34 AM, Patrick Turley wrote:
>
> On Jan 22, 2013, at 11:17 PM, Bruce Ashfield <bruce.ashfield@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@windriver.com>  wrote:
>>>> On 13-01-22 9:26 PM, Patrick Turley wrote:
>>>>> If I just hold down the "Enter" key, I believe all the defaults are taken, and I eventually *do* get hostprogs that execute, but I don't know if they're appropriate to my kernel. (Again, I'm a n00b, so perhaps there's no effect at all.)
>>>>
>>>> This will be fine, the defaults will work. The kernel build infrastructure
>>>> is picking up what it thinks is a change source ->  to config and trying
>>>> to reconcile the differences.
>>>>
>>>> If you throw in a 'make oldconfig' before you do the 'make scripts', does
>>>> that quiet things down a bit ?
>>>
>>> No -- "make oldconfig" caused the very same questions (see below).
>>
>> Aha. of course (now that I think about it), the build was simply triggering
>> old config automatically.
>>
>> silentoldconfig is what I really should have typed :)
>
>
> Nope - still doesn't work.

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.

Cheers,

Bruce

>
> --------------------
>
> $ sudo make silentoldconfig
>    HOSTCC  scripts/basic/fixdep
>    HOSTCC  scripts/basic/docproc
>    HOSTCC  scripts/kconfig/conf.o
>    HOSTCC  scripts/kconfig/kxgettext.o
>    SHIPPED scripts/kconfig/zconf.tab.c
>    SHIPPED scripts/kconfig/lex.zconf.c
>    SHIPPED scripts/kconfig/zconf.hash.c
>    HOSTCC  scripts/kconfig/zconf.tab.o
>    HOSTLD  scripts/kconfig/conf
> scripts/kconfig/conf --silentoldconfig Kconfig
> *
> * Restart config...
> *
> *
> * General setup
> *
> Prompt for development and/or incomplete code/drivers (EXPERIMENTAL) [Y/n/?] y
> Cross-compiler tool prefix (CROSS_COMPILE) []
> Local version - append to kernel release (LOCALVERSION) []
> Automatically append version information to the version string (LOCALVERSION_AUTO) [N/y/?] n
> Kernel compression mode
>> 1. Gzip (KERNEL_GZIP)
>    2. Bzip2 (KERNEL_BZIP2) (NEW)
>    3. LZMA (KERNEL_LZMA)
>    4. LZO (KERNEL_LZO)
> choice[1-4?]:
>

Re: Build external module against Yocto kernel

[Patrick Turley]

On Jan 23, 2013, at 7:48 AM, Bruce Ashfield <bruce.ashfield@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@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@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.

Re: Build external module against Yocto kernel

[John Mehaffey]

[-- Attachment #1: Type: text/plain, Size: 1257 bytes --]

On Wed, Jan 23, 2013 at 7:17 AM, Patrick Turley
<PatrickTurley@gamestop.com>wrote:

>
> On Jan 23, 2013, at 7:48 AM, Bruce Ashfield <bruce.ashfield@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@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@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.
>

It sounds like you are building for a board with an ARCH other than i386
(the default).

You need to either run it in a devshell or use "make ARCH=<arch> oldconfig".

-mehaf


>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>

[-- Attachment #2: Type: text/html, Size: 2156 bytes --]

Re: Build external module against Yocto kernel

[Bruce Ashfield]

On 13-01-24 02:58 PM, John Mehaffey wrote:
> On Wed, Jan 23, 2013 at 7:17 AM, Patrick Turley
> <PatrickTurley@gamestop.com <mailto:PatrickTurley@gamestop.com>> wrote:
>
>
>     On Jan 23, 2013, at 7:48 AM, Bruce Ashfield
>     <bruce.ashfield@windriver.com <mailto:bruce.ashfield@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@windriver.com <mailto:bruce.ashfield@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@windriver.com
>     <mailto:bruce.ashfield@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.
>
>
> It sounds like you are building for a board with an ARCH other than i386
> (the default).
>

Ah yes .. it can definitely be this. I always have an ARCH on the
command line when I invoke the oldconfig.

In theory we shouldn't need the oldconfig at all either, just the arch
on the build line with making the scripts.

Cheers,

Bruce

> You need to either run it in a devshell or use "make ARCH=<arch> oldconfig".
>
> -mehaf
>
>
>     _______________________________________________
>     yocto mailing list
>     yocto@yoctoproject.org <mailto:yocto@yoctoproject.org>
>     https://lists.yoctoproject.org/listinfo/yocto
>
>

Re: Build external module against Yocto kernel

[John Mehaffey]

[-- Attachment #1: Type: text/plain, Size: 2508 bytes --]

On Thu, Jan 24, 2013 at 12:10 PM, Bruce Ashfield <
bruce.ashfield@windriver.com> wrote:

> On 13-01-24 02:58 PM, John Mehaffey wrote:
>
>> On Wed, Jan 23, 2013 at 7:17 AM, Patrick Turley
>> <PatrickTurley@gamestop.com <mailto:PatrickTurley@**gamestop.com<PatrickTurley@gamestop.com>>>
>> wrote:
>>
>>
>>     On Jan 23, 2013, at 7:48 AM, Bruce Ashfield
>>     <bruce.ashfield@windriver.com <mailto:bruce.ashfield@**windriver.com<bruce.ashfield@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@windriver.com <mailto:bruce.ashfield@**windriver.com<bruce.ashfield@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@**windriver.com<bruce.ashfield@windriver.com>
>>     <mailto:bruce.ashfield@**windriver.com <bruce.ashfield@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.
>>
>>
>> It sounds like you are building for a board with an ARCH other than i386
>> (the default).
>>
>>
> Ah yes .. it can definitely be this. I always have an ARCH on the
> command line when I invoke the oldconfig.
>
> In theory we shouldn't need the oldconfig at all either, just the arch
> on the build line with making the scripts.
>
> Cheers,
>
> Bruce
>

Well, the real question is why you have to set ARCH at all, given that it
is in the
.config (e.g. CONFIG_ARM=y), but that is a question for someone with more
cycles
to spare than I have.

-mehaf


>  You need to either run it in a devshell or use "make ARCH=<arch>
>> oldconfig".
>>
>> -mehaf
>>
>>
>>     ______________________________**_________________
>>     yocto mailing list
>>     yocto@yoctoproject.org <mailto:yocto@yoctoproject.org**>
>>     https://lists.yoctoproject.**org/listinfo/yocto<https://lists.yoctoproject.org/listinfo/yocto>
>>
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 4049 bytes --]

Re: Build external module against Yocto kernel

[Bruce Ashfield]

On 13-01-23 10:17 AM, Patrick Turley wrote:
>
> On Jan 23, 2013, at 7:48 AM, Bruce Ashfield<bruce.ashfield@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@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@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

>

Re: Build external module against Yocto kernel

[Patrick Turley]

On Jan 31, 2013, at 10:50 PM, Bruce Ashfield <bruce.ashfield@windriver.com> wrote:

> On 13-01-23 10:17 AM, Patrick Turley wrote:
>> 
>> On Jan 23, 2013, at 7:48 AM, Bruce Ashfield<bruce.ashfield@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@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@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.

I absolutely *am* still interested in this issue, and thank you for taking another look.

There are two commands that I'm interested in executing:

    -- make oldconfig

    -- make scripts

(Since I install the SDK under /opt, I use sudo when running these commands, but I don't *think* that's important.)


Here's what happens with the first command:

$ sudo make oldconfig ARCH=arm
  HOSTCC  scripts/basic/fixdep
  HOSTCC  scripts/basic/docproc
  HOSTCC  scripts/kconfig/conf.o
  HOSTCC  scripts/kconfig/kxgettext.o
  SHIPPED scripts/kconfig/zconf.tab.c
  SHIPPED scripts/kconfig/lex.zconf.c
  SHIPPED scripts/kconfig/zconf.hash.c
  HOSTCC  scripts/kconfig/zconf.tab.o
  HOSTLD  scripts/kconfig/conf
scripts/kconfig/conf --oldconfig Kconfig
#
# configuration written to .config
#

As you say, adding "ARCH=arm" puts the build at ease and it completes just fine.


Here's what happens with the second command:

$ sudo make scripts ARCH=arm
scripts/kconfig/conf --silentoldconfig Kconfig
  HOSTCC  scripts/genksyms/genksyms.o
  SHIPPED scripts/genksyms/lex.c
  SHIPPED scripts/genksyms/parse.h
  SHIPPED scripts/genksyms/keywords.c
  HOSTCC  scripts/genksyms/lex.o
  SHIPPED scripts/genksyms/parse.c
  HOSTCC  scripts/genksyms/parse.o
  HOSTLD  scripts/genksyms/genksyms
  CC      scripts/mod/empty.o
cc1: error: unrecognized command line option "-mlittle-endian"
cc1: error: unrecognized command line option "-mapcs"
cc1: error: unrecognized command line option "-mno-sched-prolog"
cc1: error: unrecognized command line option "-mabi=aapcs-linux"
cc1: error: unrecognized command line option "-mno-thumb-interwork"
scripts/mod/empty.c:1: error: bad value (armv5t) for -march= switch
scripts/mod/empty.c:1: error: bad value (armv5t) for -mtune= switch
make[2]: *** [scripts/mod/empty.o] Error 1
make[1]: *** [scripts/mod] Error 2
make: *** [scripts] Error 2

Recall that, when I do *not* give the "ARCH=arm" argument, I get reams of config questions, but the build works.

This is an improvement in that the config questions are gone but, of course, the build fails.

Perhaps it *should* fail. Perhaps I'm doing something that actually doesn't make sense. Or perhaps I'm doing something that Yocto just isn't ready to support. At this point, I should say:

1) I have a workaround for all this, so I am *not* dead in the water.

2) I am a kernel building n00b and it legitimately may not be worth your time (or anyone else's) to continue to look at this until I "catch up." I don't want anyone throwing up their hands in frustration and saying "Doesn't this guy know anything?" It's perfectly reasonable to cut me off at this point :)

Re: Build external module against Yocto kernel

[Brian Lloyd]

[-- Attachment #1: Type: text/plain, Size: 6783 bytes --]

While, I'm not an expert, I would like to point out:
http://kernel.org/doc/index-old.html (the new index references this but
the information isn't on the new index page directly).

One thing mentioned is that a make distclean is required for reasonable
results between any run with different architectures.  So you can't run
a make scripts to get scripts for the local system in a build directory
configured for cross compiling for the device and expect it to work
correctly.

Also, about the config prompts: during dependency checking, the .config
file is validated, and if it fails validation, make oldconfig is run, as
it assumes the config was pulled from a previous kernel version.  Since
a .config file is ARCH specific, it will almost always be invalid when
checked against a different architecture, and thus fire off a make
oldconfig.  This is why you get prompted to answer questions when you do
"make scripts" and have a .config for another architecture.

Also, I suspect you need to ensure the cross compiler is being called
when necessary for the make scripts.  It looks like the errors are from
passing arm gcc parameters to an x86 gcc.  You can try "make ARCH=arm
CROSS_COMPILE=/???/" instead, where /???/ is the prefix to your arm
cross compiler.  The kernel build actually uses both cross and non-cross
compilers during build so you have some support tools compiled to run
natively and others that run on the end machine, so you don't want to
override CXX and C++ to be the cross compiler.


Brian

On Sat, 2013-02-02 at 00:48 +0000, Patrick Turley wrote:

> On Jan 31, 2013, at 10:50 PM, Bruce Ashfield <bruce.ashfield@windriver.com> wrote:
> 
> > On 13-01-23 10:17 AM, Patrick Turley wrote:
> >> 
> >> On Jan 23, 2013, at 7:48 AM, Bruce Ashfield<bruce.ashfield@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@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@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.
> 
> I absolutely *am* still interested in this issue, and thank you for taking another look.
> 
> There are two commands that I'm interested in executing:
> 
>     -- make oldconfig
> 
>     -- make scripts
> 
> (Since I install the SDK under /opt, I use sudo when running these commands, but I don't *think* that's important.)
> 
> 
> Here's what happens with the first command:
> 
> $ sudo make oldconfig ARCH=arm
>   HOSTCC  scripts/basic/fixdep
>   HOSTCC  scripts/basic/docproc
>   HOSTCC  scripts/kconfig/conf.o
>   HOSTCC  scripts/kconfig/kxgettext.o
>   SHIPPED scripts/kconfig/zconf.tab.c
>   SHIPPED scripts/kconfig/lex.zconf.c
>   SHIPPED scripts/kconfig/zconf.hash.c
>   HOSTCC  scripts/kconfig/zconf.tab.o
>   HOSTLD  scripts/kconfig/conf
> scripts/kconfig/conf --oldconfig Kconfig
> #
> # configuration written to .config
> #
> 
> As you say, adding "ARCH=arm" puts the build at ease and it completes just fine.
> 
> 
> Here's what happens with the second command:
> 
> $ sudo make scripts ARCH=arm
> scripts/kconfig/conf --silentoldconfig Kconfig
>   HOSTCC  scripts/genksyms/genksyms.o
>   SHIPPED scripts/genksyms/lex.c
>   SHIPPED scripts/genksyms/parse.h
>   SHIPPED scripts/genksyms/keywords.c
>   HOSTCC  scripts/genksyms/lex.o
>   SHIPPED scripts/genksyms/parse.c
>   HOSTCC  scripts/genksyms/parse.o
>   HOSTLD  scripts/genksyms/genksyms
>   CC      scripts/mod/empty.o
> cc1: error: unrecognized command line option "-mlittle-endian"
> cc1: error: unrecognized command line option "-mapcs"
> cc1: error: unrecognized command line option "-mno-sched-prolog"
> cc1: error: unrecognized command line option "-mabi=aapcs-linux"
> cc1: error: unrecognized command line option "-mno-thumb-interwork"
> scripts/mod/empty.c:1: error: bad value (armv5t) for -march= switch
> scripts/mod/empty.c:1: error: bad value (armv5t) for -mtune= switch
> make[2]: *** [scripts/mod/empty.o] Error 1
> make[1]: *** [scripts/mod] Error 2
> make: *** [scripts] Error 2
> 
> Recall that, when I do *not* give the "ARCH=arm" argument, I get reams of config questions, but the build works.
> 
> This is an improvement in that the config questions are gone but, of course, the build fails.
> 
> Perhaps it *should* fail. Perhaps I'm doing something that actually doesn't make sense. Or perhaps I'm doing something that Yocto just isn't ready to support. At this point, I should say:
> 
> 1) I have a workaround for all this, so I am *not* dead in the water.
> 
> 2) I am a kernel building n00b and it legitimately may not be worth your time (or anyone else's) to continue to look at this until I "catch up." I don't want anyone throwing up their hands in frustration and saying "Doesn't this guy know anything?" It's perfectly reasonable to cut me off at this point :)
> 
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



[-- Attachment #2: Type: text/html, Size: 8869 bytes --]

Re: Build external module against Yocto kernel

[Bruce Ashfield]

On 13-02-01 7:48 PM, Patrick Turley wrote:
>
> On Jan 31, 2013, at 10:50 PM, Bruce Ashfield<bruce.ashfield@windriver.com>  wrote:
>
>> On 13-01-23 10:17 AM, Patrick Turley wrote:
>>>
>>> On Jan 23, 2013, at 7:48 AM, Bruce Ashfield<bruce.ashfield@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@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@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.
>
> I absolutely *am* still interested in this issue, and thank you for taking another look.
>
> There are two commands that I'm interested in executing:
>
>      -- make oldconfig
>
>      -- make scripts
>
> (Since I install the SDK under /opt, I use sudo when running these commands, but I don't *think* that's important.)
>
>
> Here's what happens with the first command:
>
> $ sudo make oldconfig ARCH=arm
>    HOSTCC  scripts/basic/fixdep
>    HOSTCC  scripts/basic/docproc
>    HOSTCC  scripts/kconfig/conf.o
>    HOSTCC  scripts/kconfig/kxgettext.o
>    SHIPPED scripts/kconfig/zconf.tab.c
>    SHIPPED scripts/kconfig/lex.zconf.c
>    SHIPPED scripts/kconfig/zconf.hash.c
>    HOSTCC  scripts/kconfig/zconf.tab.o
>    HOSTLD  scripts/kconfig/conf
> scripts/kconfig/conf --oldconfig Kconfig
> #
> # configuration written to .config
> #
>
> As you say, adding "ARCH=arm" puts the build at ease and it completes just fine.
>
>
> Here's what happens with the second command:
>
> $ sudo make scripts ARCH=arm
> scripts/kconfig/conf --silentoldconfig Kconfig
>    HOSTCC  scripts/genksyms/genksyms.o
>    SHIPPED scripts/genksyms/lex.c
>    SHIPPED scripts/genksyms/parse.h
>    SHIPPED scripts/genksyms/keywords.c
>    HOSTCC  scripts/genksyms/lex.o
>    SHIPPED scripts/genksyms/parse.c
>    HOSTCC  scripts/genksyms/parse.o
>    HOSTLD  scripts/genksyms/genksyms
>    CC      scripts/mod/empty.o
> cc1: error: unrecognized command line option "-mlittle-endian"
> cc1: error: unrecognized command line option "-mapcs"
> cc1: error: unrecognized command line option "-mno-sched-prolog"
> cc1: error: unrecognized command line option "-mabi=aapcs-linux"
> cc1: error: unrecognized command line option "-mno-thumb-interwork"
> scripts/mod/empty.c:1: error: bad value (armv5t) for -march= switch
> scripts/mod/empty.c:1: error: bad value (armv5t) for -mtune= switch
> make[2]: *** [scripts/mod/empty.o] Error 1
> make[1]: *** [scripts/mod] Error 2
> make: *** [scripts] Error 2
>
> Recall that, when I do *not* give the "ARCH=arm" argument, I get reams of config questions, but the build works.
>

The thing is that the timestamps of the .config and the kernel's auto.conf
should match and not trigger any more oldconfig executions.

I trust that if you still try "make scripts" without the ARCH,
even after the oldconfig step #1, you are still seeing the
questions. Thinking about it .. that does make sense that you'd
be seeing the oldconfig questions .. since the ARCH did change.

.. and just so I'm clear, you are building a ARM machine on a
x86 host and creating a SDK for that same x86 host, correct ?

The kernel's scripts target are really just a set of helpers for
building the kernel, and in this case, you aren't actually building
on a ARM machine, but on your x86 host. But the ARCH= is triggering
the ARM toolchain settings to be passed to your host compiler, since
CROSS_COMPILE= wasn't passed to the build.

So there's a couple of things more to consider:

1) go back to phase #1 and back to the idea of generating a 
allnoconfig/allyesconfig
SDK configuration, that would save you from the oldconfig questions,
but if any of the kernel modules or whatever you are building *use*
the config values, you aren't going to be building them against the
running kernel and it's settings .. which is a recipe for problems.

2) Pass CROSS_COMPILE to the scripts phase and see how it works, the
cross toolchain is in the SDK after all, so it is available. The
scripts should be fine, but of course any executables that are build
won't run on the host.

And even once you are up and building with kernel modules, you have
to take care to keep your SDK in sync with the running kernel.

Moving the SDK to the target would of course get around the ARM compiler
options and executables, but you'd have to have a ARM native compiler
in the SDK and not a cross compiler. I don't know if this is done, or
possible at the moment.

> This is an improvement in that the config questions are gone but, of course, the build fails.
>
> Perhaps it *should* fail. Perhaps I'm doing something that actually doesn't make sense. Or perhaps I'm doing something that Yocto just isn't ready to support. At this point, I should say:
>
> 1) I have a workaround for all this, so I am *not* dead in the water.
>
> 2) I am a kernel building n00b and it legitimately may not be worth your time (or anyone else's) to continue to look at this until I "catch up." I don't want anyone throwing up their hands in frustration and saying "Doesn't this guy know anything?" It's perfectly reasonable to cut me off at this point :)

I'm interested still, because it shows what I've warned about a few
times in the past, and appears to still hold true .. that adding the
ability to build kernel modules against a SDK itself, is still
difficult, both in the kernel tooling and in keeping the SDK and
running kernel in sync.

Working through the issues will let us know what is missing, and how
much effort is left to complete the work.

The thing is that the SDK is constructed with the native-sdk packages
(I've added Jessica, since I'm not 100% sure on this point), which
means the SDK packages are for a particular host architecture (the
native part) to  generate binaries for another. We just need to make the
kernel build infrastructure work like this in the SDK (we know it is
possible, since that's how the entire kernel build runs during a
normal build).

Cheers,

Bruce

>

Re: Build external module against Yocto kernel

[Bruce Ashfield]

On 13-02-01 11:35 PM, Brian Lloyd wrote:
> While, I'm not an expert, I would like to point out:
> http://kernel.org/doc/index-old.html (the new index references this but
> the information isn't on the new index page directly).
>
> One thing mentioned is that a make distclean is required for reasonable
> results between any run with different architectures. So you can't run a
> make scripts to get scripts for the local system in a build directory
> configured for cross compiling for the device and expect it to work
> correctly.
>
> Also, about the config prompts: during dependency checking, the .config
> file is validated, and if it fails validation, make oldconfig is run, as
> it assumes the config was pulled from a previous kernel version. Since a
> .config file is ARCH specific, it will almost always be invalid when
> checked against a different architecture, and thus fire off a make
> oldconfig. This is why you get prompted to answer questions when you do
> "make scripts" and have a .config for another architecture.
>
> Also, I suspect you need to ensure the cross compiler is being called
> when necessary for the make scripts. It looks like the errors are from
> passing arm gcc parameters to an x86 gcc. You can try "make ARCH=arm
> CROSS_COMPILE=/???/" instead, where /???/ is the prefix to your arm
> cross compiler. The kernel build actually uses both cross and non-cross
> compilers during build so you have some support tools compiled to run
> natively and others that run on the end machine, so you don't want to
> override CXX and C++ to be the cross compiler.

We crossed while my email client was offline and I was typing up
a response. All of the above is definitely true, and what I had in
my rambling reply as well.

When building with the SDK, to avoid oldconfig AND get the build
infrastructure both CROSS_COMPILE and ARCH are required, just as bitbake
was providing during the original build.

The trick is to still generate modules that will work against the running
kernel .. but that's another story :)

Cheers,

Bruce

>
>
> Brian
>
> On Sat, 2013-02-02 at 00:48 +0000, Patrick Turley wrote:
>> On Jan 31, 2013, at 10:50 PM, Bruce Ashfield<bruce.ashfield@windriver.com  <mailto:bruce.ashfield@windriver.com>>  wrote:
>>
>> >  On 13-01-23 10:17 AM, Patrick Turley wrote:
>> >>
>> >>  On Jan 23, 2013, at 7:48 AM, Bruce Ashfield<bruce.ashfield@windriver.com  <mailto:bruce.ashfield@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@windriver.com  <mailto:bruce.ashfield@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@windriver.com  <mailto:bruce.ashfield@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.
>>
>> I absolutely *am* still interested in this issue, and thank you for taking another look.
>>
>> There are two commands that I'm interested in executing:
>>
>>      -- make oldconfig
>>
>>      -- make scripts
>>
>> (Since I install the SDK under /opt, I use sudo when running these commands, but I don't *think* that's important.)
>>
>>
>> Here's what happens with the first command:
>>
>> $ sudo make oldconfig ARCH=arm
>>    HOSTCC  scripts/basic/fixdep
>>    HOSTCC  scripts/basic/docproc
>>    HOSTCC  scripts/kconfig/conf.o
>>    HOSTCC  scripts/kconfig/kxgettext.o
>>    SHIPPED scripts/kconfig/zconf.tab.c
>>    SHIPPED scripts/kconfig/lex.zconf.c
>>    SHIPPED scripts/kconfig/zconf.hash.c
>>    HOSTCC  scripts/kconfig/zconf.tab.o
>>    HOSTLD  scripts/kconfig/conf
>> scripts/kconfig/conf --oldconfig Kconfig
>> #
>> # configuration written to .config
>> #
>>
>> As you say, adding"ARCH=arm"  puts the build at ease and it completes just fine.
>>
>>
>> Here's what happens with the second command:
>>
>> $ sudo make scripts ARCH=arm
>> scripts/kconfig/conf --silentoldconfig Kconfig
>>    HOSTCC  scripts/genksyms/genksyms.o
>>    SHIPPED scripts/genksyms/lex.c
>>    SHIPPED scripts/genksyms/parse.h
>>    SHIPPED scripts/genksyms/keywords.c
>>    HOSTCC  scripts/genksyms/lex.o
>>    SHIPPED scripts/genksyms/parse.c
>>    HOSTCC  scripts/genksyms/parse.o
>>    HOSTLD  scripts/genksyms/genksyms
>>    CC      scripts/mod/empty.o
>> cc1: error: unrecognized command line option"-mlittle-endian"
>> cc1: error: unrecognized command line option"-mapcs"
>> cc1: error: unrecognized command line option"-mno-sched-prolog"
>> cc1: error: unrecognized command line option"-mabi=aapcs-linux"
>> cc1: error: unrecognized command line option"-mno-thumb-interwork"
>> scripts/mod/empty.c:1: error: bad value (armv5t) for -march= switch
>> scripts/mod/empty.c:1: error: bad value (armv5t) for -mtune= switch
>> make[2]: *** [scripts/mod/empty.o] Error 1
>> make[1]: *** [scripts/mod] Error 2
>> make: *** [scripts] Error 2
>>
>> Recall that, when I do *not* give the"ARCH=arm"  argument, I get reams of config questions, but the build works.
>>
>> This is an improvement in that the config questions are gone but, of course, the build fails.
>>
>> Perhaps it *should* fail. Perhaps I'm doing something that actually doesn't make sense. Or perhaps I'm doing something that Yocto just isn't ready to support. At this point, I should say:
>>
>> 1) I have a workaround for all this, so I am *not* dead in the water.
>>
>> 2) I am a kernel building n00b and it legitimately may not be worth your time (or anyone else's) to continue to look at this until I"catch up."  I don't want anyone throwing up their hands in frustration and saying"Doesn't this guy know anything?"  It's perfectly reasonable to cut me off at this point :)
>>
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org  <mailto:yocto@yoctoproject.org>
>> https://lists.yoctoproject.org/listinfo/yocto
>
>
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Re: Build external module against Yocto kernel

[Brian Lloyd]

[-- Attachment #1: Type: text/plain, Size: 9217 bytes --]

I would like to point out the reason CROSS_COMPILE is used is because
kernel makes things that run natively and also things that are for the
end environment.  Thus $(CROSS_COMPILE)$(CXX) is used to prepend when
building something for the end system, and $(CXX) is used for local run
items.  So even with CROSS_COMPILE defined, not everything uses the
CROSS_COMPILE.  Let's hope the kernel maintainers got the use and not
use right for us, because I sure don't want to be second guessing on
this mess.

I do know make scripts does create items intended to run in the final
environment.

Since I build for i386 on an x64 these days, I don't usually have
problems where I can't run the cross compiled tools, so my personal
recent experience is limited as well as bad parameters issues from using
the wrong compiler (as my compiler can generally make for both).

Brian
 
On Fri, 2013-02-01 at 23:48 -0500, Bruce Ashfield wrote:

> On 13-02-01 7:48 PM, Patrick Turley wrote:
> >
> > On Jan 31, 2013, at 10:50 PM, Bruce Ashfield<bruce.ashfield@windriver.com>  wrote:
> >
> >> On 13-01-23 10:17 AM, Patrick Turley wrote:
> >>>
> >>> On Jan 23, 2013, at 7:48 AM, Bruce Ashfield<bruce.ashfield@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@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@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.
> >
> > I absolutely *am* still interested in this issue, and thank you for taking another look.
> >
> > There are two commands that I'm interested in executing:
> >
> >      -- make oldconfig
> >
> >      -- make scripts
> >
> > (Since I install the SDK under /opt, I use sudo when running these commands, but I don't *think* that's important.)
> >
> >
> > Here's what happens with the first command:
> >
> > $ sudo make oldconfig ARCH=arm
> >    HOSTCC  scripts/basic/fixdep
> >    HOSTCC  scripts/basic/docproc
> >    HOSTCC  scripts/kconfig/conf.o
> >    HOSTCC  scripts/kconfig/kxgettext.o
> >    SHIPPED scripts/kconfig/zconf.tab.c
> >    SHIPPED scripts/kconfig/lex.zconf.c
> >    SHIPPED scripts/kconfig/zconf.hash.c
> >    HOSTCC  scripts/kconfig/zconf.tab.o
> >    HOSTLD  scripts/kconfig/conf
> > scripts/kconfig/conf --oldconfig Kconfig
> > #
> > # configuration written to .config
> > #
> >
> > As you say, adding "ARCH=arm" puts the build at ease and it completes just fine.
> >
> >
> > Here's what happens with the second command:
> >
> > $ sudo make scripts ARCH=arm
> > scripts/kconfig/conf --silentoldconfig Kconfig
> >    HOSTCC  scripts/genksyms/genksyms.o
> >    SHIPPED scripts/genksyms/lex.c
> >    SHIPPED scripts/genksyms/parse.h
> >    SHIPPED scripts/genksyms/keywords.c
> >    HOSTCC  scripts/genksyms/lex.o
> >    SHIPPED scripts/genksyms/parse.c
> >    HOSTCC  scripts/genksyms/parse.o
> >    HOSTLD  scripts/genksyms/genksyms
> >    CC      scripts/mod/empty.o
> > cc1: error: unrecognized command line option "-mlittle-endian"
> > cc1: error: unrecognized command line option "-mapcs"
> > cc1: error: unrecognized command line option "-mno-sched-prolog"
> > cc1: error: unrecognized command line option "-mabi=aapcs-linux"
> > cc1: error: unrecognized command line option "-mno-thumb-interwork"
> > scripts/mod/empty.c:1: error: bad value (armv5t) for -march= switch
> > scripts/mod/empty.c:1: error: bad value (armv5t) for -mtune= switch
> > make[2]: *** [scripts/mod/empty.o] Error 1
> > make[1]: *** [scripts/mod] Error 2
> > make: *** [scripts] Error 2
> >
> > Recall that, when I do *not* give the "ARCH=arm" argument, I get reams of config questions, but the build works.
> >
> 
> The thing is that the timestamps of the .config and the kernel's auto.conf
> should match and not trigger any more oldconfig executions.
> 
> I trust that if you still try "make scripts" without the ARCH,
> even after the oldconfig step #1, you are still seeing the
> questions. Thinking about it .. that does make sense that you'd
> be seeing the oldconfig questions .. since the ARCH did change.
> 
> .. and just so I'm clear, you are building a ARM machine on a
> x86 host and creating a SDK for that same x86 host, correct ?
> 
> The kernel's scripts target are really just a set of helpers for
> building the kernel, and in this case, you aren't actually building
> on a ARM machine, but on your x86 host. But the ARCH= is triggering
> the ARM toolchain settings to be passed to your host compiler, since
> CROSS_COMPILE= wasn't passed to the build.
> 
> So there's a couple of things more to consider:
> 
> 1) go back to phase #1 and back to the idea of generating a 
> allnoconfig/allyesconfig
> SDK configuration, that would save you from the oldconfig questions,
> but if any of the kernel modules or whatever you are building *use*
> the config values, you aren't going to be building them against the
> running kernel and it's settings .. which is a recipe for problems.
> 
> 2) Pass CROSS_COMPILE to the scripts phase and see how it works, the
> cross toolchain is in the SDK after all, so it is available. The
> scripts should be fine, but of course any executables that are build
> won't run on the host.
> 
> And even once you are up and building with kernel modules, you have
> to take care to keep your SDK in sync with the running kernel.
> 
> Moving the SDK to the target would of course get around the ARM compiler
> options and executables, but you'd have to have a ARM native compiler
> in the SDK and not a cross compiler. I don't know if this is done, or
> possible at the moment.
> 
> > This is an improvement in that the config questions are gone but, of course, the build fails.
> >
> > Perhaps it *should* fail. Perhaps I'm doing something that actually doesn't make sense. Or perhaps I'm doing something that Yocto just isn't ready to support. At this point, I should say:
> >
> > 1) I have a workaround for all this, so I am *not* dead in the water.
> >
> > 2) I am a kernel building n00b and it legitimately may not be worth your time (or anyone else's) to continue to look at this until I "catch up." I don't want anyone throwing up their hands in frustration and saying "Doesn't this guy know anything?" It's perfectly reasonable to cut me off at this point :)
> 
> I'm interested still, because it shows what I've warned about a few
> times in the past, and appears to still hold true .. that adding the
> ability to build kernel modules against a SDK itself, is still
> difficult, both in the kernel tooling and in keeping the SDK and
> running kernel in sync.
> 
> Working through the issues will let us know what is missing, and how
> much effort is left to complete the work.
> 
> The thing is that the SDK is constructed with the native-sdk packages
> (I've added Jessica, since I'm not 100% sure on this point), which
> means the SDK packages are for a particular host architecture (the
> native part) to  generate binaries for another. We just need to make the
> kernel build infrastructure work like this in the SDK (we know it is
> possible, since that's how the entire kernel build runs during a
> normal build).
> 
> Cheers,
> 
> Bruce
> 
> >
> 
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



[-- Attachment #2: Type: text/html, Size: 13427 bytes --]

Re: Build external module against Yocto kernel

[Bruce Ashfield]

On 13-02-02 12:12 AM, Brian Lloyd wrote:
> I would like to point out the reason CROSS_COMPILE is used is because
> kernel makes things that run natively and also things that are for the
> end environment. Thus $(CROSS_COMPILE)$(CXX) is used to prepend when
> building something for the end system, and $(CXX) is used for local run
> items. So even with CROSS_COMPILE defined, not everything uses the
> CROSS_COMPILE. Let's hope the kernel maintainers got the use and not use
> right for us, because I sure don't want to be second guessing on this mess.

Absolutely .. the kernel always gets this right, native utilities never
use the prefix. In fact, in 12 years I've only run into one mix up
between target and native .o's in a kernel build.

Cheers,

Bruce

>
> I do know make scripts does create items intended to run in the final
> environment.
>
> Since I build for i386 on an x64 these days, I don't usually have
> problems where I can't run the cross compiled tools, so my personal
> recent experience is limited as well as bad parameters issues from using
> the wrong compiler (as my compiler can generally make for both).
>
> Brian
>
> On Fri, 2013-02-01 at 23:48 -0500, Bruce Ashfield wrote:
>> On 13-02-01 7:48 PM, Patrick Turley wrote:
>> >
>> >  On Jan 31, 2013, at 10:50 PM, Bruce Ashfield<bruce.ashfield@windriver.com  <mailto:bruce.ashfield@windriver.com>>   wrote:
>> >
>> >>  On 13-01-23 10:17 AM, Patrick Turley wrote:
>> >>>
>> >>>  On Jan 23, 2013, at 7:48 AM, Bruce Ashfield<bruce.ashfield@windriver.com  <mailto:bruce.ashfield@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@windriver.com  <mailto:bruce.ashfield@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@windriver.com  <mailto:bruce.ashfield@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.
>> >
>> >  I absolutely *am* still interested in this issue, and thank you for taking another look.
>> >
>> >  There are two commands that I'm interested in executing:
>> >
>> >       -- make oldconfig
>> >
>> >       -- make scripts
>> >
>> >  (Since I install the SDK under /opt, I use sudo when running these commands, but I don't *think* that's important.)
>> >
>> >
>> >  Here's what happens with the first command:
>> >
>> >  $ sudo make oldconfig ARCH=arm
>> >     HOSTCC  scripts/basic/fixdep
>> >     HOSTCC  scripts/basic/docproc
>> >     HOSTCC  scripts/kconfig/conf.o
>> >     HOSTCC  scripts/kconfig/kxgettext.o
>> >     SHIPPED scripts/kconfig/zconf.tab.c
>> >     SHIPPED scripts/kconfig/lex.zconf.c
>> >     SHIPPED scripts/kconfig/zconf.hash.c
>> >     HOSTCC  scripts/kconfig/zconf.tab.o
>> >     HOSTLD  scripts/kconfig/conf
>> >  scripts/kconfig/conf --oldconfig Kconfig
>> >  #
>> >  # configuration written to .config
>> >  #
>> >
>> >  As you say, adding"ARCH=arm"  puts the build at ease and it completes just fine.
>> >
>> >
>> >  Here's what happens with the second command:
>> >
>> >  $ sudo make scripts ARCH=arm
>> >  scripts/kconfig/conf --silentoldconfig Kconfig
>> >     HOSTCC  scripts/genksyms/genksyms.o
>> >     SHIPPED scripts/genksyms/lex.c
>> >     SHIPPED scripts/genksyms/parse.h
>> >     SHIPPED scripts/genksyms/keywords.c
>> >     HOSTCC  scripts/genksyms/lex.o
>> >     SHIPPED scripts/genksyms/parse.c
>> >     HOSTCC  scripts/genksyms/parse.o
>> >     HOSTLD  scripts/genksyms/genksyms
>> >     CC      scripts/mod/empty.o
>> >  cc1: error: unrecognized command line option"-mlittle-endian"
>> >  cc1: error: unrecognized command line option"-mapcs"
>> >  cc1: error: unrecognized command line option"-mno-sched-prolog"
>> >  cc1: error: unrecognized command line option"-mabi=aapcs-linux"
>> >  cc1: error: unrecognized command line option"-mno-thumb-interwork"
>> >  scripts/mod/empty.c:1: error: bad value (armv5t) for -march= switch
>> >  scripts/mod/empty.c:1: error: bad value (armv5t) for -mtune= switch
>> >  make[2]: *** [scripts/mod/empty.o] Error 1
>> >  make[1]: *** [scripts/mod] Error 2
>> >  make: *** [scripts] Error 2
>> >
>> >  Recall that, when I do *not* give the"ARCH=arm"  argument, I get reams of config questions, but the build works.
>> >
>>
>> The thing is that the timestamps of the .config and the kernel's auto.conf
>> should match and not trigger any more oldconfig executions.
>>
>> I trust that if you still try"make scripts"  without the ARCH,
>> even after the oldconfig step #1, you are still seeing the
>> questions. Thinking about it .. that does make sense that you'd
>> be seeing the oldconfig questions .. since the ARCH did change.
>>
>> .. and just so I'm clear, you are building a ARM machine on a
>> x86 host and creating a SDK for that same x86 host, correct ?
>>
>> The kernel's scripts target are really just a set of helpers for
>> building the kernel, and in this case, you aren't actually building
>> on a ARM machine, but on your x86 host. But the ARCH= is triggering
>> the ARM toolchain settings to be passed to your host compiler, since
>> CROSS_COMPILE= wasn't passed to the build.
>>
>> So there's a couple of things more to consider:
>>
>> 1) go back to phase #1 and back to the idea of generating a
>> allnoconfig/allyesconfig
>> SDK configuration, that would save you from the oldconfig questions,
>> but if any of the kernel modules or whatever you are building *use*
>> the config values, you aren't going to be building them against the
>> running kernel and it's settings .. which is a recipe for problems.
>>
>> 2) Pass CROSS_COMPILE to the scripts phase and see how it works, the
>> cross toolchain is in the SDK after all, so it is available. The
>> scripts should be fine, but of course any executables that are build
>> won't run on the host.
>>
>> And even once you are up and building with kernel modules, you have
>> to take care to keep your SDK in sync with the running kernel.
>>
>> Moving the SDK to the target would of course get around the ARM compiler
>> options and executables, but you'd have to have a ARM native compiler
>> in the SDK and not a cross compiler. I don't know if this is done, or
>> possible at the moment.
>>
>> >  This is an improvement in that the config questions are gone but, of course, the build fails.
>> >
>> >  Perhaps it *should* fail. Perhaps I'm doing something that actually doesn't make sense. Or perhaps I'm doing something that Yocto just isn't ready to support. At this point, I should say:
>> >
>> >  1) I have a workaround for all this, so I am *not* dead in the water.
>> >
>> >  2) I am a kernel building n00b and it legitimately may not be worth your time (or anyone else's) to continue to look at this until I"catch up."  I don't want anyone throwing up their hands in frustration and saying"Doesn't this guy know anything?"  It's perfectly reasonable to cut me off at this point :)
>>
>> I'm interested still, because it shows what I've warned about a few
>> times in the past, and appears to still hold true .. that adding the
>> ability to build kernel modules against a SDK itself, is still
>> difficult, both in the kernel tooling and in keeping the SDK and
>> running kernel in sync.
>>
>> Working through the issues will let us know what is missing, and how
>> much effort is left to complete the work.
>>
>> The thing is that the SDK is constructed with the native-sdk packages
>> (I've added Jessica, since I'm not 100% sure on this point), which
>> means the SDK packages are for a particular host architecture (the
>> native part) to  generate binaries for another. We just need to make the
>> kernel build infrastructure work like this in the SDK (we know it is
>> possible, since that's how the entire kernel build runs during a
>> normal build).
>>
>> Cheers,
>>
>> Bruce
>>
>> >
>>
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org  <mailto:yocto@yoctoproject.org>
>> https://lists.yoctoproject.org/listinfo/yocto
>