0. The Yocto Project and Linux® Software Development for i
The Yocto Project and Linux® Software Development for i.MX Application Processors 
AMF-SHB-T1056
Jay Marcinczyk | West Region i.MX SW FAE
March.2015

1. Agenda Introduction Freescale i.MX Releases Get Started Debugging Tips
Internet of Things
Advanced

2. What is the Yocto Project
It's not an embedded Linux distribution, it creates a custom one for you -
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.

3. 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

4. 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

5. Yocto Project Introduction: Development Environment
Source:

6. 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:
Source:
Let’s check out:

7. 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
( or
Mail list for the project:

8. Yocto Project Freescale i.MX Releases

9. Yocto Project Freescale i.MX Releases: History
Description
L on Daisy
Graphics v5, i.MX 6 SoloX, new Uboot, Gstreamer 1.0
L on Dora
Post GA graphics update with updated kernel
L on Dora
Post GA graphics only fixes for GA
L _beta and beta2 on Daisy
Kernel beta with v5 Vivante graphics, GLES 3.0, Gstreamer 1.0, U-Boot , Qt5 support and i.MX 6 SoloX
L _ga on Dora
Kernel GA release with p13 Vivante graphics and manufacturing image

10. 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-> Docs

11. 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.

12. 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

13. Yocto Project Freescale i.MX Releases: 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

14. 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.
GA was based on dora since dora was released in October and our code freeze for GA was before daisy released in April 2014.
GA is based on daisy
We test and release on last Yocto Project release that aligns to our code freeze date.
releases will be based on dizzy.

15. Differences Between 3.10.17 and 3.10.53 GA releases
Graphics
Graphics v4.6.9
DirectFB 1.6.2
Wayland 1.4
Xorg 1.14
fsl-gpu-sdk 1.1
Graphics v5.0.11
OpenGLES 3.0 APIs,
DirectFB 1.7.4
Wayland 1.6
Xorg 1.15 and 1.16
fsl-gpu-sdk 2.0
6slevk fixes for all backends
U-Boot and Kernel
U-Boot
Kernel
Mfgtools –
fsl-image-manufacturing image
U-Boot
Kernel
Mfg 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 on dora
Gcc on daisy
Documentation
Split release notes
Combined release notes and user’s guides – fewer documents

16. Yocto Project : Qt5 Qt5 on 3.10.17-1.0.0_GA is provided as demo only.
Qt5 on has support for X11, FB and Wayland backends.
FSL Graphics DirectFB does not support Qt5.
On 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 –
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.

17. Yocto Project : i.MX FSL QT5 Applications
Starting with – FSL i.MX binary provided for Qt5 player.
Features showcase performance and benchmarking integrated into the Gstreamer 1.0 framework.

18. Yocto Project : Gstreamer 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.

19. 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.

20. Yocto Project : Get Started

21. 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 or 14.04
Step 2 – Install Repo
$ mkdir ~/bin
$ curl  ~/bin/repo
$ PATH=$PATH:~/bin
$ chmod a+x ~/bin/repo

22. Yocto Project Build: Step 3 – Initialize Repo and Start Download
$ mkdir fsl-release-bsp
$ cd fsl-release-bsp
$ repo init -u git://git.freescale.com/imx/fsl-arm-yocto-bsp.git -b imx _ga
$ repo sync
This downloads the Yocto Project layers for the GA release including the release layer.
This does not setup build but it downloads the tools to do the setup in next step.

23. 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

24. 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.

25. 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"/>

26. 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="bee7e3756adf70edaeabe9d aab84f581" 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="5a12677ad000a926d23c a778ea228a7" 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_ _GA">
    <copyfile src="imx/tools/fsl-setup-release.sh" dest="fsl-setup-release.sh" />

27. 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 )
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

28. 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

29. Yocto Project Build: Machine configuration files
imx6qsabresd.conf Example
Machine
Freescale i.MX6Q SABRE Smart Device
i.MX6Q
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"

30. 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

31. Yocto Project Build: Step 6 – Build a Target Image
$ bitbake <image>
What are some of the images available?
In there were image recipes for each backend.
In 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 Non QT image works on all backends
fsl-image-qt5
Only in Freescale image QT image works on X11, Wayland and FB backends (not DirectFB)
fsl-image-x11
Only in Qt4 image
fsl-image-weston
Only in Weston Wayland
fsl-image-fb
Only in Frame buffer image recipe
fsl-image-dfb
Only in DirectFB image recipe

32. 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

33. 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

34. Yocto Project Build: Build and Deploy U-Boot
$ bitbake u-boot-imx –c deploy
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”>
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”

