How .ko file is built - linux-kernel

I am trying to port my own driver to a Beagle board xm arm-cortex-A8. While porting I am trying to figuring out how the .ko file actually builds. In our Makefile we only have a command to build an.o file.
How is a .ko file built?
Using linux-2.6.38.8 kernel and trying to configure my driver for my kernel.

The kernel kbuild module document has lots of information on how to build an external module. If you have Raspberian or some other embedded ARM Linux, you will need to get the source package for your kernel. The process differs based on whether you are compiling on the same machine the module will run on, or if you are trying to build it on a PC (hopefully a Linux PC).
Please specify which way you need to build, if the kbuild module document doesn't explain things well enough.

Related

Buiding kernel for an ARM processor

I working on Odroid XU3 with the ubuntu platform. For the DS5 software to crosscompile for profiling , I need to build Linux kernel with specific configuration. I am new to this stuff, but I have created the UImage of the kernel on the host machine for the Arm processor. I need to ask how one can get that kernel copy in the target platform i.e. Odroid.
Because for the profiling I need to have gatord and kernel with specific configuration installed on the target machine. I am done with gatord and build the kernel on host. Just need to copy it on target. But it is not happening using the sdcard of the odroid. Please let me know.
So if you have created uImage that seems like you have U-Boot as a bootloader on your target board. U-Boot in its turns can download kernel uImages via TFTP. I haven't worked with such devices as yours, but if it has Ethernet port, you could use it.
Also you have to know the U-Boot commands (fortunatelly there are a lot of information can be found over Internet, just ask google.)

How can I generate kernel headers for an "unknown" embedded ARM system?

I have an (old) embedded system for which I want to compile programs. I don't have the toolchain, so I want to create one.
The embedded system has an "ARM926EJ-S rev 5 (v5l)" CPU and "cat /proc/version" says that it runs "Linux version 2.6.20.7" with GCC 4.0.2.
I have heard that I have to include the kernel headers in the build process. I download the Linux kernel version 2.6.20 from kernel.org, extract all files and run "make headers_install ARCH=arm INSTALL_HDR_PATH=~/headers". Is this the correct way or do I need the header files of the specific kernel?
untar the kernel.
make mrproper
make ARCH=${arch} headers_check
e.g make ARCH=arm headers_check
make ARCH=${CLFS_ARCH} INSTALL_HDR_PATH=dest headers_install
This are the steps to get headers from kernel.
The purpose of kernel headers is -->C library and compiled programs needs to interact with the kernel
i.e for Available system calls and their numbers, Constant definitions, Data structures, etc.
Therefore, compiling the C library requires kernel headers, and many applications also require them.
do I need the header files of the specific kernel?
The kernel-to-userspace ABI is backward compatible
--> 1)Binaries generated with a toolchain using kernel headers older
than the running kernel will work without problem, but won't
be able to use the new system calls, data structures, etc.
-->2)Binaries generated with a toolchain using kernel headers newer
than the running kernel might work on if they don't use the
recent features, otherwise they will break.
--->3)Using the latest kernel headers is not necessary, unless access
to the new kernel features is needed
So in your case kernel version is "Linux version 2.6.20.7"
You can use kernel headers of Linux kernel version 2.6.20 or 2.6.21 from kernel.org.
does not create any problem in this case.
That should be fine if you're using the headers to build a libc
You should probably run make ARCH=arm headers_check beforehand too.

RaspberryPi rpi-firmware and .kos in buildroot package

I am trying to bring up the kernel and RFS generated by buildroot on a Raspberry Pi board. I am able to bring up the minimal kernel and access shell via a serial cable.
I could see some .ko files that looks like peripheral drivers rpi-firmware package that is downloaded by buildroot. Is it possible to integrate those into the kernel image ? if so , how?
Figured it out. I just have to enable the required drivers from the linux configuration menu (make linux-menuconfig) .
If I enable them as modules, they will be copied into a folder in /lib. Otherwise, they will be integrated in the zImage

inserting kernel module after make mrproper

I download the kernel source, compile it and run the new kernel. I am making some change to kvm kernel module and testing it.
So this is what I do after making some change in the kernel source.
make M=arch/x86/kvm
After this I am able to successfully insert the kernel module.
By mistake I did make mrproper which cleans all the binaries and byproducts on a linux compile.
So, is there a way now to make my kernel module only and insert it into current booted kernel or should I compile the whole kernel again and replace the new vmlinuz with vmlinuz file in /boot.
I can do the second option but it takes time and is not the most intelligent way for this small problem.
If the kernel is currently running you can try running make cloneconfig. This should configure the kernel tree exactly like the running kernel.
The compiled module should then match your kernel.

what is cross compilation?

what is cross compilation?
Cross-compilation is the act of compiling code for one computer system (often known as the target) on a different system, called the host.
It's a very useful technique, for instance when the target system is too small to host the compiler and all relevant files.
Common examples include many embedded systems, but also typical game consoles.
A cross-compiler is compiles the source code from one architecture to another architecture.
For example: hello.c
gcc hello.c (gcc is a compiler for x86 architecture.)
arm-cortexa8-linux-gnueabihf-gcc hello.c
(arm-....-gcc is a compiler for the arm architecture.) This you are compiling on the host pc for a target board (e.g rpi, beaglebone, wega board). In this example arm-cortexa8-linux-gnueabihf-gcc is called the 'cross compiler'.
This process is called cross compilation.
see the link for more info cross compilation
To "cross compile" is to compile source on say a Linux box with intent on running it on a MAC or Windows box. This is usually done using a cross compilation plugin, which are readily available from various web servers across the net. If one is to install a cross compilation plugin onto their Linux box that is designed to compile for Windows boxes. Then they may compile for either a Linux/*NIX box as well as have the option to compile and link a Windows-ready executable. This is extremely convenient for a freelance programmer whom has access to no more than a single Linux/Windows/MAC box. Note that various cross compilation plugins will allow for multitudes of applications, some of which you may or may not perceive as useful, thus a thorough perusal of the plugin's README file.
Did you have a particular project in mind that you would like to apply the method of cross compilation to?
In a strict sense, it is the compilation of code on one host that is intended to run on another.
Most commonly it is used with reference to compilation for architectures that are not binary-compatible with the host -- for instance, building RISC binaries on a CISC CPU platform, or 64-bit binaries on a 32-bit system. Or, for example, building firmware intended to run on embedded devices (perhaps using the ARM CPU architecture) on Intel PC-based OSs.
A Cross Compiler is a compiler capable of creating executable code for a platform other than the one on which the compiler is running.
For e.g. a compiler that runs on a Windows 7 PC but generates code that runs on Android smartphone is a cross compiler.
A cross compiler is necessary to compile for multiple platforms from one machine.
A platform could be infeasible for a compiler to run on, such as for the microcontroller of an embedded system because those systems contain no operating system.
In paravirtualization one machine runs many operating systems, and a cross compiler could generate an executable for each of them from one main source.

Resources