In-place OE/Bitbake Kernel Modifications for BeagleBoard

As mentioned in a previous post, if you follow the recommendations for setting up and building OE,  the bitbake process cleans up after itself and you can not make in-place modifications to the kernel source.  Granted it is preferable to setup a local overlay in which to do all your work, but it you just want to make a quick change and test it, this process will save you a little time.

After setting up the OE environment (and building everything once to make sure your environment is configured correctly, see Building OpenEmbedded for BeagleBoard and Building Angstrom…) do the following:

$ cd ${OETREE}/build
$ bitbake -c clean linux-omap-2.6.28
$ bitbake -f -c compile linux-omap-2.6.28

The above commands will clean and build a fresh copy of the kernel, leaving the sources in place for future use; you can find them here:

$ cd ${OETREE}/angstrom-dev/work/beagleboard-angstrom-linux-gnueabi/linux-omap-2.6.28-r18/git
$ ls
COPYING        Makefile        arch      fs       lib            samples   virt
CREDITS        Module.symvers  block     include  mm             scripts   vmlinux
Documentation  README          crypto    init     modules.order  security  vmlinux.o
Kbuild         REPORTING-BUGS  drivers   ipc      net            sound
MAINTAINERS      firmware  kernel   patches        usr

From here you can reconfigure the kernel. After ensuring ncurses was installed:

$ yum install ncurses-devel

I was able to

$ make menuconfig

and make my modifications. After saving my configuration changes to update the .config file, it was a simple matter of rerunning the forced compile step from above to rebuild the kernel:

$ bitbake -f -c compile linux-omap-2.6.28
$ bitbake -f -c deploy linux-omap-2.6.28

If your kernel configuration modifications happen to result in the generation of any loadable modules, then you will wind up with another file in the deployment images folder:

$ cd ${OETREE}/angstrom-dev/deploy/glibc/images/beagleboard
$ ls mod*

This file will need to be copied to your SD card and extracted in-place after you’ve extracted the rootfs to the SD card. I use the following script (~/bin/mvrootfs) to accomplish this:

if [ "$(id -u)" != "0" ]; then
  echo "This script must be run as root" 1>&2
  exit -1
if [ "${#}" != "1" ]; then
  echo "usage: $0 sd[x]"
  exit -2

source /home/cmma/oe/source-me.txt


/bin/cp -f ${DEPLOY}/${ROOTFS} ${DEST}
/bin/cp -f ${DEPLOY}/${MODULES} ${DEST}

cd ${DEST}
/bin/tar -jxvf ${ROOTFS} && rm -f ${ROOTFS}
/bin/tar -xvzf ${MODULES} && rm -f ${MODULES} 

/bin/umount /dev/${1}?

Where the name of my image is cmma-ptrp-image, OETREE=/home/cmma/oe and I am using an SD card configured according to these instructions. If my SD card mounts on /dev/sdb, I invoke the script as such:

$ sudo ~/bin/mvrootfs sdb

Then simply put the SD card back in the BeagleBoard and power up.


Modifying and rebuilding u-boot

I highly recommend starting with a fresh OE/Angstrom install following these directions.

NOTE: This process is not as easy as it should be because the default ‘local.conf’ includes the line:

 INHERIT += " rm_work "

which removes the source after everything has been compiled and deployed–this leads to a lot of confusion when reading posts that say the source can be found in ‘tmp/work…’ or ‘angstrom-dev/work…’.  Having previously built images will also populate your folders with a lot of stuff that is extraneous, and that’s why I recommend a fresh install.

