OpenEmbedded on Ubuntu 10.04

NOTE: In light of the instructions received from Koen, the Angström head developer, you should avoid following the instructions below, since the deb-based OE is appearantly faulty by design and bitbake 1.10.x should be used instead of Ubuntu's one. Use these setup scripts to set-up your dev branch instead. I'm not deleting the post in case the same errors occur in some other way as well.

Now's the time to talk about...setting up OpenEmbedded on Ubuntu 10.04...and...building the Ångström distribution for the BeagleBoard! (I do realize I've created some suspense surrounding this particular subject with my previous posts, but despite the problems one may run into it's not that terrifying really :))


An advantage of setting up OE on Ubuntu (or any other .deb-based system, for that matter) is that one is able to use the apt-get'able OpenEmbedded. Following the instructions on the blog post (that is, get the repository in your sources list - sudo aptitude install openembedded-minimal - oe-setup-minimal org.openembedded.dev) the set-up part becomes a breeze - this will take care of all the necessary dependencies.


You may read from several sources that you absolutely shouldn't be using the bitbake that is in Ubuntu's own repositories (ie, things like DON'T sudo apt-get install bitbake) but from what I've seen, they've updated the repository and version 1.8.18 was directly available at the time of my writing this. You may want to check for yourself by executing bitbake --version once you have obtained the packages, anything over 1.8.16 should be fine.


Once you've set up the environment by executing oe-setup-minimal org.openembedded.dev (yes, using the dev branch is appearantly recommended, instead of the stable/2009 branch) you can make an attempt at trying out your new oven...oh, I mean, development environment, by trying out something smaller via giving this command:

MACHINE=beagleboard bitbake nano

While we're at it, we can take a short look at parts of this particular command. Not that it's that complicated but here goes anyway:

• OpenEmbedded supports a lot of different target platforms, so we should specify the platform we'll be targeting. This is what the MACHINE=beagleboard part is for.
• bitbake is the central make tool, used extensively in OpenEmbedded, and nano is the name of the "recipe" for the miniscule (but useful!) text editor. For a nice introduction to bitbake and its recipes system, you may want to read this.

Although nano itself isn't all that complicated, the build can take some time since the initial setting up of the toolchain and base libraries will also be done.

During the build process, you may run into several errors. I've documented the ones I've personally ran into and how I got over them.

Error #1: Extraction error while building expat

OE Message: ERROR: '/home/maltanar/oe/openembedded.org/recipes/expat/expat_2.0.1.bb' failed

Digging down a bit further reveals 

NOTE: Unpacking ../../sources/expat-2.0.1.tar.gz to ../../tmp/minimal/org.openembedded.dev/work/armv7a-oe-linux-gnueabi/expat-2.0.1-r3/

gzip: stdin: invalid compressed data--crc error

This is a known bug in the current gzip which appearantly affects several distributions on i386 computers. The workaround I did is as follows:

1. Install the gzip recovery tools: sudo apt-get install gzrt
2. cd into the OE sources folder ($OE_ROOT/sources, should be ~/oe/sources if you used the deb setup)
3. Run gzrecover expat-2.0.1.tar.gz; mv expat-2.0.1.tar.recovered expat-2.0.1.tar; gzip expat-2.0.1.tar and say yes to the overwrite
4. Generate the md5 and sha256 sums of the new file by running md5sum expat-2.0.1.tar.gz; sha256sum expat-2.0.1.tar.gz and note them somewhere. Edit the expat-2.0.1.tar.gz.md5 file to reflect the new MD5 checksum.
5. cd into oe/openembedded.org/recipes/expat then edit the expat_2.0.1.bb file in your favorite text editor - change the MD5 and SHA256 checksums there to reflect the new ones, and save.
6. Done! You can run MACHINE=beagleboard bitbake nano once again.

I didn't run into any more problems while building nano, and it was eventually successfully built. And now it's the time to try the bit-baking oven on something bigger...an image of the actual Ångström distribution. Sounds fancy? Well, it starts off as simple as

MACHINE=beagleboard bitbake -v console-image

provided that you want to start out with something simple, that is, the barebones console image. Notice the extra -v passed on the command line - it can be helpful to have a verbose bitbake while building something major.

I've also kept track of what happened during the console-image build process:

Error #2: Trouble with glibc version while building gtk+

OE Message: NOTE: Task failed: /home/maltanar/oe/tmp/minimal/org.openembedded.dev/work/i686-linux/gtk+-native-2.20.0-r8.0/temp/log.do_configure.11847

In more detail: 

| checking for BASE_DEPENDENCIES... configure: error: Package requirements (glib-2.0 >= 2.23.6    atk >= 1.29.2    pango >= 1.20    cairo >= 1.6) were not met:

| 

| Requested 'glib-2.0 >= 2.23.6' but version of GLib is 2.22.1

For some reason, although many newer glib-2.0 recipes are available, OE chooses the older ones. To solve this, I went into the oe/openembedded.org/recipes/glib-2.0 and deleted all the recipe (*.bb) files with the -native suffix (for example, glib-2.0-native_2.2.3.bb), and re-started the build process.

I don't understand it completely but I think the old -native suffixed recipes are sort of left-overs, since OE seems to be using the BBCLASSEXTEND = "native" flag for this purpose now (the non-suffixed recipes all have this).

Error #3: Trouble with mtd-utils build

OE error message: NOTE: Task failed: /home/maltanar/oe/tmp/minimal/org.openembedded.dev/work/i686-linux/mtd-utils-native-1.3.1-r0/temp/log.do_compile.6960

crc32.o: could not read symbols: File in wrong format

Not sure why this happened either. I cd'd into the mtd-utils source directory (oe/tmp/minimal/org.openembedded.dev/work/i686-linux/mtd-utils-native-1.3.1-r0/git) and ran make clean followed by MACHINE=beagleboard bitbake mtd-utils which did complete successfully this time.

After these (and several hours later) the process was complete, and I ended up with the rootfs, uImage and u-boot images in the oe/tmp/minimal/org.openembedded.dev/deploy/images directory! The uImage was still causing a kernel panic for me upon boot with a proper USB cable, so one may want to use the uImage from the /boot folder from the last BeagleBoard demo image as I mentioned in my previous post. Or maybe use an USB cable which isn't working :)