Kernel patches with Bitbake - linux-kernel

I'm using a embedded linux on a SOM module, based on IMX6.
I would like to patch my kernel,it works fine, it has been patched, but i would like to add some features.
I apply the old patches on the sources, and add my code, and create a new patch.
In yocto I add my patch to the recipe and bitbake it, I start the board with the new loaded kernel, and it seems it does not have my modification!
For bitbake my new kernel, I type :
bitbake -c clean linux-toradex-fsl
bitbake linux-toradex-fsl
It compiles without any errors, I copy my uImage in my tftp folder, but my features do not seems to be executed.
So I try to create a simple patch, with
printk(KERN_WARNING"This is a test\n");
I place it after another warning, called and displayed.
And it does not work either.
I check with -c devshell and my modification are applied in yocto, the patch works here.
I also check the uImage file, it has the same size, with or without my patches.
Do you have some ideas for this issue?
Regards,
Pierre-Olivier
Solution
I found the solution after some tries, I just need to run
bitbake -c cleansstate linux-toradex-fsl
bitbake my-image
And the image is bitbaked with the patched kernel.

Bitbake is funny about -clean. It tries to keep a state directory, so -clean just runs the normal "clean" in the makefile, but the makefile can be short-circuited by the shared state, which can include zipped up prebuilt binaries from a previous build. Try this:
bitbake -c cleansstate linux-toradex-fsl
bitbake linux-toradex-fsl
note the extra 's' in cleansstate (clean shared state).

Related

How to do a clean rebuild of Linux kernel modules in Yocto?

I can rm -rf tmp/ sstate-cache/ cache/ and run a whole Yocto build from scratch just fine, but I'd rather not rebuild everything (especially as packages like Qt can take some time).
I've tried:
bitbake -c cleansstate linux-iwg15 kernel-module-imx-gpu-viv cryptodev-module
Note: I've also tried cleanall, but it has the same result:
Either one of the kernel modules end up throwing this error once they get to do_compile:
ERROR: Kernel configuration is invalid.
include/generated/autoconf.h or include/config/auto.conf are missing.
Run 'make oldconfig && make prepare' on kernel src to fix it.
The {build_dir}/tmp/work-shared/{MACHINE}/kernel-build-artifacts folder actually contains include/generated/autoconf.h
I tried copying the contents of kernel-build-artifacts to {build_dir}/tmp/work-shared/{MACHINE}/kernel-source but still get the errors.
The linux-iwg15 BitBake recipe is here.
Is there anything else that I should be cleaning before rebuilding the Linux kernel modules?
After a clean build, I did notice that kernel-build-artifacts contains kernel and scripts folders (as well as a symlink of source to ..\kernel-source) that I don't remember being there when attempting to rebuild after running bitbake -c cleansstate.
Is there anything else that I should be cleaning before rebuilding the Linux kernel modules?
Yes. bitbake -c cleansstate make-mod-scripts
Any kernel module recipe will contain inherit module. This references meta/classes/module.bbclass which contains inherit module-base. This references meta/classes/module-base.bbclass which contains:
# We do the dependency this way because the output is not preserved
# in sstate, so we must force do_compile to run (once).
do_configure[depends] += "make-mod-scripts:do_compile"
The make-mod-scripts recipe (at meta/recipes-kernel/make-mod-scripts/make-mod-scripts.bb) adds files to the {build_dir}/tmp/work-shared/{MACHINE}/kernel-build-artifacts directory. (This is referenced as STAGING_KERNEL_BUILDDIR which is set in conf/bitbake.conf.)
Unfortunately, the kernel recipe will remove everything in the STAGING_KERNEL_BUILDDIR directory, since that directory is added to the do_shared_workdir[cleandirs] variable in meta/classes/kernel.bbclass. This ends up removing files that make-mod-scripts put there as well.

Using populate_sdk to include kernel headers