Also, I did port over my local overlay as described here, adding ‘${OETREE}/local/recipes/*/*.bb’ to the BBFILES assigment in the ‘local.conf’ file.  I did this to include my app, not to update u-boot.  I did this before invoking any bitbake commands in the links mentioned above.

I then performed a bitbake of my own image, from my local overlay (which builds on console-image) with:

$ bitbake cmma-ptrp-image

(This could have just as easily been:

$ bitbake console-image

for a default install without a local overlay.)

This ran for a few hours and completed successfully.  Since I was then unable to find the u-boot source code  under ‘${OTREE}/angstrom-dev/work…’ (I suspect due to the default use of the rm_work task) I ran the following:

$ source ${OETREE}/source-me.txt
$ bitbake -f -c clean -b ../recipes/u-boot/
$ bitbake -f -c compile -b ../recipes/u-boot/

which forces a recompile of u-boot, leaving the source in place.  I then found the source in:


After applying my pin mux modifications in board/omap3/beagle/beagle.c (see the bottom of this post) I ran the following:

$ bitbake -f -c compile -b ../recipes/u-boot/
$ bitbake -f -c deploy -b ../recipes/u-boot/

I was then able to copy ‘u-boot-beagleboard.bin’ in ‘${OETREE}/angstrom-dev/deploy/glibc/images/beagleboard’ to my SD card.

After rebooting the beagleboard and logging in, the command:

$ cat /etc/services > /dev/ttyS0

results in a wiggly line on the scope connected to pin 15 of J5 on the beagleboard, the UART1_TX line.


Adding a Local Recipe to Angstrom/BeagleBoard

Here’s the directory structure I’ve created for a local overlay, with the name of my application being ptrp:

$ cd ${OETREE}
$ find local -type d

The following changes were made to configuration files mentioned in previous posts (Building OpenEmbedded for BeagleBoard and Building Angstrom…) to support the new local overlay functionality:


export BBPATH="${OETREE}/local:${OETREE}/build:${OETREE}/openembedded:"$BBPATH

(added ${OETREE}/local to BBPATH)


BBFILES += "${OETREE}/openembedded/recipes/*/*.bb"

(Simply replacing the := with += in the assignment)



(again, added ${OETREE}/local to BBPATH)

The content of the files added to the local tree are shown here:



