• wget http://upload.wikimedia.org/wikipedia/commons/7/76/Ding_Dong_Bell.ogg
• sudo mv Ding_Dong_Bell.ogg /usr/local/
• sudo aptitude install cplay
• sudo echo “cplay /usr/local/Ding_Dong_Bell.ogg” > /usr/local/bin/bell
• sudo chmod 775 /usr/local/bin/bell

Now, when I have a long build, I simply do something like:

bitbake my-image; bell

There is probably something better than cplay that does not start a UI — any suggestions?

import serial
import sys
import struct

if len(sys.argv) != 3:
    print "Usage: serial-dump.py <serial port> <baud rate>"
    sys.exit(-1)

print "Dumping data on %s" % (sys.argv[1])

ser = serial.Serial(sys.argv[1], sys.argv[2], timeout=0.3)

while(1):
    buf = ser.read(500)
    if len(buf) > 0:
        print "Read %i bytes:" % (len(buf)),

        for i in buf:
            value = struct.unpack('B', i)[0]
            print "%02x" % (value),

        print ""

The full source is available here.  This could obviously be improved to do true blocking reads, automatically parse protocols, implement a gui, etc.  Ideas for efficiently reading data using pyserial is available in a previous post.  Another example of using a scripting language for quick tasks is http://bec-systems.com/site/226/a-really-nice-hex-calculator.

mixing * ports and non-* ports with a NameVirtualHost address is not supported, proceeding with undefined results

Googling does not return a clear explanation to this problem, so that is why I’m writing this article. The impulsive approach of randomly changing things does not get you too far — especially with the Debian/Ubuntu Apache configuration that is composed of seperate files for each virtual host.  After reading the documentation, things become clearer:

Note that the argument to the <VirtualHost> directive must exactly match the argument to the NameVirtualHost directive.

And, by considering the fact that the seperate virtual host config files really just get concatenated into one big file, it makes sense that you can’t have more than one NameVirtualHost entry.  Ubuntu by default puts the NameVirtualHost in the default virtual host file, which gets soft linked to sites-enabled/000-default.  I presume the ‘000′ means it gets loaded first.  I find it much more intuitive to put the NameVitualHost directives in the /etc/apache2/httpd.conf file.  This way it is clear that these entries are common to all virtual host entries.  So what I end up with is:

/etc/apache2/httpd.conf

NameVirtualHost 74.208.184.45:80
NameVirtualHost 74.208.184.46:80
NameVirtualHost 74.208.184.45:443

/etc/apache2/sites-available/bec-systems.com

<VirtualHost 74.208.184.45:80>
        ServerName bec-systems.com
...

/etc/apach2/sites-available/bec-systems.com.ssl

<VirtualHost 74.208.184.45:443>
        ServerName bec-systems.com
...

/etc/apach2/sites-available/svn.bec-systems.com

<VirtualHost 74.208.184.45:80>
        ServerName svn.bec-systems.com
...

/etc/apach2/sites-available/site2.com (with different IP address)

<VirtualHost 74.208.184.46:80>
        ServerName site2.com
...

Again, the points to remember are:

1. The argument to VirtualHost must match a NameVirtualHost directive
2. the NameVirtualHost directive is common, so there should only be one entry

Use Git

Trust me on this one, just use it!  It will make your life easier.  There is a learning curve to any powerful tool.  Another way to state this is if a tool does not do much, then it would be easy to learn.  So expect to spend a little time learning to use git.  With modern Linux kernel development, much of your time is spent integrating work that others are doing.  For example, if you are using the OMAP3 CPU, you might want to start with linux-omap branch, integrate some patches from the OE beagleboard build, merge the OMAP PM tree, and then merge some bits from the Linux-wireless tree.  This is the way embedded Linux development is done today.  Git makes it possible to have many parallel developments going at their own pace, including your own.  Even in your own development, you will find significant advantages to being able to quickly create and merge branches, revise commits, etc.  There are several articles about git on this site.

Importing an OE kernel into git

If you are starting with an existing OE kernel tree, then you typically need to set up an equivalent tree in your local git workspace.  Typically you just look at the recipe to see how to manually reconstruct it.  For example, lets consider the SRC_URI from the palm-omap1 recipe:

SRC_URI = "${KERNELORG_MIRROR}/pub/linux/kernel/v2.6/linux-2.6.22.tar.bz2 \
           http://www.muru.com/linux/omap/patches/patch-2.6.22-omap1.bz2;patch=1 \
	   file://defconfig"

To set this kernel up in git, we might do the following:

1. git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
2. cd linux-2.6
3. git checkout -b my_branch v2.6.22
4. wget http://www.muru.com/linux/omap/patches/patch-2.6.22-omap1.bz2
5. bzip2 -d patch-2.6.22-omap1.bz2
6. git am patch-2.6.22-omap1

If the git am fails, then you might need to add a subject and author line to the patch in the following form and then retry git am.

