Introduction to YoctoVersion 1.2.1August 2012

Alex GonzálezDigi International

Agenda

Yocto Overview● Yocto 1.2.1 release● Yocto components● Yocto build system● Yocto Layers● Bitbake recipes

Application developers● 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

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

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 releaseThe 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 LayersOverview

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

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

Yocto layersManagement

Layer structure

meta-<bsp_name>/

meta-<bsp_name>/<bsp_license_file>

meta-<bsp_name>/README

meta-<bsp_name>/README.sources

meta-<bsp_name>/binary/<bootable_images>

meta-<bsp_name>/conf/layer.conf

meta-<bsp_name>/conf/machine/*.conf

meta-<bsp_name>/recipes-bsp/*

meta-<bsp_name>/recipes-core/*

meta-<bsp_name>/recipes-graphics/*

meta-<bsp_name>/recipes-kernel/linux/linux-yocto_<kernel_rev>.bbappend

OpenEmbedded layers can be used with Yocto.

bitbake-layers <command> [arguments]

Where command can be:

helpshow-layers: Show current configured layers.show-recipes: List available recipes and its layer parents.show-overlayed: Show overlayed recipes (duplicated name on a higher priority layer)show-appends: List .bbappend files and their recipe files.flatten: Flattens the layer configuration into a different folder. This are all layers with overlayed recipes removed and .bbappend files added to their corresponding recipes.

Creating your own layers manually

● 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 helpyocto-bsp help create

Bitbake recipesEach 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.bbrequire expat.inc

LIC_FILES_CHKSUM = "file://COPYING;md5=1b71f681713d1256e1c23b0890920874"

PR = "r0"

SRC_URI[md5sum] = "dd7dab7a5fea97d2a6a43f511449b7cd"

SRC_URI[sha256sum] = "823705472f816df21c8f6aa026dd162b280806838bb55b3432b0fb1fcca7eb86"

meta/recipes-core/expat/expat.incSUMMARY = "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 classesBitbake 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.bbclassupdate-alternatives.bbclassupdate-rc.d.bbclassbinconfig.classpkgconfig.bbclasssrc_distribute.bbclasssrc_distribute_local.bbclasscpan.bbclass

distutils.bbclassdevshell.bbclasspackage*.bbclasskernel.bbclasimage.bbclassrootfs*.bbclasssanity.bbclassinsane.bbclass

Bitbake recipesMultiple 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_MACHINEStops parsing unless machine listed here.

DEFAULT_PREFERENCERelative priority among like-named recipes. Overridden by PREFERRED_VERSION_*

PREFERRED_VERSION_virtual/kernel = "3.2"

Bitbake recipesLicense 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 licensesRecipes 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 YoctoApplication 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-env2. Edit conf/local.conf for your machine type:3. bitbake meta-ide-support4. 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 YoctoThe 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 workflowThe Eclipse plug in allows you to:

● Custom BSP○ Copy an existing one○ Make configuration

changes○ Make recipe changes

● Compile● Deploy● Run● Debug

Command line workflowBuild 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 developersInstallation

1) Install the Indigo Eclipse classic (does not work in Juno)

2) Update with:

http://download.eclipse.org/releases/indigoProgramming Languages -> Autotools Support for CDTProgramming Languages -> C/C++ Development ToolsLinux Tools -> LTTng - Linux Tracing Toolkit

http://download.eclipse.org/tm/updates/3.3TM and RSE Main FeaturesTM and RSE Optional Add-ons -> Every item except "RSE Unit Tests and RSE WinCE Services"

http://download.eclipse.org/tools/cdt/releases/indigoCDT Main FeaturesCDT Optional Features -> C/C++ Remote Launch and Target Communication Framework.

http://downloads.yoctoproject.org/releases/eclipse-plugin/1.2.1Development tools and SDKs for Yocto Linux

Eclipse plug-in for application developersConfiguration

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 directorySysroot: 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 developersRunning 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 developersDebugging 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 developersBitbake Commander

Allows you to add and modify the project's layers. As general rules:

● You never change the metadata from upstream(unless you are submitting a bug report upstream)

● You always use additional layers to make your own changes.

When creating a new Yocto Project, you can point it to an existing YPBT, or you can instruct it to clone one from the upstream Yocto project in a new location (not the Eclipse workspace).YoctoProjectTools -> yocto-bsp allows to create a new layer.

Once the metadata project is created, we can modify it as follows:

1. File -> New -> Yocto BitBaker Commander -> Bitbake recipe

2. Point SRC_URI to the package source.3. Click populate to auto complete some fields, and complete

"Description" and "License" fields.4. Project -> Launch Hob5. Choose the build directory to place the final images. (Not

the YPBT, just an output folder)6. Use Hob to customize and build your own images.

Introduction to YoctoSystem developers

System developing contentsSystem 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 tree1. Development host machine setup2. 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 kernelA 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

MACHINEBB_NUMBER_THREADSPARALLEL_MAKEDL_DIR

● Policymeta-yocto/conf/distro/poky.conf

● Machine specificmeta-bsp/conf/machine/imx51evk.conf

System development workflowOverview

● 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 workflowImage 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 workflowImage creation

Images can be customized in the build/local.conf file:

Adding packages to the image:

IMAGE_INSTALL = "task-core-x11-base package1 package2"

inherit core-image

IMAGE_INSTALL_append = " sysfsutils" [note the leading space]

Or by adding a new task (see right box), using meta/recipes-core/tasks/task-core-boot.bb as an example.

And then adding it to the image :

IMAGE_INSTALL_append " task-custom-apps task-custom-tools"

DESCRIPTION = "My Custom Tasks"

PACKAGES = "\

task-custom-apps \

task-custom-apps-dbg \

task-custom-apps-dev \

task-custom-tools \

task-custom-tools-dbg \

task-custom-tools-dev \

"

RDEPENDS_task-custom-apps = "\

dropbear \

portmap \

psplash"

RDEPENDS_task-custom-tools = "\

oprofile \

oprofileui-server \

lttng-control \

lttng-viewer"

RRECOMMENDS_task-custom-tools = "\

kernel-module-oprofile"

System development workflowPackage 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 FeaturesYocto 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_FEATURESMACHINE_FEATURES

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

● Images can be configured with:

IMAGE_FEATURESEXTRA_IMAGE_FEATURES

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

Command line buildPrepare for build

source oe-init-build-env [build_dir]

where typically build_dir represents a target.

Launch buildbitbake <target> [-k]

The -k or --continue option instructs bitbake to go ahead and build all dependencies even if there are failures.Common targets can be found in:

○ meta/recipes-core/images○ meta/recipes-sato/images

And also in:● meta/recipes-extended/images● meta/recipes-qt/images● meta/recipes-graphics/images● meta/recipes-rt/images

Explained in the Yocto project documentation.

Build results in tmp/deploy/images

Build Debugging

Enable debug output:bitbake -DDD -v targetname

Log file for shell tasks:${WORKDIR}/temp/log.do_taskname.pid

Corresponding to the bitbake tasks in run.do_taskname.pid

Adding logging to recipes (meta/classes/logging.bbclass)

Python: bb.fatal, bb.error, bb.warn, bb.note, bb.plain, and bb.debugBash: bbfatal, bberror, bbwarn, bbnote, bbplain, and bbdebug.

No dependency build

bitbake -b <somepath/somefile.bb>

Show environment information

Shows current and preferred version of packages.bitbake --show-versions

Shows global or per-package environmentbitbake --environmentbitbake --environment <package name>bitbake --environment -b <recipename>

Bitbake commandsSome usual commands:

bitbake <pkgname> -c listtasksTasks available for a package/recipebitbake <pkgname> -c rebuild -f Clean and build again a packagebitbake <pkgname> -c fetch -f Download again the source programbitbake <pkgname> -c devshell Expand a gnome xterm ready to raise commandsbitbake <pkgname> -c clean/compile Clean or compile package.bitbake <pkgname> Build package (including creating package)bitbake package-index Make package index files for feedsbitbake <target_image> Build image contains task-base packages.bitbake <target_image> -c buildall -f Build pending packages for target_imagebitbake <target_image> -c rootfs -f Populate rootfs again for target_imagebitbake -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 timesOn an Intel(R) Core(TM)2 Quad CPU Q9650 @ 3.00GHz

Build configuration

build/local.confBB_NUMBER_THREADS = "4"

PARALLEL_MAKE = "-j 4"

MACHINE ??= "qemuarm"

● Download source firstbitbake -c fetchall core-image-minimal

● Then buildbitbake core-image-minimal

● First build (all sources local)Total time: 1h 6mins

● Build, no cleanTotal time: 1min 30secs

● Clean, then rebuild○ Remove build directory

Same as first build above.○ Remove only build output /tmp (keeps

downloaded sources and state)Total time: 8 mins.

Using HobHob 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 workflowFixing existing applications

● Find the path to the temporary source code for your package.bitbake -e <target> | grep ^S=

● Change to that path and create a local git repogit init

git add *

git commit

● Edit files● Test your changes

bitbake -c compile -f <pkg_name>

● Commit your changesgit status

git add file1.c file2.c file3.c

git commit

● Generate the patchgit format-patch HEAD~1

● Copy the patch to a "files" folder in the same directory as the recipe.

● Add it to Yocto:SRC_URI += "file://my_changes.patch"

● Increment the Package revision number (PR)● Clean:

bitbake -c clean -f <pkgname>

bitbake -c cleanall -f <pkgname>

Yocto's Kernel TreeThe 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 treeKernel 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 treeKernel 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 treeBitbake tasks

do_fetchdo_unpackdo_kernel_checkoutdo_validate_branchesdo_patchdo_kernel_configmedo_populate_llicdo_configuredo_kernel_configcheckdo_compiledo_compile_kernelmodulesdo_sizecheckdo_uboot_mkimagedo_kernel_link_vmlinuxdo_compile_perfdo_installdo_install_perfdo_packagedo_deploy

● Listed by:

bitbake -c listtasks virtual/kernel

● Re-ran by:

bitbake virtual/kernel -c task

● To streamline the kernel configuration, run iteratively:

bitbake virtual/kernel -c configmebitbake virtual/kernel -c kernel_configcheck

Freescale's Yocto kernelThe 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 kernelKernel 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&AThanks for watching!

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