However I Cross Compiled ARM Kernel instead of ARMHF(for my Cubietruck). I followed this tutorial:
https://romanrm.net/a10/cross-compile-kernel
How can I determine for which architecture I´m cross-compiling?
i got a new error that /linux/utsrealease.h is not found
from above comment as you mentioned.. from that its clear that kernel module which your building must match with running kernel version . As kernel modules loading mechanism doesn't allow loading modules that were not compiled against the running kernel, due to mismatch error is coming.
The macro UTS_RELEASE is required by your driver in order to rebuild
kernel modules from source.
retrieving the version string constant,
older versions require you to include<linux/version.h>,
others <linux/utsrelease.h>,
and newer ones <generated/utsrelease.h>
So my suggestion you do workaround by doing
you can find utsrelease.h in kernel source code make sure your running kernel must match with your source-code
copy linux-x.x.x/include/generated/utsrelease.h to installed header i.e ../include/linux/utsrelease.h
Im not sure give a try .
If above doesnot work pls update your question with
1)which kernel sourcode version you have
2)Whats the kernel version running on target
When you compile your kernel, mention the architecture you are compiling for in:
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- EXTRAVERSION=-custom1 uImage
For eg, here ARCH=arm, so you are compiling for ARM, if it's x86, then you'll replace it with x86. Check what architecture your target board is on.
EDIT: gnueabihf is for armhf.
Related
I'm trying to use the Linux kernel address sanitizer (KASAN) with a loadable module, but so far haven't been able to make it work. I compiled a kernel with KASAN and was able to verify that it properly detects errors caused by the statically linked body of the kernel, but when I compile a loadable module with that kernel, the module is not configured for KASAN (e.g. KASAN CFLAGS switches are missing). I noticed that the lib/include/config/auto.conf file in the /lib/modules/xxx directory is different from the one in the kernel build directory, so I tried copying the auto.conf file from the kernel directory to lib/modules/xxx. At this point the individual files appear to compile with the same KASAN flags as the kernel, but the module build fails during the link step with missing symbols such as __asan_handle_no_return.
Is KASAN known to work with modules? If so, is any additional configuration needed for a module to use KASAN?
Answering my own question: KASAN actually works great for modules. Somehow I managed to botch the installation of the KASAN-ified kernel so that the module was compiling with old info. After reinstallation, the module compiled cleanly with KASAN and errors in the module are properly detected. Sorry for the false alarm here.
I'm trying to config my kernel (2.2.0) but when I use make menuconfig make says: No rule to make target 'arch/x86_64/Makefile'. It is a wrong response because there is no directory named x86_64 in arch. Is there a problem with the kernel tree?
The source of my kernel tree can be found here
The "problem" is that the x86_64 architecture was not yet supported in 1999. You simply need to get a kernel from this millennium if you want to target this architecture, or painstakingly backport the necessary code changes to support it from a newer version.
I am working on linux kernel development, and was trying to make my own modules for testing purposes. However, for the latest kernel source codes, the linux-headers don't exist. It only exists for 4.9.0-7 .
I googled and found 1 method where we make the module against the kernel source tree that we want (eg. 4.18)
make -C /home/prasad/linux-4.18/ M=$(PWD)
which does generate the .ko for my module. However, when I load up my kernel and insmod it , it says
insmod: ERROR: could not insert module test.ko: Unknown symbol in module
So how exactly do I generate a .ko file from my host machine that can be inserted for the 4.18 kernel ?
PS: My doubt is not a duplicate as I cannot "install" the 4.18 kernel in my vm, Im trying to avoid doing that. My question is more specific to generating an insertable .ko module, and not finding any other way to insert it in 4.18.
You cant use a module built for 4.18 in a 4.9 kernel.
If the headers for the kernel version you are building for are not available via apt/yum/etc, you will need to download the source manually from: https://www.kernel.org/
In the makefile for your module, you will specify the path to the kernel source code that you have downloaded and extracted.
That should allow you to build the module for the desired kernel version.
I want to build a application which supports eBPF on CentOS 7 (the kernel version is 3.10.0):
if(setsockopt(sock, SOL_SOCKET, SO_ATTACH_BPF, prog_fd, sizeof(prog_f)) {
......
}
So I download a 4.0.5 version, make the following configurations on:
CONFIG_BPF=y
CONFIG_BPF_SYSCALL=y
Then follow this link to build and install a 4.0.5 kernel.
After executing make modules_install install, I find there is still no SO_ATTACH_BPF in <asm-generic/socket.h>, so the above code can't be compiled successfully.
How to build Linux kernel to support SO_ATTACH_BPF socket option?
In my setup, which is based on Fedora 21, I use very similar steps to those you linked to compile and install the latest kernel. As an additional step, I will do the following from the kernel build tree to install the kernel header files into /usr/local/include:
sudo make INSTALL_HDR_PATH=/usr/local headers_install
This will cause both the stock kernel header files to remain installed in /usr/include/{linux,asm,asm-generic,...}, and the new kernel header files to be installed in /usr/local/include/{linux,asm,asm-generic,...}. During your test program compile, depending on which build system you use, you may need to prefix gcc/clang with -I/usr/local/include.
Your newly installed kernel supports SO_ATTACH_BPF, but your current libc package doesn't now about that (as you mention, distro's native 3.10.0 kernel lacks of given option support).
You need to update libc package as well for use new kernel's features in user space programs.
I've spent a lot of time setting up the CUDA toolchain on a machine running Ubuntu Linux (11.04). The rig has two NVIDIA Tesla GPUs, and I'm able to compile and run test programs from the NVIDIA GPU Computing SDK such as deviceQuery, deviceQueryDrv, and bandwidthTest.
My problems arise when I try to compile basic sample programs from books and online sources. I know you're supposed to compile with NVCC, but I get compile errors whenever I use it. Basically any sort of include statement involving CUDA libraries gives a missing file/library error. An example would be:
#include <cutil.h>
Do I need some sort of makefile to direct the compiler to these libraries or are there additional flags I need to set when compiling with NVCC?
I followed these guides:
http://hdfpga.blogspot.com/2011/05/install-cuda-40-on-ubuntu-1104.html http://developer.download.nvidia.com/compute/DevZone/docs/html/C/doc/CUDA_C_Getting_Started_Linux.pdf
To fix the include problems add the cuda include directory to your compilation options (assuming it is /usr/local/cuda/include):
nvcc -I/usr/local/cuda/include -L/usr/local/cuda/lib test.cu -o test
cutil is not part of the CUDA toolkit. It's part of the CUDA SDK. So, assuming you have followed the instructions and you have added the PATH and LIB directories to your environment variables you still need to point to the CUDA SDK includes and libraries directories.
In order to include that lib manually you must pass the paths to the compiler:
nvcc -I/CUDA_SDK_PATH/C/common/inc -L/CUDA_SDK_PATH/C/lib ...
Although I personally prefer not to use the CUDA SDK libraries, you probably will find easier start a project from a CUDA SDK example.