I need to access the target path to kernel modules in a recipe, is there a variable with such information?
I mean, where can i get "/lib/modules/4.1.23-fslc+g3617c73" since this path may change because of configuration?
The destination directory is as follows.
Look into bbclass file kernel.bbclass in poky/meta/classes/ function kernel_do_install
It is passed as a make option
oe_runmake DEPMOD=echo MODLIB=${D}${nonarch_base_libdir}/module/${KERNEL_VERSION} INSTALL_FW_PATH=${D}${nonarch_base_libdir}/firmware modules_install
I hope below info will help you,
the kernel modules path is `
tmp-glibc/work/beaglebone-linux-gnueabi/linux-ti/3.12.30-phy10-r0.0/image/lib/modules/3.12.30-AM335x-PD15.3.0`
if you add your code in your linux kernel and compile as modules(.ko) by default it will add in above mentioned path.
If you want to copy your module(.ko) manually to the lib/modules path copy your.ko file to sources/meta-youlayer/recipes-kernel/linux and create linux-ti_%.bbappend file ad below line
FILESEXTRAPATHS_prepend := "${THISDIR}:"
SRC_URI +="file://your.ko"
do_install_append(){
install -m 0777 ${S}/your.ko ${D}/lib/modules/version
}
I did not try this yet. hope it will work.
Related
I am using yocto build a linux image that integrates some layers of wlan and a specific wifi chip, but seems like patching of one of the files is failing (details below)
Steps that I did:
Created a working directory
initialized a repo for kernel 4.14.98 via:
repo init -u https://source.codeaurora.org/external/imx/imx-manifest -b imx-linux-sumo -m imx-4.14.98-2.3.3.xml
sync the repo via repo sync
created a tmp folder outside of the current working dir, and download the specific code for wifi via
repo init -u git://codeaurora.org/quic/le/le/manifest.git -b release -m CHSS.LNX_FSLS.1.0-01200-QCAAUTOHOSTHZ.xml –repo-url=git://codeaurora.org/tools/repo.git –repo-branch=caf-stable
repo the sync
copy the meta-qti-connectivity and wlan-opensource folders into the source folder of the working directory
Download the files for a specific wifi chip and copy over meta-qticonnectivity-prop and wlanproprietary into the source folder of the working directory
So now we have added additional 4 directories into the source folder of the working directory
Set up the build environment
Run bitbake core-image-minimal
and I see the following error:
ERROR: wpa-supplicant-git-r0 do_patch: Command Error: 'quilt --quiltrc <working_directory>/linux_image/build/tmp/work/imx8qxpmek-poky-linux/wpa-supplicant/git-r0/recipe-sysroot-native/etc/quiltrc push' exited with 0 Output:
Applying patch 0009-Sync-with-mac80211-next.git-include-uapi-linux-nl802.patch
patching file src/drivers/nl80211_copy.h
...
15 out of 20 hunks FAILED -- rejects in file src/drivers/nl80211_copy.h
Patch 0009-Sync-with-mac80211-next.git-include-uapi-linux-nl802.patch does not apply (enforce with -f)
ERROR: wpa-supplicant-git-r0 do_patch: Function failed: patch_do_patch
I'm new to yocto, and from the looks of it, it seems the patch 0009-Sync-with-mac80211-next.git-include-uapi-linux-nl802.patch didn't apply, but does that mean the issue is with the patch file or the way it's referenced.
This patch file resides in the meta-fsl-bsp-release layer under wpa-supplicant sub directory, which I DID NOT add manually. This sub-directory has a .bbappend file that refers to these patch files via SRC_URI variable, but it doesn't contain any .bb file.
One of the meta layers that I added has wpa-supplicant sub-directory as well but it only has .bb file and no .bbappend.
I'm confused as to how are these two subdirectories different or could they conflict in anyway? Also, shouldn't the subdirectory have both the .bbappend & a corresponding .bb file?
The SRC_URI variable is used to locate the applicable patch files and do_patch isn't needed in the respective .bb file of wpa-supplicant, right?
the respective bb file wpa-supplicant has the following:
SRC_URI = "file://wlan-opensource/wpa_supplicant_8/"
SRC_URI += "file://hostapdconf \
file://supplicantconf \
shouldn't patch files be defined with .patch at the end?
Also, I see in the yocto documentation that the path defined in file:// is relative to the FILESPATH variable, which in the bb file is defined to be "${BSPDIR}/sources:" - not certain of BSPDIR itself but I think it's referring to <top_dir>/sources, but does that mean hostapdconf is supposed to be at <top_dir>/sources? I don't see it there but in other sub directory
To me it looks like you have added a .bbappend for the wpa-supplicant recipe in a version that does not match the recipe. Likely the .bbappend is from one of the meta layers you copied into your source tree manually (meta-qti-connectivity or wlan-opensource).
I'm new to yocto, and from the looks of it, it seems the patch
0009-Sync-with-mac80211-next.git-include-uapi-linux-nl802.patch didn't
apply, but does that mean the issue is with the patch file or the way
it's referenced?
Likely the patch is targetet at a different version of the source file.
The SRC_URI variable is used to locate the applicable patch files and
do_patch isn't needed in the respective .bb file of wpa-supplicant,
right?
Right, if you don't see it explicitly ly in the .bb. The default do_patch task will be used.
the respective bb file wpa-supplicant has the following:
SRC_URI = "file://wlan-opensource/wpa_supplicant_8/" SRC_URI +=
"file://hostapdconf
file://supplicantconf \ shouldn't patch files be defined
with .patch at the end?
The .patch file is probably referenced by name in a .bbappend if you dont see it in the .bb file.
Using menuconfig for nuttx development.
Was trying to do below for custom board setup:
if ARCH_BOARD_FOO
source "configs/FOO/Kconfig"
endif
Problem here, I would like to have some permission control for FOO directory. So not all users can see it.
However, kconfig language seems will always parse the file no matter the if condition is true or not. Therefore this causing make menuconfig could not open for users do not have permission of FOO directory.
Anyone know solution for that?
Try using a custom board configuration. Then your board directory can lie inside or outside of the NuttX source tree. In either case, it will not be visible to the configuration system. you would configure this like:
CONFIG_ARCH_BOARD_CUSTOM=y
CONFIG_ARCH_BOARD_CUSTOM_NAME="myboard"
CONFIG_ARCH_BOARD_CUSTOM_DIR="/home/users/me/myboard"
... and other options ...
In the above example, the board directory lies outside of the NuttX source tree and is an absolute path. The board configuration could also lie inside of the NuttX and the path may be specified as relative to the top-level directory with:
CONFIG_ARCH_BOARD_CUSTOM_DIR_RELPATH=y
For example:
CONFIG_ARCH_BOARD_CUSTOM_DIR="configs/FOO"
CONFIG_ARCH_BOARD_CUSTOM_DIR_RELPATH=y
Now if CONFIG_ARCH_BOARD_CUSTOM=y is not defined, there is no way to access /home/users/me/myboard or configs/FOO from the configuration system.
This works because the custom board Kconfig file will be linked to configs/dummy/Kconfig in the custom configuration with CONFIG_ARCH_BOARD_CUSTOM=y. Otherwise configs/dummy/Kconfig will be linked to an empty configuration to satisfy the configuration system.
In order to ignore the error, you could use:
if ARCH_BOARD_FOO
-source "configs/FOO/Kconfig"
endif
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?
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
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.