GUT � Intel 2015/16 1/67

Embedded Systems ProgrammingOS for embedded systems - OpenEmbedded

Iwona Kochanska

Department of Marine Electronic Systems

GUT � Intel 2015/16 2/67

History

OpenEmbedded project - a software framework for creating Linuxdistributions primarily, but not exclusively, for embedded applications.

I OpenZaurus project for Sharp ZaurusPersonal Digital Assistants.

I 2001 - Sharp Corporation introducedthe SL-5000 PDA, named Zaurus(Lineo OS).

I Chris Larson founded the OpenZaurusProject, a replacement Linuxdistribution for the SharpROM, basedon a build system called buildroot.

I January 2003 - a new build system.Chris Larson, Michael Lauer, andHolger Schurig began work onOpenEmbedded.

I March 2011 - OE merged with theYocto project to form the OE-Coreproject.

GUT � Intel 2015/16 3/67

Bitbake and metadata

OE fundamental elements

I BitBake - the build engine (written in Python)

I Metadata - tells BitBake what to do

From OE user's manual:

�unlike single project tools like make [BitBake] is not based on onemake�le or a closed set of interdependent make�les, but collects andmanages an open set of largely independent build descriptions (packagerecipes) and builds them in proper order.�

GUT � Intel 2015/16 4/67

BitBake

Source: P. Raghavan, Amol Lad, Sriram Neelakandan, �Embedded Linux system design and development�

GUT � Intel 2015/16 5/67

BitBake

BitBake interprets recipes and con�guration�les to determine what needs to be built and

how⇓

necessary source code over the network⇓

set of packages and �le system images

.

GUT � Intel 2015/16 6/67

BitBake

I Implemented in Python.

I Created from Gentoo's emerge tool.

I Fetches sources from the Internet (tarballs, svn, cvs, git...).

I Applies patches, contained in package descriptions.

I Builds the latest version of all components.

I Builds the compiler and crosscompiler versions you speci�ed, as wellas con�guration tools (autoconf...).

I Con�gures, compiles and deploys (copies to the root �lesystem andcreates packages), including the C library.

I Can be used to compile for several architectures in parallel.

I Builds �lesystem images by creating and installing packages;supports several package formats: .rpm, .ipk, .deb

GUT � Intel 2015/16 7/67

Packets in Linux

I deb - shortcut of �Deborah�, the name of ex-wife of Ian Murdock

I Linux Debian GNU/Linux and derived OS (Progeny, Ubuntu, Corel) .I package management software: dpkg.I uses Make�le for bulding process management.

I rpm - shortcut of Red Hat Package Manager.

I Red Hat Linux, Fedora, SUSE, Mandriva, PLD.I package management software: rpm.I uses own tool (rpmbuild) for bulding process management.I macros RPM translated to Make�le recipes.

I ipk (ipkg) - shortcut of Itsy Package Management System

I Debian-based OS for embedded systems (Unslung, OpenWrt,Openmoko, webOS, Gumstix, the iPAQ, QNAP NASes,OpenEmbedded, Yocto Project).

I package management software: opkg (ipkg)

GUT � Intel 2015/16 8/67

Bitbake - building the image

Source: www.denx.de/wiki/

GUT � Intel 2015/16 9/67

Metadata

Four categories of Metadata:

I Recipes (*.bb)� the most common form of metadata. A recipeprovides instructions for BitBake to build a single package. Itdescribes the package, its dependencies, and any special actionsrequired to build it

I Classes (*.bbclass)�perform a role similar to that of classes inobject-oriented programming languages like C++. They encapsulatecommon functionality across a large number of recipes (autotools,cross compilers, ...).

I Tasks�used to group packages into a root �le system, for example.Tasks are usually relatively simple, consisting of a few lines ofpackage dependencies.

I Con�guration (*.conf)�de�nes the overall behavior of BitBake(local con�guration, machine/distro con�guration).

GUT � Intel 2015/16 10/67

Starting with OpenEmbedded

I Getting OpenEmbedded:git clone git://git.openembedded.org/openembedded-core

I Getting BitBake (to openembedded-core directory):git clone git://github.com/openembedded/bitbake

I Con�guring OpenEmbedded:http://docs.openembedded.org/usermanual/html/gettingoe_con�guring_oe.html

