Introduction to yocto

Introduction to Yocto
Version 1.2.1
August 2012
Alex González
Digi International

Agenda
Yocto Overview
● Yocto 1.2.1 release System developers
● Yocto components ● Installing the Yocto build tree
● Yocto build system ● Using Yocto for system development
● Yocto Layers ● Yocto build system
● Bitbake recipes ● Yocto configuration
● System development workflow
○ Overview
Application developers ○ Image generation process
● Application Development Kit Overview ○ Image creation
● Yocto standalone toolchain installation ○ Package repository
● Using the toolchain outside of Yocto ○ Yocto Features
● Yocto ADT installer ○ Command line build
● Application development workflow ■ Bitbake commands
● Command line workflow ■ Build times
● Eclipse plug-in for application developers ○ Using Hob
○ Installation ○ Fixing existing applications
○ Configuration ○ Yocto's Kernel Tree
○ Running a Yocto project application ■ Kernel customization
○ Debugging a Yocto project application ■ Kernel patching
○ Bitbake commander ○ Freescale's Yocto kernel
■ The meta-fsl-arm layer
■ Kernel configuration

Yocto Overview
● Open source, collaborative, umbrella project.

● git.yoctoproject.org (98 projects)

● Stable releases every 6 months.

● Suitable both for:
○ System developers
○ Application developers

● Supported by Freescale, Intel, LSI, Wind River, Montavista, Mentor
Graphics, Texas Instruments, Huawei and others.

Yocto 1.2.1 release
The release is available at http://downloads.yoctoproject.org/releases/yocto/yocto-1.2.1/.
It comprises poky denzil 7.0.1, eclipse plugin, toolchains, package sources, packaged package sources (rpm,ipk), a
build appliance, an ADT installer and a set of supported BSP layers.

The structure of poky once untarred:

The most up to date development can be fetched by:

git clone git://git.yoctoproject.org/poky.git

Yocto components
● Poky (Build system)
○ OE-core
○ bitbake
○ Reference BSP metadata (one per arch)
○ meta-yocto
○ Documentation
● ADT eclipse plugin
● Embedded kernel tools
● Pseudo (fakeroot replacement)
● Swabber (Host system access detection)
● Hob (Bitbake GUI)
● Build Appliance (Virtual host image)
● eglibc
● autobuilder (QA and test plans)

Yocto Layers
Overview
Collection of recipes that contain extensions and customizations to base systems.

They are directories to look for recipes and added to BBLAYERS in build/conf/bblayers.conf

