Introduction to Yocto

Version 1.2.1
August 2012
Alex Gonzlez
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 build system
 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"
Introduction to Yocto
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
 Eclipse plug-in for application developers
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.
 Eclipse plug-in for application developers
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
 Eclipse plug-in for application developers
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.
 Eclipse plug-in for application developers
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.
Introduction to Yocto
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 build system
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.

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

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
 System development workflow
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
 Q&A
Thanks for watching!
This presentation is shared with an Attribution-NonCommercial-ShareAlike 3.0 Unported license.