int main(int argc, char** argv)
    int i;
    for (i=0;i<10;i++) {
        printf("Hello world!\nFrom the new PTRP application\n\n");
    return 0;


This is just a doc file in the PTRP application.


DESCRIPTION = "PTRP Application"
PR = "r0.1"

SRC_URI = "file://ptrp.c \


do_compile() {
    ${CC} ${CFLAGS} ${LDFLAGS} ${WORKDIR}/*.c -o ptrp

do_install() {
    install -m 0755 -d ${D}${bindir} ${D}${docdir}/ptrp
    install -m 0755 ${S}/ptrp ${D}${bindir}
    install -m 0644 ${WORKDIR}/README.txt ${D}${docdir}/ptrp


require recipes/images/


export IMAGE_BASENAME = "cmma-ptrp-image"


BBFILES += "${OETREE}/local/recipes/*/*.bb"
BBFILE_PATTERN_overlay = "${OETREE}/local"

Once all the files are in place it’s simply a matter of baking eveything:

$ cd ${OETREE}
$ source ./source-me.txt
$ bitbake -c clean -b ${OETREE}/local/recipes/ptrp/
$ bitbake cmma-ptrp-image

Adding “Hello, World!” to Angstrom console image

The recipe that comes with OE will build an image with a statically linked “Hello, World!” app which will replace ‘init’ on boot, print “Hello, World!” and loop endlessly. This is useful to show how to get your own app running in place of ‘init’. But I was looking to add a “Hello, World!” app to the console image so I can carry forward all the functionality of the console image as well.

These steps are done after work done in previous posts, here and here.

I started by  duplicating an existing image recipe,

$ cd ${OETREE}/openembedded/recipes/images
$ cat | sed 's/altboot/helloworld/g' - >
$ cat

ANGSTROM_EXTRA_INSTALL += " helloworld "

export IMAGE_BASENAME = "helloworld-console-image"

What this recipes does different than the included recipe is that it builds upon the standard console image (require and adds the helloworld package to those being installed in the image (ANGSTROM_EXTRA_INSTALL += ” helloworld “).

I then built the image:

$ cd ${OETREE}
$ source source-me.txt
$ bitbake helloworld-console-image

Once the image was built, I followed the steps for setting up the SD card, with the only real difference being the use of /dev/sdb vs. /dev/sdc (since that’s where the card auto-mounted) and I wound up formatting and labeling (as root) like this:

$ /sbin/mkfs.msdos -F 32 /dev/sdb1 -n LABEL1
$ /sbin/mkfs.ext3 -L LABEL2 /dev/sdb2

(Unplug and replug SD card reader.)

After verifying everything the existence of the images in ‘${OETREE}/angstrom-dev/deploy/glibc/images/’ I populated the SD card as follows:

$ cd ${OETREE}/angstrom-dev/deploy/glibc/images/
$ cp MLO-beagleboard /media/LABEL1/MLO
$ cp u-boot-beagleboard.bin /media/LABEL1/u-boot.bin
$ cp uImage-beagleboard.bin /media/LABEL1/uImage
$ cp Angstrom-helloworld-console-image-glibc-ipk-2009.X-test-20090501-beagleboard.rootfs.tar.bz2 /media/LABEL2
$ cd /media/LABEL2
$ tar -jxvf Angstrom-helloworld-console-image-glibc-ipk-2009.X-test-20090501-beagleboard.rootfs.tar.bz2
$ rm Angstrom-helloworld-console-image-glibc-ipk-2009.X-test-20090501-beagleboard.rootfs.tar.bz2
$ sync
$ cd
$ umount /media/LABEL*

This sequence was based on the steps found here for populating the SD card but I’ve used full file names as found in the images folder not generic names like ‘MLO’ and ‘uImage’.

When booting the BeagleBoard off this card Angstrom comes up to the login prompt:

|       |                  .-.
|   |   |-----.-----.-----.| |   .----..-----.-----.
|       |     | __  |  ---'| '--.|  .-'|     |     |
|   |   |  |  |     |---  ||  --'|  |  |  '  | | | |
'---'---'--'--'--.  |-----''----''--'  '-----'-'-'-'
                -'  |

The Angstrom Distribution beagleboard ttyS2

Angstrom 2009.X-test-20090428 beagleboard ttyS2

beagleboard login: [root]
root@beagleboard:~# helloworld
Hello world![Ctrl-C]
root@beagleboard:~# ls -al /usr/bin/helloworld
-rwxr-xr-x    1 root     root       445632 May  1  2009 /usr/bin/helloworld

We still haven’t connected all the dots.  This doesn’t include the ‘myhelloworld’ app we build in a previous post in new console image build, but the ‘helloworld’ app as distributed with OE, which is rather simplistic as the source file is generated via a ‘printf’ in ‘do_fetch()’ function of the recipe file, helloworld/

$ cd ${OETREE}/openembedded/recipes
$ cat  helloworld/
DESCRIPTION = "Minimal statically compiled Hello world!"
PR = "r0"

S = "${WORKDIR}/${P}"

do_fetch () {
        mkdir -p ${WORKDIR}/${P}
        cd ${WORKDIR}/${P}
        printf "#include nint main(void)n{ntprintf("Hello world!\n");twhile(1);ntreturn 0;n}n" >helloworld.c

do_compile () {
        ${CC} -o helloworld helloworld.c -static

do_install () {
        install -d ${D}${bindir}
        install -m 0755 helloworld ${D}${bindir}/
        # /bin/init is on purpose, it is tried after /sbin/init and /etc/init
        # so if a sysvinit is installed, it will be used instead of helloworld
        install -d ${D}${base_bindir}
        ln -sf ${bindir}/helloworld ${D}${base_bindir}/init

The last step to be accomplished is to create a local overlay structure for building our own image so we do not have to mess with the base install. Instructions for doing that can be found here.  I’ll keep you posted on my progress.


Building Ångström… One Step Beyond OpenEmbedded

This will be short and sweet…

To complete the Ångström build I followed the instructions here with the caveat that the OETREE environment variable was set to “/home/cmma/oe/stuff” vs. “/OE” as stated above. (‘cmma’ is the name on the account I am using to build this stuff.)

I added the OETREE definition to my .bashrc and also ensured that it was set the same in the ‘source-me.txt’ file after I downloaded it.

Also, it was not necessary to run the first 3 steps of the steps below as I’d already cloned the OE base.

    export OETREE="/OE"
    mkdir -p ${OETREE} && cd ${OETREE}
    git clone git:// openembedded
    cd openembedded
    git checkout origin/stable/2009 -b stable/2009

I simply ran (after setting OETREE properly):

    cd ${OETREE}/openembedded
    git checkout origin/stable/2009 -b stable/2009

I then continued as instructed in the link above. (I did add a ‘-f’ flag to the local.conf ‘cp’ command to force an overwrite of my previous local.conf file.)

Bitbake is currently on step 610 of 2946 and counting…


Bulding OpenEmbedded for BeagleBoard

My experience getting OE built for a BeagleBoard….

A Fresh Start

Wanting to start with a fresh host, I did a network install of CentOS 5.3 from our internal CentOS mirror (this will turn out to bite me later) onto a new hard drive.

With the fresh CentOS install I started looking at putting together the OpenEmbedded build environment (see BeagleBoard#OpenEmbedded and OpenEmbedded Getting_Started.) The Getting_Started page provides the basis for my process.

Just to make things interesting I decide to place the root for the build inside a fresh user account so my first step is:

$ mkdir -p ~/oe/stuff/build/conf

(this will also cause a little confusion later.)

Installing BitBake

Even after configuring proxy settings in ~/.subversion/servers, I can’t get svn to checkout bitbake.  The workaround is to download bitbake-1.8.12.tar.gz and extracting the tarball to ~/oe/stuff/bitbake.

Getting GIT

I try following the steps at Bulding Git on CentOS 5.  The first difference is using yum vs apt-get, so installing dependencies is:

sudo yum install gettext-devel expat-devel curl-devel zlib-devel openssl-devel

instead of:

sudo apt-get install gettext-devel expat-devel curl-devel zlib-devel openssl-devel

Of course, I am still connected to the corporate internal network so when I get to this command:


the process just hangs–another proxy issue.  Time to call IT and get a DMZ port…  Ok, now I am back connected to a DMZ port, no more fiddling with proxy issues from tool to tool.  The GIT install goes off without a hitch once connected to a DMZ port.  Moving on now the GIT is got …

Obtaining OpenEmbedded using GIT

Since we are now on a DMZ port, the git clone process goes off without a hitch.  Moving on to the local configuration, lack of attention to detail cost me a half hour (due to my use of the ~/oe/stuff root.)

Local Configuration and ‘bitbake console-image’

We make some small changes here to the local.conf file, /home/cmma/oe/stuff/build/conf/local.conf:

BBFILES = "/home/cmma/oe/stuff/openembedded/recipes/*/*.bb"
DISTRO = "angstrom-2008.1"
MACHINE = "beagleboard"

Note the machine is set to ‘beagleboard’.

When adding BBPATH to my .bashrc file I updated the /stuff/build path element, but failed to update the /stuff/openembedded path element.  This caused bitbake to fail and I spent  some time researching the error messages.  When I reviewed the .bashrc I caught my mistake.

I found I was still missing some dependencies and ran:

sudo yum install gcc-c++ diffstat texi2html python-devel

This is where my choice of a local miror started to get me in trouble–it didn’t have other dependencies that bitbake needed.  So there was a manual install of the following:


Once the required dependencies were in place, I installed the recommend psyco:

$ cd ~/src
$ svn co psyco-dist

following the instructions found here (I had previously configured all sources to be downloaded to ~/src so that’s where psyco went as well.)

After that my bitbake command:

$ bitbake console-image

started without and complaints and 4 hours later it completed.


Two days later I’ve just issued my first ‘git pull’ () and the ‘bitbake console-image’ is currently about 10% complete.  I don’t expect any issues from here on.

This was all done in preparation for a custom beagleboard solution I am working on which will require some OMAP pinmux changes.  Confirming we can build an image was the first step in this process.