7. Creating a new root filesystem

The root file system is the place where system applications and libraries are stored. Most probably you want to change certain files or add additional software. If these changes are minimal and only for a small number of devices, you can make these by hand on the device. Changes will be preserved between reboots. Only certain directories (like /tmp) will be wiped after each boot.

If you want to make bigger changes and deploy them on a lot of devices, it is advised to create a new image, that can be flashed to all targets. The root file system provided by taskit was made with OpenEmbedded (using the Ångström distribution). OpenEmbedded is a build system using so-called recipes as build instructions used by the build tool bitbake. This chapter will explain, how to set up your system to use OpenEmbedded to create your root file system.

You may also consult the OpenEmbedded wiki for additional information: http://wiki.openembedded.net/index.php/Main_Page

It is assumed, that all OpenEmbedded related work is done in the directory /develop/oe. Adjust all paths, if you use a different directory.

Furthermore, all instructions are done exemplary for the Stamp9G20 evaluation board. If you use a different machine, replace all occurrences of the machine name with the correct one.

1. Setting up the OpenEmbedded build system

1.1. Prerequisites

Before you can start to use the OpenEmbedded build system, you need to install some software first. On Debian everything should be installed after the following command entered as root:

apt-get install ccache sed wget cvs subversion git-core bzip2 \
 coreutils unzip texi2html texinfo libsdl1.2-dev docbook-utils \
 gawk python-pysqlite2 diffstat help2man make gcc build-essential

If some packages are missing, bitbake will complain and tell you what is missing. Just install the packages.

You can find additional information on http://wiki.openembedded.net/index.php/Required_software and http://wiki.openembedded.net/index.php/OEandYourDistro.

1.2. Getting the needed metadata

First we create our working directory and enter it:

mkdir /develop/oe
cd /develop/oe

1.2.1. Stamp9G20/PortuxG20

Now we get the OpenEmbedded metadata. It is stored in a git revision control repository:

git clone git://git.openembedded.org/openembedded

This will take a while. After the command is finished, you will have a new directory called openembedded. It will contain all the OpenEmbedded metadata for the development branch (org.openembedded.dev). As we want a more stable environment, we checkout the stable branch:

cd openembedded
git checkout origin/stable/2009 -b stable/2009
cd ..

The stable branch also contains the build tool bitbake, which the development branch does not. If you later decide to try out the development branch, you will have the additional install step of obtaining bitbake which will not be discussed here. Refer to the OpenEmbedded wiki.

Now you should get the taskit overlay for OpenEmbedded. Overlays contain additional metadata, in this case metadata specific to taskit products.

git clone git://gitorious.org/taskit/taskit-overlay.git

1.2.2. Stamp9G45

For the Stamp9G45 OpenEmbedded Core was used instead of the classic OpenEmbedded, so the setup is a bit different. OpenEmbedded Core uses a much more layered approach regarding the metadata. Therefore we need to clone multiple repositories:

git clone git://git.openembedded.org/openembedded-core
git clone git://git.openembedded.org/meta-openembedded
git clone git://git.angstrom-distribution.org/meta-angstrom

Additionally clone the taskit overlay for OpenEmbedded Core:

git clone git://gitorious.org/taskit/taskit-overlay-oe-core.git