35. Yocto Project Build: Build and Deploy Kernel
$ bitbake linux-imx
Freescale i.MX kernel recipes point defconfig to location in git tree
Community kernel recipes use static defconfig
recipes-kernel/linux/linux-imx_ /mx6/defconfig
Uboot type
Local.conf
Default config
FSL_KERNEL_DEFCONFIG = "imx_v7_defconfig"
Manufacturing image
FSL_KERNEL_DEFCONFIG = "imx_v7_mfg_defconfig"

36. Yocto Project Build: Adding new device trees
Create device tree in kernel source arch/arm/boot/dts
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>“
Build kernel
bitbake –c compile –f linux-imx
bitbake –c deploy –f linux-imx
New device tree should be in tmp/deply/images/<machine>
Update uboot
Change the fdt_file parameter to the new device tree.dtb

37. 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 beta release
bsp.git/tree/README?h=imx _beta
Community currently has in dizzy and master branches
Soon will have _beta in master branch

38. Yocto Project Debugging Tips

39. Yocto Project Debugging Tips: Bitbake commands
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

40. 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“

41. 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 = " "
PREFERRED_VERSION_linux-imx_mx6 = " ”
PREFERRED_VERSION_imx-lib_mx6 = " ”
PREFERRED_VERSION_imx-test_mx6 = " “

42. 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“

43. 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 descriptor PREFERRED_VERSION_linux-imx_mx6q = “ ”
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.

44. Yocto Project Debugging Tips: Examples
Community settings
arm/blob/master/conf/machine/include/imx-base.inc
Release – Settings
release.git/tree/imx/meta-fsl-arm/conf/layer.conf?h=daisy_ _beta
Look at directfb in layer.conf how we override community directfb version in imx-base.inc

45. 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/ r0/
Log output -- <build-dir>/tmp/work/imx6qsabresd-poky-linux-gnueabi/linux- imx/ r0/temp
Kernel dependent components will go into machine working directories.
Non-Kernel dependent components will go the cortexa9 working directories.

46. 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.

47. 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.

48. 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”

49. 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

50. Yocto Project Debugging Tips: Assistance
Community
i.MX Community
Click on Content->Yocto Project
Documents has tips for getting started

51. Yocto Project: Internet of Things

52. 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

53. 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 GA
Will be rebased to after release
Suitcase Demo
Open source solution and 3rd party solution using Java

54. 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

55. Yocto Project: Advanced T0948 Session

56. 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

57. Yocto Project Creating Custom Machines and Layers

58. 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

59. Yocto Project: Custom Machine Configurations
How to Build
Two options – change build configuration or specify with bitbake
Existing build – edit local.conf and change MACHINE to new machine
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

60. Yocto Project: Vendor machines
Vendor machine board configuration files reside in meta-fsl-arm- extra
extra/tree/master/conf/machine
Vendor machine kernel recipes and other vendor specific recipes.
kernel/linux
Upstream into community through meta-freescale mailing list into master branch to be part of next Yocto Project release.

61. Yocto Project Build: Machine configuration files
Imx6qsabresd.conf Example
Machine
Freescale i.MX6Q SABRE Smart Device
i.MX6Q
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"

62. 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

63. Yocto Project: Example layer meta-fsl-demos
Sample Layer Configuration – layer.conf
demos/conf/layer.conf?h=daisy_ _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 "

64. Yocto Project Kernel and U-Boot Configurations

65. Yocto Project Build: Build and Deploy Kernel
$ bitbake linux-imx
Freescale i.MX kernel recipes point defconfig to location in git tree
Example _Beta2 – imx_v7_defconfig
imx.git/tree/arch/arm/configs?h=imx_ _1.1.0_beta2
Community kernel recipes use static defconfig
recipes-kernel/linux/linux-imx_ /mx6/defconfig
Default kernel is linux-imx uses imx_v7_defconfig
and Manufacturing kernel recipe is linux-imx-mfgtool
Manufacturing kernel recipe is linux-imx with imx_v7_mfg_defconfig

66. 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
kernel/linux/linux-imx_ bb?h=daisy_ _beta
Community releases
Static config with kernel recipes called defconfig
/mx6/defconfig

67. Yocto Project Build: Adding new device trees
Create device tree in kernel source arch/arm/boot/dts
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>“
Build kernel
bitbake –c compile –f linux-imx
bitbake –c deploy –f linux-imx
New device tree should be in tmp/deply/images/<machine>
Update uboot
Change the fdt_file parameter to the new device tree.dtb

68. 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

69. 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.

70. Yocto Project Build: Build and Deploy Uboot
$ bitbake u-boot-imx –c deploy
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”>
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”

