I need to build mmc_block.ko but with MMC_BLOCK_MINORS=16. I do not wish to build the entire kernel. I am using Ubuntu 15.10. How do I do this?
Dpending on how the Makefile has been written, a module can be compiled out of the kernel tree or in the kernel tree.
Concerning your specific example, I assume the module is the one shipped with the kernel and therefore the Makefile has been written for in-tree compilation. In this case, you can just type make modules to rebuild the module, provided that the kernel has been already compiled (which is a mandatory condition also for out-of-the-tree compilation).
Related
I hope somebody can shine me a light. I am using Yocto/Poky with linux kernel sources from a custom repository with an "in-tree" kernel configuration and device tree. (not using fragments or overlays)
When building the kernel stand alone using:
make myconfig_defconfig
make
All the device tree binaries for the configured architecture are built.
When building the same kernel+config within Yocto (Kirkstone), the kernel image is built, but no device tree files.
During Yocto build, a defconfig is generated in "/.kernel-meta/configs"
This config is what I expect and has the correct "CONFIG_ARCH_" set to match the devicetree Makefile.
Compared to the previous setup(s) another machine definition is used (meta-Xilinx), Poky-dunfell changed to Poky-Kirkstone and the kernel is a newer version. (but since this compiles the devicetree when used stand alone, it seems not the cause)
At this moment I have no idea what may cause not to compile the devicetree files.
Any suggestions are welcome.
I have a Linux kernel for NXP i.MX6. There are some capture kernel modules in /driver/media/platform/mxc/capture.
One of the files called mxc_v4l2_capture.c. I had to change this file for using it with my own new kernel driver.
I created a repository with my driver and the sources for mxc_v4l2_capture. Then I made a new Yocto recipe in my layer recipies-kernel -> kernel-modules->my-kernel-module.bb
Yocto can build these two kernel modules (my-kernel-module.ko and mxc_v4l2_capture.ko).
Okay, now there is a problem because the kernel recipe already builds the mxc_v4l2_capture module. Therefore I want to manipulate the Makefile for the original kernel modules and exclude the make of mxc_v4l2_capture.
I have created the patch but I don't know how to use the patch with Yocto. Where to place it and how can I call it?
Normally I put a patch into a .bbappend file and finish but I don't know the name of the recipe that build the kernel modules.
It would be great if there is a way without manipulating this Makefile.
Is there a way to solve this with my kernel module recipe?
mxc_v4l2_capture.c is in-tree kernel driver. If you want to change the in-tree driver code and compile, it's highly recommended to patch the kernel and compile the kernel with usual recipe.
Having additional bitbake recipe for the in-tree kernel module is not necessary. To patch the kernel and compile, you can use .bbappend or .bb itself. For example,
if you have recipes-kernel/linux/linux-stable_4.19.75.bb in your Yocto BSP layer, you can add the patch to SRC_URI as below.
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
SRC_URI += "file://mxc_v4l2_capture.patch"
Now, you create recipes-kernel/linux/linux-stable-4.19.75/ and copy the mxc_v4l2_capture.patch file inside.
Or if you don't have permission or not possible to modify the Kernel recipe in BSP layer, you can create .bbappend in your custom layer. For the above example, you can create linux-stable_4.19.75.bbappend (specific version) or linux-stable_%.bbappend (any version). Then place the same content as mentioned above.
Yocto supports various patch formats, refer here for more details.
Look at this answer I wrote some days ago. The steps are basically the same. Using
devtool modify virtual/kernel
will create a working copy in build/workspace where you can do the work you want. Commiting those changes to the local branch and running
devtool finish linux-mainline <path-to-your-layer>
will create a .bbappend file with the patches already created and put to the correct location for you.
If you want to learn how to do it manually follow the advice #Parthiban gave.
Userspace package built for and along with root file system image of some embedded Linux-based system here (using Yocto project) apparently uses autotools - one can see Makefile.am's and configure.ac in package's sources. pkg-config or its successor seems to be used too (.pc.in is present), however out-of scope here.
Package in focus here does it this way (by involving autotools) as in the beginning of its development it was apparently the line of lowest resistance to copy and adopt build scripts from similar but already-existing package.
Actually autotools seem to be dispensable when building with Yocto, as Yocto build system meta data do specify target precisely enough for every target. For good reason standard build flow in Yocto is download, unpack, patch, configure, build,... with scan-and-detect-target-environment not included in this chain.
Now I wonder if it was good to streamline package's build process by removing autotools stage. I'm going to conduct it by proceeding in sequence of few steps starting with replacing .am file with real makefile. Question is if it will be sufficient enough to find env. variables defined and used in .am and .ac then transfer them to makefile? Remaining target-device specification should actually come from Yocto build system meta data. Possibly it will work this straightforward if to build package in scope of root file system image build. But how to ensure build environment provides complete target device specification when building only this package bitbake package-name?
Replacing autotools with a bare makefile isn't a trivial operation, as https://nibblestew.blogspot.co.uk/2017/12/a-simple-makefile-is-unicorn.html demonstrates nicely.
If you don't want to use autotools in your packages then alternatives such as Meson are generally faster.
I'm afraid my question is a bit complex. Appreciate anyone who can help.
Some background:
I have a 3rd party SW package that compile both kernel modules and user space applications.
Unfortunately, this 3rd party is very complex, and doesn't use Kbuild for building kernel modules (I tried without success)
When compiling the kernel modules, I add -I{path to kernel headers}, but I see the .config file is not being parsed in the compilation, which, of course, causes many errors.
I tried to manually add all flags from .config to gcc in command line (using a script to generate the command line) but that was a very very long line and gcc couldn't handle it.
So my question would be: Is there a way to force all these flags to gcc somehow?
Appreciate your ideas :)
Clarification:
The 3rd party SW can compile on older kernels (2.6, 2.4) I'm trying to compile it for 3.2
Maybe if someone can explain how the original kernel Makefile manages the .config file, I can mimic that behavior.
After digging in the kernel sources, I found the answer. Here it is in case someone needs it.
There's an automatically generated h file called autoconf.h which contains all the relevant definitions in C pre processor format. Just need to include it manually when compiling the module.
Also in theory, I could use my script to create such a file and include it from the sources.
Hope this helps someone. Now on to the next problem :)
I'm new in writing Linux device driver, and I'm wondering how the kernel Makefile magically knows what to compile. To illustrate what I don't understand, consider the following case:
I did a #include <linux/irq.h> in my driver code and I'm able to find the header file irq.h in the kernel directory KDIR/include/linux. However, this is only the header file, so I thought the irq.c source code must be out there somewhere. Hence, I looked into the KDIR/arch/arm searching for irq.c (since I'm using the ARM architecture). My confusion begins here when I found really many irq.c inside KDIR/arch/arm. To simply list a few, I got:
KDIR/arch/arm/mach-at91/irq.c
KDIR/arch/arm/mach-davinci/irq.c
KDIR/arch/arm/mach-omap1/irq.c
KDIR/arch/arm/mach-orion5x/irq.c
many more...
In my Makefile, I have a line like this:
$(MAKE) -C $(KDIR) M=$(PWD) CROSS_COMPILE=arm-none-linux-gnueabi- ARCH=arm modules
So I understand that the kernel Makefile knows that I'm using the ARM architecture, but under KDIR/arch/arm/, there are so many irq.c with the same name. I'm guessing that the mach-davinci/irq.c is compiled since davinci is the cpu name I'm using. But then, how can the kernel Makefile knows this is the one to compile? Or if I would like to have a look for the irq.c that I'm actually using, which one should I refer to?
I believe there must be a way to know this besides reading the long kernel Makefile. Thanks for any help!
Beyond the ARCH variable, you can also choose the system type (mach) from the configuration menu (there is actually a sub-menu called "System type" when you type make menuconfig for instance). This selection will include and compile all files under linux2.6/arch/$ARCH/mach-$MACH, and in your case this is how only one irq.c gets compiled.
That aside, it is interesting to understand how the kernel chooses which files to compile. The mechanism behind this is called Kconfig, and it is what allows you to precisely configure your kernel using make menuconfig and others, to compile a module from the outside like you are doing, and to select the right files to compile from simple Makefiles. While it is simple to use, its internals are rather complex - but this article, although rather old, explains it rather well:
http://www.linuxjournal.com/article/6568
To make a very long story short, there's a target make config, which you can trace. That one generates .config, that is your main guideline to making dependencies and controlling what will be compiled, what not, what as module and what will be compiled into the kernel.
This guide should give you a basic understanding of building a kernel module (and I assume that's where you want to start with your driver).