Finally, you need a current copy of bitbake in the openembedded-core directory. Use either a snapshot (http://git.openembedded.org/bitbake/) or clone the bitbake repository:

git clone git://git.openembedded.org/bitbake

You can directly do this inside the openembedded-core directory or just create a symlink there.

1.3. Configuring bitbake

1.3.1. Stamp9G20/PortuxG20

Now it is time to create the configuration. The configuration will be put into the file build/conf/local.conf.

mkdir -p build/conf
vi build/conf/local.conf

You can use any other editor, if you are not comfortable with vi.

The file contents should look like in Example 7.1, “Bitbake local configuration”

DL_DIR = "/develop/oe/sources" 1
TMPDIR = /develop/oe/tmp 2
BBFILES = " \ 3
		/develop/oe/taskit-overlay/recipes/*/*.bb \
		/develop/oe/openembedded/recipes/*/*.bb \
"
MACHINE ?= "stamp9g20evb" 4
DISTRO = "angstrom-2008.1" 5
ENABLE_BINARY_LOCALE_GENERATION = "1" 6
GLIBC_GENERATE_LOCALES = "en_GB.UTF-8 de_DE.UTF-8 fr_FR.UTF-8" 7
IMAGE_FSTYPES = "jffs2 tar" 8

Example 7.1. Bitbake local configuration


1

Source packages are downloaded to this directory

2

All compilation and packaging will be done in this directory. It will also contain a subdirectory called deploy, where packages and images will be put.

3

This variable tells bitbake where packages recipes can be found. In this case we told it to look into the OpenEmbedded repository and the taskit overlay.

4

Define the machine to build. It determines which kernel will be built and can select machine specific package overrides. This variable can be overridden on the console, because it is defined with ?=.

5

Define the distribution to build. We use Ångström, as it is most tested distribution in the OpenEmbedded repository.

6

This enables the binary locale generation. It speeds up the first boot of the target board, because the locales are built on the development machine instead of the target.

7

Select only certain locales to speed up the build process. Add needed locales or leave this variable out to build all locales, although this will increase the build time considerably.

8

We create jffs2-images and tar-archives. See http://docs.openembedded.org/usermanual/usermanual.html#image_types for all available image types. As you can see, you can also specify multiple images types to create them all at once.

The jffs2-images will be used to deploy images in the flash memory. The tar-archives can be used to write the rootfs to SD cards.

1.3.2. Stamp9G45

The basic configuration is automatically done by a script provided in the openembedd-core directory called oe-init-build-env. If you source it with no parameters, it will create and enter the directory called build in the current directory. This will be used for the subsequent builds and contains the configuration files in the subdirectory conf.

The command would look like

. openembedded-core/oe-init-build-env

or

source openembedded-core/oe-init-build-env

You can also append another name to the command if would like to use a different build directory.

Two configuration files will be created by default, bblayers.conf and local.conf. The first one will by default look like in Example 7.2, “Bitbake layer configuration”

# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
LCONF_VERSION = "4"

BBFILES ?= ""
BBLAYERS = " \
  /develop/oe/openembedded-core/meta \
  "

Example 7.2. Bitbake layer configuration


This has to be extend to look like in Example 7.3, “Extended bitbake layer configuration”.

# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
LCONF_VERSION = "4"

BBFILES ?= ""
BBLAYERS = " \
  /develop/oe/openembedded-core/meta \
  /develop/oe/meta-openembedded/meta-oe \
  /develop/oe/meta-openembedded/meta-gnome \
  /develop/oe/meta-openembedded/meta-efl \
  /develop/oe/meta-angstrom \
  /develop/oe/taskit-overlay-oe-core \
  "

Example 7.3. Extended bitbake layer configuration


The local.conf is basically fine as it is, but adjusting the MACHINE variable should make it more convenient to invoke bitbake later on (set it to "stamp9g45"). Additionally, the following line should be added, to use the Ångström distribution for building:

DISTRO = "angstrom-2010.x"

Read the comments in the file as some of the options can improve the build performance on multicore systems.

1.4. Setting up the environment

[Note]Note

This section only applies to Stamp9G20 and PortuxG20. For the Stamp9G45, the script from the previous section also sets up the environment, so just source it again before you use bitbake in a new shell.

The last thing to do to get a working OpenEmbedded build environment is to set some environment variables.

export BBPATH=/develop/oe/build:/develop/oe/taskit-overlay:\
/develop/oe/openembedded
export PATH=/develop/oe/openembedded/bitbake/bin:$PATH

The first line sets the variables BBPATH. It is used by bitbake to search for configuration files. Here, build contains your local.conf, and taskit-overlay and openembedded contain distribution and machine configurations.

The second line adjusts the PATH variable so that you do not have to type the full path every time you want to start bitbake.

[Note]Note

This value only works with the stable branch, if you want to use the development branch you have to obtain bitbake separately and adjust the path accordingly.

[Tip]Tip

It is advised to put both lines into a file, e.g. sourceme, so that you do not have to type them every time you want to build something. Now you can enter the following line before you start bitbake the first time in your shell session:

. sourceme

1.5. Keeping the metadata up to date

The metadata from the OpenEmbedded repository can change each day, so can the taskit overlay. These changes can be bug fixes or feature additions.

To update all the metadata, just enter the corresponding directory (/develop/oe/taskit-overlay and /develop/oe/openembedded) and use the following command:

git pull

It is advised to remember the current revision before updating in case the update includes some bugs, so that you can go back easily. Just enter

git show

and you see the last change in the current branch. The first line includes the commit hash.

If you notice that builds do not work anymore after updating or the result has some errors use

git checkout hash

to go back to the commit (hash) remembered. In this state, you cannot use git pull. You have to checkout stable/2009 again to update it:

git checkout stable/2009

To list the changes between hash and the current checked out revision, use

git log hash..

To learn more about git, consult http://git-scm.com.