wh1t3's

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/u-boot_git.bb
$ bitbake -f -c compile -b ../recipes/u-boot/u-boot_git.bb

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

${OETREE}/angstrom-dev/work/beagleboard-angstrom-linux-gnueabi/u-boot-2008.10+r22+gitrb7038cff739684bb95853eb5bee924c2574a222e-r22/git

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/u-boot_git.bb
$ bitbake -f -c deploy -b ../recipes/u-boot/u-boot_git.bb

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.

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:

wget http://kernel.org/pub/software/scm/git/git-1.6.2.tar.gz

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:

pysqlite
help2man

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

$ cd ~/src
$ svn co http://codespeak.net/svn/psyco/dist/ 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.

Updates

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.