Manually building a Kernel source from Yocto build

Question

I have a Yocto build for i.mx6 and I want to modify its Kernel. I figured that if I copy Kernel source outside the Yocto project and make my modifications without dealing with patches, I can speed things up significantly. But the thing is, the Kernel source I have to use is already patched and I want to fetch and continue working from there. I will work on the already-patched source files and re-arranging them is a painful process.

For starting point, my patches work fine, and I can get a working image using bitbake fsl-image-multimedia-full command. The Kernel source I want to use is created after this process.

I have tried copying the source under ..../tmp/work-shared/imx6qsabresd/kernel-source. Although make zImage and make modules finished without any trouble, manual building was not successful with an error in a dtsi file (Unable to parse...). Of course, I have checked the file and there was no syntax error.

Also, I checked the kernel source files I copied and it seems that the patches are successfully implemented.

Am I doing something wrong with the patches? With my manual build routine, I can build unpatched kernel source with no errors. I am sure that there are experienced Yocto users here that have their own workarounds to make this process shorter. So, any help is appreciated. Thanks in advance.

Answer 1

My favorite method of doing kernel development in a Yocto project is to create an SDK and build the kernel outside of the Yocto system. This allows more rapid builds because make will only build new changes, whereas a kernel build within Yocto always starts from scratch.

Here are some of my notes on compiling the Linux kernel outside of the Yocto system. The exact paths for this will depend on your exact configuration and software versions. In your case, IMAGE_NAME=fsl-image-multimedia-full

1. Run bitbake -c populate_sdk ${IMAGE_NAME}. You will get a self-extracting and self-installing shell script.

2. Run the shell script (for me it was tmp/deploy/sdk/${NAME}-glibc-i686-${IMAGE_NAME}-cortexa9hf-neon-toolchain-1.0.0.sh), and agree to the default SDK location (for me it was usr/local/oecore-i686).

3. Source the scripts generated by the install script. I use the following helper script to load the SDK so I don't have to keep track of the paths involved. You need to source this in each time you want to use the SDK.

enable_sdk.sh:

#!/bin/bash
if [[ "$0" = "$BASH_SOURCE" ]]
then
    echo "Error: you must source this script."
    exit 1
fi
source /usr/local/oecore-i686/environment-setup-corei7-32-${NAME}-linux
source /usr/local/oecore-i686/environment-setup-cortexa9hf-neon-${NAME}-linux-gnueabi

4. Copy the defconfig file from your Yocto directory to your kernel directory (checked out somewhere outside of the Yocto tree) as .config.

5. Run make oldconfig in your kernel directory so that the Linux kernel build system picks up the existing .config.

   Note: you may have to answer questions about config options that are not set in the .config file.

   Note: running make menuconfig will fail when the SDK is enabled, because the SDK does not have the ncurses libraries set up correctly. For this command, run it in a new terminal that has not enabled the SDK so that it uses the local ncurses-dev packages you have installed.

6. Run make -jN to build the kernel.

7. To run the new kernel, copy the zImage and ${NAME}.dtb files to your NFS/TFTP share or boot device. I use another script to speed up the process.

update_kernel.sh:

#!/bin/bash
set -x
sudo cp /path-to-linux-source/arch/arm/boot/dts/${NAME}.dtb /srv/nfs/${DEVICE}/boot/
sudo cp /path-to-linux-source/arch/arm/boot/zImage /srv/nfs/${DEVICE}/boot/
set +x

8. You can also point Yocto to your local Linux repo in your .bb file. This is useful for making sure your kernel changes still build correctly within Yocto.

   SRC_URI = "git:///path-to-linux-source/.git/;branch=${KBRANCH};protocol=file"

UPDATE: Over a year later, I realize that I completely missed the question about broken patches. Without more information, I can't be sure what went wrong copying the kernel source from Yocto to an external build. I'd suggest opening a Bitbake devshell for the kernel and doing a diff with the external directory after manually applying patches to see what went wrong, or just copy the source from inside the devshell to your external directory. https://www.yoctoproject.org/docs/1.4.2/dev-manual/dev-manual.html#platdev-appdev-devshell

When debugging certain commands or even when just editing packages, devshell can be a useful tool. When you invoke devshell, source files are extracted into your working directory and patches are applied.

Answer 2

You can also edit files in tmp/work-shared/<machine>/kernel-source then compile modified kernel with bitbake -C compile virtual/kernel