GUT � Intel 2015/16 11/67

Workspace directory layout

my_OE/|−− bitbake|−−−− bin|−−−− ...|−− OE.mtn`−− openembedded|−− _MTN ==> special Monotone directory|−− classes|−− conf|−− contrib|−− �les|−− packages ==> package rule �les, bitbake recipes|−−−− tasks/ ==> base tasks, useful tasks groups in �le recipes|−−−− conf|−−−− machine/ ==> machine rule �les|−−−− distro/ ==> distro rule �les|−− site

GUT � Intel 2015/16 12/67

Setting up environment

The bitbake tool should be accessible with execution path. Specialvariable BBPATH, and BBFILES, for OE uses should be set:

$ export PATH=$PATH:${HOME}/my_OE/bitbake/bin/$ export BBPATH=${HOME}/my_OE/build:${HOME}/my_OE/openembedded$ export BBFILES=${HOME}/my_OE/openembedded/packages/*/*.bb

In latest OE version the environment can be con�gured withoe-init-build-env �le:

$ source ./oe−init−build−env [<build directory>]

GUT � Intel 2015/16 13/67

Special �le local.conf

Build directory holds a local con�guration �le:

my_OE/−−build/−−−−conf/−−−−−− local.conf

File local.conf - basic con�guration �le which contains any OE variable.The most important ones are:

I MACHINE = "any_available_machine_type"

I DISTRO = "any_available_distro"

OE will use this information as a starting point, making cross compilersfor the target architecture and building a distro based on it.

GUT � Intel 2015/16 14/67

Build distro

The bitbake tool should be accessible with execution path. Specialvariable BBPATH, and BBFILES, for OE uses should be set:

~/my_OE/build$ bitbake helloworld

And we can turn on the favourite TV channel ... ;)

GUT � Intel 2015/16 15/67

Build distro

After this �rst compilation - a new tmp directory that is used by bitbakeas output working directory:

~/my_OE/build/tmp/|−− cache/|−− cross/ ==> cross tools (gcc, ldd, ...)|−− deploy/|−−−− images ==> �nal image �les (cpio, j�s2, ext2, ...)|−−−− ipk ==> �nal packets|−− rootfs/ ==> �nal rootfs layout.|−− staging/ ==> shared items availables for the whole system.|−− stamps/ ==> magnagement stamps.|−− work/ ==> where bitbake uncompress, con�gure, compile, ...

GUT � Intel 2015/16 16/67

Yocto Project

I Yocto - smallest SI unit. As a pre�x, yocto indicates 10^-24.

I Springs from OpenEmbedded.

I Project's core is the Poky build system, created by Richard Purdie

I November 2010 - the Linux Foundation announced that this workwould all continue under the heading of the Yocto Project as a LinuxFoundation-sponsored project.

I Since 2011 - Yocto Project and OpenEmbedded developed as theOE-Core.

GUT � Intel 2015/16 17/67

Yocto components

I Poky - the core of the Yocto Project; the reference build system

I A build appliance; VMware image of a host system ready to useYocto

I An Application Development Toolkit (ADT) installer for your hostsystem

I And for the di�erent supported platforms:

I Prebuilt toolchainsI Prebuilt packaged binariesI Prebuilt images

GUT � Intel 2015/16 18/67

Poky build system

I The purpose of Poky is to build the components needed for anembedded Linux product, namely:

I A bootloader imageI A Linux kernel imageI A root �lesystem imageI Toolchains and software development kits (SDKs) for applicationdevelopment

I The Yocto project makes a new release every six months.

I metadata layers can be added to extend functionality:

I provide an additional software stack for an image type,I add a board support package (BSP) for additional hardwareI represent a new image type.

GUT � Intel 2015/16 19/67

Setting up the host system

For professional developer's workstations, it is recommended to use:

I symmetric multiprocessing (SMP) systems with 8 GB or moresystem memory and a high capacity,

I fast hard drive.

I Build servers can employ distributed compilation.

I Due to di�erent bottlenecks in the build process, there does notseem to be much improvement above 8 CPUs or around 16 GBRAM.

I The �rst build will also download all the sources from the Internet,so a fast Internet connection is also recommended.

GUT � Intel 2015/16 20/67

Setting up the host system

I Yocto is able to run on any Linux system if it has the followingdependencies:

I Git 1.7.8 or greater

I Tar 1.24 or greater

I Python 2.7.3 or greater (but not Python 3)

I Yocto also provides a way to install the correct version of these toolsby either downloading a buildtools-tarball or building one on asupported machine. This allows virtually any Linux distribution to beable to run Yocto, and also makes sure that it will be possible toreplicate your Yocto build system in the future. This is important forembedded products with long-term availability requirements.

I

GUT � Intel 2015/16 21/67

Poky - supported hardware

The Poky build system only supports virtualized QEMU machines for thefollowing architectures:

I ARM (qemuarm)

I x86 (qemux86)

I x86-64 (qemux86-64)

I PowerPC (qemuppc)

I MIPS (qemumips, qemumips64)

GUT � Intel 2015/16 22/67

Poky - supported hardware

It also supports some reference hardware Board Support Packages(BSPs):

I Texas Instruments Beaglebone (beaglebone)

I Freescale MPC8315E-RDB (mpc8315e-rdb)

I Intel x86 based PCs and devices (genericx86 and genericx86-64)

I Ubiquiti Networks EdgeRouter Lite (edgerouter)

To develop on di�erent hardware, additional hardware-speci�c Yoctolayers are needed.

GUT � Intel 2015/16 23/67

Poky's layers

Poky contains three metadata directories:

I meta: contains the OpenEmbedded-Core metadata, which supportsthe ARM, x86, x86-64, PowerPC, MIPS, and MIPS64 architecturesand the QEMU emulated hardware.

I meta-yocto: contains Poky's distribution-speci�c metadata.

I meta-yocto-bsp: contains metadata for the reference hardwareboards.

Poky also contains a emplate metadata layer, meta-skeleton, that canbe used as a base for new layers.

GUT � Intel 2015/16 24/67

Poky build directory

I sourcing oe-init-build-env script:

I sets the environment variables,I creates the con�guration �les,I checks the minimal resources for building the image

I the script call the scripts/oe-setup-builddir script inside the pokydirectory to create the build directory. On creation, the builddirectory contains a conf directory with three �les:

I bblayers.conf: lists the metadata layers to be considered for thisproject.

I local.conf: contains the project-speci�c con�guration variables.I templateconf.cfg: contains the directory that includes the templatecon�guration �les used to create the project. By default it uses theone pointed to by the templateconf �le in your Poky installationdirectory, which is meta-yocto/conf by default.

GUT � Intel 2015/16 25/67

Example of bblayers.conf

# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf# changes incompatiblyLCONF_VERSION = "4"BBFILES ?= ""BBLAYERS = " \/home/e�anagan/poky/meta \/home/e�anagan/poky/meta−yocto \/home/e�anagan/poky/meta−intel/crownbay \/home/e�anagan/poky/meta−x32 \/home/e�anagan/poky/meta−baryon\ /h

GUT � Intel 2015/16 26/67

Example of layer.conf

After initial parsing of bblayers.conf BitBake parses conf/layer.conf.From here it adds additional recipes, classes and con�guration to thebuild.layer.conf:

# Layer con�guration for meta−baryon layer# Copyright 2011 Intel Corporation# We have a conf directory, prepend to BBPATH to prefer our versionsBBPATH := "${LAYERDIR}:${BBPATH}"# We have recipes−* directories, add to BBFILESBBFILES := "${BBFILES} ${LAYERDIR}/recipes−*/*/*.bb ${LAYERDIR}/recipes−*/*/*.bbappend"BBFILE_COLLECTIONS += "meta−baryon"BBFILE_PATTERN_meta−baryon := "^${LAYERDIR}/"BBFILE_PRIORITY_meta−baryon = "7"

GUT � Intel 2015/16 27/67

Poky build process

I During the creation of the image, BitBake parses its con�guration,include any additional layers, classes, tasks or recipes de�ned, andbegin by creating a weighted dependency chain. This processprovides an ordered and weighted task priority map.

I BitBake uses this map to determine what packages must be built inwhich order so as to most e�ciently ful�ll compilation dependencies.

I Tasks needed by the most other tasks are weighted higher, and thusrun earlier during the build process.

I The task execution queue for our build is created.I BitBake stores the parsed metadata summaries and if, on subsequentruns, it determines that the metadata has changed, it can re-parseonly what has changed.

GUT � Intel 2015/16 28/67

Poky build process

TASK DESCRIPTION FUNCTION

Fetch getting the sources do_fetch()Unpack unpack the sources do_unpack()Patch applying patches do_patch()

Con�gure con�guring the source tree do_con�gure()Compile compilation of the sources do_compile()Stage installation in stage space do_stage()Install installation do_install()Package building the package do_package()

GUT � Intel 2015/16 29/67

Poky build process

I The compiled source is then split up into packages and variouscalculations are made on the compilation result such as the creationof debug package information.

I The split packages are then packaged into a supported packageformat; RPM, ipk and deb are supported. BitBake will then usethese packages to build the root �le system.

GUT � Intel 2015/16 30/67

Poky build system concepts

I Every aspect of a build is controlled by metadata.

I Metadata can be loosely grouped into package recipes orcon�guration �les.

I A package recipe is a collection of non-executable metadata used byBitBake to set variables or de�ne additional build-time tasks.

I contains �elds such as the recipe description, the recipe version, thelicense of the package and the upstream source repository.

I may also indicate that the build process uses autotools, make,distutils or any other build process, in which case the basicfunctionality can be de�ned by classes it inherits from the OE-Corelayer's class de�nitions in ./meta/classes.

I additional tasks can also be de�ned, as well as task prerequisites.BitBake also supports both _prepend and _append as a method ofextending task functionality by injecting code indicated by usingprepend or append su�x into the beginning or end of a task.

GUT � Intel 2015/16 31/67

Poky build system concepts

I Con�guration �les can be broken down into two types.

I con�guration of BitBake and the overall build run,

I con�guration of various layers Poky uses to create di�erentcon�gurations of a target image.

I A layer is any grouping of metadata that provides some sort ofadditional functionality. For example:

I BSP for new devices,I additional image typesI additional software outside of the core layers.

I meta-yocto - the core Yocto Project metadata; a layer applied ontop of the OE-Core metadata layer, meta which adds additionalsoftware and image types to the OE-Core layer.

GUT � Intel 2015/16 32/67

Poky layers

Source: http://www.aosabook.org/en/yocto.html

GUT � Intel 2015/16 33/67

BitBake's Interprocess Communications (IPC)

I Core BitBake executable: bitbake/bin/bake

I Initially, BitBake had no concept of a client-server. This functionalitywas factored into the BitBake design over a period of time in orderto allow BitBake to run multiple processes during a build, as it wasinitially single-threaded, and to allow di�erent user experiences.

I All Poky builds are begun by starting a user interface instance. UIprovides a mechanism for:

I logging of build output, build status and build progress,I receiving events from build tasks through the BitBake event module.

I The default user interface used is knotty, BitBake's command lineinterface.

I Additional (graphical) user interface: Hob. is Hob. Brings theability to modify con�guration �les, add additional layers andpackages, and fully customize a build.

GUT � Intel 2015/16 34/67

BitBake - Hob

GUT � Intel 2015/16 35/67

BitBake's Interprocess Communications (IPC)

I BitBake user interfaces have the ability to send commands to theBitBake server module.

I Like the user interface, BitBake also supports multiple di�erentserver types, such as XMLRPC. The default server that most usersuse when executing BitBake from the knotty user interface isBitBake's process server. After bringing up the server, the BitBakeexecutable brings up the cooker.

I The cooker manages the parsing of metadata, initiates thegeneration of the dependency and task trees and manages the build.

I Once the cooker is brought up from the BitBake executable, itinitializes the BitBake datastore and then begins to parse all ofPoky's con�guration �les. It then creates the runqueue object, andtriggers the build.

GUT � Intel 2015/16 36/67

BitBake architecture

User interface (UI)

⇓process server (IPC)

⇓Cooker⇓

DataSmart⇓

Parsing the con�guration �les⇓

Runqueue object⇓

Scheduler

GUT � Intel 2015/16 37/67

BitBake DataSmart module

I The DataSmart module, which uses the COW dictionary, stores thedata from the initial Poky con�guration, data from .conf �les and.bbclass �les, in a dict as a data object.

I Each of these objects can contain another data object of just the di�of the data.

I If a recipe changes something from the initial data con�guration,instead of copying the entire con�guration in order to localize it, adi� of the parent data object is stored at the next layer down in theCOW stack.

I When an attempt is made to access a variable, the data module willuse DataSmart to look into the top level of the stack. If the variableis not found it will defer to a lower level of the stack until it does�nd the variable or throws an error.

GUT � Intel 2015/16 38/67

Runqueue i Scheduler

I Building the image - hundreds of receipes, each of multiple packagesand tasks connected with dependencies

I BitBake organizes them

I Cooker builds a map of weighted tasks - the runqueue

I full list of packages for building the imageI dependencies chain

GUT � Intel 2015/16 39/67

Runqueue i Scheduler

Recipe

⇓

checking the PREFERRED_PROVIDER or

choosing package provider

⇓

checking DEPENDS and RDEPENDS

⇓

choosing package provider from dependencies

⇓

list of packages and their providers

GUT � Intel 2015/16 40/67

Scheduler - dependencies

I DEPENDS - a build dependency; something we require as aprerequisite so that Poky can build the required package;DEPENDS = "b" in receipe "a": all the �b� adds to the �lesystemis avaiable during �a� con�guration

I RDEPENDS - DS - a runtime dependency; requires that the imagethe package is to be installed on also contains the package listed asan RDEPENDS;RDEPENDS_${PN} = "b" in receipe "a": pacakge �b� is avaiablewhen �a� is built

GUT � Intel 2015/16 41/67

BitBake Scheduler - building the Runqueue

�rst package A found

⇓

list of tasks necessary for building A

⇓

de�ning the weights according to the number of

packages necessary for completing the task

On the basis of Runqueue the BitBake distributes the tasks between thethreads

GUT � Intel 2015/16 42/67

BitBake architecture

Source: Elizabeth Flanagan, �The Architecture of Open Source Applications�

GUT � Intel 2015/16 43/67

Poky images

I List of default Poky images:

$ cd /opt/yocto/poky$ ls meta*/recipes*/images/*.bb

I Most popular are:

I core-image-minimal: minimal image (only console), that includes:

I busybox - basic UNIX toolI sysvinit - �rst process executed once the Linux kernel loadsI udev - device manager for the Linux kernel

I core-image-full-cmdline: console, full hardware support, bashI core-image-lsb: concole image based on Linux Standard BaseI core-image-x11: image with graphical UI (X11)I core-image-sato: image with graphical UI (X11), desktop GNOMEMobile and SATO theme

I core-image-weston: image with protocol Wayland and Westonreference compositor-based image

GUT � Intel 2015/16 44/67

Poky images

Images names can have su�xes:

I dev: image with header �les and libraries for software developement

I sdk: image with complete SDK, that can be used on the targetmachine

I initramfs: initial RAM �le system

GUT � Intel 2015/16 45/67

Build image

Target MACHINE can be de�ned in three ways. Assuming that the targetis the x86 emulator:

1. De�nine MACHINE when bitbake runs:

$ MACHINE=qemux86 bitbake core−image−minimal

2. Export MACHINE to the current shell:

$ export MACHINE=qemux86$ bitbake core−image−minimal

3. Edit conf/local.conf:

# MACHINE ?= "qemux86"

than in the command line:

$ bitbake core−image−minimal

GUT � Intel 2015/16 46/67

Build image

Bitbake analyses �les:

I conf/bblayers.conf: list of layers

I conf/layer.conf: each layer con�guration

I meta/conf/bitbake.conf: BitBake con�guration

I conf/local.conf: building process con�guration,

I conf/machine/<machine>.conf: target machine con�guration(i.e. qemux86.conf)

I conf/distro/<distro>.conf: OS distro con�guration (default -poky.conf)

Next, BitBake parses receipes and dependenciesThe outcome is a set ofinterdependent tasks that BitBake will then execute in order.

GUT � Intel 2015/16 47/67

Build image

I Remove sources and logs after bulding the image - in conf/local.conf�le:

INHERIT += "rm_work"

I Save given sources and logs from removing:

RM_WORK_EXCLUDE += "linux−yocto u−boot"

GUT � Intel 2015/16 48/67

Build image

I Example con�guration �le (default con�guration):local.conf.sample

I Built images in directory:

build/tmp/deploy/images/qemux86

I By default, the images aren't removed from deploy directory. Tochange this (save older versions), in conf/local.conf:

RM_OLD_IMAGE = "1"

I Testing image in QEMU:

$ runqemu qemuarm core−image−minimal

GUT � Intel 2015/16 49/67

Bulding Yocto for Intel Galileo

I Intel provides the �les necessary to build aLinux image

I Documentation:Intel® QuarkTM SoC X1000 Board Support Package (BSP) Buildand Software User Guidehttps://downloadcenter.intel.com/download/23197/Intel-Quark-BSP

I The example is based on Release 1.1 (January 2015)

I Host requirement:

I PC with Linux (64-bit) or Windows 7 (x64). In this example - 64-bitDebian 8.0 (Jessie).

I internet linkI at list 30 GB of disk spaceI serial inteface for communication with Intel Galileo

GUT � Intel 2015/16 50/67

Host software environment

I Required packages:

I Python 2.6 or 2.7 (but not Python 3.x )I GCC and G++ (up to GCC 4.7).I git clientI uuid-dev (uuid = Universally Unique Identi�er)I iasl (iasl = ACPI Source Language Compiler)

I Packages installation:

$ sudo apt−get install build−essential p7zip−ful

I Download BSP sources:https://downloadcenter.intel.com/download/23197/Intel-Quark-BSP

GUT � Intel 2015/16 51/67

Host software environment

I Unpack downloaded �le:

$ 7z x Board_Support_Package_Sources_for_Intel_Quark_v1.1.0.7z

I Download and install EDKII:

$ tar −xvf Quark_EDKII_*.tar.gz$ cd Quark_EDKII*$ ./svn_setup.py$ svn update

I Install OpenSSLpatch(CryptoPkg/Library/OpensslLib/Patch-HOWTO.txt)

I Build bootloader EDKII:

$ ./buildallcon�gs.sh GCC46 QuarkPlatform

GUT � Intel 2015/16 52/67

Build Yocto image

I In new terminal session unpack a layer of Yocto system(meta-clanton_v1.1.0-dirty) and run the script setup.sh whichdownloads from external sources �les needed to build the �le system

$ tar −xvf meta−clanton*.tar.gz # cd meta−clanton*$ ./setup.sh

I Run script initializing the build process:

$ source ./iot−devkit−init−build−env my_build

I Run BitBake:

$ bitbake image−full

and be patient ...

GUT � Intel 2015/16 53/67

Build Yocto image

I Built images are written in:

./tmp/deploy/images/quark/

Theese are:I image-full-quark.ext3 (main �le system)I core-image-minimal-initramfs-quark.cpio.gz (RAM �le system)I bzImage (kernel)I grub.e�I boot (directory)

I Files can be written into empty SD card or USB memory (formattedas EXT3).

GUT � Intel 2015/16 54/67

Record images to the SD card

I Files in tmp/deploy/images/:

I bzImage�wersja-r0-clanton-YYYYMMDDhhmmss.binI core-image-minimal-initramfs-clanton-YYYYMMDDhhmmss.rootfs.cpio.gz

I image-full-clanton-YYYYMMDDhhmmss.rootfs.ext3I modules�wersja-r0-clanton-YYYYMMDDhhmmss.tgzI boot/grub/grub.conf

I Format the SD card:

$ sudo dd if=/dev/zero of=/dev/sdd

I Record the �les as:

I bzImageI core-image-minimal-initramfs-clanton.cpio.gzI image-full-clanton.ext3I boot/grub/grub.conf

GUT � Intel 2015/16 55/67

Building history

I Building history - can be used for checking the packagesdependencies

I Option in conf/local.conf:

INHERIT += "buildhistory"

I Turn on information gathering in local GIT repository:

BUILDHISTORY_COMMIT = "1"

I GIT repository directory - variable BUILDHISTORY_DIR (default:build/buildhistory)

GUT � Intel 2015/16 56/67

Building history

I By default, buildhistory follows all changes in packages, images andSDK. If only images are to be followed, change theBUILDHISTORY_FEATURES variable in conf/local.conf:

BUILDHISTORY_FEATURES = "image"

I Follow the given �le:

BUILDHISTORY_IMAGE_FILES += "/path/to/�le"

GUT � Intel 2015/16 57/67

Building history

For packages the following information is saved:

I version of package and recipe

I dependencies

I packages size

I packages �les

For images the following information is saved:

I build con�guration

I dependency graph

I list of �les of permissions

I list of installed packages

GUT � Intel 2015/16 58/67

Building history

For SDK the following information is saved:

I SDK con�guration

I list of host and target �les

I dependency graphs

I list of installed packages

Reading the build history:

1. Git tools (gitk or git log).

2. buildhistory-di� command

3. Django-1.4-based network interface

GUT � Intel 2015/16 59/67

Building statistics

I Gathering information for optimalization and identi�cation ofbottlenecks.

I For information gathering the buildstats class inheritance is needed:

USER_CLASSES ?= "buildstats"

I BUILDSTATS_BASE variable indicates statistics directory (defaultbuild/tmp/buildstats)

I Gathered information:

I host systemI size and localization of �le systemI building timeI CPU average usageI hard drive statistics

GUT � Intel 2015/16 60/67

Building statistics

Example inforamtion in statistic �le:

I ReadsComp: total number of read operations

I TimeReads: total number of milliseconds spent on read operations

I WritesComp: total number of write operations

I TimeWrite: total number of milliseconds spent on write operations

I TimeIO: total number of milliseconds spent on I/O operations

GUT � Intel 2015/16 61/67

Building statistics

I pybootchartgui.py tool - graphical representation of data fromPoky sources

I Generate bootchart.png in directory /tmp:

$ ../sources/poky/scripts/pybootchartgui/pybootchartgui.pytmp/buildstats/core−image−minimal/ −o /tmp

GUT � Intel 2015/16 62/67

Debugging

I Check whether the �le is present in the layer:

$ �nd −name "*busybox*"

This command recursive search in all layers of pattern "BusyBox".

I Search in receipes:

$ �nd −name "*busybox*.bb*"

I Search �les with variable DISTRO_FEATURES:

$ bitbake −e | grep −w DISTRO_FEATURES

I Find work directory of package or image:

$ bitbake −e <target> | grep ^WORKDIR=

GUT � Intel 2015/16 63/67

Debugging

I BitBake provides devshell, which unpacks the source and appliespatches, and then starts a new terminal session with properly setenvironment variables:

$ bitbake −c devshell <target>

I Inside devshell commands such as con�gure, make and run can beused.

I If the host machine does not have a graphical environment - in theconf / local.conf set the output screen:

OE_TERMINAL = "screen"

GUT � Intel 2015/16 64/67

Debugging

I Bulding error messages are printed in the terminal during the buildprocess.

I Task list for the recipe:

$ bitbake −c listtasks <target>

I Repeat the error (forced building process):

$ bitbake −f <target>

or forced running a given task:

$ bitbake −c compile −f <target>

I Pring packages versions:

$ bitbake −−show−versions

I List of dependencies:

$ bitbake −v <target>

GUT � Intel 2015/16 65/67

Debugging

I Writing dependencies to DOT �le:

$ bitbake −g <target>

to read use the package GraphVizI Some dependencies can be removed from the graph:

$ bitbake −g <target> −I glibcI After printing the dependency �le there are three �les in currentdirectory:

I package-depends.dot: packages dependenciesI pn-depends.dot: receipes dependenciesI task-depends.dot: tasks dependencies

I .dot to .ps conversion:

$ dot −Tps �lename.dot −o out�le.ps

I Printing dependencies data with explorer:

$ bitbake −g −u depexp <target>

GUT � Intel 2015/16 66/67

Error reporting

I A central database errors reported by users:http://errors.yoctoproject.org.

I Report an error to the database with a class report-error:INHERIT += "report-error"

I By default the error information is stored in directorybuild/tmp/log/error-reportDirectory can be changed with ERR_REPORT_DIR variable.

GUT � Intel 2015/16 67/67

References

Elizabeth Flanagan, The Architecture of Open Source Applications,www.aosabook.org

P. Raghavan, Amol Lad, Sriram Neelakandan, Embedded Linuxsystem design and development, Auerbach Publications, 2005