Confidential and Proprietary TM The Yocto Project and Linux ® Software Development for i.MX Application Processors AMF-SHB-T1056 March.2015 Jay Marcinczyk.

Confidential and Proprietary

TM

The Yocto Project and Linux® Software Development for i.MX Application Processors AMF-SHB-T1056

M a r c h . 2 0 1 5

Jay Marcinczyk | West Region i.MX SW FAE

TM

Confidential and Proprietary 2

Agenda

• Introduction

• Freescale i.MX Releases

• Get Started

• Debugging Tips

• Internet of Things

• Advanced

TM


What is the Yocto Project

• It's not an embedded Linux distribution, it creates a custom one for you - https://www.yoctoproject.org/

− The Yocto Project is an open source collaboration project that provides templates, tools and methods to help you create custom Linux-based systems for embedded products regardless of the hardware architecture.

− The Yocto Project hosts other projects as well, including the Poky build system, Autobuilder automated build and test system, and the Embedded GLIBC (EGLIBC)C library.

https://www.yoctoproject.org/

TM


Yocto Project Introduction: Releases

Yocto Project has releases on 6 month cycles approximately

every October and April.

Latest Releases: Yocto Project 1.7 (Dizzy) in Oct 2014

Next Release: Yocto Project 1.8 in Apr 2015

Past releases:• Yocto Project 1.6 (Daisy) in April 2014• Yocto Project 1.5 (Dora) in October 2013• Yocto Project 1.4 (Dylan) in April 2013• Yocto Project 1.3 (Danny) in October 2012• Yocto Project 1.2 (Denzil) in April 2012

TM


Yocto Project Introduction: Building Blocks

Poky - Open source platform build tool. At the core of Poky is the bitbake task executor

together with various types of configuration files. Poky contains common components

and toolchain.

Bitbake - Parses metadata, generating a list of tasks from it and then executing them.

OpenEmbedded-Core - metadata repository

Metadata - .bb files are usually referred to as 'recipes‘

Class - (.bbclass) Contain information which is useful to share between metadata files

Configuration - (.conf) files define various configuration variables which govern what

Poky does.

Layers - Sets of common recipes such as meta-fsl-arm

TM


Yocto Project Introduction: Development Environment

Source: http://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs.html

TM


Yocto Project Introduction: Layers of recipes

The OpenEmbedded build system supports organizing Metadata into multiple layers. Layers allow you to isolate different types of customizations from each other. You might find it tempting to keep everything in one layer when working on a single project. However, the more modular you organize your Metadata, the easier it is to cope with future changes.Source: http://www.yoctoproject.org/docs/1.6/dev-manual/dev-manual.html#understanding-and-creating-layers

Source: https://www.yoctoproject.org/tools-resources/projects/openembedded-core

Let’s check out: http://layers.openembedded.org/layerindex/

http://layers.openembedded.org/layerindex/

TM


Yocto Project Introduction:The Freescale i.MX Community BSP

• “The Freescale Yocto Community BSP is a development community outside of Freescale providing support for i.MX boards on the Yocto Project environment.”

• There are several developers working on the Freescale Yocto Community BSP, its maintainer is Otavio Salvador from O.S. Systems

