Its not an embedded Linux

distribution
It creates a custom one for you.

Building Custom Embedded Images

with the Yocto Project
Saul Wold / Tom Zanussi
Intel Corporation
April 13th, 2011

Overview

Some basic background (images, recipes, etc)

Customizing images with layers

BSP Layers

Enabling a new machine

Dive into a couple key components, the kernel and X

Application Layers

Future

Media Server Demo

Image Creator

Q&A

April 13th,

2/

The Yocto Project in a Nutshell

Tools and metadata for creating custom embedded systems

Images are tailored to specific hardware and use cases

But metadata is generally arch-independent

Unlike a distro, 'kitchen sink' is not included (we know what we

need in advance)

An image is a collection of 'baked' recipes (packages)

A 'recipe' is a set of instructions for building 'packages'

Where to get the source and which patches to apply

Dependencies (on libraries or other recipes, for example)

Config/compile options, 'install' customization

A 'layer' is a logical collection of recipes representing the core, a

board support package (BSP), or an application stack

April 13th,

3/

The Yocto Project Build System

bitbake + metadata (Poky)

bitbake - a task executor and scheduler

metadata task definitions in recipes, classes + config

configuration (.conf) global definition of variables

build/conf/local.conf (local user-defined variables)

distro/poky.conf (Yocto 'distro' config variables)

machine/beagleboard.conf (machine-specific variables)

classes (.bbclass) encapsulation and inheritance of logic

recipes (.bb) the logical unit of execution,
software/images to build

April 13th,

4/

The Yocto Project and Poky

April 13th,

5/

Layers

April 13th,

6/

BSP 'Layers'

Image contents can be modified by 'layers'

Layers specialize images by adding or modifying recipes

Really just another directory to look for recipes in

Added to the BBLAYERS variable in build/conf/bblayers.conf

BSPs are layers that add machine settings and recipes

Machine settings are specified in a layer's conf/machine/xxx.conf file(s)

Examples:

Sandy Bridge + Cougar Point:

meta-intel/meta-sugarbay/machine/sugarbay.conf

Beagleboard (arm)

April 13th,

yocto/meta/conf/machine/beagleboard.conf
7/

Practical Requirements for a BSP

A BSP developer's task is to create a machine layer

Define a machine configuration to match hardware

Add machine-specific recipes or extend existing recipes

Very few hard requirements, but there are some

All BSPs must select and configure a kernel

Machines with graphics capabilities probably also want
to select and configure graphics recipes

Custom recipes can be added for special hardware

Most other things covered by standard recipes

New BSPs should follow a standard layout

April 13th,

8/

The Layout of a BSP Layer

trz@elmorro:/usr/local/src/yocto/snb/metaintel$find./metasugarbay
./metasugarbay
./metasugarbay/recipesbsp
./metasugarbay/recipesbsp/formfactor/formfactor/sugarbay
./metasugarbay/recipesbsp/formfactor/formfactor/sugarbay/machconfig
./metasugarbay/recipesbsp/formfactor/formfactor_0.0.bbappend
./metasugarbay/COPYING.MIT
./metasugarbay/recipeskernel
./metasugarbay/recipeskernel/linux/linuxyocto_git.bbappend
./metasugarbay/README
./metasugarbay/recipesgraphics
./metasugarbay/recipesgraphics/xorgxserver/xserverxf86config_0.1.bbappend
./metasugarbay/recipesgraphics/xorgxserver/xserverxf86config
./metasugarbay/recipesgraphics/xorgxserver/xserverxf86config/xorg.conf
./metasugarbay/recipesgraphics/xorgxserver/xserverxf86lite_1.9.3.bbappend
./metasugarbay/binary
./metasugarbay/conf
./metasugarbay/conf/machine/sugarbay.conf
./metasugarbay/conf/layer.conf

April 13th,

9/

A Machine Configuration

(meta-sugarbay/conf/machine/sugarbay.conf)

TARGET_ARCH="x86_64"
MACHINE_FEATURES="kernel26screenkeyboardpciusbhostext2ext3x86
KERNEL_IMAGETYPE="bzImage"
PREFERRED_PROVIDER_virtual/kernel="linuxyocto"
PREFERRED_PROVIDER_linuxlibcheaders?="linuxlibcheadersyocto"
PREFERRED_PROVIDER_virtual/libx11?="libx11trim"
PREFERRED_PROVIDER_virtual/libgl?="mesadri"
PREFERRED_PROVIDER_virtual/xserver?="xserverxf86drilite"
PREFERRED_PROVIDER_virtual/xserverxf86?="xserverxf86drilite"
XSERVER?="xserverxf86drilite\
xf86inputmouse\
xf86inputkeyboard\
xf86videointel"
MACHINE_EXTRA_RRECOMMENDS="kernelmoduleseeeacpiscripts"
GUI_MACHINE_CLASS="bigscreen"
IMAGE_ROOTFS_SIZE_ext3="2000000"
IMAGE_FSTYPES?="ext3cpio.gz"
MACHINE_ESSENTIAL_EXTRA_RDEPENDS="grub"
PREFERRED_VERSION_grub?="1.98"
SRCREV_machine_pnlinuxyocto_sugarbay?="41ec30ddc42912fec133a533b924e9c56ecda8f9"
SRCREV_meta_pnlinuxyocto_sugarbay?="5a32d7fe3b817868ebb697d2d883d743903685ae"

