Software:Openembedded Build System

From BUGwiki

Jump to: navigation, search

Contents

Overview

Open Embedded (OE) is a framework for building Linux distributions for small computers. It is essentially a set of python scripts and package metadata used to evaluate dependencies and build binaries. The OE community is fairly large and the number of target devices and available packages is also fairly large. Ångström is a well-maintained distribution based on OpenEmbedded. With the large community surrounding Ångström developers have access to rich documentation as well as externally maintained respositories of software for a variety of device archtectures.

External Resources

Open Embedded Wiki: http://www.openembedded.org/index.php/Getting_started

Embedded Linux Blog Planet: http://planet.linuxtogo.org/

An assortment of OpenEmbedded tips: http://www.uv-ac.de/openembedded/openembedded-11.html

OpenMoko Wiki: http://wiki.openmoko.org/wiki/OpenEmbedded

The Ångström Distribution: http://www.angstrom-distribution.org/

Setup

System Requirements

Currently we test on x86_64 and i686 Ubuntu 10.04 GNU/Linux. Support is claimed for other distros.

There is a minimal set of packages required to run OE. The system will tell you what it's missing when you run it. More information is available here.

sudo apt-get install gawk diffstat help2man texi2html texinfo build-essential subversion cvs unzip git-core python-ply


Also on Ubuntu, you need to switch /bin/sh so that it points to /bin/bash rather than /bin/dash:


sudo dpkg-reconfigure dash