71. Freescale Manufacturing Tool: Details
Kernel is built with imx_v7_mfg_defconfig
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 0x12c n "initramfs" -d fsl- image-manufacturing-imx6qdlsolo.cpio.gz initramfs.cpio.gz.uboot
and 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

72. 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

73. Yocto Project Recipe Structure

74. 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?

75. 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_ bb
Kernel IMX is linux-imx_ bb
In Graphics version is gpu-viv-bin_ p4.01-hfp.bb
In – Graphics version is gpu-viv-bin-mx6q_ 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“

76. 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 = "6fb348b4e49b0213bf8df b6fdfeda97d"
Example 2:
Specific to branch but AUTOREV uses latest commit on branch
SRCBRANCH = "imx_v _ _1.1.0_ga"
SRC_URI = "git://${FSL_ARM_GIT_SERVER}/uboot- imx.git;protocol=git;branch=${SRCBRANCH}"
SRCREV = "${AUTOREV}“

77. 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.

78. 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

79. Yocto Project: Recipe – Reference Variables
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
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

80. Yocto Project: Recipe – Variables to Set
Description
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.

81. Yocto Project: Recipe – Optional Variables to Set
Description
DEPENDS
Set dependencies on other components required to build first
RDEPDENDS
Set runtime dependencies PE
Set only if versioning schema changes like to
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

82. 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

83. 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 - arm/blob/master/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc

84. 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 +=

85. 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
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 = 'wayland', 'wayland', '', d)}"

86. 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”

87. 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

88. 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 mx6
SRC_URI_append_mx6 += " file://add-imx6-support.patch“
Example –
lib_%25.bbappend

89. 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
bin-mx6q/gpu-viv-bin-mx6q.inc

90. Yocto Project SOC customization

91. 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 fsl-bsp-release.git/tree/imx/meta-fsl-arm/recipes-bsp/imx-test/imx- test_ bb?h=daisy_ _beta

92. 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“

93. 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

94. Yocto Project Images and Package Groups

95. Yocto Project : Add packages to a build
Three options:
local.conf – Add CORE_IMAGE_EXTRA_INSTALL
CORE_IMAGE_EXTRA_INSTALL += “ <pkg1> <pkg2> “
Add package to the image recipes under IMAGE_INSTALL
Create a package group for a set of multiple packages and add package group to the image recipe

96. 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 - release.git/tree/imx/meta-fsl-demos/recipes-fsl/images/fsl-image- gui.bb?h=daisy_ _beta

97. 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 - release.git/tree/imx/meta-fsl-demos/recipes- fsl/packagegroup?h=daisy_ _beta

98. Yocto Project Debugging

99. 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/ r0/
Log output -- <build-dir>/tmp/work/imx6qsabresd-poky-linux-gnueabi/linux- imx/ r0/temp
Kernel dependent components will go into machine working directories.
Non-Kernel dependent components will go the cortexa9 working directories.

100. Yocto Project : Debugging Fetch issues
Common Problems
How to Solve
Failure fetch package
Look at log.do_fetch
Sometimes mirror is not working or SRC_URI is incorrect
Also 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

101. Yocto Project : Debugging Patch issues
Common Problems
How to Solve
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.

102. Yocto Project : Debugging Version issues
Common Problems
How to Solve
Wrong component built
Some components have multiple providers (kernel, uboot for example)
Make sure to set PREFERRED_PROVIDERS
PREFERRED_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 wins
PREFERRED_VERSION_directfb_mx6q = “1.7.4”
Look at imx-base.inc in meta-fsl-arm
And 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.

103. Yocto Project : Debugging Compiler issues
Common Problems
How to Solve
Component has random build break
Usually caused by a missing dependency in the recipe – check for DEPENDS needed
This can show up on faster machines or slower machines and on clean builds
Also check if build needs clean build
If 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 recompile
bitbake <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.

104. Yocto Project : Debugging Install
Common Problems
How to Solve
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 directory
Install 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.

105. Yocto Project Debugging Tips: Bitbake commands
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

106. 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"

107. 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 = " "
PREFERRED_VERSION_linux-imx_mx6 = " ”
PREFERRED_VERSION_imx-lib_mx6 = " ”
PREFERRED_VERSION_imx-test_mx6 = " “

108. 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

109. 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

110. Yocto Project Debugging Tips: Assistance
Community
i.MX Community
Click on Content->Yocto Project
Documents has tips for getting started

111. Yocto Project Community

112. Yocto Project : Community Upstreaming
Be active member of community
Build on master branch
repo init -u -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- to meta-freescale
For git send- make sure [send ] is set in .gitconfig