April 13th,

10/

Selecting and Configuring a Kernel

The Yocto Project supports several kernels (recipes in meta/recipes-kernel)

linux-yocto is the current release's kernel (2.6.37)

linux-yocto-stable is the previous release's kernel (2.6.34)

linux-yocto-dev is the cutting edge (2.6.39-rc1)

All kernels used by the Yocto Project are kernel.org based (plus patches)

No 'single-kernel' lock-in you can use any kernel you want

You can provide a kernel recipe for any kernel and use it (see e.g. laverne)

You can create a git repo usable by the Yocto Project's kernel tools

The -yocto kernels are contained in standalone git repos

The kernel recipes reference the git repos via SRC_URIs:

SRC_URI = "git://git.pokylinux.org/linux-yocto-2.6.37;branch=${KBRANCH}

The kernel for a given machine is actually built from two git branches

The 'machine' branch (KBRANCH above), and the 'meta' branch

April 13th,

11/

The 'Machine' Branch

The machine branch is a base kernel plus patches

Branch names reflect an inheritance hierarchy

yocto/base
yocto/standard/base
yocto/standard/beagleboard
yocto/standard/commonpc64/base
yocto/standard/commonpc64/sugarbay
yocto/standard/commonpc/atompc
yocto/standard/commonpc/base
yocto/standard/crownbay

You derive your machine branch from one of the */base branches

Commit machine-specific patches on top of that

$gitcheckoutbyocto/standard/mymachineyocto/standard/base
$patchp1<mypatch.patch
$gitcommitas

April 13th,

12/

The 'meta' Branch

The meta branch defines 'feature descriptions'

These are compiled and executed to produce the kernel .config

For example, here are the elements of the 'logbuf' feature:

The size-normal.cfg file contains a 'config fragment':

CONFIG_LOG_BUF_SHIFT=16

The size-normal.scc file contains a feature command to execute:

kconfnonhardwaresizenormal.cfg

The top-level .scc file adds it by including the feature:

includefeatures/logbuf/sizenormal.scc

Each 'include features/x' appends another cfg fragment

The config options up the inheritance hierarchy are also added

The end result is the .config used to build the kernel

April 13th,

13/

Tying It All Together

The final step is to tell the BSP about the machine branch

Recall the SRC_URI from the kernel recipe:

KBRANCH=${KMACHINE}
SRC_URI="git://git.pokylinux.org/linuxyocto2.6.37;protocol=git;
branch=${KBRANCH},meta;name=machine,meta

In the layer, 'append' the machine branch to the recipe:

$catmetasugarbay/kernelrecipes/kernel/linuxyocto_git.bbappend
COMPATIBLE_MACHINE_sugarbay="sugarbay"
KMACHINE_sugarbay="yocto/standard/commonpc64/sugarbay"

The actual machine branch is named by KMACHINE

The kernel tools know where in 'meta' to start .config

At the top-level feature .scc with a matching scc_leaf

Machine + meta + kernel recipe + bitbake + kernel tools --> kernel

April 13th,

14/

Adding Graphics Capabilities

Yocto provides an extensive set of X recipes

Enabling X means selecting the right components

The machine configuration defines its set of XSERVER components:

XSERVER ?= "xserver-xf86-dri-lite xf86-input-mouse xf86-input-keyboard \
xf86-video-intel mesa-dri mesa-dri-driver-i915"

There are several possible implementation choices for each component

'virtual/xserver-xf86' - several different implementation choices for each component

xserver-xf86-dri-lite is one implementation, which adds enable-dri

xserver-xf86-lite is another 'lite' implementation that removes dri

xserver-kdrive is yet another, that uses enable-kdrive

Need matching kernel graphics options

As with any other kernel option, use or create a kernel feature
includefeatures/i915/i915.scc

Now that we have Yocto running on our machine, let's build our application!

April 13th,

15/

Layers

April 13th,

16/

Application Layer on the BSP layer

Suppose we're working on a project to create a Media