How do I include the linux kernel headers as part of the SDK package in Yocto?
I'm using Yocto 1.8 (fido) in an embedded project and want to do out-of-tree kernel module development. Currently, I can build my kernel modules (apart from bitbake) by pointing my $KERNEL_PATH to the poky/build/tmp/work-shared/<machine>/kernel-source/ directory when I run make. I don't want to do this in the long term, however, since others need to easily build the modules without installing and building a full image from bitbake.
I can generate an SDK using bitbake myimage -c populate_sdk. However, this doesn't include the kernel headers (all I ever see is sysroots/<mach>/usr/include/linux). How do I cause the kernel headers to be included in the SDK package? Also, I don't want the kernel headers to show up as part of my target image.
[Edit]
My image recipe is as follows:
EXTRA_IMAGE_FEATURES_append = " eclipse-debug debug-tweaks"
TOOLCHAIN_HOST_TASK_append = " nativesdk-cmake"
IMAGE_INSTALL = "packagegroup-core-boot ${CORE_IMAGE_EXTRA_INSTALL} util-linux kernel-modules netbase busybox base-passwd base-files sysvinit initscripts bash gdbserver strace sysfsutils dtc gawk ethtool grep sed wget iptables oprofile net-tools dropbear rsync stress-ng rt-tests i2c-tools"
inherit core-image
The kernel I'm using is linux-altera-ltsi-rt in the meta-altera layer.
From the fido release, the handling of kernel builds has been changed. In previous releases, you could usually just skip down to the usage example below.
In fido or any 1.8+, if you want the kernel src and build system available in the SDK, you should add
TOOLCHAIN_TARGET_TASK_append = " kernel-devsrc"
to your image recipe. That will ensure that the new, kernel-devsrc package is installed into your toolchain.
The procedure below is just to ensure that the rest of the workflow is fully understood (even though it's not strictly part of the original question).
Usage Example
Lets assume a module Makefile as follows:
obj-m += hello-1.o
all:
make -C $(KERNEL_SRC) M=$(PWD) modules
clean:
make -C $(KERNEL_SRC) M=$(PWD) clean
Example taken from The Linux Kernel Module Programming Guide (Note that the actual commands needs to have a tab character for indentation).
Then you'll have to define KERNEL_SRC to be sysroots/<mach>/usr/src/kernel/, either in the Makefile, or from your make call. (Using a variable like KERNEL_SRC will ensure that your module recipe automatically picks the right location when building using bitbake).
To manually build your kernel module:
Source the environment-* file for your SDK.
Go to you modules directory.
KERNEL_SRC=<sdk-install-path>/sysroots/<mach>/usr/src/kernel LDFLAGS="" make However, this will fail, as fixdep can't be found. We'll fix this manually.
cd <sdk-install-path>/sysroots/<mach>/usr/src/kernel
make modules_prepare
If this needs to be run with sudo, be sure to source the environment file in the sudo environment: sudo bash -c "source <sdk-install-path>/environment-setup-<mach> && make modules_prepare"
Go back to your modules directory.
KERNEL_SRC=<sdk-install-path>/sysroots/<mach>/usr/src/kernel LDFLAGS="" make
This should now allow you to build your modules.
If you don't have the kernel source under sysroots/<mach>/usr/src/kernel/, we'll have to look into that.
anders answer is very good, but in recent versions of yocto the way to add kernel-devsrc seems to be
IMAGE_INSTALL += "kernel-devsrc"
which I found here: https://www.mail-archive.com/yocto#yoctoproject.org/msg36448.html
With Yocto Zeus (3.0.x) add this to your image recipe:
TOOLCHAIN_TARGET_TASK += "kernel-devsrc"
EDIT: Same for Gatesgarth (3.2.x) but the make scripts command has a new host dependency to libyaml-dev

How can I extract the environment variables used when building a recipe in Yocto?

I am working on a kernel module for a project using Yocto Linux (version 1.3). I want to use the kernel headers and the compiler and libraries from my Yocto project, but develop the kernel module without needing to run bitbake every time. My initial solution to this was to execute the devshell task and extract the environment variables using something like this:
bitbake mykernel -c devshell
Then in the new xterm window bitbake opened for me:
env | sed 's/\=\(.*\)/\="\1"/' > buildenv #put quotes around r-values in env listing
^D #(I leave the devshell)
Then copy this to my development directory and source it before running make with all of its options
KERNEL_PATH=/mypathto/build/tmp/sysroots/socfpga_cyclone5/usr/src/kernel
source ./buildenv && make -C $KERNEL_PATH V=1 M=`pwd` \
ARCH=arm CROSS-COMPILE=arm-linux-gnueabihf- \
KERNEL_VERSION=3.13.0-00298-g3c7cbb9 \
CC="arm-linux-gnueabihf-gcc -mno-thumb-interwork -marm" \
LD=arm-linux-gnueabihf-ld AR=arm-linux-gnueabihf-ar
Now to my questions:
Am I going about this completely wrong? What is the recommended way to cross-develop kernel modules? I am doing it this way because I don't want to open a bitbake devshell and do my code development in there every time.
This sort of works (I can compile working modules) but the make script gives me an error message saying that the kernel configuration is invalid. I have also tried this with KERNEL_PATH set to the the kernel package git directory (build/tmp/work///git (which contains what appears to be a valid .config file) and I get a similar error.
How can I extract the env without needing to open a devshell? I would like to write a script that extracts it so my coworkers don't have to do it manually. The devshell command opens a completely separate Xterm window, which rather dampens its scriptability...
the sdk installer is what you are looking for:
bitbake your-image -c populate_sdk
then, from your build directory go to tmp/deploy/sdk
and execute the generated shell script.
this script will allow you to generate and install an sdk.
Not only the sdk will allow you to (cross) compile your kernel by providing the needed environment variables and tools, but it will also provide a sysroot + a standalone toolchain to help you easily (and by easily I mean really easily) crosscompile applications with the autotools (as long as you provide Makefile.am and configure.ac)
just source the environment-setup-* file, got to your kernel directory and compile.
Or, for application developpment based on the autotools,
go to the folder containing your project (sources + Makefile.am and configure.ac)
and do:
libtoolize --automake
aclocal
autoconf
automake -a
now your project is ready for compilation:
./configure $CONFIGURE_FLAGS
make
make install DESTDIR=path/to/destination/dir
If you're after a quick hack, instead of Ayman's more complete solution, the scripts run to complete each build stage are available in the directory:
./build/tmp/work/{target_platform}/{package}/{version}/temp/run.do_{build_stage}
These scripts can be run standalone from the ./temp/ directory, and contain all of the environment variables required.

Reliable build of the Linux Kernel for the BeagleBone Black

Is there a reliable build of the Linux kernel for the BeagleBone Black platform anywhere ? I've followed the instructions here, as well as numerous other places, and none of them work. Either the modules don't build (the .ko files just don't get built and can't be found in the case of the link above), or there's missing build targets for the kernel. I'm using the Linaro ARM compiler (arm-linux-gnueabihf-gcc) cross compiling on 32-bit x86 Ubuntu 14.04.
Specifically, I've checked out the source at the BeagleBone Git repository, branches 3.8, 3.11, 3.12, 3.13 and 3.14. I've also checked out a 3rd party git clone here. The problems I've encountered are as follows:
3.8: Kernel will compile (with numerous warnings), but the modules fail to compile due to errors in the patching process from running patch.sh in the branch.
3.11: Kernel will compile (with numerous warnings), but the uImage-dtb.am335x-boneblack Make target will not. Compiling modules fails due to at least one file having an incorrect patch that yields incorrect C syntax.
3.12: Kernel will compile (with numerous warnings), along with the modules. Copying kernel and modules to the board succeeds. Booting the kernel fails, and freezes as soon as the bootup begins right out of the boot command in U-Boot.
3.13, 3.14: The kernel compilation fails with numerous syntax errors.
3.8.13+ from TowerTech: The kernel compilation succeeds (with numerous warnings), the module compilation fails, again due to incorrect patching from patch.sh.
In the cases where I could compile a kernel, I copied it to a fresh, vanilla board in memory using a TFTP boot server from U-Boot, and booted the kernel in memory. However, none of the successfully compiled kernels could work properly because they were missing their modules / firmware / dtbs. What could be causing the incorrect patching ? Surely, the developers who've written the code and patches must have tested it, so there may be something wrong with my workspace, though I can't imagine what at this point. The commands I used were the same as those at link 1.
I also followed the link you have mentioned and I am able to boot the BBB. I am using the mainline kernel from https://www.kernel.org/. The following are the steps I followed
Download the latest kernel. My version is 3.18-rc4
Use "omap2plus_defconfig" which is the default config for beaglebone black
Make commands are
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- omap2plus_defconfig -j4
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- uImage dtbs LOADADDR=0x80008000 -j4.
The image produced is present in the following path.
arch/arm/boot/uImage uImage
arch/arm/boot/dts/am335x-boneblack.dtb
After this compile the modules.
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- modules -j4
I was using busybox and NFS server as root
Compiler used is arm-linux-gnueabi-gcc. With this I am able to boot successfully and run modules. It has the advantage that we are using the latest kernel available.
I was finally able to boot the BBB with a new kernel 3.14
I am on a beagleboneblack rev C with debian pre-installed.
I basically followed steps here
http://dev.ardupilot.com/wiki/building-for-beaglebone-black-on-linux/
Kernel download: (I didn't use git, limited bandwidth...)
https://github.com/beagleboard/linux/archive/3.14.tar.gz
Build (done on a Ubuntu 14.04) : (I am not sure if some steps are not relevant or redundant)
Install mkimage
sudo apt-get install libssl-dev
wget ftp://ftp.denx.de/pub/u-boot/u-boot-latest.tar.bz2
tar -xjf u-boot-latest.tar.bz2
cd u-boot-2014.10/
make sandbox_defconfig tools-only
sudo install tools/mkimage /usr/local/bin
Download am335x-pm-firmware.bin from http://arago-project.org/git/projects/?p=am33x-cm3.git;a=tree;f=bin;h=75a5de7aa94ff6ccbfb1b3b9dc80bc2fe5b423bf;hb=refs/heads/master and copy to kernel directory
Build the kernel
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- bb.org_defconfig
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- menuconfig
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- uImage dtbs LOADADDR=0x80008000 -j4
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- modules -j4
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- am335x-boneblack.dtb -j4
Install Modules
mkdir -p ../export/rootfs
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- INSTALL_MOD_PATH=../export/rootfs/ modules_install
Now copy modules to /lib/modules/ directory in your beaglebone black (create a new directory for the modules)
cd ../export/rootfs/lib/modules/
rsync -avz 3.14.25/ root#192.168.1.3:/lib/modules/3.14.25/
Next is to copy the zImage and am335x-boneblack.dtb to the BBB
copy zImage from arch/arm/boot to /boot/uboot/ of BBB
copy am335x-boneblack.dtb from arch/arm/boot/dts to /boot/uboot/dtbs
If you replace the existing zImage and am335x-boneblack.dtb with new ones directly and they don't work, you will be in trouble. I stored the new images in a folder in /boot/uboot and manipulated environment variables in uboot to pick the one i wanted.
I know, I could have used tftpserver..
I hope it helps someone. I spent a lot of time on this which should have been very straightforward :(
Yeah, the documentation is really out of date (circa 2011 or early 2012) and very confusing. First, the github/beagleboard/kernel area says it is deprecated and to use beagleboard/linux for the kernel. BUT, it is still be actively used 1) to add patches that have not been accepted to the kernel tree yet and 2) to add kernel configs specifically for the beaglebone devel builds. The bb.org_defconfig in the kernel tree does not turn on some debug stuff.
So.. both github/beagleboard/linux AND github/beagleboard/kernel work for me (3.14) on a BBB. If you want a standard image, use "linux"; if you want a bells-and-whistles image use "kernel".
Also, a more recent cross-compiler is in APT at gcc-arm-linux-gnueabihf. Make sure you have the "hf" (hard floating point unit) version. No need to depend on linaro.
I'll update the docs after I get the project rolling....

Kernel recompiled with same config but: cpufreq: no nforce2 chipset error

I need to compile an old kernel 2.6.23 (downloaded from linuxkernels.com) in order to use it with a real time patch (it's a long story...), I installed ubuntu 10.04 which has a kernel 2.6.32-43-generic-pae.
I decided to simple copy ubuntu configuration:
cp cp /boot/config-2.6.32-43-generic-pae /usr/src/linux-2.6.23/.config
I recompile the kernel:
make menuconfig
make
make install
make modules_install
mkinitramfs -o /boot/initrd.img-2.6.23-MYVER 2.6.23-MYVER
note that in the config I make this edit: I remove the module versioning support under loadable modules section. (this step is required by the patch).
At start, I get the title error:
cpufreq: no nforce2 chipset error
how it possible, since I copied a working configuration? Maybe is because of that only flag I disable?
Not sure, but when I copy an existing .config, I run "make oldconfig" first to make sure I'm all sync'd up. Then I run make menuconfig if I want to interactively review/change any settings.

Resources