Installing the proper headers for a self-compiled kernel

Hi

I am working on a kernel module for the beaglebone black and trying to make use of preempt rt to improve timing. I tweaked some settings in the 4.1.13-ti-rt-r36 kernel and compiled it using Robert Nelson’s instructions here.
The kernel runs on the beaglebone, however I cannot seem to get the headers right to install my kernel module. I first installed the kernel directly to the sd-card using the install_kernel.sh script. This does not install the kernel headers. Installing the headers for the exact same version from the repository lets me compile my module, however not insert it:

[ 1495.737241] UARTbbMod: disagrees about version of symbol module_layout

Next I installed the kernel image along with headers and firmware image as .deb files, however now I cannot compile my module as I get the following error:

root@beaglebone:~/UARTbbModule# make
make -C /lib/modules/4.1.13-ti-rt-r36/build M=/root/UARTbbModule modules
make[1]: Entering directory /usr/src/linux-headers-4.1.13-ti-rt-r36' ./scripts/recordmcount: 1: ./scripts/recordmcount: Syntax error: end of file unexpected make[2]: *** [/root/UARTbbModule/UARTbitbangModule.o] Error 2 make[1]: *** [_module_/root/UARTbbModule] Error 2 make[1]: Leaving directory /usr/src/linux-headers-4.1.13-ti-rt-r36’
make: *** [all] Error 2

according to some google research this seems to be a problem when cross-compiling headers on a different system architecture (my host pc has 64-bit Linux Mint 17.3 installed).

Can somebody point me in the right direction on how to get the kernel headers working alongside a self-compiled kernel?

Help is greatly appreciated, thanks!

Use build_deb.sh instead of build_kernel.sh, following the directions exactly the same otherwise, and you should be presented with 3-4 debs in the deploy directory when done. One of those will be a kernel headers *deb for which you can easily move to the target, and dpkg -i to install.

By the way. building that kernel is asking for trouble, unless you’re familiar with git, and rebasing repo’s.

Hi William

I actually used build_deb.sh to build the .deb files I used for the second try, wasn’t really clear maybe, sorry. There I just ran into the architecture problem.

Hi William

I actually used build_deb.sh to build the .deb files I used for the second try, wasn’t really clear maybe, sorry. There I just ran into the architecture problem.

Well, the top of that page for Robert’s guide tells you how to deal with 64bit host systems. e.g. :386, and dpkg add-architecture, etc.

I installed these i386 libraries as described, so that can’t be the problem. The build_kernel.sh script downloads it’s own toolchain, which is gcc-linaro-4.9-2015.05-x86_64_arm-linux-gnueabihf, everything compiles without error, but as stated the architecture problem appears after installing the .deb files. Now, when I manually download the gcc-linaro-arm-linux-gnueabihf-``4.9``-``2014``.09_linux toolchain as described in Robert's guide and set the system.sh to use this one, I get a constant stream of errors:

ERROR: ld.so: object ‘libfakeroot-sysv.so’ from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.

installing fakeroot:i386 does not help at all, the error just changes to:

ERROR: ld.so: object ‘libfakeroot-sysv.so’ from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.

I don’t know if using the x86_64 toolchain causes the “./scripts/recordmcount: 1: ./scripts/recordmcount: Syntax error: end of file unexpected” architecture mismatch, but I cannot get using the toolchain recommended in Robert’s guide to work.

These wrong ELF class errors are recognised as a fakeroot bug, it seems. Not that this would help me…

https://bugs.launchpad.net/ubuntu/+source/fakeroot/+bug/1001129

The elf errors are just an annoyance…

The real problem, the headers package doesn’t build correctly when cross built…

The elf errors are just an annoyance…

The real problem, the headers package doesn’t build correctly when cross built…

Really ? Never installed them myself, as if I’m already cross compiling the kernel, wtf do I need the header files on the target for ? :wink:

The elf errors are just an annoyance…

The real problem, the headers package doesn’t build correctly when cross built…

Really ? Never installed them myself, as if I’m already cross compiling the kernel, wtf do I need the header files on the target for ? :wink:

That’s my thought too… You already have the full source, build you module against that…

For some reason, when cross built, a ‘few’ things get built for the ‘host’.

It’s been getting better… 3.8 was terrible, 3.14 usable, 4.1 (haven’t tested as the driver I was testing went mainline…)

I found it more convenient for my small module to tweak and compile it on the beaglebone itself, but I’ll set everything up to compile it directly on the host, then.

thanks for your help