Server Demo
We're going to use the Yocto Project Build System
We know we'll need a custom image definition for our
product, and a layer to keep our changes in, let's start
there

April 13th,

17/

Media Server Layer Demo

Network Attached
Storage

Router Station Pro

MIPS 24Kc
NFS

uPnP
Audio Renderer

Content Directory

Video Renderer

Beagleboard
OMAP ARMv7

PPC 8513
E300

SandyBridge
Atom e660

Rygel (uPNP)

MediaTomb

Rygel (uPNP) / Clutter

Control Point

Acer Netbook
Atom N270
Rygel / Sato

Yocto running on 4 architectures

Streams audio & video from NAS over uPnP

Runs Yocto 1.0 with the Demo Layer out of the box

April 13th,

18/

conf/layer.conf
#Defaulttofirstdisk/firstpartitionontheRouterStationPro
RSP_ROOT?="sda1"
#RSP_ROOT?="sda2"
#Wehaveaconfandclassesdirectory,addtoBBPATH
BBPATH:="${BBPATH}:${LAYERDIR}"
#Wehaveanimagesandvariousrecipe*directories,addtoBBFILES
BBFILES:="${BBFILES}${LAYERDIR}/images/*.bb$
{LAYERDIR}/images/*.bbappend${LAYERDIR}/recipes*/*/*.bb$
{LAYERDIR}/recipes*/*/*.bbappend"
BBFILE_COLLECTIONS+="demo"
BBFILE_PATTERN_demo:="^${LAYERDIR}/"
BBFILE_PRIORITY_demo="6"
#SetuptheaudiomixerfortheBeagleboardxM
MACHINE_EXTRA_RRECOMMENDS_append_beagleboard+="bbxmaudio"

April 13th,

19/

Configure bblayers.conf

The build/conf/bblayers.conf needs to know where to

find the new layer
# LCONF_VERSION is increased each time
build/conf/bblayers.conf
# changes incompatibly
LCONF_VERSION = "4"
BBFILES ?= ""
BBLAYERS = " \
/yocto/poky/meta \
/yocto/elc/layers/bsp \
/yocto/elc/layers/demo \
"

April 13th,

# BSP Layer
# Demo Layer

20/

DLNA Library gupnp-dlna_0.5.0.b

b
DESCRIPTION="AutilitylibraryforvariousDLNArelated
functionalityusefulforDLNAMediaServerimplementations."
HOMEPAGE="http://www.gupnp.org/"
LICENSE="LGPLv2.1+"
LIC_FILES_CHKSUM=\

file://COPYING;md5=4fbd65380cdd255951079008b364516c\
file://libgupnpdlna/gupnpdlna
discoverer.c;endline=20;md5="

DEPENDS="gupnpgstreamergstpluginsbase"
PR="r0"
SRC_URI="http://gupnp.org/sites/all/files/sources/${PN}$
{PV}.tar.gz"
SRC_URI[md5sum]="c97ffbada5cb9f700d910995fab6ab46"
SRC_URI[md256sum]=<sha256sum>
inheritautotoolspkgconfig
April 13th,

21/

MediaTomb - mediatomb_0.12.1.bb
DESCRIPTION="MediaTombUPnPAVMediaServerforLinux"
HOMEPAGE="http://mediatomb.cc/"
LICENSE="GPLv2"
LIC_FILES_CHKSUM=
"file://COPYING;md5=0b609ee7722218aa600220f779cb5035\

file://src/main.cc;beginline=14;endline=25;md5=<md5sum>"
DEPENDS="expatffmpegsqlite3libexifjszlibfileid3lib
ffmpegthumbnailercurl
PR="r1"
SRC_URI="${SOURCEFORGE_MIRROR}/mediatomb/mediatomb${PV}.tar.gz\
file://youtube_warning.patch\
file://init\
file://default\
file://config.xml\
"
inheritautotoolspkgconfigupdaterc.d
INITSCRIPT_NAME="mediatomb"
INITSCRIPT_PARAMS="defaults90"
April
13th,

22/

MediaTomb (cont)
EXTRA_OECONF="disablemysqldisablerplmallocenablesqlite3enable
libjs\
enablelibmagicenableid3libenablelibexifenableinotify\
enabledbautocreatedisablelargefilewithsqlite3h=$
{STAGING_INCDIR}\
withsqlite3libs=${STAGING_LIBDIR}\
withmagich=${STAGING_INCDIR}\
withmagiclibs=${STAGING_LIBDIR}\
withexifh=${STAGING_INCDIR}\
withexiflibs=${STAGING_LIBDIR}\
withzlibh=${STAGING_INCDIR}\
withzliblibs=${STAGING_LIBDIR}\
withjsh=${STAGING_INCDIR}/js\
withjslibs=${STAGING_LIBDIR}\
withid3libh=${STAGING_INCDIR}\
withid3liblibs=${STAGING_LIBDIR}\
withffmpegh=${STAGING_INCDIR}\
withffmpeglibs=${STAGING_LIBDIR}\
withsearch=${STAGING_DIR_HOST}${prefix}/local\
ac_cv_header_sys_inotify_h=yes"
SRC_URI[md5sum]="e927dd5dc52d3cfcebd8ca1af6f0d3c2"
SRC_URI[sha256sum]=
"31163c34a7b9d1c9735181737cb31306f29f1f2a0335fb4f53ecccf8f6
April 13th,
23/
2f11cd"

Creating an Image

IMAGE_INSTALL

List tasks and packages to install to create image

IMAGE_FEATURES

Used to further customize what's installed in the image

Maps to additional tasks or packages

-dev or -dbg packages

Tasks - arbitrary groups of software, useful when

creating several similar images. i.e.

A companies proprietary/value-add software

All software from a project

Graphics / UI

Standards

April 13th,

24/

Task Example task-poky-nfs.bb

DESCRIPTION="NFStasksforPoky"
LICENSE="MIT"
LIC_FILES_CHKSUM="file://${POKYBASE}/LICENSE;md5=<md5sum>\
file://${POKYBASE}/meta/COPYING.MIT;md5=<md5sum>"
PR="r0"
PACKAGES="\
taskpokynfsserver\
taskpokynfsserverdbg\
taskpokynfsserverdev\
"
ALLOW_EMPTY="1"
RDEPENDS_taskpokynfsserver="\
nfsutils\
"
#rpcinfocanbeusefulbutonlywithglibcimages
GLIBC_DEPENDENCIES="glibcutils"
RRECOMMENDS_taskpokynfsserver_append_linux="${GLIBC_DEPENDENCIES}"
RRECOMMENDS_taskpokynfsserver_append_linuxgnueabi="${GLIBC_DEPENDENCIES}"

April 13th,

25/

MediaTomb Image - poky-image-mediatomb.bb

#
#Copyright(C)2010IntelCorporation.
#
requirerecipescore/images/pokyimageminimal.bb
SRC_URI="file://interfaces"
IMAGE_INSTALL+="dropbearmediatombtaskpokynfsserver"
LICENSE="MIT"
ROOTFS_POSTPROCESS_COMMAND+="setup_target_image;"
#Manualworkaroundforlackofautoeth0(seebug#875)
setup_target_image(){
installm0644${WORKDIR}/interfaces$
{IMAGE_ROOTFS}/etc/network/interfaces
}

April 13th,

26/

poky-image-mediatomb-live.bb
DESCRIPTION = "Bootable Live Media Renderer Image"
require recipes-core/images/poky-image-live.inc
LABELS += "boot install"
ROOTFS = "${DEPLOY_DIR_IMAGE}/poky-image-mediatomb-${MACHINE}.ext3"
LICENSE = "MIT"
do_bootimg[depends] += "poky-image-mediatomb:do_rootfs"

April 13th,

27/

Layers Summary

3 image recipes built for any architecture

All share same set of recipes, just compiled for the
target
Created Layer which contains

Recipes

Tasks

Images

April 13th,

28/

An Image Creator GUI

April 13th,

29/

What does it do?

Select and review software to include in an image

Change some configuration options without having to
edit conf files

MACHINE

Disable GPLv3 recipes

Future

Policy management (distributions, licenses, package format)

Layer management

Build cross-compiler toolchains and development images

Save/load customized configurations

April 13th,

30/

Q&A

April 13th,

31/

Resources

http://www.yoctoproject.org

http://wiki.yoctoproject.org

April 13th,

32/

Legal Information
INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH INTEL
PRODUCTS. EXCEPT AS PROVIDED IN INTEL'S TERMS AND CONDITIONS OF
SALE FOR SUCH PRODUCTS, INTEL ASSUMES NO LIABILITY WHATSOEVER, AND
INTEL DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY RELATING TO SALE
AND/OR USE OF INTEL PRODUCTS, INCLUDING LIABILITY OR WARRANTIES
RELATING TO FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR
INFRINGEMENT OF ANY PATENT, COPYRIGHT, OR OTHER INTELLECTUAL
PROPERTY RIGHT.
Intel may make changes to specifications, product descriptions, and plans at any time,
without notice.
All dates provided are subject to change without notice.
Intel is a trademark of Intel Corporation in the U.S. and other countries.
*Other names and brands may be claimed as the property of others.
Copyright 2009, Intel Corporation. All rights are protected.

April 13th,

33/

April 13th, 2011 - 11:00am

34