changed for oe-core kernel

This article is to detail the workflow I personally use when I am doing kernel development for devices supported by OE. I find OE very useful for this as I can use it to build the toolchain and ultimately to control my patch tree until I am ready to send the patches upstream.

If you have a correctly configured machine then virtual/kernel should point to the correct kernel for your device. So in this article I use virtual/kernel to represent the present kernel. Paths will of course vary with kernel versions.

So I first make sure I am starting from clean

bitbake virtual/kernel -c clean

Then take the kernel as far as the configuration stage, this makes sure all patches in the metadata are applied and that the defconfig has been copied to .config and make oldconfig has been run.

bitbake virtual/kernel -c configure

Now I switch to another window where I shall be actually editing the code. I change to the temporary working directory of the kernel I am working with. This path below will change depending on kernel version or name. Kernels are always found in the machine workdir so tmp/work/$MACHINE-angstrom-linux-gnueabi/

cd tmp/work/elphel-10373-angstrom-linux-gnueabi/linux-elphel-2.6.31+2.6.32-rc8+r4+gitr2a97b06f43c616abb203f4c0eb40518c44c8d7fe-r28/

At this point I normally elect to use quilt to temporarily manage my patches so.

quilt new new-feature.patch

And to add files to this patch, I make sure to do this before I make any edits as the diff ends up being the diff from when this is first called to the current state.

quilt add driver/camera/random.c

Then load the file into my favourite editor.

vi driver/camera/random.c

I make the changes I require then it is time to create a patch from these changes so I then do.

quilt refresh

The above steps created a patches/ directory inside this is one or more patches and a file called series. series is a list of all the patches in the order they should be applied (quilt takes care of this).

So now I want to actually build this code to make sure it compiles so I switch back to my original terminal and issue.

bitbake virtual/kernel -c compile

If this stage fails I continue editing the files to correct the errors remebering to refresh the patches as I go. The above command can be issued repeatedly until is succeeds. When it does I then wish to make the kernel image used on the the board I am playing with so.

bitbake virtual/kernel -c deploy

I take the uImage file from tmp/deploy/images/ and send it to the board for booting however it is done in my setup. For this kernel I will write it into flash on the Elphel camera.

It is almost certain that this first attempt as create the new feature will have some problems. In this case I return to the terminal where I was editing the code and fix it (still not forgetting to refresh the patches). To force the compile stage to happen again I issue the command.

bitbake virtual/kernel -c compile -f

The -f means force and forces bitbake to return to that stage. When the compile is successful I can again issue the following command to deploy the image again.

bitbake virtual/kernel -c deploy

I repeat this cycle as needed until I have my new feature working as I wish.

When I am happy with the changes that have been made to the kernel I will have a patch file in patches/new-feature.patch that is suitable for adding directly to the OpenEmbedded meta data or which can be applied to a git tree ready for sending upstream.

I shall leave the git instructions to the git manual. For the case where I want to apply it to the OE meta data then I edit the original bitbake recipe, adding the patch to the SRC_URI in the form

file://new-feature.patch;patch=1

For example a finished line.

SRC_URI = "git://elphel.git.sourceforge.net/gitroot/elphel/linuxdavinci;branch=elphel-10373;protocol=git \
file://new-feature.patch;patch=1 \
file://defconfig"

I copy the patch into a suitable directory in the metadata. More information on how the build system searches directories for patches can be found on the OE wiki and the bitbake manual. In this case.

recipes/linux-elphel/new-feature.patch

Now I test everything is ok with a clean rebuild so.

bitbake virtual/kernel -c clean
bitbake virtual/kernel


This should successfully complete the build and I should have a kernel with my new feature. If at a later date I find my new feature does not quite work as expected I can use a variation of the same process to update it. Instead of issuing the quilt new/add commands I just start editing the files in the patch again and a quilt refresh will refresh the last patch applied to the source which is most likely my new feature. If it is not or I have done this process multiple times I can use quilt pop and push to move between patches.