Yocto layers
Management
bitbake-layers <command> [arguments]
Layer structure
Where command can be:
meta-<bsp_name>/
meta-<bsp_name>/<bsp_license_file> help
meta-<bsp_name>/README show-layers: Show current configured layers.
meta-<bsp_name>/README.sources show-recipes: List available recipes and its layer parents.
meta-<bsp_name>/binary/<bootable_images> show-overlayed: Show overlayed recipes (duplicated name on
meta-<bsp_name>/conf/layer.conf a higher priority layer)
meta-<bsp_name>/conf/machine/*.conf show-appends: List .bbappend files and their recipe files.
meta-<bsp_name>/recipes-bsp/* flatten: Flattens the layer configuration into a different folder.
meta-<bsp_name>/recipes-core/* This are all layers with overlayed recipes removed and .
meta-<bsp_name>/recipes-graphics/* bbappend files added to their corresponding recipes.
meta-<bsp_name>/recipes-kernel/linux/linux-yocto_<kernel_rev>.
bbappend

Creating your own layers manually
OpenEmbedded layers can be used with Yocto.
● Copy meta-skeleton
● Modify conf/layer.conf.
● Optionally add conf/machine/ and conf/distro/
● Optionally, add new recipes to the recipes-* sub
directories. Use .bbappend to override parts of other
recipes better than pasting recipe code.
● Enable your layer by adding it to conf/bblayers.conf

Or use the yocto-bsp command line tool:

yocto-bsp help
yocto-bsp help create

Bitbake recipes
Each application has one or more bitbake recipe in the different layers. To add a new package to Yocto you need to provide
a .bb recipe for it. You can use any OpenEmbedded recipe as template.

meta/recipes-core/expat/expat_2.1.0.bb
require expat.inc
LIC_FILES_CHKSUM = "file://COPYING;md5=1b71f681713d1256e1c23b0890920874"
PR = "r0"
SRC_URI[md5sum] = "dd7dab7a5fea97d2a6a43f511449b7cd"
SRC_URI[sha256sum] = "823705472f816df21c8f6aa026dd162b280806838bb55b3432b0fb1fcca7eb86"

meta/recipes-core/expat/expat.inc
SUMMARY = "A stream-oriented XML parser library."
DESCRIPTION = "Expat is an XML parser library written in C. It is a stream-oriented parser in which an application registers handlers
for things the parser might find in the XML document (like start tags)"
HOMEPAGE = "http://expat.sourceforge.net/"
SECTION = "libs"
LICENSE = "MIT"
SRC_URI = "${SOURCEFORGE_MIRROR}/expat/expat-${PV}.tar.gz
file://autotools.patch"
inherit autotools lib_package gzipnative
# This package uses an archive format known to have issue with some versions of gzip
do_unpack[depends] += "gzip-native:do_populate_sysroot"
do_configure_prepend () {
rm -f ${S}/conftools/libtool.m4
}

Bitbake classes
Bitbake classes (.bbclass) provide encapsulation and inheritance logic. They abstract common functionality and share
it amongst several recipes.

Class files are placed in a classes directory under the meta or build directory, and are searched for in the BBPATH as
.conf files.

To enable its features it is usually enough to inherit the class. Every .bb recipe inherits the base.bbclass automatically.
It contains definitions of basic tasks as fetching, unpacking, configuring, compiling, installing and packaging. These are
usually overridden by other classes as autotool.bbclass or package.bbclass.

Some important classes are:

autotools.bbclass
distutils.bbclass
update-alternatives.bbclass
devshell.bbclass
update-rc.d.bbclass
package*.bbclass
binconfig.class
kernel.bbclas
pkgconfig.bbclass
image.bbclass
src_distribute.bbclass
rootfs*.bbclass
src_distribute_local.bbclass
sanity.bbclass
cpan.bbclass
insane.bbclass

Bitbake recipes
Multiple providers
If a target has multiple providers, like different kernel or application versions, bitbake defaults to the
higher version. But this selection can be qualified by adding the following to a recipe:

PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"
COMPATIBLE_MACHINE
Stops parsing unless machine listed here.
DEFAULT_PREFERENCE
Relative priority among like-named recipes. Overridden by
PREFERRED_VERSION_*
PREFERRED_VERSION_virtual/kernel = "3.2"

Bitbake recipes
License tracking
LIC_FILES_CHKSUM variable contains checksums of the license text in the source code for the recipe. It's mandatory
for all recipes, unless the LICENSE variable is set to "CLOSED".
LIC_FILES_CHKSUM = "file://COPYING;md5=xxxx
file://licfile1.txt;beginline=5;endline=29;md5=yyyy
file://licfile2.txt;endline=50;md5=zzzz

Commercial licenses
Recipes which contain:
LICENSE_FLAGS = "commercial"
LICENSE_FLAGS = "license_${PN}_${PV}"
Need to have a matching entry in the LICENSE_FLAGS_WHITELIST in local.conf, as:
LICENSE_FLAGS_WHITELIST = "commercial_gst-plugins-ugly"
LICENSE_FLAGS_WHITELIST = "commercial_gst-plugins-ugly license_emgd_1.10"

Application developers

Application developing contents
Application developing
● Application Development Kit Overview
● Yocto standalone toolchain installation
● Using the toolchain outside of Yocto
● Yocto ADT installer
● Application development workflow
● Command line workflow
● Eclipse plug-in for application developers
○ Installation
○ Configuration
○ Running a Yocto project application
○ Debugging a Yocto project application
○ Bitbake commander

Application Development Kit Overview
The application developer can:

● Install standalone Yocto toolchains.

● Use the ADT installer to install per architecture cross toolchains, environment setup scripts
(/opt/poky/1.2.1), a sysroot (configured location f.e ${HOME}/yocto), and QEMU images:

● Or can use the toolchain and sysroot from a Yocto release tarball, what we will call Yocto Project
Build Tree (YPBT).

Yocto standalone toolchain installation
● Download a precompiled tarball.
● Built in the YPBT for deployment:
source oe-init-build-env [optional folder name]
bitbake meta-toolchain-gmae (sato)
bitbake meta-toolchain

Compiles the tarball in tmp/deploy/sdk.

In both cases the tarball is uncompressed in /opt/poky/x.y, the recommended toolchain location.

● Built in the YPBT for internal usage:
1. source oe-init-build-env
2. Edit conf/local.conf for your machine type:
3. bitbake meta-ide-support
4. Repeat the last two steps for several machine types.

The toolchain will be built in the tmp directory.

The sysroot and QEMU images would need to be installed separately.

Using the toolchain outside of Yocto
The toolchain in /opt/poky can be used outside of the Yocto project to build autotools or Makefile
based source, just by sourcing the architecture specific environment setup script before building.

/opt/poky/1.2/environment-setup-${ARCH}-poky-linux

Autotools

configure --host=armv5te-poky-linux-gnueabi --with-libtool-
sysroot=<sysroot-dir>

Makefile

CC=arm-poky-linux-gnueabi-gcc
LD=arm-poky-linux-gnueabi-ld
CFLAGS=”${CFLAGS} --sysroot=<sysroot-dir>”
CXXFLAGS=”${CXXFLAGS} --sysroot=<sysroot-dir>”

Yocto ADT installer
● Download a precompiled release

● Build one from the Yocto Project build tree:

source oe-init-build-env
bitbake adt-installer

Extract anywhere:

tar -xjf adt_installer.tar.bz2
cd adt-installer/
vim adt-installer.conf
./adt_installer

Installs into /opt/poky/x.y the toolchain, sysroot (at the configured location) and QEMU kernel images
(in the adt-installer/download_image/zImage-qemuarm.bin)

Application development workflow
The Eclipse plug in allows you to:
● Custom BSP
○ Copy an existing one
○ Make configuration
changes
○ Make recipe changes
● Compile
● Deploy
● Run
● Debug

Command line workflow
Build the ipk package

bitbake <pkgname>
bitbake package-index

Deploy the package to target's root filesystem

Copy them to a web server and modify the base-feeds.conf file in the target:

/etc/opkg/base-feeds.conf
src/gz all http://www.mysite.com/somedir/deploy/ipk/all

Deploy the package to the sysroot

opkg-cl –f <conf_file> -o <sysroot_dir> update
opkg-cl –f <cconf_file> -o <sysroot_dir> --force-overwrite install <pkgname>
opkg-cl –f <cconf_file> -o <sysroot_dir> --force-overwrite install <pkgname>-dbg
opkg-cl –f <conf_file> -o <sysroot_dir> --force-overwrite install <pkgname>-dev

Eclipse plug-in for application developers
Installation
1) Install the Indigo Eclipse classic (does not work in Juno)

2) Update with:

http://download.eclipse.org/releases/indigo
Programming Languages -> Autotools Support for CDT
Programming Languages -> C/C++ Development Tools
Linux Tools -> LTTng - Linux Tracing Toolkit
http://download.eclipse.org/tm/updates/3.3
TM and RSE Main Features
TM and RSE Optional Add-ons -> Every item except "RSE Unit Tests and RSE WinCE Services"
http://download.eclipse.org/tools/cdt/releases/indigo
CDT Main Features
CDT Optional Features -> C/C++ Remote Launch and Target Communication Framework.
http://downloads.yoctoproject.org/releases/eclipse-plugin/1.2.1
Development tools and SDKs for Yocto Linux

Configuration
Windows -> Preferences -> Yocto ADT (also per project configuration)

Selecting the Toolchain Type:

Standalone Pre-built Toolchain: Toolchain and sysroot installed separately, without the Yocto Project build tree.
Build System Derived Toolchain: Toolchain built as part of the Yocto Project build tree.

Toolchain: For standalone prebuilt toolchain use /opt/poky/x.y , otherwise, point to the Yocto's project build/tmp
directory
Sysroot: Point to the place where the rootfs for the target is created by the ADT installer. Used by QEMU, the NFS
boot process and the x-toolchain. Otherwise, the YBPT installs it in build/tmp.
Target architecture: Chose from the dropdown box.
QEMU: For a build system derived toolchain, the kernel will be in tmp/deploy/images. Otherwise, it's in the directory
specified to he ADT installer to download the image, by default adt_installer/download_image/zImage-qemuarm.bin.

Project -> "Change Yocto Project Settings" can change the toolchain configuration per project.

Running a Yocto project application
Creating a project

File -> New -> C/C++ project -> Yocto ADT project

Can be based in both autotools or Makefiles. We will use a
"Hello World ANSI C Autotools" sample project.

Running an example application

Compile and test in QEMU, Run -> Externals tools ->
qemu_armv5te-poky-linux-gnueabi

Open a terminal and run ifconfig to get its IP address.

In Run Configurations create a new C/C++ remote
application with a TCF (Target Communication Framework)
connection to QEMU's IP address. The run the configuration:

root@qemuarm:/# /bin/HelloWorld;exit
Hello World
logout

Debugging a Yocto project application
● Place a breakpoint in main().
● Debug Configuration->C/C++ Remote applications, click Debug.
The debug perspective appears with the application executed in QEMU.

For this to work the target image needs to contain a TCF agent service, which is added to an image as part of the tools.
debug feature.

Bitbake Commander
Allows you to add and modify the project's layers. Once the metadata project is created, we can modify it as
follows:
As general rules:
1. File -> New -> Yocto BitBaker Commander -> Bitbake
● You never change the metadata from upstream
recipe
(unless you are submitting a bug report upstream)
2. Point SRC_URI to the package source.
● You always use additional layers to make your own
3. Click populate to auto complete some fields, and complete
changes.
"Description" and "License" fields.
When creating a new Yocto Project, you can point it to an 4. Project -> Launch Hob
existing YPBT, or you can instruct it to clone one from the 5. Choose the build directory to place the final images. (Not
upstream Yocto project in a new location (not the Eclipse the YPBT, just an output folder)
workspace). 6. Use Hob to customize and build your own images.
YoctoProjectTools -> yocto-bsp allows to create a new
layer.

System developers

System developing contents
System developers
● Installing the Yocto build tree
● Using Yocto for system development
● Yocto build system
● Yocto configuration
● System development workflow
○ Overview
○ Image generation process
○ Image creation
○ Package repository
○ Yocto Features
○ Command line build
■ Bitbake commands
■ Build times
○ Using Hob
○ Fixing existing applications
○ Yocto's Kernel Tree
■ Kernel customization
■ Kernel patching
○ Freescale's Yocto kernel
■ The meta-fsl-arm layer
■ Kernel configuration

Installing the Yocto build tree
1. Development host machine setup
2. Yocto installation:

● Download Yocto release as tarball (for supported platforms)
● Clone from git repositories

○ Clone the Yocto project build tree (YPBT)
git clone git://git.yoctoproject.org/poky
Initialized empty Git repository in ${USER}/poky/.git/

● Clone the Yocto Linux kernel
A bare (allow pushes) local repository:
git clone --bare git://git.yoctoproject.org/linux-yocto-3.2 linux-yocto-3.2.git
A local working copy:
git clone linux-yocto-3.2.git my-linux-yocto-3.2-work
The Yocto project metadata needed to modify and build kernel images.
git clone git://git.yoctoproject.org/poky-extras poky-extras
Initialized empty Git repository in ${USER}/poky/poky-extras/.git/

● Clone the BSP layer:
git clone git://github.com/Freescale/meta-fsl-arm.git
Initialized empty Git repository in ${USER}/poky/meta-fsl-arm/.git/

Using Yocto for system development
● The Yocto Project build tree is f.e located at /usr/local/yocto-1.2
● We initialize an environment for our project:
source oe-init-build-env $HOME/ccwmx53
● The initial project contents are:
~/ccwmx53$ find
./conf/bblayers.conf
./conf/local.conf
● We would edit local.conf and add layers to bblayers.conf
● Run bitbake to build:
bitbake <target>, f.e bitbake core-image-minimal
● Find the build output in deploy/images

Using local source mirrors

Downloading all sources is time consuming so you probably only what to do it once. To use a local mirror, after a
complete build move the sources and edit your local.conf file to include:
SOURCE_MIRROR_URL ?= "file://path_to_local_mirror"
INHERIT += "own-mirrors"
BB_GENERATE_MIRROR_TARBALLS = "1"
To make sure you can build without network access you can add:
BB_NO_NETWORK = "1"

Yocto configuration
● Local user defined:
build/conf/local.conf

MACHINE
BB_NUMBER_THREADS
PARALLEL_MAKE
DL_DIR

● Policy
meta-yocto/conf/distro/poky.conf

● Machine specific
meta-bsp/conf/machine/imx51evk.conf

System development workflow
Overview
● Image creation
○ Adding existing packages to image
■ Adding a Yocto feature
○ Creating a custom image
○ Adding new packages to Yocto
○ Fixing existing applications workflow

● Kernel development
○ Source modifications
○ Configuration changes

Note that Yocto does not seem to support bootloader development.

Image generation process
Recipes do:
● fetch package sources
● patch
● configure
● compile
● package.

Shared state caching (Or using checksum information during the build)
Bitbake uses a per-task state caching system and not per recipe. It checksums the tasks inputs and rerun the
task if they have changed. This is called the basehash. A master checksum add the basehash and the
hashes of the task's dependencies.

The shared state code looks in SSTATE_DIR (local) and SSTATE_MIRRORS (network) for shared state
files. The state validity is detected looking at its name as the task checksum is there. If it's valid, it downloads
it and uses it to accelerate the task.

Image creation DESCRIPTION = "My Custom Tasks"

PACKAGES = "
Images can be customized in the build/local.conf file: task-custom-apps
task-custom-apps-dbg
Adding packages to the image: task-custom-apps-dev
task-custom-tools
IMAGE_INSTALL = "task-core-x11-base package1 package2" task-custom-tools-dbg
inherit core-image task-custom-tools-dev
IMAGE_INSTALL_append = " sysfsutils" [note the leading space] "
RDEPENDS_task-custom-apps = "
Or by adding a new task (see right box), using meta/recipes-core/tasks/task- dropbear
core-boot.bb as an example. portmap
psplash"
And then adding it to the image : RDEPENDS_task-custom-tools = "
oprofile
IMAGE_INSTALL_append " task-custom-apps task-custom-tools" oprofileui-server
lttng-control
lttng-viewer"
RRECOMMENDS_task-custom-tools = "
kernel-module-oprofile"

Package repository

Images are generated from the
packages for:

● Target rootfs images
● QEMU rootfs images
● Sysroots for application
development

Newer packages can be generated to
update both sysroots and target root
filesystems.

Yocto Features
Yocto introduces features as a mechanism to group recipes by logical function. Features can be
selected by the distribution or at image creation time.

● Distribution can select which features they want to support via:

DISTRO_FEATURES
MACHINE_FEATURES

Some distribution feature example are alsa, bluetooth, ext2, usbgadget, usbhost, wifi, nfs, ipv6 ,
toucshcreen etc

● Images can be configured with:

IMAGE_FEATURES
EXTRA_IMAGE_FEATURES

Some image feature example are x11-base, x11-sato, nfs-server,package-management, tools-debug
etc

Command line build
Build Debugging
Prepare for build
source oe-init-build-env [build_dir] Enable debug output:
bitbake -DDD -v targetname
where typically build_dir represents a target.
Log file for shell tasks:
${WORKDIR}/temp/log.do_taskname.pid
Launch build
Corresponding to the bitbake tasks in run.do_taskname.pid
bitbake <target> [-k]
The -k or --continue option instructs bitbake to go Adding logging to recipes (meta/classes/logging.bbclass)
ahead and build all dependencies even if there are
failures. Python: bb.fatal, bb.error, bb.warn, bb.note, bb.plain, and bb.
Common targets can be found in: debug
Bash: bbfatal, bberror, bbwarn, bbnote, bbplain, and bbdebug.
○ meta/recipes-core/images
○ meta/recipes-sato/images
No dependency build
And also in:
● meta/recipes-extended/images bitbake -b <somepath/somefile.bb>
● meta/recipes-qt/images
● meta/recipes-graphics/images Show environment information
● meta/recipes-rt/images
Shows current and preferred version of packages.
bitbake --show-versions
Explained in the Yocto project documentation.
Shows global or per-package environment
bitbake --environment
Build results in tmp/deploy/images
bitbake --environment <package name>
bitbake --environment -b <recipename>

Bitbake commands
Some usual commands:

bitbake <pkgname> -c listtasksTasks available for a package/recipe
bitbake <pkgname> -c rebuild -f Clean and build again a package
bitbake <pkgname> -c fetch -f Download again the source program
bitbake <pkgname> -c devshell Expand a gnome xterm ready to raise commands
bitbake <pkgname> -c clean/compile Clean or compile package.
bitbake <pkgname> Build package (including creating package)
bitbake package-index Make package index files for feeds
bitbake <target_image> Build image contains task-base packages.
bitbake <target_image> -c buildall -f Build pending packages for target_image
bitbake <target_image> -c rootfs -f Populate rootfs again for target_image
bitbake -e <pkgname> | grep ^S= Finds the source code.
bitbake -e <target> | grep ^WORKDIR= Finds bitbakes's working directory.
bitbake -e <image-target> | grep ^IMAGE_FSTYPES=Finds the image types being build.

bitbake -g -u depexp<target_image> Dependency explorer UI

More details on the bitbake manual.

Build times
On an Intel(R) Core(TM)2 Quad CPU Q9650 @ 3.00 ● First build (all sources local)
GHz
Total time: 1h 6mins

Build configuration
● Build, no clean
Total time: 1min 30secs
build/local.conf
BB_NUMBER_THREADS = "4"
● Clean, then rebuild
PARALLEL_MAKE = "-j 4"
○ Remove build directory
MACHINE ??= "qemuarm"
Same as first build above.
○ Remove only build output /tmp (keeps
● Download source first downloaded sources and state)
bitbake -c fetchall core-image- Total time: 8 mins.
minimal
● Then build
bitbake core-image-minimal

Using Hob
Hob is a GUI for bitbake.

It allows to build for different machine types
as well as:

● Adding layers
● Choose image type
● Add/remove individual recipes and
tasks
● Select output image types, packaging
format, etc

Fixing existing applications
● Find the path to the temporary source code for your ● Generate the patch
package.
git format-patch HEAD~1
bitbake -e <target> | grep ^S=
● Copy the patch to a "files" folder in the same directory
● Change to that path and create a local git repo as the recipe.
git init ● Add it to Yocto:
git add * SRC_URI += "file://my_changes.patch"
git commit ● Increment the Package revision number (PR)
● Clean:
● Edit files
● Test your changes bitbake -c clean -f <pkgname>
bitbake -c compile -f <pkg_name> bitbake -c cleanall -f <pkgname>
● Commit your changes
git status
git add file1.c file2.c file3.c
git commit

Yocto's Kernel Tree
The Yocto kernel team has its own set of processes and tools. The Yocto
kernel tree is structured as follows:

● Once the Yocto kernel branches
from kernel.org, BSPs and custom
features are all in branches.

● Once it's released, new features
are backported on a process
named "upward revision" (uprev).

● The kernel build system compiles
a list of KERNEL_FEATURES,
producing a series of meta
directories to apply to the base
tree.

● The released Yocto kernel tree is a
combination of all supported
boards and configurations.

Yocto's kernel tree
Kernel customization
● Create a new layer copying an existing layer or using the yocto-
bsp command line tool.
yocto-bsp create custom arm

● Add it to bblayers.conf

● The template left by yocto-bsp leaves a set of .cfg files to add
configuration variables.

● It also leaves .scc files to add kernel features to.

● The meta-fsl-arm kernel does not yet use the same .cfg and .scc
files, and does not use the Yocto kernel project tool.

Yocto's kernel tree
Kernel patching
● Kernel patches can be manually added/removed.
● Or we can use the yocto-kernel command line tool.

yocto-kernel patch add custom ~/test.patch
Added patches:
test.patch
yocto-kernel patch list custom
The current set of machine-specific patches for myarm is:
1) test.patch

● It also works for configuration fragments:

yocto-kernel config add custom CONFIG_MISC_DEVICES=y
Added items:
CONFIG_MISC_DEVICES=y
yocto-kernel config list custom
The current set of machine-specific kernel config items for myarm is:
1) CONFIG_MISC_DEVICES=y

Yocto's kernel tree
Bitbake tasks
do_fetch ● Listed by:
do_unpack
do_kernel_checkout bitbake -c listtasks virtual/kernel
do_validate_branches
● Re-ran by:
do_patch
do_kernel_configme bitbake virtual/kernel -c task
do_populate_llic
do_configure ● To streamline the kernel configuration, run iteratively:
do_kernel_configcheck
do_compile bitbake virtual/kernel -c configme
do_compile_kernelmodules
bitbake virtual/kernel -c kernel_configcheck
do_sizecheck
do_uboot_mkimage
do_kernel_link_vmlinux
do_compile_perf
do_install
do_install_perf
do_package
do_deploy

Freescale's Yocto kernel
The meta-fsl-arm layer
● Browsable at https://github.com/Freescale/meta-fsl-arm.git
● Contains recipes to build all the components of the FSL BSP, including kernel,
U-Boot and multimedia components.
● imx53qsb.conf
○ includes machine/imx-base.inc
○ includes distro/fsl-default-providers.inc
Defines the preferred providers:
PREFERRED_PROVIDER_virtual/xserver = "xserver-xorg-
lite"
PREFERRED_PROVIDER_virtual/kernel ?= "linux-imx"
PREFERRED_PROVIDER_linux-libc-headers ?= "linux-libc-
headers-imx"
PREFERRED_PROVIDER_u-boot ?= "u-boot"

So bitbake will look for the most recent "linux-imx" recipe from:
● linux-imx_2.6.35.3.bb
● linux-imx_2.6.38.bb
● linux-imx_3.0.15.bb

Taking into account the DEFAULT_PREFERENCE and COMPATIBLE_MACHINE
variables as with all recipes.

So linux-imx_2.6.35.3.bb is chosen in this case.

Freescale's Yocto kernel
Kernel configuration
● The kernel recipe selected contains a defconfig
file
● The do_configure task in:
meta/classes/kernel.bbclass
copies it to .config and runs make oldconfig.

● Kernel patches are kept on the linux-imx-
2.6.35.3 folder and are listed on the SRC_URI of
the linux-imx-2.6.35.3.bb recipe.

● Configuration fragments can also be kept in the
same folder and appended also to SRC_URI.
SRC_URI += "file://i2c.cfg"

● The kernel can be configured with:
source oe-init-build-env
bitbake virtual/kernel -c
menuconfig

This presentation is shared with an Attribution-NonCommercial-ShareAlike 3.0 Unported license.

Introduction to yocto

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (7)

Similaire à Introduction to yocto

Similaire à Introduction to yocto (20)

Dernier

Dernier (20)

Introduction to yocto