How to use an own device tree and modified kernel config in Yocto? - linux-kernel

I am working to build an own "embeeded linux" with yocto. It is based on the SAMA5D3x-MB + SAMA5D3x-CM(RONETIX) with the SAMA5D35. I have two questions:
1.) changing the device tree
I build an image based on: MACHINE ??= "sama5d3xek"
After the generating process I found two device tree files for the 5D35 in the deploy dir:
zImage--4.1+git0+19291d7be4-r0-sama5d35ek-.dtb
zImage--4.1+git0+19291d7be4-r0-sama5d35ek-revc-.dtb
Because the mainboard is revD I am using zImage--4.1+git0+19291d7be4-r0-sama5d35ek-.dtb.
In this file only can0 and i2c1 are defined.
I like to use can1 and i2c0 as well. For that I think I need to create a own dts file and include it into the kernel build process.
So far I put the dts file at my meta-test recipe. Ideas how to copy/patch it into the kernel?
2.) changing the kernel config
I checked the kernel with
bitbake virtual/kernel -c menuconfig
because I am not using the SAMA5D2 etc. and only the console I deactivated these kernel configs. I saved the new ".config" to "my.config" into the my-recipe dir. I have a similar question like in 1 - How to patch/copy it into the kernel?
I am new to yocto and to kernel hacking. Any idea how to do it?

If you're on a recent Yocto project release, you can make use of recipetool to do most of the legwork on this. You have two options, you can use the existing recipetool commands and a small amount of manual work, or you can use the recipetool plugin in meta-mentor that provides a few kernel-specific commands to do this for you.
Layer setup
First, you'll want to have a layer to store your changes. If you've already created a layer, you can use that, otherwise we can create one and add it to our configuration:
$ yocto-layer create local 1
$ bitbake-layers add-layer meta-local
Option one: Using the recipetool plugin from meta-mentor
Setup
First, clone meta-mentor:
$ git clone https://github.com/MentorEmbedded/meta-mentor
Next, either add meta-mel to your configuration:
$ bitbake-layers add-layer path/to/meta-mentor/meta-mel
Or copy meta-mentor/meta-mel/lib into your own layer:
$ cp -a path/to/meta-mentor/meta-mel/lib meta-local/
Device tree
$ recipetool kernel_add_dts meta-local /path/to/your.dts
Kernel configuration
$ recipetool kernel_add_fragments meta-local /path/to/your.cfg
Or:
$ recipetool kernel_set_defconfig meta-local /path/to/the/defconfig
Option two: Manual
In the below section, clearly in your case, your-machine-name should be sama5d3xek. The '-m your-machine-name' passed to the recipetool commands below makes the changes in the recipe specific to your machine, rather than affecting any machine which uses that recipe. If you know that recipe is only used for your machine, then you could drop that, but it's safest to keep it, as some BSP layers use the same kernel recipe for multiple machines. For example, linux-yocto is used for many.
Device tree
Then, assuming you have a .dts handy you want to use:
$ recipetool appendsrcfile -wm your-machine-name path/to/meta-local virtual/kernel /path/to/your.dts 'arch/${ARCH}/boot/dts/your.dts'
This will create a .bbappend in meta-local and add the .dts to SRC_URI, placing it in the appropriate path in the kernel source tree. The next step is to edit the append it created and add the .dtb for your .dts to the KERNEL_DEVICETREE variable, i.e.:
KERNEL_DEVICETREE += "your.dtb"
If the kernel recipe includes recipes-kernel/linux/linux-dtb.inc, any .dtb files in KERNEL_DEVICETREE will be created from their .dts files by using the kernel's buildsystem. Some kernels do not include linux-dtb.inc, in which case you can do so yourself in the append:
require recipes-kernel/linux/linux-dtb.inc
Kernel configuration
The kernel configuration is slightly more complex, just because how the configuration is done varies slightly between kernel recipes. Some kernel recipes support configuration fragments (which are just a text file with part of a defconfig/.config), whereas others you'd have to override the configuration entirely. The 'linux-yocto' recipe can handle and use fragments, as can a few others.
To see what kernel recipe you're using (the top filename will be the one used):
$ bitbake -e virtual/kernel | grep '^FILE='
If you want to use configuration fragments, you can either manually create a fragment, or generate one:
$ bitbake -c menuconfig virtual/kernel
$ bitbake -c diffconfig virtual/kernel
The 'diffconfig' task will create a fragment with your changes from the menuconfig and print the path to it.
Then you can add it to the kernel (though again, only certain recipes will use it):
$ recipetool appendsrcfile -wWm your-machine-name meta-local virtual/kernel /path/to/your.cfg
To override the entire config, most recipes will obey and use a 'defconfig' source file, so:
$ recipetool appendsrcfile -Wm your-machine-name meta-local virtual/kernel /path/to/the/defconfig
Note: The defconfig is not generated automatic. Replace defconfig with the result of menuconfig('.config').