and choose "<No>" from the menu. (dash is the default in Ubuntu, but newer versions of Poky's sanity check warn about this: Using dash as /bin/sh causes various subtle build problems, please use bash instead.).

Install

Source Branch (R 1.4)

The sources and build scripts you will want depend on what you want to build. For an R1.4.x compatible build, you can either build from a release tag, which is known to work, or from TRUNK of the R1.4.x release. You can also check out code for R1.5, our next major release, but things may or may not build properly, as there are still many changes happening. Select the most appropriate SVN URL from the following table:

Description SVN URL
Trunk (bleeding edge) svn://bugcamp.net/bug/trunk/com.buglabs.build.oe
Tagged RC's svn://bugcamp.net/bug/tags/RCs/R2.0.2/RC2.0.2.3/com.buglabs.build.oe


Checkout whichever version you need of com.buglabs.build.oe from bugcamp.net, for example trunk:

svn co svn://bugcamp.net/bug/trunk/com.buglabs.build.oe

You'll find a directory meta-bug which contains all the build scripts (metadata) that are BUG specific. The other directories are general there for various purposes, namely:


Source Branch 2.1.x

As of SW R2.1.0 we'll be moving to the Openembedded "release" branches and scheduling. To build the oe-release tree for bug20, try the following warning: this is being verified right now:

First, get chrpath.

sudo apt-get install chrpath

Then do this:

git clone git://github.com/buglabs/oe-buglabs.git
cd oe-buglabs/ && git checkout -b buglabs-sw2.1 origin/buglabs-sw2.1 && cd ..
source oe-buglabs/buglabs-scripts/reinstate-build-env
oe-buglabs/buglabs-scripts/update.sh

Build

The steps below outline how to build the standard BUG Rootfs for R2.0. If you want to add additional packages, or change some of the configurations, please see the information about hand compiling the BUG YT kernel.

Preparing For a Build

Begin by setting the environment variables. This primarily means the $BBPATH, and on Ubuntu systems the mmap_min_addr

On all systems begin by setting the $BBPATH. Change into the directory where you checked out com.buglabs.build.oe above, and do:

source reinstate-build-env

The first time you run the above command, you'll have to wait quite a while. This is because it's calling scripts/init.sh, which is cloning the entire OE git repo and all of its meta-data. This is ~460MB of meta-data, so depending on your download speeds, it could take quite a while.


On Ubuntu systems, reset mmap_min_addr to 0 (without this you will get in the bitbake sanity-checker).

sudo -i
echo 0 > /proc/sys/vm/mmap_min_addr


You will need to do that every time you turn your machine on, which might not be such a bad thing as it's a potential security risk to leave it like that. However if you want to make it stick you can:

vm.mmap_min_addr=0

Once you've saved the file, execute the following command:

invoke-rc.d procps start

BUG Kernel

You can see our kernel package in the meta-bug directory:

ls meta-bug/packages/linux/
linux.inc  linux-omap-hah  linux-omap-hah_2.6.31.bb


The .inc file is the base "recipe" or configuration file for the kernel. Executing bitbake with the package name will generate the kernel:

bitbake linux-omap-hah

The binary image is available in your temp directory:

build/tmp/deploy/glibc/images/bug20/
modules-2.6.31-r110-bug20.tgz   uImage-2.6.31-r110-bug20.bin     uImage-bug20.bin

Openjdk-6

If you'd like to just build openjdk-6, it will build a number of packages, including openjdk-6-zero, openjdk-6-shark, the JRE and JDK, among others.

To build, simply:

bitbake openjdk-6

The binary packages are available in ipk form in the armv7a directory, because the VM is itself arch-specific:

$ ls tmp/deploy/glibc/ipk/armv7a/*openjdk-* | grep -v dbg | grep -v dev
openjdk-6-common_6b18-1.8-r10.4.1_armv7a.ipk  openjdk-6-demo_6b18-1.8-r10.4.1_armv7a.ipk  openjdk-6-doc_6b18-1.8-r10.4.1_armv7a.ipk  openjdk-6-java_6b18-1.8-r10.4.1_armv7a.ipk  openjdk-6-jdk_6b18-1.8-r10.4.1_armv7a.ipk  openjdk-6-jre_6b18-1.8-r10.4.1_armv7a.ipk  openjdk-6-source_6b18-1.8-r10.4.1_armv7a.ipk  openjdk-6-vm-cacao_6b18-1.8-r10.4.1_armv7a.ipk  openjdk-6-vm-shark_6b18-1.8-r10.4.1_armv7a.ipk  openjdk-6-vm-zero_6b18-1.8-r10.4.1_armv7a.ipk


Apache Felix

To build Java packages such as felix other recipies are required. You should be able to build Java packages such as Felix:

bitbake felix

The binary packages for felix, being that they're pure-java, are in the all directory, because felix is platform independent:

ls tmp/deploy/glibc/ipk/all/felix_*
 felix_3.0.4-r5.1_all.ipk


Complete Rootfs

The recipe that defines the root filesystem for the production bug is called:

bug-image-production

They both live in the images directory in the bug metadata section:

[OEROOT]/meta-bug/packages/images

To build the full production root filesystem, simply run bitbake with the image name:

bitbake bug-image-production

Putting the Rootfs and Kernel onto your BUG

You now have several choices as to the means of deployment for your rootfs and kernel image. The latter is a touch harder to deploy, but see the Software:Manually_Compile_the_Kernel wiki about how to do this.

Notes and Tips

Building the OE-release branch (R2.1)

As of SW R2.1.0 we'll be moving to the Openembedded "release" branches and scheduling. To build the oe-release tree for bug20, try the following warning, this is being verified right now:

First, get chrpath.

sudo apt-get install chrpath

Then do this:

git clone git://github.com/buglabs/oe-buglabs.git
cd oe-buglabs/ && git checkout -b buglabs-sw2.1 origin/buglabs-sw2.1 && cd ..
source oe-buglabs/buglabs-scripts/reinstate-build-env
oe-buglabs/buglabs-scripts/update.sh

Bitbake Tips

Debugging

To see the contents of all bitbake variables:

$ bitbake -e

To run bitbake on a particular bb recipe, use

$ bitbake -b path/to/recipe.bb

This is especially helpful in debugging, as is the devshell...

To run bitbake in interactive mode (devshell):

$ bitbake [recipe name] -c devshell

U-Boot compilation issues

These instructions also fix u-boot build issues on Ubuntu 9.04

The u-boot sources we used have some code that fails to compile on Gentoo systems, and maybe others. Go to the u-boot-1.3.2+svnr9272-r5 source tree, and edit fdt.h so that the top looks like this:

#ifndef _FDT_H
#define _FDT_H 

#ifndef __ASSEMBLY__

#include <stdint.h>

struct fdt_header {


See Also

Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox
Print/export