Search by Tags

OpenEmbedded (core)


Compare with Revision

Subscribe for this article updates

This document describes how to build our BSP V2.x from scratch using OpenEmbedded core (oe-core).

OpenEmbedded ( is a build framework which creates kernel images, root filesystem images and installable packages from source code. (OpenEmbedded for the sake of this document is a synonym for Yocto).

OpenEmbedded comes in two flavours, OpenEmbedded classic, and the newer OpenEmbedded core. Our Linux images V1.x are based on OpenEmbedded (classic) while the images starting from V2.0 use OpenEmbedded core.

OpenEmbedded uses meta information (called recipes) for downloading/compiling/deploying of software packages on a x86/x86_64 Linux build host for a target device. This meta information is structured into so called layers. Layers are directory trees with recipes which provide similar functionality, e.g. meta-lxde which provides recipes to build packages for the LXDE desktop.

In order to provide a full desktop environment we make use of the Yocto compatible distribution Ångström, see

Toradex Version Ångström Distribution OpenEmbedded/Yocto Codename Yocto Project Release
2.1 v2013.06 dylan 1.4
2.2 v2013.12 dora 1.5
2.3 v2014.06 daisy 1.6
2.4 v2014.12 dizzy 1.7
2.5 v2015.06 fido 1.8
2.6 / 2.6.1 v2015.12 jethro 2.0
2.7 v2016.12 morty 2.2


For our Linux image starting from V2.0 we use OpenEmbedded core. Layers from are used together with a number of other layers.

oe-core installation and configuration (and the later build) will setup the following directory structure

+-- build
¦   +-- conf
¦   +-- downloads
¦   +-- tmp-glibc
¦   +-- sstate-cache
+-- deploy
+-- layers
    +-- meta-angstrom
    +-- meta-browser
    (... other layers)
    +-- openembedded-core

All meta data is stored under the 'layers' tree, under the 'build' tree is the configuration of what is to be built, the downloaded sources and intermediate output, generated packages, SDKs, and the final images are put under 'deploy'.
Under 'build' only conf/* needs to be preserved. The other content under 'build' can be regenerated by bitbake.

Note: This layout has changed over time:

In BSP releases prior to V2.6.1:
- The 'layers' directory was called 'stuff'.
- The 'tmp-glibc' directory was called 'out-glibc'.
- The 'deploy' directory was a subdirectory of 'out-glibc'.

In BSP releases prior to V2.4:
- The 'out-glibc' directory was called 'out-eglibc'.


To build the whole OpenEmbedded image a powerful host machine is highly recommended. If the host system is a multi-core machine, you can configure the Yocto Project build system to significantly decrease the time needed to build images. There should be a minimum of 60 GBytes of free disk space. For some images a 32-bit image with 4 GBytes of memory is enough, but in order to build applications such as the WebKit web engine, a 64-bit machine with 8 GBytes of RAM is recommended.

As for operating environment, a supported Linux distribution (i.e. recent releases of Fedora, openSUSE, CentOS, Debian, or Ubuntu) is required. The OpenEmbedded wiki provides a required software list for several Linux distributions. Make sure your Distribution is supported and those required software is installed:

OpenEmbedded (Getting started) (do not proceed with 'Setup instructions' available on the same page!)

Should you choose Ubuntu or another distro which uses dash as the default shell we recommend to change this to bash. (Google for 'ubuntu bash update-alternatives')

Toradex BSP (meta-toradex) builds require some additional packages, mainly to compile the flashing utilities as 32-bit executables:

E.g. for Fedora 24 for releases prior to V2.7

Unfortunately gcc-6.1 and later can not yet be used and it is recommended building inside a lightweight systemd container setup as follows (<path to containers rootfs> being e.g. /home/f23 and <username> being a string of your choosing):

sudo dnf install systemd-container
sudo dnf -y --releasever=23 --nogpg --installroot=<path to containers rootfs> --disablerepo='*' --enablerepo=fedora install systemd dnf fedora-release vim-minimal
sudo systemd-nspawn -D <path to containers rootfs>
dnf update
dnf groupinstall "Development Libraries" "Development Tools"
dnf install SDL-devel bzip2 ccache chrpath gcc-c++ patch tar texinfo wget which xterm python git make diffstat cpio file perl-Thread-Queue
dnf install cryptopp-devel.i686 glibc-devel.i686 libusb-devel.i686 libuuid-devel.i686 lzo-devel.i686 lzop zlib-devel.i686
dnf install findutils perl-bignum
dnf install libstdc++-static libstdc++-static.i686 --best
cd /lib; ln -s
useradd <username>

To do an actual build one can change into the lightweight systemd container as follows:

sudo systemd-nspawn -D <path to containers rootfs> -u <username>

E.g. for Fedora 22 & 23 & 24 & 25

Releases V2.5 & V2.6 require a native gcc compiler version of 5 or earlier. So Fedora 24 and 25 require a workaround, see above.

sudo dnf install cryptopp-devel.i686 glibc-devel.i686 libusb-devel.i686 libuuid-devel.i686 lzo-devel.i686 lzop zlib-devel.i686
sudo dnf install libstdc++-static libstdc++-static.i686 --best
sudo dnf install perl-bignum # fixes Can't locate
cd /lib; ln -s # fixes /usr/bin/ld: cannot find -lusb-1.0

Fedora 23 is using perl 5.22 which might require an update to gtk+ for successful building (see Bitbake Build Issues below).

Unfortunately for builds prior to our V2.5 gcc-5.1.1 and later can not yet be used and it is recommended building inside a lightweight systemd container setup as follows (<path to containers rootfs> being e.g. /home/f21 and <username> being a string of your choosing):

sudo dnf -y --releasever=21 --nogpg --installroot=<path to containers rootfs> --disablerepo='*' --enablerepo=fedora install systemd dnf fedora-release vim-minimal
sudo systemd-nspawn -D <path to containers rootfs>
dnf update
dnf groupinstall "Development Libraries" "Development Tools"
dnf install SDL-devel bzip2 ccache chrpath gcc-c++patch tar texinfo wget which xterm
dnf install cryptopp-devel.i686 glibc-devel.i686 libstdc++-static.i686 libusb-devel.i686 libuuid-devel.i686 lzo-devel.i686 zlib-devel.i686
cd /lib; ln -s
useradd <username>

To do an actual build one can change into the lightweight systemd container as follows:

sudo systemd-nspawn -D <path to containers rootfs> -u <username>

E.g. for Fedora 20 & 21

sudo yum install cryptopp-devel.i686 curl glibc-devel.i686 libstdc++-static.i686 libusb-devel.i686 libuuid-devel.i686 lzo-devel.i686 lzop zlib-devel.i686
cd /usr/lib; sudo ln -s # fixes /usr/bin/ld: cannot find -lusb-1.0 

E.g. for Ubuntu 16.04 (64-bit)

sudo dpkg --add-architecture i386
sudo apt-get update
sudo apt-get install g++-5-multilib
sudo apt-get install curl dosfstools gawk g++-multilib gcc-multilib lib32z1-dev libcrypto++9v5:i386 libcrypto++-dev:i386 liblzo2-dev:i386 lzop libstdc++-5-dev:i386 libusb-1.0-0:i386 libusb-1.0-0-dev:i386 uuid-dev:i386
cd /usr/lib; sudo ln -s

E.g. for Ubuntu 15.10 (64-bit)

sudo dpkg --add-architecture i386
sudo apt-get update
sudo apt-get install g++-4.9-multilib
sudo apt-get install curl dosfstools gawk g++-multilib gcc-multilib lib32z1-dev libcrypto++9v5:i386 libcrypto++-dev:i386 liblzo2-dev:i386 lzop libstdc++-4.9-dev:i386 libusb-1.0-0:i386 libusb-1.0-0-dev:i386 uuid-dev:i386
cd /usr/lib; sudo ln -s

E.g. for Ubuntu 15.10 (32-bit)

sudo apt-get install curl dosfstools gawk g++ gcc libcrypto++9v5 libcrypto++-dev liblzo2-dev lzop libstdc++-4.9-dev libusb-1.0-0 libusb-1.0-0-dev uuid-dev zlib1g
cd /usr/lib; sudo ln -s

E.g. for Ubuntu 14.04 (64-bit)

sudo dpkg --add-architecture i386
sudo apt-get update
sudo apt-get install g++-4.8-multilib
sudo apt-get install chrpath curl dosfstools gawk g++-multilib gcc-multilib lib32z1-dev libcrypto++9:i386 libcrypto++-dev:i386 liblzo2-dev:i386 lzop libsdl1.2-dev libstdc++-4.8-dev:i386 libusb-1.0-0:i386 libusb-1.0-0-dev:i386 texinfo uuid-dev:i386
cd /usr/lib; sudo ln -s

E.g. for Ubuntu 14.04 (32-bit)

sudo apt-get install chrpath curl dosfstools gawk g++ gcc libcrypto++9 libcrypto++-dev liblzo2-dev lzop libsdl1.2-dev libstdc++-4.8-dev libusb-1.0-0 libusb-1.0-0-dev texinfo uuid-dev zlib1g
cd /usr/lib; sudo ln -s


V2.1 and Later Images


Since OpenEmbedded requires several git repositories to be available to build our images, starting with V2.1 images we are using a utility called 'repo'. The repo manifest manages the various git repositories and their branches. (more on repo: )

Install the repo bootstrap binary:

mkdir ~/bin
export PATH=~/bin:$PATH
curl > ~/bin/repo
chmod a+x ~/bin/repo

Alternatively, in Ubuntu, 'repo' may be installed as part of the 'phablet-tools' package.

Create a directory for your oe-core setup to live in and clone the meta information. For the Vx.y... Image use the branch LinuxImageVx.y..., e.g. for the V2.5 Image use the branch LinuxImageV2.5

mkdir oe-core
cd oe-core
repo init -u -b LinuxImageV2.7
repo sync

Source the file 'export' to setup the environment. On first invocation this also copies a sample configuration to build/conf/*.conf.

. export

Note: Sourcing 'export' configures the shell environment for the current shell session. It must be entered whenever a new shell session is opened for use with OpenEmbedded.


Adapt build/conf/local.conf to your needs.

Set MACHINE to the module type you are planning to build for. Our BSP layers provide the following machines:

Machine Name

e.g. set in local.conf

MACHINE ?= "colibri-t30"

Note: You can explicitly override the MACHINE setting on the cmdline, set the variable MACHINE when calling the bitbake command (e.g. MACHINE=apalis-t30 bitbake...)

If you have lots of disk space and want to browse the unpacked sources, consider commenting the 'INHERIT += "rm_work"' line.

If you already have a download directory with sources from a previous oe setup consider moving that directory into oe-core/build/download or change local.conf to point to your common download location. DL_DIR.

If you want to build for the apalis-imx6, colibri-imx6 or colibri_imx7 machine some downloads require you to read and accept the NXP®/Freescale EULA available in layers/meta-fsl-arm/EULA. You have to state your acceptance by adding the following line to your local.conf file:
If this line is missing the relevant packages will produce an ERROR similar to: ERROR: To use 'imx-vpu' you need to accept the NXP®/Freescale EULA at 'layers/meta-fsl-arm/EULA'. Please read it and in case you accept it, write: ACCEPT_FSL_EULA = "1" in your local.conf.

Setup is finished, continue with the Building chapter.

Update an Existing Configuration

To update the installation you first update the repo manifest to the version you want to work with and then sync all layers. Check the known issues section below before starting the update.

If you did local changes to the individual layers merge conflicts may occur which you will have to resolve in the respective layer.

Update to the HEAD Revision

e.g. use LinuxImageV2.7 to update to V2.7 Image version.

repo init -b LinuxImageV2.7
repo sync

Update to a Specific Version by Using its Tag

A list of available tags can be found in the manifest repository:

repo init -b refs/tags/Colibri_T20_LinuxImageV2.3_20150320
repo sync

Known Issues

If your repo command succeeds, you can directly proceed with the instructions in the chapter Building below.

Update from pre V2.6.1 to V2.6.1

It is not recommended to update an installation which predates V2.6.1 to V2.6.1 or later. With the changed directory structure and the massively different layer setup you likely end up with at best a lot of dead data and at worst interfering meta data. So it's best to start from scratch and port your changes from your old installations into the new one.

Update from pre V2.6 to V2.6

For V2.6 we changed the location from where repo sync downloads some of the git repositories in the hope that the repo sync issues described further down get reduced.
Due to this, if you update an existing oe-core setup based on V2.5 or earlier you might get errors of the following kind (meta-openembedded.git taken as an example). The errors have to be resolved manually, note that repo outputs the necessary command.

error: Cannot fetch meta-openembedded.git (GitError: --force-sync not enabled; cannot overwrite a local work tree. If you're comfortable with the possibility of losing the work tree's git metadata, use `repo sync --force-sync stuff/meta-openembedded` to proceed.)

If you did change something in the affected layers, save your work to somewhere outside of layers so you can reapply your changes after the layer update, then continue with e.g.:

cd .../oe-core
repo sync --force-sync stuff/meta-openembedded

Repo Sync Issues

Due to lots of company firewalls/proxies only permitting HTTP traffic this is what our default repo manifest is using. At times however the OpenEmbedded or Linaro repositories might show inconsistencies if fetched over HTTP or their web servers might just be under such heavy load. If you get any kind of the following repo fetch/sync issues:

error: Unable to find d29dee17d9a95f2ec6b641c234870f3ccbe24102 under
Cannot obtain needed blob d29dee17d9a95f2ec6b641c234870f3ccbe24102

error: Unable to find 318f971bb4515a6dcbbb0b87f85f2bc58b6e314f under
Cannot obtain needed commit 318f971bb4515a6dcbbb0b87f85f2bc58b6e314f

fatal: loose object 8807fd141bb73d6b405eff223b3b105613bc809a (stored in /home/user/oe-core/.repo/projects/layers/meta-openembedded.git/objects/88/07fd141bb73d6b405eff223b3b105613bc809a) is corrupt
error: did not send all necessary objects

First just try repo syncing again it might just have been a connection glitch.

Then, if the error(s) persist try using git's garbage collection on the failing repository before attempting to sync again, e.g. if the error indicates an issue in the meta-openembedded repository:

cd .repo/projects/layers/meta-openembedded.git
git gc

If the error(s) persist try removing your local git/repo cache before attempting to sync again, e.g. if the error indicates an issue in the meta-openembedded repository:

rm -rf .repo/projects/layers/meta-openembedded.git
rm -rf .repo/project-objects/meta-openembedded.git

Additionally you can limit the number of git repositories which are downloaded in parallel by using the additional parameter "-jX". e.g. to download one repository at a time:

repo sync -j1

Additionally Angstrom reports the following tweak to your IP settings helpful:

sudo sysctl -w net.ipv4.tcp_window_scaling=0

If your Internet connection permits you might also try switching those failing repositories to using the git protocol instead by modifying your .repo/manifest.xml as follows:

<remote fetch="git://" name="oe"/>
<remote fetch="git://" name="linaro"/>

Bitbake Build Issues

Download paths, checksums and so on change over time. If you try to build an older image you might experience errors which are caused by such changes.
Also newer host tools, like the native compiler can introduce build errors.
Check the relevant layer git repo for a fix and cherry-pick/update to a commit which fixes your specific issue.

  • V2.1Beta1 requires an update to meta-toradex in order to fix some checksum mismatches:

    cd stuff/meta-toradex
    git fetch trdx
    git checkout 789432b52eff002a9e9bce2b28e3ea54a44168fe
  • V2.1: With the native gcc 4.8 compiler on Ubuntu 13.10 the following fixes a compile time error with elfutils-native:
    ( elfutils-native/0.148-r11/elfutils-0.148/tests/line2addr.c:135:7: error: format '%a' expects argument of type 'float *', but argument 3 has type 'char **' [-Werror=format=] )

    cd stuff/openembedded-core
    git fetch oe
    git cherry-pick -x 51008a21629561c8d40a7addcddde6c2be176e90
  • V2.1: With the texinfo tools on Ubuntu 13.10 the following fixes a install time error with stress:
    ( stress.texi:68: @itemx must follow @item )

    cd stuff/meta-toradex
    git fetch trdx
    git checkout 60485153fa555caf71a2f92a7eb7585b8d1d7f27
  • V2.3: Linaro's cbuild server is considered temporary and recently down which results in the following eglibc-linaro build failure:
    ( ERROR: Fetcher failure: Fetch command failed with exit code 8, output: 2014-11-06 21:00:36 ERROR 503: Service Unavailable. )

    cd stuff/meta-linaro
    cat <<EOF > eglibc.patch
    diff --git a/meta-linaro-toolchain/recipes-core/eglibc/ b/meta-linaro-toolchain/recipes-core/eglibc/
    index b85181b..990d650 100644
    --- a/meta-linaro-toolchain/recipes-core/eglibc/
    +++ b/meta-linaro-toolchain/recipes-core/eglibc/
    @@ -6,7 +6,7 @@ MMYY = "14.04"
     RELEASE = "20\${MMYY}"
     PR = "r\${RELEASE}"
    -SRC_URI = "\${PV}-\${RELEASE}.tar.bz2 \\
    +SRC_URI = "\${PV}-\${RELEASE}.tar.bz2 \\
                file://eglibc-svn-arm-lowlevellock-include-tls.patch \\
                file://IO-acquire-lock-fix.patch \\
                file://mips-rld-map-check.patch \\
    patch -p1 < eglibc.patch
  • The Ångström distribution uses the Gold linker by default, which requires more memory then the standard GNU GCC BFD linker. If your system runs out of memory during build, disabling Gold by un-commenting the line in meta-angstrom/conf/distro/include/ might help:

    DISTRO_FEATURES_append_arm = " ld-is-gold"
  • V2.5: Building with perl 5.22 as e.g. shipped with Fedora 23 requires gtk+ to be updated to 2.24.28 to avoid the following build failure:

    Can't use 'defined(@array)' (Maybe you should just omit the defined()?) at /home/user/oe-core_V2.5/build/out-glibc/work/armv7at2hf-vfp-neon-angstrom-linux-gnueabi/gtk+/2.24.25-r0/build/demos/gtk-demo/ line 43.
    cd stuff/openembedded-core
    git cherry-pick -x 5c20144fd6d936becc419ae4e4b091b5bbfd2f1c
    git cherry-pick -x 00c501866a2de14f8e1c1c99a0ca36b799f8b123

V2.0 Images

To configure V2.0 builds, see OpenEmbedded (core) Configuration for V2.0 Images.


#setup the environment
cd oe-core
. export

Build the image, bitbake automatically logs console output to timestamped files in build/tmp-glibc/log/cooker/$MACHINE/.

Note: With oe-core you need to be in the directory 'build' when you execute bitbake.

Note2: This will at first build take hours, download lots of stuff and fill 'build/out-glibc', so have at least 60 GByte free.

bitbake -k angstrom-lxde-image

Build a single package and all things it depends on.

bitbake samba

Building an SDK for your image (See also Linux SDKs)

bitbake angstrom-lxde-image -c populate_sdk

The output can be found here:

  • For images, u-boot, uImage, rootfs, deployable tarball: deploy/images/${MACHINE}/
  • For SDKs: deploy/sdk/
  • For ipk packages: deploy/ipk//*.ipk
  • Cross compiler and tools: build/tmp-glibc/sysroots/x86_64-linux/usr/bin/arm-angstrom-linux-gnueabi
  • Library headers and un-stripped binary libraries can be found in: build/tmp-glibc/sysroots/${MACHINE}/


The image tarball, (e.g. Colibri_T20_LinuxImageV2.3_20150320.tar.bz2) has the same structure as our pre-built ones we provide for download.
To update your Colibri module with a newly built image follow the update procedures documented in the release notes and the flashing articles for i.MX6 , i.MX7 , Tegra and Vybrid.

To deploy ipk packages into a running image copy the relevant ipk files onto the module and use the opkg package manager to install it. If the package has dependencies which are not yet installed you will have to install them as well.

opkg install file1.ipk file2.ipk

If you built an alternative image target like core-image-minimal one can just replaced the rootfs from e.g. our Colibri_T20_LinuxImageV2.7Beta1_20170112.tar.bz2 tarball with the one from your core-image-minimal build and update your module as usual. Note however that Toradex images newer than 03.2013 determine the module type from the rootfs/etc/issue file. On newer images use ' -h' and then '-m' parameter to force a module type. For older images add a line so that our script can determine the correct module type e.g.:

sudo sh -c 'echo "" >> etc/issue'
sudo sh -c 'echo "Colibri_T20" >> etc/issue'

Use one of the following strings: "Apalis_iMX6", "Apalis_T30", "Apalis_TK1", "Colibri_iMX6",
"Colibri_iMX7", "Colibri_T20", "Colibri_T30", "Colibri_VF"

Failing Builds

An OpenEmbedded build sometimes fails.

This is what I normally do when a task fails:

  • Reading through the error messages.
  • Restarting bitbake without deleting anything and see if it happens again.
  • Clean the task which failed and then restart building the image

    $ bitbake -c clean python $ bitbake angstrom-lxde-image

  • Clean the task which failed, including deleting cached output and then restart building the image

    $ bitbake -c cleansstate python; $ bitbake angstrom-lxde-image

  • Clean the task which failed, including deleting cached output and the downloaded files and then restart building the image

    $ bitbake -c cleanall python; $ bitbake angstrom-lxde-image

  • Check the layer which provides the recipe if a newer commit exists which addresses the problem.

For builds before V2.1 I had at least one installation where bitbake consistently failed on some task because there was garbage in the ccache. Deleting $HOME/.ccache helped, alternatively you can disable the feature by commenting the CCACHE line in build/conf/local.conf. Also deleting the parser cache helps sometimes. $OEHOME/output/cache

The native readline build fails on some machines. An issue for which I do not have a clean solution. The workaround which works is to install readline on the build machine and add an entry to build/conf/local.conf that it need not be built: ASSUME_PROVIDED += "readline-native"

If there are a lot of issues with fetching sources you could try to first only download all needed sources.

bitbake -c fetchall angstrom-lxde-image

Some Useful Bitbake Commands

If you do an unattended build, '-k' tells bitbake to keep going with independent packages after an error occurred.

bitbake -k angstrom-lxde-image

If you need to dig into what recipes and settings are used the following command outputs a bunch of environment settings and infos about what is going on:

bitbake -e virtual/kernel
bitbake -e virtual/kernel | grep ^WORKDIR

If you want to see all tasks which exist for a given recipe:

bitbake -c listtasks virtual/kernel

Additional Layers

Recipes for even more software are available in additional layers. e.g. The java layer provides recipes related to java. Most layers are registered at They provide a web interface to find layers or individual recipes:

Note that just because a layer or a recipe exists, that does not mean that these recipes will compile / execute. The layers/recipe might have a version conflict with what we use or might never been used with or intended for an ARM architecture.
Refer to the following 'Adding the Qt5 Layer', 'Adding the Java layer' to see examples on how to add a new layer to our setup.

Adding the Qt5 Layer

To add Qt5 to oe-core, you have to add the "meta-qt5" layer. We tried the Qt5 layer only with Tegra and i.MX6 based modules.

Starting with V2.6 meta-qt5 is part of the layers which get set up and the manual cloning and change to bblayers.conf is not longer needed.

Note: It is not recommended to use the open source variants of Qt5 with QtQuick 2.0 on Colibri VF50/VF61. The open source variant of QtQuick 2.0 requires OpenGL graphics API, which is provided by software emulated Mesa drivers for Vybrid SoCs. Hence, depending on the features used in QtQuick, UI's will be rendered rather slow. The commercial offerings of Qt offer a 2D Renderer for QtQuick 2.0 which is suited for Vybrid SoCs (see Qt for Device Creation).

cd oe-core/stuff

# repository version known to work with V2.1 and V2.2 images
# repository version known to work with v2.4 images (alternatively use HEAD of dizzy branch)
# repository version known to work with v2.5 images

git clone --no-checkout 
cd meta-qt5
git checkout -b mywork $META_QT5
cd ..

Add the layer to "build/conf/bblayers.conf".

   ${TOPDIR}/../stuff/meta-openembedded/meta-systemd \
   ${TOPDIR}/../stuff/meta-openembedded/meta-networking \
   ${TOPDIR}/../stuff/meta-openembedded/meta-multimedia \
+  ${TOPDIR}/../stuff/meta-openembedded/meta-ruby \
   ${TOPDIR}/../stuff/meta-lxde \
   ${TOPDIR}/../stuff/meta-browser \
+  ${TOPDIR}/../stuff/meta-qt5 \

Change the "build/conf/local.conf" file to add the packages:

 PREFERRED_PROVIDER_psplash-support = "psplash-angstrom"
+IMAGE_INSTALL_append = " qtbase qtbase-fonts qtbase-plugins cinematicexperience"

For images starting with V2.7 Qt 5.7 qtbase-fonts package is no longer provided. So don't add qtbase-fonts to IMAGE_INSTALL. If you need fonts make sure fonts are installed and qtbase is compiled with PACKAGECONFIG fontconfig so they get found.

PREFERRED_PROVIDER_psplash-support = "psplash-angstrom"
+IMAGE_INSTALL_append = " qtbase qtbase-plugins cinematicexperience liberation-fonts"
+PACKAGECONFIG_FONTS_append_pn-qtbase = " fontconfig"

For using framebuffer with EGLFS (only supported on iMX6) and building an image without the X11 and LXDE desktop environment, use the console-trdx-image target and add the following to the "build/conf/local.conf" in addition to the above

DISTRO_FEATURES_remove = "x11 wayland"
IMAGE_INSTALL_remove = "eglinfo-x11"

Note: Every time one changes the DISTRO_FEATURES, one has to remove all build output and sstate cache, in our setup remove the directories build/out-*libc and build/sstate-cache, if present from any previous build.

For building meta-toolchain-qt5 with v2.5 images, the following patch is required

cd stuff/openembedded-core
cat <EOF> automake.patch
diff --git a/meta/recipes-devtools/automake/ b/meta/recipes-devtools/automake/
index d5b6e9e..f07dda2 100644
--- a/meta/recipes-devtools/automake/
+++ b/meta/recipes-devtools/automake/
@@ -18,8 +18,7 @@ RDEPENDS_${PN} += "\

 RDEPENDS_${PN}_class-native = "autoconf-native perl-native-runtime"

-SRC_URI += " file://python-libdir.patch \
-            file://py-compile-compile-only-optimized-byte-code.patch \
+SRC_URI += " file://py-compile-compile-only-optimized-byte-code.patch \

 SRC_URI[md5sum] = "716946a105ca228ab545fc37a70df3a3"
patch -p1 < automake.patch

Adding the Java Layer

Note that java currently does not compile in a V2.7 due to code not compatible with gcc 6.

There is a layer which adds recipes related to Java to the oe-core setup.
Define the layer version and add the repository meta data:

cd oe-core/layers

# repository version known to work with V2.0 images

# repository version known to work with V2.1 images

# repository version known to work with V2.4 images

# repository version known to work with V2.5 images

# repository version known to work with V2.6 images

git clone --no-checkout
cd meta-java; git checkout -b mywork $META_JAVA; cd ..

Add the layer to build/conf/bblayers.conf

--- build/conf/bblayers.conf~   2012-10-19 17:39:36.000000000 +0200
+++ build/conf/bblayers.conf    2013-04-22 18:31:58.278660259 +0200
@@ -17,6 +17,7 @@
   ${TOPDIR}/../layers/meta-openembedded/meta-multimedia \
   ${TOPDIR}/../layers/oe-tworaz/meta-lxde \
   ${TOPDIR}/../layers/meta-browser \
+  ${TOPDIR}/../layers/meta-java \

 # These layers hold machine specific content, aka Board Support Packages

Note that this will build OpenJDK without xawt, the Abstract Window Toolkit giving one framework for a graphical user interface. In order to build with xawt you will have to patch recipes-core/openjdk/openjdk-7*/icedtea-jdk-nio-use-host-cc.patch.

--- a/recipes-core/openjdk/openjdk-7-75b13/icedtea-jdk-nio-use-host-cc.patch
+++ b/recipes-core/openjdk/openjdk-7-75b13/icedtea-jdk-nio-use-host-cc.patch
@@ -49,26 +49,3 @@ Index: openjdk/jdk/make/java/nio/Makefile

  .PHONY: sources
-Index: openjdk/jdk/make/sun/Makefile
---- openjdk/jdk/make/sun/Makefile      2013-07-25 09:10:09.000000000 -0700
-+++ openjdk/jdk/make/sun/Makefile      2013-10-01 21:32:01.625839149 -0700
-@@ -55,7 +55,7 @@
-     endif
-   endif
-   HEADLESS_SUBDIR = headless
--  XAWT_SUBDIR     = xawt gtk
-+  XAWT_SUBDIR     = 
- endif
- ifeq ($(PLATFORM), macosx)
-@@ -87,7 +87,7 @@
- endif
- SUBDIRS_desktop    = audio $(RENDER_SUBDIR) image \
-                      $(LWAWT_PRE_SUBDIR) $(DISPLAY_LIBS) $(DGA_SUBDIR) $(LWAWT_SUBDIR) \
--                     jawt font jpeg cmm $(DISPLAY_TOOLS) beans 
-+                     font jpeg cmm $(DISPLAY_TOOLS) beans
- SUBDIRS_management = management
- SUBDIRS_misc       = $(ORG_SUBDIR) rmi $(JDBC_SUBDIR) tracing
- SUBDIRS_tools      = native2ascii serialver tools jconsole
\ No newline at end of file

To use the layer either add openjdk-7-jre and openjdk-7-demo packages to your image recipe or build the openjdk-7 recipe and install the openjdk-7-jre...ipk and openjdk-7-demo...ipk packages and their dependencies.

Run a demo application on the module

java -jar /usr/lib/jvm/java-7-openjdk/demo/jfc/Font2DTest/Font2DTest.jar

Working with the Package Manager

Use Angstrom Feeds

The Angstrom distribution provides packages for certain architectures and versions of OpenEmbedded which you can test and use as follows.

Download the list of packages in the available feeds, if a configured feed is not available it will print an error message:

opkg update

Listing available packages, search the list:

opkg list
opkg list | grep jpeg

Install a package and its dependencies:

opkg install nano

Note that using 'opkg upgrade' likely leads to an unusable system. Due to the closed source X11 drivers the whole of X11 must use a matching version. opkg upgrade will update some X11 components to a non compatible version resulting in X11 unable to start.

Note: Starting with V2.7 beta 1 we modified libc to work on Apalis/Colibri T20/T30 despite us relying on an ancient Linux kernel version from NVIDIA's L4T. Please make sure to hold on to our libc version as follows to avoid it getting replaced leading to FATAL: kernel too old:

root@colibri-t30:~# opkg flag hold libc6
Setting flags for package libc6 to hold.

What Package Provides a File

The following script can be used on a module to search what package provides a given file.

PKGS=`opkg list-installed | sed 's/^\(.*\)\s-\s.*/\1/g'`
for pkg in $PKGS
        CNT=`opkg files $pkg | grep -c $FILE`
        if [ $CNT -ne 0 ]
                echo $pkg

Further reading

The Yocto Documentation, particularly the Complete Documentation Set and the Bitbake User Manual provides a lot of information.
Two books we can recommend are:
Embedded Linux Development with Yocto Project
Embedded Linux Projects Using Yocto Project Cookbook

Webinar: Building Embedded Linux Images with the Yocto Project