The devtool can be very handy if you want to generate patches for the linux-yocto kernel. Other kernel might not support devtool.
## create kernel source patch
devtool modify virtual/kernel
# make some changes
cd ~/poky_sdk/workspace/sources/linux-yocto
vi init/calibrate.c
# test before patch
bitbake -C compile virtual/kernel
# create patch
git add .
git commit -m 'some fix'
devtool update-recipe -a ~/meta-mylayer/ linux-yocto
# clean the source
rm -rf workspace/sources/linux-yocto/
see devtool for details

Related to this question, for educational purposes I tried to add a device tree to an x86 architecture (kernel 5.2.20). To enable the device tree compiler, the following additions to the configuration were needed :
CONFIG_COMPILE_TEST=y
CONFIG_OF=y
CONFIG_OF_ALL_DTBS=y
Furthermore, to enable device tree support at runtime, this was additionally needed :
CONFIG_OF_UNITTEST=y
A convenient place to check if your kernel configs are merged without problems is file
kernel-source/.kernel-meta/cfg/merge_config_build.log

Related

Install systemd service using autotools

I have an autotools project which successfully builds and tests an app (https://github.com/goglecm/AutoBrightnessCam). The app is installed in the bin directory (preceded by any prefix the user specifies). That's pretty straightforward. I now need to make a systemd service to start it at boot time. I've created the service file and ran it manually and it works fine.
The last bit is to tell configure.ac and Makefile.am to patch a *.service.in file with the correct path for the app (just like config.h is created from config.h.in).
Will using AC_CONFIG_HEADERS be appropriate to patch *.service.in into *.service? Is there another macro used for "non-headers" perhaps?
Also, how do I specify that the service file should land (i.e. installed) in /etc/systemd/system?
Is there perhaps a better way of starting this app at boot time without systemd?
How do I specify that the service file should land (i.e. installed) in /etc/systemd/system?
According to Systemd's daemon man page:
<BEGINQUOTE>
Installing systemd Service Files
At the build installation time (e.g. make install during package build), packages are recommended to install their systemd unit files in the directory returned by pkg-config systemd --variable=systemdsystemunitdir (for system services) or pkg-config systemd --variable=systemduserunitdir (for user services). This will make the services available in the system on explicit request but not activate them automatically during boot. Optionally, during package installation (e.g. rpm -i by the administrator), symlinks should be created in the systemd configuration directories via the enable command of the systemctl(1) tool to activate them automatically on boot.
Packages using autoconf(1) are recommended to use a configure script excerpt like the following to determine the unit installation path during source configuration:
PKG_PROG_PKG_CONFIG
AC_ARG_WITH([systemdsystemunitdir],
[AS_HELP_STRING([--with-systemdsystemunitdir=DIR], [Directory for systemd service files])],,
[with_systemdsystemunitdir=auto])
AS_IF([test "x$with_systemdsystemunitdir" = "xyes" -o "x$with_systemdsystemunitdir" = "xauto"], [
def_systemdsystemunitdir=$($PKG_CONFIG --variable=systemdsystemunitdir systemd)
AS_IF([test "x$def_systemdsystemunitdir" = "x"],
[AS_IF([test "x$with_systemdsystemunitdir" = "xyes"],
[AC_MSG_ERROR([systemd support requested but pkg-config unable to query systemd package])])
with_systemdsystemunitdir=no],
[with_systemdsystemunitdir="$def_systemdsystemunitdir"])])
AS_IF([test "x$with_systemdsystemunitdir" != "xno"],
[AC_SUBST([systemdsystemunitdir], [$with_systemdsystemunitdir])])
AM_CONDITIONAL([HAVE_SYSTEMD], [test "x$with_systemdsystemunitdir" != "xno"])
This snippet allows automatic installation of the unit files on systemd machines, and optionally allows their installation even on machines lacking systemd. (Modification of this snippet for the user unit directory is left as an exercise for the reader.)
Additionally, to ensure that make distcheck continues to work, it is recommended to add the following to the top-level Makefile.am file in automake(1)-based projects:
AM_DISTCHECK_CONFIGURE_FLAGS = \
--with-systemdsystemunitdir=$$dc_install_base/$(systemdsystemunitdir)
Finally, unit files should be installed in the system with an automake excerpt like the following:
if HAVE_SYSTEMD
systemdsystemunit_DATA = \
foobar.socket \
foobar.service
endif
...
</ENDQUOTE>
So it appears you should use systemdsystemunitdir and systemduserunitdir. How well Autotools supports it, well...
A quick grep on Fedora 31 using grep systemdsystemunitdir /bin/autoconf and grep -IR systemdsystemunitdir /usr/share shows no Autotools support yet. 7 years and counting...
Is there perhaps a better way of starting this app at boot time without systemd?
Systemd should be OK to start your app. Simply use systemctl(1) to enable and start them as you normally would.
Based on your GitHub and autobrightnesscam.service.in, I would not dick around with Autotools for this. You can waste copious amounts of time working around Autotols short comings (speaking from experience).
My configure.ac script (which is just a shell script) would copy autobrightnesscam.service.in to autobrightnesscam.service, and then use sed to copy-in the correct directories and files. Then, I would copy the updated autobrightnesscam.service to its proper location in AC_CONFIG_COMMANDS_POST. Maybe something like:
SERVICE_FILE=autobrightnesscam.service
SYSTEMD_DIR=`pkg-config systemd --variable=systemdsystemunitdir`
# Use default if SYSTEMD_DIR is empty
if test x"$SYSTEMD_DIR" = "x"; then
SYSTEMD_DIR=/etc/systemd/system
fi
AC_CONFIG_COMMANDS_POST([cp "$SERVICE_FILE" "$SYSTEMD_DIR"])
AC_CONFIG_COMMANDS_POST([systemctl enable "$SYSTEMD_DIR/$SERVICE_FILE"])
AC_CONFIG_COMMANDS_POST([systemctl start "$SERVICE_FILE"])
Will using AC_CONFIG_HEADERS be appropriate to patch *.service.in into *.service? Is there another macro used for "non-headers" perhaps?
No. AC_CONFIG_HEADERS is for setting up configuration headers to support your build. It is rarely used for anything other than building a config.h recording the results of certain tests that Autoconf performs, and it is not as flexible as other options in this area.
If you have additional files that you want Autoconf to build from templates then you should tell Autoconf about them via AC_CONFIG_FILES. Example:
AC_CONFIG_FILES([Makefile AutoBrightnessCam.service])
But if some of the data with which you are filling that template are installation directories then Autoconf is probably not the right place to do this at all, because it makes provision for the installation prefix to be changed by arguments to make. You would at least need to work around that, but the best thing to do is to roll with it instead, and build the .service file under make's control. It's not that hard, and there are several technical advantages, some applying even if there aren't any installation directory substitutions to worry about.
You can do it the same way that configure does, by running the very same template you're already using through sed, with an appropriate script. Something like this would appear in your Makefile.am:
SERVICE_SUBS = \
s,[#]VARIABLE_NAME[#],$(VARIABLE_NAME),g; \
s,[#]OTHER_VARIABLE[#],$(OTHER_VARIABLE),g
AutoBrightnessCam.service: AutoBrightnessCam.service.in
$(SED) -e '$(SERVICE_SUBS)' < $< > $#
Also, how do I specify that the service file should land (i.e.
installed) in /etc/systemd/system?
You use Automake's standard mechanism for specifying custom installation locations. Maybe something like this:
sytemdsysdir = $(sysconfdir)/systemd/system
systemdsys_DATA = AutoBrightnessCam.service
Is there perhaps a better way of
starting this app at boot time without systemd?
On a systemd-based machine, systemd is in control of what starts at boot. If you want the machine to start your application automatically at boot, then I think your options are limited to
Configuring systemd to start it
Configuring something in a chain of programs ultimately started by systemd to start it
Hacking the bootloader or kernel to start it
There is room for diverging opinions here, but I think the first of those is cleanest and most future-proof, and I cannot recommend the last.

How to write a BitBake driver recipe which requires kernel source header files?

Introduction
I have a do_install task in a BitBake recipe which I've written for a driver where I execute a custom install script. The task fails because the installation script cannot find kernel source header files within <the image rootfs>/usr/src/kernel. This script runs fine on the generated OS.
What's Happening
Here's the relevant part of my recipe:
SRC_URI += "file://${TOPDIR}/example"
DEPENDS += " virtual/kernel linux-libc-headers "
do_install () {
( cd ${TOPDIR}/example/Install ; ./install )
}
Here's a relevant portion of the install script:
if [ ! -d "/usr/src/kernel/include" ]; then
echo ERROR: Linux kernel source include directory not found.
exit 1
fi
cd /usr/src/kernel
make scripts
...
./install_drv pci ${DRV_ARGS}
I checked changing to if [ ! -d "/usr/src/kernel" ], which also failed. install passes different options to install_drv, which I have a relevant portion of below:
cd ${DRV_PATH}/pci
make NO_SYSFS=${ARG_NO_SYSFS} NO_INSTALL=${ARG_NO_INSTALL} ${ARGS_HWINT}
if [ ${ARG_NO_INSTALL} == 0 ]; then
if [ `/sbin/lsmod | grep -ci "uceipci"` -eq 1 ]; then
./unload_pci
fi
./load_pci DEBUG=${ARG_DEBUG}
fi
The make target build: within ${DRV_PATH}/pci is essentially this:
make -C /usr/src/kernel SUBDIRS=${PWD} modules
My Research
I found these comments within linux-libc-headers.inc relevant:
# You're probably looking here thinking you need to create some new copy
# of linux-libc-headers since you have your own custom kernel. To put
# this simply, you DO NOT.
#
# Why? These headers are used to build the libc. If you customise the
# headers you are customising the libc and the libc becomes machine
# specific. Most people do not add custom libc extensions to the kernel
# and have a machine specific libc.
#
# But you have some kernel headers you need for some driver? That is fine
# but get them from STAGING_KERNEL_DIR where the kernel installs itself.
# This will make the package using them machine specific but this is much
# better than having a machine specific C library. This does mean your
# recipe needs a DEPENDS += "virtual/kernel" but again, that is fine and
# makes total sense.
#
# There can also be a case where your kernel extremely old and you want
# an older libc ABI for that old kernel. The headers installed by this
# recipe should still be a standard mainline kernel, not your own custom
# one.
I'm a bit unclear if I can 'get' the headers from the STAGING_KERNEL_DIR properly since I'm not using make.
Within kernel.bbclass provided in the meta/classes directory, there is this variable assigment:
# Define where the kernel headers are installed on the target as well as where
# they are staged.
KERNEL_SRC_PATH = "/usr/src/kernel"
This path is then packaged later within that .bbclass file here:
PACKAGES = "kernel kernel-base kernel-vmlinux kernel-image kernel-dev kernel-modules"
...
FILES_kernel-dev = "/boot/System.map* /boot/Module.symvers* /boot/config* ${KERNEL_SRC_PATH} /lib/modules/${KERNEL_VERSION}/build"
Update (1/21):
A suggestion on the yocto IRC channel was to use the following line:
do_configure[depends] += "virtual/kernel:do_shared_workdir"
which is corroborated by the Yocto Project Reference Manual, which states that in version 1.8, there was the following change:
The kernel build process was changed to place the source in a common shared work area and to place build artifacts separately in the source code tree. In theory, migration paths have been provided for most common usages in kernel recipes but this might not work in all cases. In particular, users need to ensure that ${S} (source files) and ${B} (build artifacts) are used correctly in functions such as do_configure and do_install. For kernel recipes that do not inherit from kernel-yocto or include linux-yocto.inc, you might wish to refer to the linux.inc file in the meta-oe layer for the kinds of changes you need to make. For reference, here is the commit where the linux.inc file in meta-oewas updated.
Recipes that rely on the kernel source code and do not inherit the module classes might need to add explicit dependencies on the do_shared_workdir kernel task, for example:
do_configure[depends] += "virtual/kernel:do_shared_workdir"
But I'm having difficulties applying this to my recipe. From what I understand, I should be able to change the above line to:
do_install[depends] += "virtual/kernel:do_shared_workdir"
Which would mean that the do_install task now must be run after do_shared_workdir task of the virtual/kernel recipe, which means that I should be able to work with the shared workdir (see Question 3 below), but I still have the same missing kernel header issue.
My Questions
I'm using a custom linux kernel (v3.14) from git.kernel.org. which inherits the kernel class. Here are some of my questions:
Shouldn't the package kernel-dev be a part of any recipe which inherits the kernel class? (this section of the variables glossary)
If I add the virtual/kernel to the DEPENDS variable, wouldn't that mean that the kernel-dev would be brought in?
If kernel-dev is part of the dependencies of my recipe, wouldn't I be able to point to the /usr/src/kernel directory from my recipe? According to this reply on the Yocto mailing list, I think I should.
How can I properly reference the kernel source header files, preferably without changing the installation script?
Consider your Environment
Remember that there are different environments within the the build time environment, consisting of:
sysroots
in the case of kernels, a shared work directory
target packages
kernel-dev is a target package, which you'd install into the rootfs of the target system for certain things like kernel symbol maps which are needed by profiling tools like perf/oprofile. It is not present at build time although some of its contents are available in the sysroots or shared workdir.
Point to the Correct Directories
Your do_install runs at build time so this is within the build directory structures of the build system, not the target one. In particular, /usr/src/ won't be correct, it would need to be some path within your build directory. The virtual/kernel do_shared_workdir task populates ${STAGING_DIR_KERNEL} so you would want to change to that directory in your script.
Adding a Task Dependency
The:
do_install[depends] += "virtual/kernel:do_shared_workdir
dependency like looks correct for your use case, assuming nothing in do_configure or do_compile accesses the data there.
Reconsider the module BitBake class
The other answers are correct in the recommendation to look at module.bbclass, since this illustrates how common kernel modules can be built. If you want to use custom functions or make commands, this is fine, you can just override them. If you really don't want to use that class, I would suggest taking inspiration from it though.
Task Dependencies
Adding virtual/kernel to DEPENDS means virtual/kernel:do_populate_sysroot must run before our do_configure task. Since you need a dependency for do_shared_workdir here, a DEPENDS on virtual/kernel is not enough.
Answer to Question 3
The kernel-dev package would be built, however it would then need to be installed into your target image and used at runtime on a real target. You need this at build time so kernel-dev is not appropriate.
Other Suggestions
You'd likely want the kernel-devsrc package for what you're doing, not the kernel-dev package.
I don't think anyone can properly answer that last question here. You are using a non-standard install method: we can't know how to interact with it...
That said, take a look at what meta/classes/module.bbclass does. It sets several related variables for make: KERNEL_SRC=${STAGING_KERNEL_DIR}, KERNEL_PATH=${STAGING_KERNEL_DIR}, O=${STAGING_KERNEL_BUILDDIR}. Maybe your installer supports some of these environment variables and you could set them in your recipe?

How do I generate loadable modules during Linux kernel build?

I seem to successfully build a kernel image, but I can not generate all the modules I expect. I expect more modules since I see them enabled in the gconfig window. Here is a copy of my make session. Seems like make goes into the devices directories. I can not figure out why it is not create the .ko files. I expect to see .ko files. I have checked the Makefile in /drivers directory, and I can see that it is configured with a number of lines like
obj-$(CONFIG_PCI) += pci/
Which directs make to build the pci module for instance. I think this implies that I should see a number .ko files. But I do not. I have seen just one .ko file for scsi module. I like to be able to build all of modules selected.
I also verified that a number of mudules are enabled when I issued:
make VARIANT_DEFCONFIG=msm8974_sec_hlte_spr_defconfig msm8974_sec_defconfig SELINUX_DEFCONFIG=selinux_defconfig gconfig
But as I said, I do not see any of them. What am I missing please?
#Subin - Thanks. I just tried make modules_install. I have to mention that I am cross compiling this for an arm target. I believe modules_install is for the purpose of installing the driver for the machine you are on? I got a message about needing to be in root, and I did not proceed. I have been wondering when I need to run it. What does it do exactly please?
Re: the make modules; I have run it before. I'll run it again and post the result. Since I got one .ko file I figured the issue is something different between that one module, and every other one enabled in my config. Here is what I got when I ran make modules:
sansari#ubuntu:~/WORKING_DIRECTORY$ make modules
CHK include/linux/version.h
CHK include/generated/utsrelease.h
make[1]: `include/generated/mach-types.h' is up to date.
CALL scripts/checksyscalls.sh
Building modules, stage 2.
MODPOST 1 modules
Re: your comment on the location of .ko files, I am doing a find to see if perhaps I am not looking at the right place, it only finds the one which was built. Not the other ones. Here is the output:
sansari#ubuntu:~/WORKING_DIRECTORY$ find . -type f -name "*.ko"
./drivers/scsi/scsi_wait_scan.ko
sansari#ubuntu:~/WORKING_DIRECTORY$
Should I perhaps run make v=1, in verbose mode that is? Would that provide more information on why the other modules are not built?
#Gil Hamilton - Thanks. You are right. Here is an excerpt of the .config file:
#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
# CONFIG_BLK_DEV_SR is not set
CONFIG_CHR_DEV_SG=y
CONFIG_CHR_DEV_SCH=y
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_LOGGING=y
CONFIG_SCSI_SCAN_ASYNC=y
CONFIG_SCSI_WAIT_SCAN=m
This entry is the only one set to 'm'.
Most device driver modules in the linux kernel build system use a tristate (3-valued) configuration setting. The options are
'n' (don't build at all),
'y' (build and link statically into the main kernel object), and
'm' (build as module for dynamic loading).
The values are determined by the content of .config. The values in .config are usually generated from an existing config file (look in arch/<ARCH>/configs for your <ARCH>). Also check the output of 'make help' for interesting configuration targets.
If you're not seeing the .ko files being created, that indicates the corresponding configuration variable is either set to 'y' or 'n'.

How to "make" existing Linux kernel module driver after modifying the driver source code

I have made some trivial modifications to a Linux USB Wi-Fi card driver to insert some logging (printk statements). I am loosely following a guide on how to recompile/load the module, which states that I need to execute make in order to build the .ko file. There is an existing Makefile in the working directory (/usr/src/linux/drivers/net/wireless/rtl818x/rtl8187/), which reads:
rtl8187-objs := dev.o rtl8225.o leds.o rfkill.o
obj-$(CONFIG_RTL8187) += rtl8187.o
ccflags-y += -Idrivers/net/wireless/rtl818x
When I execute make inside this directory, I get:
make: *** No targets. Stop.
According to this, this means "that some makefile was found, but it didn't contain any default goal and none was given on the command line. GNU make has nothing to do in these situations."
So my question is, what does this mean in the context of what I am trying to do, and how do I go about generating the .ko file which I am purported to need for the next step?
You must run make from the top directory of the Linux source (/usr/src/linux/). Be sure that your driver is included in your /usr/src/linux/.config file. So, build the kernel with your driver.
If you don't want to rebuild the entire kernel, read more :)
If you want to re-build all modules inside the directory:
make M=drivers/net/wireless/rtl818x/rtl8187/
If you want to re-build a single module inside the directory:
make M=drivers/net/wireless/rtl818x/ CONFIG_RTL8187=m
The *CONFIG_RTL8187* name can be found in drivers/net/wireless/rtl818x/Kconfig (CONFIG_ + RTL8187)
It should works also this:
make drivers/net/wireless/rtl818x/rtl8187/rtl8187.ko

Adding new driver code to linux source code

I have developed a Linux device driver. As of now I am compiling it on Ubuntu 12.04 with cross-compiler for arm and then insmoding it in my arm Linux image. But I want to learn how I can add it in Linux source code and give and option to add/remove through configuration of arm Linux, so that I can compile it with Linux source code compilation?
Any ideas?
To cross compile your own driver in the arm architecture you have to follow some steps as mentioned below.
Create a directory like my_drvr inside drivers(which is in the Linux source code) for your driver and put your driver (my_driver.c) file inside this directory. It will looks like
/linux_source_code/drivers/my_drvr/my_driver.c
Create one Makefile inside your driver directory (using vi any editor) and inside this put obj-$(CONFIG_MY_DRIVER) += my_driver.o
and save this file. This will appears like /linux_source_code/drivers/my_drvr/Makefile
Create one Kconfig file inside your driver directory (using vi any editor) and inside this put
config MY_DRIVER
tristate "my driver" //gives your driver description like vendor name etc.
depends on ARM
default y if ARM
help
my driver module.
Save this file, this will appears like /linux_source_code/drivers/my_drvr/Kconfig
Add both Makefile and Kconfig file in the Linux source drivers Makefile and Kconfig file which are at /linux_source_code/drivers/Makefile
and /linux_source_code/drivers/Kconfig
In the Makefile add below in last line
obj-y += my_drvr/
or
obj-$(CONFIG_MY_DRIVER) += my_drvr/
In Kconfig file add below in last line
source "drivers/my_drvr/Kconfig"
Finally have to add Kconfig file into architecture specific config file which will be at kernel_source/arch/arm/configs/--defconfig in this add below line in the last
CONFIG_MY_DRIVER=y
Note:- Last step will differ according to your architecture, so that you have take care.
Now you can compile your driver by using make command.
(eg: sun7i_defconfig)
You need to add a config option in the Kconfig file of the kernel source subdirectory in which your device driver will be put. You also need to add lines to the Makefile of that directory. Obviously you need to copy the source files to that directory too.
Since your driver depends on the ARM architecture, in the Kconfig, you need to put an option of 'depends on' like:
config SND_ARMAACI
tristate "ARM PrimeCell PL041 AC Link support"
depends on ARM_AMBA
and your Makefile will look like
obj-$(CONFIG_SND_ARMAACI) += snd-aaci.o
snd-aaci-objs := aaci.o
So now when you do a make menuconfig in your kernel source tree, you will find the config option you put in the Kconfig and you will be able to select it to be compiled into the kernel or built as a module or not compiled at all.
Look for examples in the subsystem directory your driver is meant for.
Create patch and add applying of this patch as a step after decompressing kernel tarball and before configuring/compilation.

Resources