From: Name <name@company.com>
Subject: omap1 patch

Now when you do a git log, you will see the above patch applied.  git apply can also be used to apply patches, but I prefer git-am as it automatically handles new files and fills in the commit message and author.

Setting up the toolchain

Now that you have a kernel, you must set up a toolchain so you can build it.  I typically set up my kernel directory next to my OE build directory in my project space, so I can then source the following script to set up the toolchain:

CROSS_COMPILER_PATH=`cd ../oe/build/angstrom-2008.1/tmp/cross/armv7a/bin; pwd`
BUILD_ARCH=`uname -m`
OE_STAGING_PATH=`cd ../oe/build/angstrom-2008.1/tmp/staging/${BUILD_ARCH}-linux/usr/bin; pwd`
STAGING_KERNEL_DIR=`cd linux-2.6; pwd`
export PATH=$PATH:$CROSS_COMPILER_PATH:$OE_STAGING_PATH
export ARCH=arm
export CROSS_COMPILE=arm-angstrom-linux-gnueabi-

Adjust to whatever you are building for.  Now you can simply type make.  The reason the OE_STAGING_PATH is added to the PATH in the above example is so that the uboot mkimage utility can be used directly from the OE build if your build target is make uImage.

Installing modules

Sometimes you need to re-install all modules on the target because you changed kernel version, etc.  Typically OE packages up all modules and adds the one you specify to the rootfs.  Because we are building the kernel outside the OE directory, OE can no longer do this.  However, its still very easy to install modules from your kernel development directory:

rm -rf modules_install; INSTALL_MOD_PATH=modules_install make modules_install
rsync -av modules_install/lib/modules/2.6.22 root@192.168.1.115:/lib/modules/

The first command installs the modules to a temporary directory, and the second command rsync’s the modules to your target system.

Creating a kernel recipe with your changes

Once you get to the point where you want to create a recipe with your changes, you can easily export a patch, or series of patches using git diff or git format-patch.  Simply add the patch files to your kernel recipe SRC_URI.  You can also teach bitbake to fetch your kernel source directly from a git repository, but I’ve generally found the patch mechanism to be adequate and easier in most cases.  As an example, you can create one large patch with all your changes that can be applied on the 2.6.22 released kernel:

git diff HEAD..v2.6.22 > my_kernel_changes.patch

Other ways …

This is just one flow and there are many variations.  There is also a new mechanism in OpenEmbedded called srctree that allows you to use OpenEmbedded in an external source tree.  srctree has the potential to further streamline this type of development.

As with any task, you want to use the tools that make sense for the task.  OpenEmbedded makes sense for building Linux distributions, but it is not a kernel development tool.  Git and the kernel build system make sense for kernel development.

http://dev.bec-systems.com/svn/pub/avi_to_ogg/avi_to_ogg

And some of the results:

http://bec-systems.com/video/

(hint, download firefox 3.5 to view these videos)

Application Source

I created a sample GTK hello application located at: http://dev.bec-systems.com/svn/pub/gtk_hello.  This is a SVN repository, so you can simply “svn co” the above URI to check out the code.  If you are running Ubuntu, you can install the necessary tools to build a native Gtk+ application by:

• sudo apt-get install libgtk2.0-dev build-essential autoconf automake pkg-config

To build on your x86 Linux PC, run the following steps:

• svn co http://dev.bec-systems.com/svn/pub/gtk_hello
• cd gtk_hello
• autoreconf -i
• ./configure –prefix=`pwd`/install
• make install

This compiles and installs the application in to the “install” directory.  If you look in this directory, you will notice the application binary is installed in the “install/bin” directory.  Typically, the install directory is set to /usr/bin, but in this example we set it to install so we don’t need to run “make install” as root, but yet we can verify the install logic works properly.

OpenEmbedded Recipe

Now that you have verified the application builds and installs properly on a x86 PC, it is trivial to build the application in OpenEmbedded.  Create a recipe in your OE recipes directory named gtk-hello_svn.bb with the following contents:

DESCRIPTION = "Sample Gtk+ Hello application, used to demonstrate build system"
AUTHOR = "Cliff Brake <cbrake@bec-systems.com>"

SRCREV = "17"
PV = "0.0+svn${SRCREV}"
PR = "r0"

DEPENDS = "gtk+"

SRC_URI = "svn://dev.bec-systems.com/svn/pub;module=gtk_hello;proto=http;rev=17"

S = "${WORKDIR}/gtk_hello/"

inherit autotools

Now, run: bitbake gtk-hello.  That is it!  Building Linux applications is easy if you simply use the tools, whether it be autotools, qmake, etc.  Too often there is the tendency to set up your own compile steps with ${CC} variables, etc.  While this seems to be the simple approach at first glance (autotools is too hard), it quickly becomes unmaintainable and in the end is a lot more work than simply learning the basics of the industry standard tools.  See previous autotools article for more information.