(http://ossystems.com.br/ or https://www.slideshare.net/secret/cmdMnute8kNFUK)

• Mail list for the project: https://lists.yoctoproject.org/listinfo/meta-freescale

TM


Yocto Project Freescale i.MX Releases

TM


Yocto Project Freescale i.MX Releases: History

Release Description

L3.10.53-1.1.0 on Daisy Graphics v5, i.MX 6 SoloX, new Uboot, Gstreamer 1.0

L3.10.17-1.0.2 on Dora Post GA graphics update with updated kernel

L3.10.17-1.0.1 on Dora Post GA graphics only fixes for 3.10.17 GA

L3.10.31-1.1.0_beta and beta2 on Daisy

Kernel 3.10.31 beta with v5 Vivante graphics, GLES 3.0, Gstreamer 1.0, U-Boot 2014.04, Qt5 support and i.MX 6 SoloX

L3.10.17-1.0.0_ga on Dora Kernel 3.10.17 GA release with p13 Vivante graphics and manufacturing image

TM


Yocto Project Freescale i.MX Releases: Distribution

meta-fsl-bsp-release layer• Distributes changes on top of community layers • At our code freeze we lock all community layers in manifest.• After each release the changes are upstreamed into the layers for the

next Yocto release to provide

Release Distribution • Freescale i.MX Yocto Project mirror

− Stores Freescale packages

• Git.freescale.com− Kernel and u-boot-imx releases

• Extranet download for packages with license restrictions• Documentation – freescale.com/imx – GA docs only

− Click i.MX6 box-> i.MX6 SW and Dev Tools->Linux->3.10.53 Docs

TM


Yocto Project Freescale i.MX Releases: Community

• Community layers are continuously updated.• Freescale i.MX releases are based on a static point in time at

our code freeze. So community is still changing while we are testing our release and community changes after our code freeze will not be in our release.

• After our release we pick up the latest community changes until code freeze.

• After release we upstream into community the changes so the changes can be removed from next release.

TM


Yocto Project Freescale i.MX Releases: Roadmap

• 2015 activities− Kernel upgrades to 3.14− U-boot upgrades− IOTG – Internet of Things Gateway− Yocto Project Releases 1.7 and beyond− 2015 Releases for new silicon

TM


Yocto Project Freescale i.MX Releases: Contents

Contents Description

recipes-kernel Kernel

recipes-bsp U-Boot, imx-test, imx-lib, imx-vpu, imx-kobs, imx-uuc, firmware,

recipes-graphics gpu-viv-bin, xorg-driver, wayland

recipes-multimedia libfslcodec, libfslparser, libfslvpuwrap, gstreamer, alsa

recipes-core busybox, eglibc, udev

recipes-fsl Image and package group

recipes-qt Qt5 package groups and demos

TM


i.MX Yocto Project Release Strategy

• Yocto Project has releases every 6 months April and October.• After each Yocto Project release, next release is based on new

Yocto Project release.• 3.10.17-1.0.0 GA was based on dora since dora was released in

October and our code freeze for GA was before daisy released in April 2014.

• 3.10.53-1.1.0 GA is based on daisy• We test and release on last Yocto Project release that aligns to our

code freeze date.• 3.14 2015 releases will be based on dizzy.

TM


Differences Between 3.10.17 and 3.10.53 GA releases

Release 3.10.17-1.0.0 3.10.53-1.1.0

Graphics Graphics v4.6.9DirectFB 1.6.2Wayland 1.4Xorg 1.14fsl-gpu-sdk 1.1

Graphics v5.0.11OpenGLES 3.0 APIs, DirectFB 1.7.4 Wayland 1.6Xorg 1.15 and 1.16fsl-gpu-sdk 2.06slevk fixes for all backends

U-Boot and Kernel U-Boot 2013.04Kernel 3.10.17Mfgtools – fsl-image-manufacturing image

U-Boot 2014.04Kernel 3.10.53Mfg tools – fsl-image-mfgtool-initramfs

New Hardware none 6 SoloX introduction

Multimedia Gstreamer 0.1 Gstreamer 1.0 and 0.1

Qt Qt4 with demo support for Qt5.2.1 on X11

Qt5.2.1 support on X11, FB and Wayland

Toolchain + Yocto Project Gcc 4.8.1 on dora Gcc 4.8.2 on daisy

Documentation Split release notes Combined release notes and user’s guides – fewer documents

TM


Yocto Project : Qt5

• Qt5 on 3.10.17-1.0.0_GA is provided as demo only.• Qt5 on 3.10.53 has support for X11, FB and Wayland backends. • FSL Graphics DirectFB does not support Qt5.• On 3.10.53 build fsl-image-qt5 to build an image with Qt5.• Daisy uses Qt5 5.2• Yocto 1.7 uses Qt 5.3• Note that Qt5 has specific license terms. Before users develop

with Qt5 they should understand these terms – • http://qt-project.org/doc/qt-5/licensing.html to know whether to

start with a commercial license or continue with an open source license. Future Qt5 features will only be licensed as LGPLv3 not as LGPL v2.1 as earlier features were and some features will only be available with commercial licenses.

http://qt-project.org/doc/qt-5/licensing.html

TM


Yocto Project : i.MX FSL QT5 Applications

• Starting with 3.10.53 – FSL i.MX binary provided for Qt5 player.• Features showcase performance and benchmarking integrated

into the Gstreamer 1.0 framework.

TM


Yocto Project : Gstreamer 1.0

• 3.10.31-1.1.0 was first release to include Freescale i.MX Gstreamer 1.0 support.

• Community has a Gstreamer 1.0 version also called gstreamer-imx. This is not developed by Freescale but is on the community branches in daisy.

• The community gstreamer-imx is not as robust as the Freescale version.

• After a decade of content Freescale gathered form our customers, our release must not hang or crash on any content. The community does not have access to this protected content.

• Customers can choose which Gstreamer they want to use by use preferred provider settings.

TM


Yocto Project : Graphics

• i.MX supports 4 backends for graphics− X11, Wayland, Frame Buffer and DirectFB

• Graphics package provides binaries for all backends.• Some features only work on specific backends – X11 has most

features.• Wayland works with Weston compositor• X11 and wayland are in default Distro features but choose one.• Build each separately.• Backends are distinguished through

DISTRO_FEATURES_append or remove – explained later.• Our scripts set the backend features from setup script.

TM


Yocto Project : Get Started

TM


Yocto Project Build: Steps 1 and 2

• Step 1 - Install required host packages− Check references on previous pages for the required host software.− Refer to Freescale Yocto Project User’s Guide Host Setup Section 3− Host can be Ubuntu 12.04 or 14.04

• Step 2 – Install Repo

$ mkdir ~/bin

$ curl http://commondatastorage.googleapis.com/git-repo-downloads/repo > ~/bin/repo

$ PATH=$PATH:~/bin

$ chmod a+x ~/bin/repo

http://storage.google.com/git-repo-downloads/repo

TM


Yocto Project Build: Step 3 – Initialize Repo and Start Download

This downloads the Yocto Project layers for the 3.10.17-1.0.2 GA release including the release layer.

This does not setup build but it downloads the tools to do the setup in next step.

$ mkdir fsl-release-bsp$ cd fsl-release-bsp$ repo init -u git://git.freescale.com/imx/fsl-arm-yocto-bsp.git -b imx-3.10.17-1.0.2_ga$ repo sync

https://github.com/Freescale/fsl-community-bsp-platform

TM


Yocto Project Build: Step 3: After BSP Download

• Layers examples:− poky: base build system− meta-openembedded: extra packages and features − meta-fsl-arm: support for Freescale's processors and board− meta-fsl-arm-extra: support for boards using Freescale's chips− meta-fsl-demos: demo images and recipes− meta-fsl-bsp-release – Freescale’s release layer of changes

TM


Yocto Project Build: Manifest and Layer Integration

• Manifest describes each layer to download and where to download

• Which branch/revision of each layer− Can be specific to commits on each layer (used for Freescale releases)− The manifest released by Freescale can be used to reproduce the same

images tested by the Freescale test team

Layers are integrated in the bblayer.conf. Just because repo downloads does not mean it is part of the build until the layer is in bblayer.conf.

TM


Yocto Project Build: Community Manifest

<remote fetch="git://git.yoctoproject.org" name="yocto"/>

<remote fetch="git://github.com/Freescale" name="freescale"/>

<remote fetch="git://git.openembedded.org" name="oe"/>

<project remote="yocto" revision="daisy" name="poky" path="sources/poky"/>

<project remote="yocto" revision="daisy" name="meta-fsl-arm" path="sources/meta-fsl-arm"/>

<project remote="oe" revision="daisy" name="meta-openembedded" path="sources/meta-openembedded"/>

<project remote="freescale" revision="daisy" name="fsl-community-bsp-base" path="sources/base">

<copyfile dest="README" src="README"/>

<copyfile dest="setup-environment" src="setup-environment"/>

</project>

<project remote="freescale" revision="daisy" name="meta-fsl-arm-extra" path="sources/meta-fsl-arm-extra"/>

<project remote="freescale" revision="daisy" name="meta-fsl-demos" path="sources/meta-fsl-demos"/>

TM


Yocto Project Build: i.MX Release Manifest

• <remote fetch="git://git.yoctoproject.org" name="yocto" />

• <remote fetch="git://github.com/Freescale" name="freescale" />

• <remote fetch="git://git.openembedded.org" name="oe" />

• <remote fetch="git://git.freescale.com/imx" name="fsl-release" />

• <remote fetch="git://github.com/OSSystems" name="OSSystems"/>

•

• <project remote="yocto" revision="bee7e3756adf70edaeabe9d43166707aab84f581" name="poky" path="sources/poky" />

• <project remote="yocto" revision="af392c22bf6b563525ede4a81b6755ff1dd2c1c6" name="meta-fsl-arm" path="sources/meta-fsl-arm" />

• <project remote="oe" revision="eb4563b83be0a57ede4269ab19688af6baa62cd2" name="meta-openembedded" path="sources/meta-openembedded" />

• <project remote="freescale" revision="6bc2400f3045e27dc1a4a65cb28bfb0e32403bb7" name="fsl-community-bsp-base" path="sources/base">

• <copyfile dest="README" src="README" />

• <copyfile dest="setup-environment" src="setup-environment" />

• </project>

• <project remote="freescale" revision="07ad83db0fb67c5023bd627a61efb7f474c52622" name="meta-fsl-arm-extra" path="sources/meta-fsl-arm-extra" />

• <project remote="freescale" revision="5a12677ad000a926d23c444266722a778ea228a7" name="meta-fsl-demos" path="sources/meta-fsl-demos" />

• <project remote="OSSystems" revision="fc3969f63bda343c38c40a23f746c560c4735f3e" name="meta-browser" path="sources/meta-browser" />

• <project remote="fsl-release" name="meta-fsl-bsp-release" path="sources/meta-fsl-bsp-release" revision="dora_3.10.17-1.0.0_GA">

• <copyfile src="imx/tools/fsl-setup-release.sh" dest="fsl-setup-release.sh" />

• </project>

TM


Yocto Project Build: Step 4 - Configure the build environment

• What are the supported boards?

i.MX Reference Boards

i.MX6Q imx6qsabresd imx6qsabreauto

i.MX6DualLite imx6dlsabresd imx6dlsabreauto

i.MX6Solo imx6solosabresd imx6solosabreauto

i.MX6SoloLite imx6slevk

i.MX6SoloX imx6sxsabresd imx6sxsabreauto (in 3.10.53)

i.MX53 imx53qsb

i.MX28 Imx28evk

$ MACHINE=imx6qsabresd source fsl-setup-release –b build-x11 –e x11

This is your build environment, you can set a different name to reflect the configuration

TM


Yocto Project Build: Machine configuration files

• Yocto Project builds for a target machine• Machines are defined with machine configuration files that reside in

the conf/machine directory of each layer.• meta-fsl-arm has each machine.• setup-environment called by our setup scripts requires that these

machine files be in the community meta-fsl-arm/conf/machine directory.

• Machine configuration file tells environment− Kernel Device Trees− U-Boot configurations− Supported silicon families− Machine features

TM



• imx6qsabresd.conf Example

• #@TYPE: Machine• #@NAME: Freescale i.MX6Q SABRE Smart Device• #@SOC: i.MX6Q• #@DESCRIPTION: Machine configuration for Freescale i.MX6Q SABRE Smart Device

• require conf/machine/include/imx6sabresd-common.inc

• SOC_FAMILY = "mx6:mx6q"

• KERNEL_DEVICETREE = "imx6q-sabresd.dtb imx6q-sabresd-ldo.dtb “• KERNEL_DEVICETREE += “imx6q-sabresd-hdcp.dtb"

• UBOOT_CONFIG ??= "sd"• UBOOT_CONFIG[sd] = "mx6qsabresd_config,sdcard"• UBOOT_CONFIG[sata] = "mx6qsabresd_sata_config"

TM


Yocto Project Build: License Agreement

• Freescale releases packages on external mirror• Proprietary packages are packaged as self-extracting binaries with

our LAOPT27 EULA license agreement• fsl-eula-unpack class will unpack based on acceptance of EULA• Microsoft, AACPlus, AC3 not on mirror – only on extranet with

moderated downloads (AACPlus is on freescale.com)• Set-up environment will show EULA and record acceptance in

local.conf

• Do not set up i.MX Yocto Project unless you agree to the License terms

TM


Yocto Project Build: Step 6 – Build a Target Image

What are some of the images available?

In 3.10.17 there were image recipes for each backend.

In 3.10.53 we have only 2 – with and with Qt5

Targt image Description

core-image-minimal Kernel image command prompt

core-image-sato Kernel build with GUI

fsl-image-gui Only in 3.10.53 - Non QT image works on all backends

fsl-image-qt5 Only in 3.10.53 - Freescale image QT image works on X11, Wayland and FB backends (not DirectFB)

fsl-image-x11 Only in 3.10.17 - Qt4 image

fsl-image-weston Only in 3.10.17 - Weston Wayland

fsl-image-fb Only in 3.10.17 - Frame buffer image recipe

fsl-image-dfb Only in 3.10.17 - DirectFB image recipe

$ bitbake <image>

TM


Yocto Project Build: Hook in the i.MX release

• Hook in the meta-fsl-bsp-release layer using fsl-setup-release.sh• The –e option sets up the build to add and remove

DISTRO_FEATURES to set up for each backend.• Be careful combining multiple backends in one working directory. • Best use different build directories for each backend.

Graphics Backend

Command

X11 MACHINE=imx6qsabresd source fsl-setup-release.sh –b build-x11 –e x11

Frame Buffer MACHINE=imx6qsabresd source fsl-setup-release.sh –b build-fb –e fb

DirectFB MACHINE=imx6qsabresd source fsl-setup-release.sh –b build-dfb –e dfb

Wayland with Weston compositor

MACHINE=imx6qsabresd source fsl-setup-release.sh –b build-wayland –e wayland

TM


Yocto Project Build: Step 7 - Deploy image on the target

• Build image resides in <build>/tmp/deploy/images/<machine>• Contents are sdcard, kernel, uboot, rootfs

• Note multiple sd card images take up disk space• Keep track of tmp/deploy/images/<machine> and remove old

sdcard images to keep disk space usage reduced.

$ cd tmp/deploy/images$ cat proc/partitions$ sudo dd if=fsl-image-gui-imx6qsabresd.sdcard of=<sd card device> bs=1M && sync

TM


Yocto Project Build: Build and Deploy U-Boot

• Look in machine configuration for U-Boot options (below are just a few examples.)• Default is SD boot, so no change needed for SD boot• To change, add line to <build>/conf/local.conf

− UBOOT_CONFIG=“<boot_config”>

$ bitbake u-boot-imx –c deploy

U-Boot Type Local.conf

SD boot UBOOT_CONFIG = “sd”

EIM NOR UBOOT_CONFIG = “eimnor”

SPI NOR UBOOT_CONFIG = “spinor”

SATA UBOOT_CONFIG = “sata”

NAND UBOOT_CONFIG = “nand”

TM


Yocto Project Build: Build and Deploy Kernel

• Freescale i.MX kernel recipes point defconfig to location in git tree• Community kernel recipes use static defconfig

recipes-kernel/linux/linux-imx_3.10.17/mx6/defconfig

$ bitbake linux-imx

Uboot type Local.conf

Default config FSL_KERNEL_DEFCONFIG = "imx_v7_defconfig"

Manufacturing image

FSL_KERNEL_DEFCONFIG = "imx_v7_mfg_defconfig"

TM


Yocto Project Build: Adding new device trees

1. Create device tree in kernel source arch/arm/boot/dts

2. Update machine configuration files with new name• Note that device tree source is extension dts• Binary device tree is extension dtb

− KERNEL_DEVICETREE = “<new device tree.dtb>“

3. Build kernel• bitbake –c compile –f linux-imx• bitbake –c deploy –f linux-imx• New device tree should be in tmp/deply/images/<machine>

4. Update uboot • Change the fdt_file parameter to the new device tree.dtb

TM


Yocto Project Build: Community vs Release Setup

For Community Builds – use manifest and instructions


For Release builds – use manifest and setup instructions from README from manifest repo – fsl-arm-yocto-bsp – Example below is from 3.10.31 beta release

http://git.freescale.com/git/cgit.cgi/imx/fsl-arm-yocto-bsp.git/tree/README?h=imx-3.10.31-1.1.0_beta

Community currently has 3.10.17-1.0.2 in dizzy and master branches

Soon will have 3.10.31-1.1.0_beta in master branch




TM


Yocto Project Debugging Tips

TM


Yocto Project Debugging Tips: Bitbake commands

bitbake command Details

bitbake –c cleanall <component> Cleans downloads and all cache entries for component. Cleans out all entries in working directory!

bitbake –c cleansstate <component> Cleans cache but does not remove the download entry. Cleans out all entries in working directory!

bitbake –c compile –f <component> Forces a recompile of a component. Use after making changes in working directory.

bitbake –c configure –f <component> Forces a reconfigure – useful in kernel if defconfig is changed

bitabke –c menuconfig linux-imx Runs the menu config for the kernel

btibake <component> -v Verbose output on command line (same as what is in the log)

bitbake <component> -k Continue past build breaks until a dependency requires stopping

bitbake <component> -c deploy –f Deploys a component to the rootfs with force – sometimes Yocto thinks a component is already deployed so this forces it

bitbake <component> -g Lists a dependency tree for component

bitbake <image> -c populate_sdk Generates an SDK script to reproduce the rootfs and build environment for non-Yocto Project build systems

TM


Yocto Project Debugging Tips: Preferred Providers

• Multiple recipes can provide same component with different names• Use preferred providers in local or layer.conf or build will complain.• Bitbake will fail asking which provider if it is not clear

• Community has kernel and uboot – linux-fslc, u-boot-fslc• i.MX provides kernel and uboot - linux-imx and u-boot-imx• Specify which one

• Examples to provide imx as provider− PREFERRED_PROVIDER_u-boot_mx6 = "u-boot-imx“− PREFERRED_PROVIDER_virtual/kernel_mx6 = “linux-imx“

TM


Yocto Project Debugging Tips: Preferred Versions

• Multiple versions of components in different layers

• Build should pick up the highest version unless stated in local.conf. • Used to designate specific versions of components to build• Look at meta-fsl-bsp-release/imx/meta-fsl-arm/conf/layer.conf for

examples.

• Examples:− PREFERRED_VERSION_u-boot-imx_mx6 = "2014-04"− PREFERRED_VERSION_linux-imx_mx6 = "3.10.31”− PREFERRED_VERSION_imx-lib_mx6 = "3.10.31-1.1.0”− PREFERRED_VERSION_imx-test_mx6 = "3.10.31-1.1.0“

TM


Yocto Project Debugging Tips: SoC extensions

• To make target specific changes to: − System on chip (SoC) family like i.MX 6 Series, i.MX6Q or i.MX6SL− Machine-like i.MX6Q SABRE SD or i.MX 6SLEVK− Recipes can limit builds to a specific SoC family, SoC or boards− Within recipes, settings or tasks can be limited by SoC family, SoC or boards.

• SOC_FAMILY = "mx6:mx6sl"

• Examples between SoC families− PREFERRED_PROVIDER_u-boot_mx6 = "u-boot-imx"− PREFERRED_PROVIDER_u-boot_mx5 = "u-boot-fslc“

• Examples between boards, sololite has no vpu− DEPENDS_mx6q = "virtual/kernel imx-lib imx-vpu"− DEPENDS_mx6sl = "virtual/kernel imx-lib“

TM


Yocto Project Debugging Tips: SoC extensions Warnings

Important to understand:• SOC extensions will affect PREFERRED_VERSION settings• If other layers already define a PREFERRED_VERSION for _mx6

then setting PREFERRED_VERSION without _mx6 will not take affect

• If PREFERRED_VERSION with _mx6 must be overridden from another layer use specific SOC descriptorPREFERRED_VERSION_linux-imx_mx6q = “3.10.53”

• The most specific SOC extension will take priority.• To confirm which version is used – look at working directory –

version is always in the directory structure.

TM


Yocto Project Debugging Tips: Examples

• Community settings• https://github.com/Freescale/meta-fsl-arm/blob/master/conf/machin

e/include/imx-base.inc

• Release – 3.10.31 Settings• http://git.freescale.com/git/cgit.cgi/imx/meta-fsl-bsp-release.git/tree/i

mx/meta-fsl-arm/conf/layer.conf?h=daisy_3.10.31-1.1.0_beta

• Look at directfb in layer.conf how we override community directfb version in imx-base.inc

https://github.com/Freescale/meta-fsl-arm/blob/master/conf/machine/include/imx-base.inc

https://github.com/Freescale/meta-fsl-arm/blob/master/conf/machine/include/imx-base.inc

http://git.freescale.com/git/cgit.cgi/imx/meta-fsl-bsp-release.git/tree/imx/meta-fsl-arm/conf/layer.conf?h=daisy_3.10.31-1.1.0_beta

http://git.freescale.com/git/cgit.cgi/imx/meta-fsl-bsp-release.git/tree/imx/meta-fsl-arm/conf/layer.conf?h=daisy_3.10.31-1.1.0_beta

TM


Yocto Project Debugging Tips: Debugging

• Yocto has multiple tasks that it runs.

• Each task has a log output in the component working directory− log.do_<task> shows output of task− run.do_<task> shows content of task

• Yocto Working directory− Example: Kernel working directory <build-dir>/tmp/work/imx6qsabresd-poky-linux-gnueabi/linux-imx/3.10.17-r0/ Log output -- <build-dir>/tmp/work/imx6qsabresd-poky-linux-gnueabi/linux-imx/3.10.17-r0/temp

− Kernel dependent components will go into machine working directories.− Non-Kernel dependent components will go the cortexa9 working

directories.

TM


Yocto Project Debugging Tips: Toolchains

• Yocto Project updates the toolchains on each release.

• Can switch to last one by setting GCC_VERSION

• Try setting GCC_VERSION in local.conf to previous version− GCC_VERSION = “4.7”− Note for dizzy release does not support older gcc versions.

• Hardware Floating Point is Default− DEFAULTTUNE_mx6 ?= "cortexa9hf-neon"

• To change to software floating point set in local.conf− DEFAULTTUNE_mx6 = "cortexa9-neon“

• Notes:− Any changes to toolchain require a clean build. − Only hardware floating point binaries get full test before release.

TM


Yocto Project Debugging Tips: Graphics

• Four graphics backends supported – X11, FB, DFB and Wayland

• Each backend is setup with a different set of DISTRO_FEATURES.

• Each of these backends conflict with each other.

• Many recipes check DISTRO_FEATURES to determine how to build, so it must be set in the local.conf.

• Use the fsl-setup-release.sh to set the local.conf with the correct DISTRO_FEATURES.

TM


Yocto Project Debugging Tips: Graphics DISTRO_FEATURES

• Table below shows the DISTRO_FEATURES for each backend.• fsl-setup-release.sh adds these to the local.conf• Frame buffer does not have a specific distro feature but is the

absence of X11,DirectFB and Wayland• Without any changes in local.conf – default is x11 with wayland.

Graphics Backend DISTRO_FEATURES in local.conf

X11 DISTRO_FEATURES_add = “x11”DISTRO_FEATURES_remove = “wayland directfb”

Frame Buffer DISTRO_FEATURES_remove = “x11 wayland directfb”

DirectFB DISTRO_FEATURES_add = “directfb”DISTRO_FEATURES_remove = “x11 wayland”

Wayland DISTRO_FEATURES_add = “wayland”DISTRO_FEATURES_remove = “x11 directfb”

TM


Yocto Project Debugging Tips: Reducing Build Time

• Share the download folder− In local.conf− DL_DIR = “<directory path>”− Multiple builds will share common downloads, reducing disk space and improving

speed

• Share the state folder− SSTATE_DIR = “<directory path>”− Multiple builds will share state of previous builds to reduce build time. For example,

will not rebuild toolchain.

• Keep track of the tmp/deploy/images contents. • Multiple builds will generate new images and increase disk space usage.• To reduce disk space usage put rm_work in local.conf – this deletes the

source and build and leaves only logs and final output and build – increases build time slightly

INHERIT += rm_work

TM


Yocto Project Debugging Tips: Assistance

Community Email

[email protected]

https://lists.yoctoproject.org/listinfo/meta-freescale

i.MX Community

https://community.freescale.com/community/imx/content

Click on Content->Yocto Project

Documents has tips for getting started

mailto:[email protected]



TM


Yocto Project: Internet of Things

TM


Internet of Things: Connectivity in BSP

• What is connectivity in the BSP− Kernel enablement in defconfig− Stack enablement with bluez and supporting packages

• Two versions of bluez – bluez4 and bluez5• Yocto Project defaults to bluez4 stack – very difficult to switch to bluez5• Changes made to configure easily between both• Some hardware not supported on both bluez4 and bluez5

TM


Internet of Things: Internet of Things Gateway

• Utilite Box – imx6qiotg through Compulab• 3 components

− Connectivity Stack− Device configuration (Kernel and U-Boot)− Gateway support

• Features− Changes based on 3.10.17-1.0.0 GA− Will be rebased to 3.10.53 after release− Suitcase Demo− Open source solution and 3rd party solution using Java

TM


Internet of Things: Automotive CPU2

• Recent Announcement about the CPU2 Auto board reconfigurations for imx6q and imx6dl

• Requires new device trees• Boards released in 2015.• Two modes

− Legacy mode – default switch setting− AVB mode – software not in BSP

TM


Yocto Project: AdvancedT0948 Session

TM


Agenda

• Custom Machines and Layers

• Kernel, U-Boot and Device Trees

• Recipe Structure

• SOC Differentiation in recipes

• Images and Package Groups

• Debugging in Yocto

• Community

TM


Yocto Project Creating Custom Machines and Layers

TM


Yocto Project: Custom Machine Configurations

• What SOC is your custom machine based off − Machine configurations reside in conf/machine in each layer

− Copy the reference machine to new name

− For example, a new board based on imx6qsabresd

− cp imx6qsabresd imx6newboard.conf

• Edit new machine− Update SOC family to support – important to pick up applicable recipes

− Support latest uboot or older uboot – if older specify KERNEL_IMAGETYPE = “uImage”

• If latest nothing required – defaults to zImage

− Update Device tree list supported

− Update uboot configuration options

− Update uboot board.cfg to support machine or use existing uboot board configurations in U-Boot

− Update features – or use default settings from existing includes.

− Note SabreSD and Automotive have different includes.

− BSP Release overides some settings in imx-base.inc in community in meta-fsl-arm/conf/layer.conf

TM


Yocto Project: Custom Machine Configurations

How to Build− Two options – change build configuration or specify with bitbake

1. Existing build – edit local.conf and change MACHINE to new machine

2. MACHINE=imx6newboard.conf bitbake linux-imx

• Creates new working directory for kernel, uboot and other recipes tied to SOC family restrictions

• setup-environment only looks in layers that are in bblayers.conf• Might have to copy machine conf file into meta-fsl-arm/conf/machine to

be found

TM


Yocto Project: Vendor machines

• Vendor machine board configuration files reside in meta-fsl-arm-extra

• https://github.com/Freescale/meta-fsl-arm-extra/tree/master/conf/machine

• Vendor machine kernel recipes and other vendor specific recipes.• https://github.com/Freescale/meta-fsl-arm-extra/tree/master/recipes-ke

rnel/linux

• Upstream into community through meta-freescale mailing list into master branch to be part of next Yocto Project release.

https://github.com/Freescale/meta-fsl-arm-extra/tree/master/conf/machine

https://github.com/Freescale/meta-fsl-arm-extra/tree/master/conf/machine

https://github.com/Freescale/meta-fsl-arm-extra/tree/master/recipes-kernel/linux

https://github.com/Freescale/meta-fsl-arm-extra/tree/master/recipes-kernel/linux

TM



• Imx6qsabresd.conf Example

• #@TYPE: Machine• #@NAME: Freescale i.MX6Q SABRE Smart Device• #@SOC: i.MX6Q• #@DESCRIPTION: Machine configuration for Freescale i.MX6Q SABRE Smart Device

• require conf/machine/include/imx6sabresd-common.inc

• SOC_FAMILY = "mx6:mx6q"

• KERNEL_DEVICETREE = "imx6q-sabresd.dtb imx6q-sabresd-ldo.dtb “• KERNEL_DEVICETREE += “imx6q-sabresd-hdcp.dtb"

• UBOOT_CONFIG ??= "sd"• UBOOT_CONFIG[sd] = "mx6qsabresd_config,sdcard"• UBOOT_CONFIG[sata] = "mx6qsabresd_sata_config"

TM


Yocto Project: Custom Layer

• Directory structure important− Easiest is copy existing layer and edit

− Each layer has a conf/layer.conf which defines the layer

− bblayer.conf in build/conf hooks in the layer into build

− Recipes must reside in directories 2 levels below layer top level

− A layer can have multiple sub-layers but each sub-layer must have a conf/layer.conf directory - look at meta-fsl-bsp-release for example

• Steps− cd sources

− mkdir meta-custom

− mkdir meta-custom/conf

− cp meta-fsl-arm/conf/layer.conf meta-custom/conf/layer.conf Edit and remove the MIRROR and EULA file definitions

− mkdir meta-custom/recipes-custom

− mkdir meta-custom/recipes-custom/recipe1/

− Edit bblayer.conf and add in meta-custom layer

TM


Yocto Project: Example layer meta-fsl-demos

Sample Layer Configuration – layer.confhttp://git.freescale.com/git/cgit.cgi/imx/meta-fsl-bsp-release.git/tree/imx/meta-fsl-demos/conf/layer.conf?h=daisy_3.10.31-1.1.0_beta

BBPATH .= ":${LAYERDIR}“

BBFILES += "${LAYERDIR}/recipes-*/*/*.bb ${LAYERDIR}/recipes-*/*/*.bbappend"

BBFILE_COLLECTIONS += "fsl-bsp-release"

BBFILE_PATTERN_fsl-bsp-release := "^${LAYERDIR}"

BBFILE_PRIORITY_fsl-bsp-release = "8“

BBLAYER integration• Edit <build>/conf/bblayer.conf

• BBLAYERS += " ${BSPDIR}/sources/meta-fsl-bsp-release/imx/meta-fsl-demos "

http://git.freescale.com/git/cgit.cgi/imx/meta-fsl-bsp-release.git/tree/imx/meta-fsl-demos/conf/layer.conf?h=daisy_3.10.31-1.1.0_beta

http://git.freescale.com/git/cgit.cgi/imx/meta-fsl-bsp-release.git/tree/imx/meta-fsl-demos/conf/layer.conf?h=daisy_3.10.31-1.1.0_beta

TM


Yocto Project Kernel and U-Boot Configurations

TM


Yocto Project Build: Build and Deploy Kernel

• Freescale i.MX kernel recipes point defconfig to location in git tree• Example 3.10.31-1.1.0_Beta2 – imx_v7_defconfig

− http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/tree/arch/arm/configs?h=imx_3.10.31_1.1.0_beta2

• Community kernel recipes use static defconfig − recipes-kernel/linux/linux-imx_3.10.17/mx6/defconfig

Default kernel is linux-imx uses imx_v7_defconfig

3.10.31 and 3.10.53 - Manufacturing kernel recipe is linux-imx-mfgtool

3.10.17 - Manufacturing kernel recipe is linux-imx with imx_v7_mfg_defconfig

$ bitbake linux-imx

http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/tree/arch/arm/configs?h=imx_3.10.31_1.1.0_beta2



TM


Yocto Project: Kernel Configuration

• Understand the differences between community and releases− To switch look at the do_config in each recipe.

• Dynamic kernel configuration− To bitbake linux-imx –c menuconfig

− Save into .config in the git directory of linux-imx in working directory

− BSP releases using release layer always use the imx_v7_defconfig for main releases and imx_v7_mfg_config for manufacturing tool kernsl.

− Copy this config over to .config to start.

− To add features to this base config bitbake linux-imx –c menuconfig

− http://git.freescale.com/git/cgit.cgi/imx/meta-fsl-bsp-release.git/tree/imx/meta-fsl-arm/recipes-kernel/linux/linux-imx_3.10.31.bb?h=daisy_3.10.31-1.1.0_beta

• Community releases− Static config with kernel recipes called defconfig

− https://github.com/Freescale/meta-fsl-arm/blob/dizzy/recipes-kernel/linux/linux-imx_3.10.17.bb

− https://github.com/Freescale/meta-fsl-arm/blob/dizzy/recipes-kernel/linux/linux-imx-3.10.17/mx6/defconfig

http://git.freescale.com/git/cgit.cgi/imx/meta-fsl-bsp-release.git/tree/imx/meta-fsl-arm/recipes-kernel/linux/linux-imx_3.10.31.bb?h=daisy_3.10.31-1.1.0_beta

http://git.freescale.com/git/cgit.cgi/imx/meta-fsl-bsp-release.git/tree/imx/meta-fsl-arm/recipes-kernel/linux/linux-imx_3.10.31.bb?h=daisy_3.10.31-1.1.0_beta

https://github.com/Freescale/meta-fsl-arm/blob/dizzy/recipes-kernel/linux/linux-imx_3.10.17.bb

https://github.com/Freescale/meta-fsl-arm/blob/dizzy/recipes-kernel/linux/linux-imx-3.10.17/mx6/defconfig

https://github.com/Freescale/meta-fsl-arm/blob/dizzy/recipes-kernel/linux/linux-imx-3.10.17/mx6/defconfig

TM


Yocto Project Build: Adding new device trees

1. Create device tree in kernel source arch/arm/boot/dts

2. Update machine configuration files with new name• Note that device tree source is extension dts• Binary device tree is extension dtb

− KERNEL_DEVICETREE = “<new device tree.dtb>“

3. Build kernel• bitbake –c compile –f linux-imx• bitbake –c deploy –f linux-imx• New device tree should be in tmp/deply/images/<machine>

4. Update uboot • Change the fdt_file parameter to the new device tree.dtb

TM


Yocto Project: Custom Device Tree

• Device Tree reside in arch/arm/boot/dts− Make a copy of arch/arm/boot/dts/imx6q-sabresd.dts− Modify the dts file as per customer’s board differences− Copy the dts file to boot device− Add dtb to machine configuration file - KERNEL_DEVICETREE− bitbake linux-imx to build (or whatever kernel being used – could be linux-fslc)− dtb file will be in tmp/work/deploy/< machine>− U-Boot - Change the fdt_file parameter to the new device tree.dtb

TM


Yocto Project: U-Boot Customization

• Copy board/freescale/mx6sabresd to customer board name - board/freescale/mx6q_customer/

• Make a copy of include/configs/mx6sabresd.h e.g. mx6q_customer_conf.h• Modify boards.cfg file and copy paste the mx6qsabresd line:• Active arm armv7 mx6 freescale mx6sabresd

mx6qsabresd mx6sabresd:IMX_CONFIG=board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg,MX6Q,DEFAULT_FDT_FILE="imx6q-sabresd.dtb",DDR_MB=1024,SYS_USE_SPINOR

• Modify the 6th parameter to specify customer’s directory name under board/freescale – in this case mx6q_customer .

• Modify the 8th parameter to match the customer config name – in this case mx6q_customer_conf

• Modify IMX_CONFIG such that it points to the customer’s DDR settings as collected from DDR calibration process.

• Modify DEFAULT_FDT_FILE to match customer’s device tree file name. • Modify DDR_MB to match the DDR size on customer’s board.

TM


Yocto Project Build: Build and Deploy Uboot

• Look in machine configuration for uboot options• Default is SD boot, so no change needed for SD boot• To change, add line to <build>/conf/local.conf

− UBOOT_CONFIG=“<boot_config”>

$ bitbake u-boot-imx –c deploy

Uboot Type Local.conf

SD boot UBOOT_CONFIG = “sd”

EIM NOR UBOOT_CONFIG = “eimnor”

SPI NOR UBOOT_CONFIG = “spinor”

SATA UBOOT_CONFIG = “sata”

NAND UBOOT_CONFIG = “nand”

TM


Freescale Manufacturing Tool: Details

• Kernel is built with imx_v7_mfg_defconfig

• 3.10.17 released a manufacturing image− bitbake fsl-image-manufacturing− Required extra step of mkimage after building fsl-image-manufacturing.− mkimage -A arm -O linux -T ramdisk -a 0x12c00000 -n "initramfs" -d fsl-image-

manufacturing-imx6qdlsolo.cpio.gz initramfs.cpio.gz.uboot

• 3.10.53 and 3.10.31 use community solution which has manufacturing kernel and u-boot which generates the initramfs.− bitbake fsl-image-mfgtool-initramfs− Uses linux-imx-mfgtool and u-boot-imx-mfgtool recipes.

Installation:• Copy 3 files to mfgtools\Profiles\Linux\OS Firmware\firmware• Change mfgtools's ucl.xml to update file name

TM


Freescale Manufacturing Tool: Kernel Configuration

Manufacturing Install defconfig key section

CONFIG_USB_GADGET=y

# CONFIG_USB_ZERO is not set

# CONFIG_USB_AUDIO is not set

# CONFIG_USB_ETH is not set

# CONFIG_USB_G_NCM is not set

# CONFIG_USB_GADGETFS is not set

# CONFIG_USB_FUNCTIONFS is not set

CONFIG_USB_MASS_STORAGE=y

CONFIG_FSL_UTP=y

# CONFIG_USB_G_SERIAL is not set

# CONFIG_USB_MIDI_GADGET is not set

# CONFIG_USB_G_PRINTER is not set

# CONFIG_USB_CDC_COMPOSITE is not set

# CONFIG_USB_G_ACM_MS is not set

# CONFIG_USB_G_MULTI is not set

# CONFIG_USB_G_HID is not set

# CONFIG_USB_G_DBGP is not set

# CONFIG_USB_G_WEBCAM is not set

TM


Yocto Project Recipe Structure

TM


Yocto Project: Recipe Structure – Initial Questions

• What is component name?• What is component version?• Where is the source?• Does a recipe for this component already exist in another layer – re-use

− Is the same version you want? If desire newer version use existing and upgrade.− Does it need changes like patches or i.mx specific configurations flags?− Look in sources to check other layers – could be in poky or meta-oe or in master branch (look

at internet githubs to check other branches)

• How is source packaged?• Are there patches to apply to a component?• Does component only work on specific i.MX SOC• Does source have autotools or just makefiles?• Does component require special build run time flags?• Does component require special installation?• Does component have build or runtime dependencies?

TM


Yocto Project: Recipes – Recipe Name and Version

• Recipe name is <component>_<version>.bb• Create an include for common features for components that have multiple versions• Version can be internal versions, date or git• Examples:

− U-Boot –imx version is uboot-imx_2014.04.bb− Kernel IMX is linux-imx_3.10.53.bb− In 3.10.53 - Graphics version is gpu-viv-bin_5.0.11.p4.01-hfp.bb− In 3.10.17 – Graphics version is gpu-viv-bin-mx6q_3.10.17-1.1.0-hfb.bb− Recipe name should only have one underscore between component and version but use

hypens in component and version.

• Packaging:− Packages directories packaged as <component>-<version> (hyphen between component

and version) are automatically found − If not packaged in this format must set the S variable− S="${WORKDIR}/${PN}-${PV}-beta“

TM


Yocto Project: Recipes – Source Packaging

• Source is packaged either on git repositories or packages.• For git repositories, know the branch and commit• Example 1:

− Defaults to master branch but on specific commit− SRC_URI = "git://gitorious.org/qt-labs/qt5-everywhere-demo.git“− SRCREV = "6fb348b4e49b0213bf8df09328768b6fdfeda97d"

• Example 2:− Specific to branch but AUTOREV uses latest commit on branch− SRCBRANCH = "imx_v2014.04_3.10.53_1.1.0_ga"− SRC_URI = "git://${FSL_ARM_GIT_SERVER}/uboot-imx.git;protocol=git;branch=$

{SRCBRANCH}"− SRCREV = "${AUTOREV}“

TM


Yocto Project: Recipes – Patches

• Patches can be applied 2 ways to a new recipe or existing recipe with restrictions• First put patch in subdirectory of recipe named <component>• For a new recipe just update SRC_URI with patch name

− Look at imx-test as example – patches applied for mx5

SRC_URI_append_mx5 = " file://revert_epdc_hdr_change.patch − Patch should be in directory of recipe in <comp>/

For example revert_epdc_hdr_change.patch is in meta-fsl-arm/recipes-bsp/imx-test/imx-test/

• Existing recipe in other layers apply patches− Create new append recipe <component>_<version>.bbappend or <component>_

%.bbappend if patch applies to all versions− In recipe

FILESEXTRAPATHS_prepend_mx6 := "${THISDIR}/${PN}:" SRC_URI_append_mx6 = " file://<patch name>”

• Having trouble getting patches applied− Look at fetch and patch log and run files to verify what directories are being searched.

TM


Yocto Project: Recipes – Makefiles and Autotools

• Some components have vanilla makefiles− Yocto Project can build if environment is not hard codec− Make sure makefiles do not hard code CC, CFLAGS or use ?= when setting

environment variables

− Using ?= allows Yocto Project build environment to override

• Some components use auto tools− Yocto project can build if inherit appropriate classes− Add following to recipes to build components that use autotools

inherit autotools pkgconfig

• Some components require other classes to inherit to build− Example glcompbench requires waf class

TM


Yocto Project: Recipe – Reference Variables

Variable Description

${PN} Part Name – component name taken from recipe name

${PV} Version taken from recipe name

${WORKDIR} Working directory under tmp that component is downloaded, built and packaged

${FSL_ARM_GIT_SERVER} Location of external mirror for Freescale packages

${libdir} Location of destination for libraries

${includedir} Location of destination for include headers

${D} Destination working directory

${SOLIBS} Use for .so extensions for libraries

• Poky defines many variables to use recipes in bitbake.conf• Sources/poky/meta/conf/bitbake.conf• Use these variables in recipes – Don’t redefine in recipe

TM


Yocto Project: Recipe – Variables to Set


SRC_URI Location of source – git or package

SRC_URI[md5sum] md5sum of a package – use only for package source

SRC_URI[sha256sum] sha256sum of package – use only for package source

SRCREV Commit hash – use only for git source

S Only set if path of source is not in format <component>-<version>

EXTRA_OEMAKE Allows recipe to override or set specific compile time defines or includes paths

COMPATIBLE_MACHINE Restrict recipe to specific SOC family or chips

DESCRIPTION Description of component built by recipe

LICENSE License of component

LICENSE_FILES_CHKSUM Validates md5sum of license provided by component Licenses can point to specific lines of licenses in headers – see gpu-viv-bin as example.

TM


Yocto Project: Recipe – Optional Variables to Set


DEPENDS Set dependencies on other components required to build first

RDEPDENDS Set runtime dependencies

PE Set only if versioning schema changes like 11.09 to 3.10.17-1.0.0

FILES Specifies files to install into rootfs otherwise might get a QA error

PROVIDES states packages being provided by recipe – required for virtual packages like kernel, libegl

PACKAGES Sets which packages are provided by recipe – used for complex recipes providing multiple packages in one recipe like graphcis

FILESEXTRAPATHS Set path for patches for bbappend recipes

TM


Yocto Project: Recipe – Build environment

• Does Component require Special Settings− DEFINE settings?− Include paths?

• Use EXTRA_OECONF to specify this − EXTRA_OECONF = "PLATFORM=${PLATFORM} -I${STAGING_KERNEL_DIR}/include –

DFLAG1"

• Override makefile – rarely needed− Install – create do_install in recipe− Compile – create do_compile (not needed if EXTRA_OECONF)− Configure – overide do_configure for auto tool components

TM


Yocto Project: Recipe – Installation

• Most makefiles, configurations have installation• QA error in yocto saying files built but not installed• In recipe add FILES statement

− For complex example look at gpu-viv-bin include file− FILES_<component> = “${libdir}/libComponent${SOLIBS}− FILES_<component> = “${bindir}/Example”− FILES_libvivante-mx6 = "${libdir}/libVIVANTE${SOLIBS}“

• Yocto build each component’s installation space under component working directory – check this first before rootfs area

• Rootfs builds go through every components working package directories and consolidate into one rootfs.

• Example scroll to bottom - https://github.com/Freescale/meta-fsl-arm/blob/master/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc

https://github.com/Freescale/meta-fsl-arm/blob/master/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc


TM


Yocto Project: Recipe – Append or Remove

• Variables can be added or restricted− Remove used mostly for sololite which has limited graphics support.

• Use _append to add to a variable− Other option is use +=− Append is better when restricting for an SOC− DEPENDS_append_mx6 = “ package”

• Applies DEPENDS only for i.MX6 SOC DEPENDS_append_mx6q = “ package”

• Applies DEPENDS only for i.MX6 DQ

− DEPENDS += “package”

• Use _remove to remove from a variable• Spaces

− Required for _append− Not required for +=

TM


Yocto Project: Recipe – Build Dependencies

• For building for packages dependent on other packges use− DEPENDS += “package”− DEPENDS += “gpu-viv-bin”− Depends specific to soc only

DEPENDS_append_mx6q = “imx-vpu”

Look at fsl-gpu-sdk which set dynamic depends based on SOC and DISTRO features

https://github.com/Freescale/meta-fsl-demos/blob/dizzy/recipes-graphics/fsl-gpu-sdk/fsl-gpu-sdk_1.1.bb

- DEPENDS = "${WL_DEPENDS}"

− DEPENDS_append_mx6q = " virtual/libgles1 virtual/libgles2"

− DEPENDS_append_mx6dl = " virtual/libgles1 virtual/libgles2"

− WL_DEPENDS = "${@base_contains('DISTRO_FEATURES', 'wayland', 'wayland', '', d)}"



TM


Yocto Project: Recipe – Runtime Dependencies

• Packages should specify run-time dependencies.• Maybe not required to build but required to run on system• Not required for all recipes• Sometimes images do not explicitly state a package• RDEPENDS will force a package to be included on system.• Example

RDEPENDS_${PN} += “ package”

TM


Yocto Project: Recipe – Creating a bbappend

• Recipe already exists in another layer• Bug found and fix created• How to apply this patch in your custom layer• Create a bbappend

− <comp>_%.bbappend Applies to all version− <comp>_<version>.bbappend – Applies to a specific version− Put configuration or recipe file in a subdirectory− In custom layer create a directory for bbappend− In directory create bbappend− Create subdirectory for patch/configuration Subdirectory should be just <comp> for patch that applies to all versions Or <comp>-<version> for patch that applies to specific versions

TM


Yocto Project: Recipe – Inside a bbappend

• Add line FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:“ Means apply this patch first FILESEXTRAPATHS_append := "${THISDIR}/${PN}:“ Mean apply this patch last Patch is in <comp> For patches in <comp>-<version> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"

• To add patch – in example below only adds it for mx6SRC_URI_append_mx6 += " file://add-imx6-support.patch“

Example –

https://github.com/Freescale/meta-fsl-arm/blob/master/recipes-multimedia/alsa/alsa-lib_%25.bbappend



TM


Yocto Project: Recipe – virtual components

• Virtual components are ones which define a generic component that multiple recipes can provide Using PREFERRED_PROVIDERS can specify which provider of a component

Allows more generic names since multiple recipes can provide it but each recipe have a unique name.

For example • linux-fslc and linux-imx both provide virtual/kernel• Gpu-viv-bin and mesa both provide virtual/libegl

Recipes should depend on the virtual not the specific recipes PROVIDES += “ virtual/kernel” is how a recipe states it provides virtual component.

• Example – gpu-viv-bin-mx6q – virtual graphics libraries • https://github.com/Freescale/meta-fsl-arm/blob/master/recipes-graphics/gpu-viv-bin-

mx6q/gpu-viv-bin-mx6q.inc



TM


Yocto Project SOC customization

TM


Yocto Project: SoC Customization

• Recipes can be restricted to specific SOC− COMPATIBLE_MACHINES For recipes that need VPU, machines only with VPU COMPATIBLE_MACHINE = "(mx6q|mx6dl)“

• DEPENDS can be restricted to specific SOC− DEPENDS_append_mx6 = “ gpu-viv-bin”

• Patches applied only to specific SOC− SRC_URI_append_mx6q = file://vpu-only.patch

• Flags only applied to specific SOC− CFLAGS_append_mx6q = “${GST_CFLAGS_EXTRA}”

• Example – imx-test - http://git.freescale.com/git/cgit.cgi/imx/meta-fsl-bsp-release.git/tree/imx/meta-fsl-arm/recipes-bsp/imx-test/imx-test_3.10.31-1.1.0.bb?h=daisy_3.10.31-1.1.0_beta

http://git.freescale.com/git/cgit.cgi/imx/meta-fsl-bsp-release.git/tree/imx/meta-fsl-arm/recipes-bsp/imx-test/imx-test_3.10.31-1.1.0.bb?h=daisy_3.10.31-1.1.0_beta



TM


Yocto Project : SoC extensions

• To make target specific changes to: − System on chip (SoC) family like i.MX 6 Series, i.MX6Q or i.MX6SL− Machine-like i.MX6Q SABRE SD or i.MX 6SLEVK− Recipes can limit builds to a specific SoC family, SoC or boards− Within recipes, settings or tasks can be limited by SoC family, SoC or boards.

• SOC_FAMILY = "mx6:mx6sl"

• Examples between SoC families− PREFERRED_PROVIDER_u-boot_mx6 = "u-boot-imx"− PREFERRED_PROVIDER_u-boot_mx5 = "u-boot-fslc“

• Examples between boards, sololite has no vpu− DEPENDS_mx6q = "virtual/kernel imx-lib imx-vpu"− DEPENDS_mx6sl = "virtual/kernel imx-lib“

TM


Yocto Project : PACKAGE_ARCH

• PACKAGE_ARCH defines how common code and if can be re-used across multiple machines

• For components that have SOC specific features – 2 options− PACKAGE_ARCH = “${MACHINE_SOCARCH}”− PACKAGE_ARCH = “${MACHINE_ARCH}”− MACHINE_SOCARCH combines like SOC

Mx6q, mx6dl and mx6sx all share full featured GPU so recipes that depend on a full GPU should use

MACHINE_SOCARCH. This means gpu-viv-bin is shared across multiple machines requiring less build space and generating faster builds.

− MACHINE_ARCH used for machine specific recipes like kernel and uboot− No PACKAGE_ARCH means it works on all platforms so this is optional

setting.− Look in imx-base.inc in meta-fsl-arm community layer for settings

TM


Yocto Project Images and Package Groups

TM


Yocto Project : Add packages to a build

Three options:

1. local.conf – Add CORE_IMAGE_EXTRA_INSTALLCORE_IMAGE_EXTRA_INSTALL += “ <pkg1> <pkg2> “

2. Add package to the image recipes under IMAGE_INSTALL

3. Create a package group for a set of multiple packages and add package group to the image recipe

TM


Yocto Project: Images

• Image recipes state the components needed for a particular build• Can include an existing recipe and add to it• Can inherit core-image as starting point – defined in poky• IMAGE_FEATURES += “ features “ controls the features included

in the build.• IMAGE_INSTALL += “ package list “ package list for components to

add to the build• One image recipe can include other image recipes.• Example -

http://git.freescale.com/git/cgit.cgi/imx/meta-fsl-bsp-release.git/tree/imx/meta-fsl-demos/recipes-fsl/images/fsl-image-gui.bb?h=daisy_3.10.31-1.1.0_beta




TM


Yocto Project: Package Groups

• Package Groups simplify image recipes by gathering like components into a single group

• inherit package group• PACKAGES += “ package list”• Add RDEPENDS_${PN} = list of packages that package group is

dependent on that must be in the rootfs.• Add packagegroup name to image recipe.• Examples -

http://git.freescale.com/git/cgit.cgi/imx/meta-fsl-bsp-release.git/tree/imx/meta-fsl-demos/recipes-fsl/packagegroup?h=daisy_3.10.31-1.1.0_beta




TM


Yocto Project Debugging

TM


Yocto Project Debugging Tips: Debugging

• Yocto has multiple tasks that it runs.

• Each task has a log output in the component working directory− log.do_<task> shows output of task− run.do_<task> shows content of task

• Yocto Working directory− Example: Kernel working directory <build-dir>/tmp/work/imx6qsabresd-poky-linux-gnueabi/linux-imx/3.10.17-r0/ Log output -- <build-dir>/tmp/work/imx6qsabresd-poky-linux-gnueabi/linux-imx/3.10.17-r0/temp

− Kernel dependent components will go into machine working directories.− Non-Kernel dependent components will go the cortexa9 working

directories.

TM


Yocto Project : Debugging Fetch issues

Common Problems How to Solve

Failure fetch package Look at log.do_fetchSometimes mirror is not working or SRC_URI is incorrectAlso check that correct version is being fetched – version is in the working directory (<build>/<sub dir>/<component>/<version>

Failure to find a patch Check that SRC_URI and directory structure works – look at log.do_fetch to verify patch is found. Log file lists all locations it is looking and make sure patch is in one of those directories.

MD5 errors Sometimes packages change and in dirty builds the recipe no long aligns try a cleanall on component then rebuild. Otherwise use the new md5sum/sha256sum displayed by output

TM


Yocto Project : Debugging Patch issues


Patch not applied Check in bbappend file that FILESEXTRAPATHS is set and directory structure matches.Look in log.do_fetch that patch was fetched and found. If fetched, patch will reside in top directory of the component working directory.

Patch fails to apply Check that patch is applied to correct version of code – maybe other versions exist and using those instead of the version patch was created for.Check version of component is expected one.

TM


Yocto Project : Debugging Version issues


Wrong component built Some components have multiple providers (kernel, uboot for example)

Make sure to set PREFERRED_PROVIDERSPREFERRED_PROVIDER_virtual/kernel_mx6 = “linux-imx”

Wrong version built Some layers might hard code the version (meta-fsl-arm/imx-base.inc)Override using other descriptors from SOC family – the one that is most descriptive winsPREFERRED_VERSION_directfb_mx6q = “1.7.4”

Look at imx-base.inc in meta-fsl-armAnd layer.conf in meta-fsl-bsp-release

Recipe in another layer breaks recipe in other layer

Some recipes can’t be added to or revised. Use BBMASK to mask out other recipes that cause problems and create update in custom layer.

TM


Yocto Project : Debugging Compiler issues


Component has random build break

Usually caused by a missing dependency in the recipe – check for DEPENDS neededThis can show up on faster machines or slower machines and on clean buildsAlso check if build needs clean buildIf using rm_work and dependencies are incorrect, a dependent component might be removed too soon in build.

Component not rebuilding Cache thinks component is already built so must force it to recompilebitbake <comp> -c compile –f

Be careful of doing clean all on a component you made local changes – changes will be lost after a cleanall. That is what patches are for in SRC_URI.

TM


Yocto Project : Debugging Install


QA Error in build about files built but not installed

Recipes needs a FILES_<component> lines to install

Error on installing In build install must create the directories.Install –d creates a directoryInstall is creating subdirectory in <comp>/package directory. Later rootfs will be gather these into common rootfs.

Add a do_install to recipe to create directories via install and copy using install

Packages not in rootfs Check that package directory under component working directory has the files. Check image rootfs working directory has files.

Packages not showing up in SDK builds

SDK builds provide headers for building on target device. These require –dev annd –dbg in the FILES statements. In recipes.

TM


Yocto Project Debugging Tips: Bitbake commands

bitbake command Details

bitbake –c cleanall <component> Cleans downloads and all cache entries for component. Cleans out all entries in working directory!

bitbake –c cleansstate <component> Cleans cache but does not remove the download entry. Cleans out all entries in working directory!

bitbake –c compile –f <component> Forces a recompile of a component. Use after making changes in working directory.

bitbake –c configure –f <component> Forces a reconfigure – useful in kernel if defconfig is changed

bitabke –c menuconfig linux-imx Runs the menu config for the kernel

btibake <component> -v Verbose output on command line (same as what is in the log)

bitbake <component> -k Continue past build breaks until a dependency requires stopping

bitbake <component> -c deploy –f Deploys a component to the rootfs with force – sometimes Yocto thinks a component is already deployed so this forces it

bitbake <component> -g Lists a dependency tree for component

bitbake <image> -c populate_sdk Generates an SDK script to reproduce the rootfs and build environment for non-Yocto Project build systems

TM


Yocto Project Debugging Tips: Preferred Providers

• Multiple recipes can provide same component• Use preferred providers in local or layer.conf.• Bitbake will fail asking which provider if it is not clear

• Community has kernel and uboot• i.MX provides kernel and uboot • Specify which one

• Examples to provide imx as provider− PREFERRED_PROVIDER_u-boot_mx6 = "u-boot-imx“− PREFERRED_PROVIDER_virtual/kernel_mx6 = “linux-imx"

TM


Yocto Project Debugging Tips: Preferred Versions

• Multiple versions of components in different layers

• Build will pick up the highest version unless stated in local.conf.

• Used to designate specific versions of components to build

• Examples:− PREFERRED_VERSION_u-boot-imx_mx6 = "2014-04"− PREFERRED_VERSION_linux-imx_mx6 = "3.10.31”− PREFERRED_VERSION_imx-lib_mx6 = "3.10.31-1.1.0”− PREFERRED_VERSION_imx-test_mx6 = "3.10.31-1.1.0“

TM


Yocto Project : DISTRO_FEATURES

• DISTRO_FEATURES used to enable features for a build• Most commonly used for graphics• DISTRO_FEATURES_append = “ x11”• DISTRO_FEATURES_remove = “ wayland directfb”• Make sure to do a clean build if modifying DISTRO_FEATURES in

a local.conf• Fsl-setup-release does the DISTRO_FEATURES enablement via

the –e option

TM


Yocto Project Debugging Tips: Reducing Build Time

• Share the download folder− In local.conf− DL_DIR = “<directory path>”− Multiple builds will share common downloads, reducing disk space and improving

speed

• Share the state folder− SSTATE_DIR = “<directory path>”− Multiple builds will share state of previous builds to reduce build time. For example,

will not rebuild toolchain.

• Keep track of the tmp/deploy/images contents. • Multiple builds will generate new images and increase disk space usage.• To reduce disk space usage put rm_work in local.conf – this deletes the

source and build and leaves only logs and final output and build – increases build time slightly

INHERIT += rm_work

TM


Yocto Project Debugging Tips: Assistance

Community Email

[email protected]


i.MX Community


Click on Content->Yocto Project

Documents has tips for getting started

mailto:[email protected]



TM


Yocto Project Community

TM


Yocto Project : Community Upstreaming

• Be active member of community• Build on master branch

− repo init -u https://github.com/Freescale/fsl-community-bsp-platform -b master− repo sync− Add patch to meta-fsl-arm/meta-fsl-demos− Generate patch using git format patch− mkdir patch− git format-patch –M –o patch –subject-prefix=“meta-fsl-arm][PATCH” code/yocto− Git send-email to meta-freescale

For git send-email make sure [sendemail] is set in .gitconfig


TM

© 2014 Freescale Semiconductor, Inc. | External Use

www.Freescale.com

http://www.freescale.com/

https://twitter.com/Freescale

https://twitter.com/Freescale

https://www.facebook.com/freescale

https://www.facebook.com/freescale

Confidential and Proprietary TM The Yocto Project and Linux ® Software Development for i.MX Application Processors AMF-SHB-T1056 March.2015 Jay Marcinczyk.

Documents

yocto project introduction

releases yocto project

yocto project environment

yocto project hosts

single project

proprietary tm

tm confidential

freescale yocto community