My guide to creating OE kernel patches for the Beagleboard

Hi,

It was quite awkward figuring out a nice way to build my custom
patches on top of the "standard" Beagleboard build, and add them back
into my recipe directory. There may well be a better method for doing
this, but it works for me!

To summarize, this process involves doing a git source-code checkout
of the linux repository used by the linux_omap-2.6.29.bb recipe.
Then, performing a temporary modification of the recipe, we will apply
the existing Beagleboard patches to provide us with an up-to-date file-
system. We then use that as our basis for creating new patches, which
we can add back into the openembedded project.

(1) Clone kernel in a directory of your choosing (not in your
OpenEmbedded project, however):
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git

(2) Look at the recipes/linux/linux-omap_2.6.29.bb recipe to check
what branch we're need (specified by the SRCREV variable), and then
check it out:
$ cd linux-omap-2.6
$ git checkout 58cf2f1425abfd3a449f9fe985e48be2d2555022

(3) No we'll go back to our OE directory. We'll make a couple of
temporary changes to the recipe that will prevent bitbake from
patching and building the compressed kernel source in your download
directory. Instead, it will work with the kernel you just checked
out:
(a) Change the SRC URI (and create an empty file called dummy.txt in
recipes/linux/files):
SRC_URI = "file://dummy.txt \
     file://defconfig"
(b) Change S to "/path/to/your/linux-omap-2.6" (obviously
substituting the path for where you did your git checkout.:
S = "/home/wherever/linux-omap-2.6"

(4) Perform the following commands to apply the recipe's patches to
your checkout:
$ bitbake linux-omap -c clean -f ; bitbake linux-omap -c patch

(5) Now we return to to your git checkout directory; type "git diff"
and you'll see a big stack of changes have been applied. This is your
new base configuration, so it makes sense to commit it to a branch of
your own:
$ git branch my_branch_name
$ git checkout my_branch_name
$ git commit -a -m "this is my base configuration"

(6) do a quick check to make sure there are no outstanding diffs:
$ git diff

Now you can make your changes to the kernel source, add your own
modules, etc. If you like, you can build the kernel locally to check
the your modifications are ok before creating your patch:
$ make uImage CROSS_COMPILE=arm-angstrom-linux-gnueabi-

(7) Create a patch of your modifications:
$ git diff -p > 001_myname_beagleboard.patch

(8) Copy the 001_myname_beagleboard.patch file into your openembedded/
recipes/linux/linux-omap-2.6.29/beagleboard directory.

(9) Now, restore the changes you made to your linux_omap-2.6.29.bb
script, and also add your patch to the END of the
SRC_URI_append_beagleboard field:

SRC_URI_append_beagleboard = " file://logo_linux_clut224.ppm \
                         file://beagle-asoc.patch;patch=1 \
                               file://tincantools-puppy.diff;patch=1 \
                               file://tincantools-zippy.diff;patch=1 \
             file://beaglebug/beaglebug-full.patch;patch=1 \
                               file://001_myname_beagleboard.patch;patch=1
\
"

(10) You should be all set. Rebuild your linux image:
$ bitbake linux-omap -c clean -f
$ bitbake linux-omap

Hope this helps,
Tim (winding down for Thanksgiving)

I have a PNY 8 GB SDHC card. This card does not always boot properly due to
a kernel panic. My SanDisk 2 GB standard SD cards work perfectly.

  Has anyone else tried one of the PNY SDHC cards? If so, do they work well?

  8-Dale

No, but we're using 8G SanDisk SDHC cards, and a colleague said that he
initially had trouble when the main partition was formatted as ext3. We now
use ext2 for the main partition, and they are working reliably.

Sorry I don't have more info, but you might try reformatting to ext2. (Just
disabling the journal wasn't reliable).

Cameron.

Thanks for the exaustive explaination,

I’ll try your suggestions out in matter of minutes.

As a matter of fact, me, an OE newby, I’m always keeping a copy of my modified files locally and run

a) bitbake -c clean virtual/kernel;
b) bitbake -c configure virtual/kernel;
c) bitbake -c compile virtual/kernel;
d) bitbake -c deploy virtual/kernel

between b and c I replace the modified files (typically mux.h, mux.h, omap_beagle.c and defconfig) with the modified ones.
I guess that modifying the recipie as you mention shuold make this process easier and less risky.

Main problems I have are

  • if I run compile and modify the sources afterwards, bitbake calims there is nothing to do
  • so I’m compelled to run configure, this replaces my files with the original ones out of the repository

I have another question :

  • how do I roll back to the original branch?? See your point 5.

Thanks

Fabio

Thanks for the exaustive explaination,

I'll try your suggestions out in matter of minutes.

As a matter of fact, me, an OE newby, I'm always keeping a copy of my
modified files locally and run

a) bitbake -c clean virtual/kernel;
b) bitbake -c configure virtual/kernel;
c) bitbake -c compile virtual/kernel;
d) bitbake -c deploy virtual/kernel

between b and c I replace the modified files (typically mux.h, mux.h,
omap_beagle.c and defconfig) with the modified ones.
I guess that modifying the recipie as you mention shuold make this process
easier and less risky.

Main problems I have are
- if I run compile and modify the sources afterwards, bitbake calims there
is nothing to do

bitbake -ccompile -f virtual/kernel

Ok got you
-f
!!!
Thanks