Kernel-devel

[cha...@gmail.com]

Hi everyone.

I need to compile a device driver against Angstrom. In the Makefile of the driver I have to set the path to the directory that contains the Makefile of the kernel. As I understood, by default there is not kernel-devel installed on Minnowboard's Angstrom by default. There is not a package such named in the Package browser in Angstrom web site neither. My question is what would be the Angstrom's equivalent to kernel-devel and what would be the location of the kernel's Makefile?.

Thanks

[Koen Kooi]

Op 7 sep. 2013, om 22:44 heeft cha...@gmail.com het volgende geschreven:

> Hi everyone.
>
> I need to compile a device driver against Angstrom. In the Makefile of the driver I have to set the path to the directory that contains the Makefile of the kernel. As I understood, by default there is not kernel-devel installed on Minnowboard's Angstrom by default. There is not a package such named in the Package browser in Angstrom web site neither. My question is what would be the Angstrom's equivalent to kernel-devel and what would be the location of the kernel's Makefile?.

'kernel-dev'

[cha...@gmail.com]

Hi Koen. Thanks for your response.

After the installation, the make file for the kernel seems to be "/usr/src/kernel/Makefile" For the record this was the output of the proccess (it seems there was a "unsatisfied recommendation" warning):

root@minnow:~# opkg install kernel-dev
Installing kernel-dev (3.8.13+gitAUTOINC+c0851dfb8535635e1e31d4a5146d3f021e30506c_4afed227ab8d84c7eaf222cad85e8232e4ea9cb0-r4.1.1) to root...
Downloading http://feeds.angstrom-distribution.org/feeds/v2012.12/ipk/eglibc/core2/machine/minnow/kernel-dev_3.8.13+gitAUTOINC+c0851dfb8535635e1e31d4a5146d3f021e30506c_4afed227ab8d84c7eaf222cad85e8232e4ea9cb0-r4.1.1_minnow.ipk.
kernel-dev: unsatisfied recommendation for kernel-base-dev
Configuring kernel-dev.

Despite having installed "kernel-dev" there was not possible to compile the module. I faced this issues:

1. The source code contained the function err() that was not recognized by the compiler. I tried to change it for fprintf() but the compiler could not find stdio.h!!. I presumed that it was for the lack of Build-Essential package. Finally y replace the unknown function for dbg().

2. After "resolving" the former problem, there were a few more after running make:

/bin/sh: /usr/src/kernel/scripts/recordmcount: No such file or directory

solved it with "make recordmcount"

/bin/sh: scripts/basic/fixdep: No such file or directory

solved it with "make fixdep"

/bin/sh: scripts/mod/modpost: No such file or directory

I could not compile this. I got "modpost.h:12:23: fatal error: elfconfig.h: No such file or directory".

If I try to "make modules" i get "*** No rule to make target `arch/x86/tools/relocs.c', needed by `arch/x86/tools/relocs'.  Stop."

I hope that someone that identify the source of the errors, or have experience building modules for this OS, could me with this.

Thanks for reading.

[Darren Hart]

That one is a generated file...

>
> If I try to "make modules" i get "*** No rule to make target
> `arch/x86/tools/relocs.c', needed by `arch/x86/tools/relocs'. Stop."

Hrm, but this one should be there... this is familiar, but I can't put
my finger on it just now. Can you confirm that the sources do not
include arch/x86/tools/relocs.c?

>
> I hope that someone that identify the source of the errors, or have
> experience building modules for this OS, could me with this.

The issue is that while building modules on the target is supported, it
is not the typical method employed by the developers associated with the
project. We tend to build the kernel and any modules using bitbake. This
needs to be fixed and it is supported, it just isn't the common case.
Please file a bug containing the information you supplied here in the
yocto project bugzilla:

http://bugzilla.yoctoproject.org

Thanks,

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


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

[cha...@gmail.com]

This is the content of the directory:

drwxr-xr-x  2 root root 4096 Jan  1 00:06 ./
drwxr-xr-x 25 root root 4096 Jan  1 00:06 ../
-rw-r--r--  1 root root    7 Jul  3  2013 .gitignore
-rw-r--r--  1 root root 1786 Jul  3  2013 Makefile
-rw-r--r--  1 root root  721 Jul  3  2013 chkobjdump.awk
-rw-r--r--  1 root root 1274 Jul  3  2013 distill.awk
-rw-r--r--  1 root root 9417 Jul  3  2013 gen-insn-attr-x86.awk
 

>
> I hope that someone that identify the source of the errors, or have
> experience building modules for this OS, could me with this.

The issue is that while building modules on the target is supported, it
is not the typical method employed by the developers associated with the
project. We tend to build the kernel and any modules using bitbake. This
needs to be fixed and it is supported, it just isn't the common case.
Please file a bug containing the information you supplied here in the
yocto project bugzilla:

http://bugzilla.yoctoproject.org

Sorry. I have buid this modules for other distros from the own target, followin the procedure recomended by the device manufacturer. And I don't now very well the recommended cross-compiled process (if you know a tuttorial to getting started with this it would be helpful.)

Sorry. I have builded this modules for other distros, from the own target system, following the procedure recomended by the device manufacturer. I don't know very well the recommended cross-compiled process (if you know about a tutorial to getting started quickly with this, it would be very helpful.)

By the way, should I create new account at bugzilla.yoctoproject.org to report this as a bug?
 

[Darren Hart]

As you know, the Yocto Project was involved with the development of the
MinnowBoard, which is why I mentioned it. Note that there is nothing
wrong with what you are trying to do, it just isn't how many of us do
things. This is a valid bug that needs fixing.

As for tutorials, if you are so inclined, I suggest reading the
MinnowBoard BSP README here:
http://git.yoctoproject.org/cgit/cgit.cgi/meta-minnow/tree/README

The Yocto Project Quick Start Guide here:
https://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs.html

And finally, the Yocto Project Kernel Development Manual, here:
http://www.yoctoproject.org/docs/current/kernel-dev/kernel-dev.html

>
> By the way, should I create new account at bugzilla.yoctoproject.org
> to report this as a bug?

Yes, if you don't have one already, you will need to create an account.

Thanks for taking the time to report it. Getting it into Bugzilla will
help make sure it doesn't get lost in the chaos :-)

--
Darren

[cha...@gmail.com]

After some weeks of hiatus (I had my Minnowboard on RMA), I got back to work with it. I was trying to build a third party module on the Minnowboard, but I got the following errors:

/bin/sh: /usr/src/kernel/scripts/recordmcount: No such file or directory

solved it with "make recordmcount"

/bin/sh: scripts/basic/fixdep: No such file or directory

solved it with "make fixdep"

/bin/sh: scripts/mod/modpost: No such file or directory

I could not compile this. I got "modpost.h:12:23: fatal error: elfconfig.h: No such file or directory".

If I try to "make modules" i get "*** No rule to make target `arch/x86/tools/relocs.c', needed by `arch/x86/tools/relocs'.  Stop."

As @Darren Hart suggested, I filled a report on Bugzilla for this issue. For the record, there was a related report "Building a kernel module on target image fails" that was closed as "INVALID".

I was wondering if there is a source from I can copy the missing files or other workaround that let me continue with my work, meanwhile the bug report is revised.

Thanks.

[Hart, Darren]

On Mon, 2013-10-28 at 17:28 -0700, cha...@gmail.com wrote:
> After some weeks of hiatus (I had my Minnowboard on RMA), I got back
> to work with it. I was trying to build a third party module on the
> Minnowboard, but I got the following errors:
>
> /bin/sh: /usr/src/kernel/scripts/recordmcount: No such file or
> directory
>
> solved it with "make recordmcount"
>
> /bin/sh: scripts/basic/fixdep: No such file or directory
>
> solved it with "make fixdep"
>
> /bin/sh: scripts/mod/modpost: No such file or directory
>
> I could not compile this. I got "modpost.h:12:23: fatal error:
> elfconfig.h: No such file or directory".
>
> If I try to "make modules" i get "*** No rule to make target
> `arch/x86/tools/relocs.c', needed by `arch/x86/tools/relocs'. Stop."
>
> As @Darren Hart suggested, I filled a report on Bugzilla for this
> issue. For the record, there was a related report "Building a kernel
> module on target image fails" that was closed as "INVALID".

Yes, but that was a different bug. The thing you are hitting is a
complication associated with cross compiling where things like
recordmcount are built for the build host, they must be rebuilt on the
target.

> I was wondering if there is a source from I can copy the missing files
> or other workaround that let me continue with my work, meanwhile the
> bug report is revised.

I was thinking "make scripts" solved all the issues, but perhaps the
relocs issue remains. Hrm. I have built a module on the minnow, so I
need to recall the steps. Unfortunately it is not documented in the
kernel-dev manual. Will look into it, but poke again in a week if you
haven't heard back. Traveling at the moment.

--
Darren

[cha...@gmail.com]

Hi Darren:

After reporting the bug, this was the respose given (by Bruce Ashfield)

This is expected (at the moment), there are open enhancements to prepare the SDK to build modules by default, and since the SDK uses the kernel-dev package, you'll have the same results just using it. The scripts that support module building are not in the kernel-dev package, since we can't mix architectures (as one of several QA errors you get if they are left in place). So after install (in the sysroot or on the target), you need to restore the scripts. If you head to the installed kernel source tree and do a 'make scripts', what is your result ? (The enhancement to the SDK is all about ensuring that make scripts is run during SDK creation, so you don't need this manual step anymore).

After "make scripts", I ran "make" for the module, and it worked.

[Hart, Darren]

Great, glad you're unstuck. We would like to make this a bit more
seamless, but the cross-compilation issues with the kernel's build
system makes the workaround a lot more attractive than the solution :-)
But yes, the bug is valid and we'll work on it - unless of course
someone else beats us to it ;-)