introduction to yocto project™ tools for i.mx and qoriq ... · freescale i.mx bsp releases are...

External Use

TM

Introduction to Yocto Project™ Tools

for i.MX and QorIQ SDKs, Part 1

FTF-DES-F1189

J U N E . 2 0 1 5

Lauren Post | i.MX Yocto Project Team Lead

Richard Schmitt | Digital Networking QorIQ Team Lead

TM

External Use 1 #FTF2015

Agenda

• Yocto Project Introduction

• Repo

• Freescale i.MX

• Freescale QorIQ

• BitBake

• Build Structure

• Board Bringup

• BitBake and Git

• Customization

• QoriQ Emulation

• QorIQ ADT with Target Board

• Device Trees

• Debug Help

TM


Yocto Project Introduction

TM


Yocto Project Introduction: What is the Yocto Project?

• “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.”

• Helps developers create custom Linux-based systems for embedded products

• Many individuals and companies, including Freescale, Intel, TI, Wind River, Mentor

Graphics are contributing to the Yocto Project

• Freescale is an active part of the upstream community and is a full Yocto Project

Member and a member of the Advisory Board

Source: www.yoctoproject.org

TM


Yocto Project Introduction: Building Blocks

• OpenEmbedded Core: core metadata and build information to build

baseline embedded systems

• Poky: Yocto Project example distribution which integrates all the required

pieces and makes an official release. Poky contains common components,

toolchain and bitbake engine

• Bitbake: parses metadata and runs tasks. At the core of Poky is the

bitbake task executor together with various types of configuration files

• 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 poky, meta-freescale

TM


Yocto Project Introduction: Yocto Project Releases

Yocto Project has releases on 6 month cycles approximately

every October and April. Releases are named in month of release.

Next Release: Yocto Project 1.9 (unnamed) in October 2015

Latest Releases: Yocto Project 1.8 (Fido) in April 2015

Past releases:

• Yocto Project 1.7 (Dizzy) in October 2014

• 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: Overview

TM


Yocto Project Introduction: Layers

The OpenEmbedded build system supports organizing Metadata into

multiple layers. Layers allow you to isolate different types of customizations

from each other.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://www.yoctoproject.org/docs/1.6/dev-manual/dev-manual.html

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

TM


Yocto Project Introduction: Documentation

The Yocto Project documentation is available on the Yocto Project

website: (https://www.yoctoproject.org/documentation)

Recommended Reading:

1. Yocto Project Complete Documentation (Link)

2. BitBake User Manual (Link)

3. Yocto Project Reference Manual (Link)

https://www.yoctoproject.org/documentation

http://www.yoctoproject.org/docs/1.6.1/mega-manual/mega-manual.html

http://www.yoctoproject.org/docs/1.6.1/bitbake-user-manual/bitbake-user-manual.html

http://www.yoctoproject.org/docs/1.6.1/ref-manual/ref-manual.html

TM


Yocto Project Introduction: Host Build Machine Setup

Yocto Project Supported Distributions — Check this for supported systems for a host build machine.

For i.mx, on Ubuntu common tools installation

$ sudo apt-get install gawk wget git-core diffstat unzip texinfo gcc-multilib build-essential chrpath socat

For i.MX, on Ubuntu 12.04

$ sudo apt-get install uboot-mkimage

For i.MX, on Ubuntu 14.04

$ sudo apt-get install u-boot-tools

For QorIQ on supported host distro and release

$ sudo poky/scripts/host-prepare.sh

http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html

TM


Transition

TM


Transition: Why Present i.MX and QorIQ together?

• Goal of common Freescale ease of use

• Many synergies created by using Yocto Project environment

• Working toward a combined Yocto Project build environment for

i.MX and QorIQ by using new layer meta-freescale

• New layer meta-freescale based on meta-fsl-arm

• New environment supports building QorIQ arm and powerpc and

i.MX in same build directory

• When?

− Jun 22, 2015

− Parallel releases until end of 2015 then only meta-freescale.

− Each product lines delivers releases as previous method then only with

meta-freescale in 2016

TM


Transition: Introducing meta-freescale

• Based on meta-fsl-arm with all its history

• Available on git.freescale.com starting 6/22/2015

• QorIQ and i.MX release on new branch fido_freescale.

• Goal is align on product lines for i.MX and QorIQ and support

common recipes

• meta-imx — Includes i.MX specific meta-data

• meta-qoriq — Includes QorIQ specific meta-data

• common — Common recipes for all Freescale Yocto Project

TM


Transition: What is common?

• Common means it contains no product line specific configuration.

• Common Setup Build environment – fsl-setup-env

• Common recipes

• Common package groups

• Common images — Each product line uses package groups to add

product line specific packages

• Common layer configuration — Both product lines included for all

setup so that one build environment will build all Freescale

machines

• Manifest — previously fsl-arm-yocto-bsp to fsl-yocto-repo

TM


Transition: meta-imx in meta-freescale

• Include some contents from meta-fsl-arm used as base

• Additions include image recipes and package groups

• Big change is primarily directory structure

• Uses DISTRO fsl-imx-release to configure build for all backends.

• Poky will build for community.

TM


Transition: meta-qoriq in meta-freescale

• QorIQ — ARM and PowerPC consolidated with common kernel and

U-boot

• SDK 1.7 available

• SDK 1.8 available soon

• meta-fsl-ppc deprecated with SDK 1.9

TM


Transition: Milestones

• Jun 22, 2015 — consolidation of i.MX 3.14.28 GA and QorIQ SDK

1.7 in one layer

• Updated once monthly until migration complete

• Summer 2015 — QorIQ SDK 1.8 and i.MX 3.14.38 beta releases

• Fall 2015 — i.MX 3.14 GA releases for new SoC

• December 2015 —

− QorIQ SDK 1.9 released only on meta-freescale

− i.MX 3.14.38-1.1.0 GA release only on meta-freescale

TM


Repo

TM


Repo : What is Repo?

• Repo is a tool that Google built on top of Git

• Repo helps manage multiple Git repositories

• Repo is not meant to replace Git

• The repo command is an executable Python

script that you can put anywhere in your path

• Currently i.MX uses repo

• QorIQ moving toward use repo

Repo repository and cheat sheet: Link

https://code.google.com/p/git-repo/

TM


Repo : Transition

• i.MX used fsl-arm-yocto-bsp

• Transition to combined manifest to use with

QorIQ

• fsl-yocto-repo on git.freescale.com

− Available on 6/22/2015

• Current releases still work with fsl-arm-yocto-

bsp but slides show new manifest repository

TM


Repo: Initial Repo Setup

i.MX, and now the QorIQ, use the repo manifest to configure

additional release layer.

To install the repo tool$ mkdir ~/bin

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

$ chmod a+x ~/bin/repo

$ PATH=${PATH}:~/bin

To setup i.MX 3.14.28-1.0.0 GA release or QorIQ 1.7 release$ mkdir fsl-yocto-bsp

$ cd fsl-yocto-bsp

$ repo init -u git://git.freescale.com/yocto/fsl-yocto-repo.git -b yocto-fsl-20150622

$ repo sync

TM


Repo: Repo Sync

• We run repo sync and this goes to each git repository that is defined in the manifest.xml file and clones the project that is specified. Example shown from i.MX

$ repo sync

< Including a subset – not showing all output >

• From http://sw-stash.freescale.net/scm/yocto/meta-freescale

• * [new branch] fido -> fsl-release/fido

• * [new branch] fido_freescale -> fsl-release/fido_freescale

• * [new branch] master -> fsl-release/master

• From http://sw-stash.freescale.net/scm/yocto/meta-freescale-extra

• * [new branch] fido -> fsl-release/fido

• * [new branch] master -> fsl-release/master

• Fetching projects: 62% (5/8) Fetching project meta-openembedded

• From git://git.openembedded.org/meta-openembedded

• * [new branch] fido -> oe/fido

• * [new branch] master -> oe/master

• Fetching projects: 75% (6/8) Fetching project meta-fsl-demos

• From git://github.com/Freescale/meta-fsl-demos

• * [new branch] fido -> freescale/fido

• * [new branch] master -> freescale/master

• Fetching projects: 87% (7/8) ^[[5~From git://git.yoctoproject.org/poky

• * [new branch] fido -> yocto/fido

• * [new branch] master -> yocto/master

Some output

omitted for clarity

TM


Repo: Repo Initialization

• Repo pulls Yocto Project layers from multiple git repositories based

on the manifest for the particular branch we are using. In this case

we will use the i.MX 3.14.28 GA release based on the Yocto Project

Fido release (1.8). Link to manifest — Manifest Link

$ repo init -u git://git.freescale.com/yocto/fsl-yocto-repo.git -b yocto-fsl-20150622

note:

-u is the manifest url

-b is the manifest branch or revision

• Repo init creates a .repo hidden directory that contains information

that tells repo what git repositories and commits to pull into our

directory. Repo doesn’t download the layers until repo sync

http://git.freescale.com/git/cgit.cgi/imx/fsl-arm-yocto-bsp.git/tree/default.xml?h=imx-3.14.28-1.0.0_ga

TM


Freescale i.MX

TM


Freescale i.MX: Documentation

[fsl-yocto-<kernel>]├──i.MX Linux User’s Guide├──i.MX Linux Release Notes├──i.MX VPU API├── i.MX Graphics User’s

Guide├──i.MX BSP Porting Guide├──i.MX Linux Reference

Manual└── Freescale Yocto Project

User’s Guide

Documentation — freescale.com/imx —

GA docs only.

Click i.MX6 box-> i.MX6 SW and Dev

Tools->Linux->3.14.28 Docs

http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=IMX6_SW

TM


Freescale i.MX: Yocto Project Recent History

Release Description

Alpha L3.14.28-7D_alpha Alpha release of new SoC imx7dsabresd

Patch L3.14.28-1.0.1 on Dizzy Graphics update

GA L3.14.28-1.0.0 on Dizzy Kernel upgrade to 3.14.28 including i.MX 6 Auto

CPU2 update

Patch L3.10.53-1.1.1 on Daisy CPU2 update

GA L3.10.53-1.1.0 on Daisy Graphics v5, i.MX 6 SoloX, U-Boot 2014.04,

Gstreamer 1.0

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

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

GA L3.10.17-1.0.0_ga on Dora Kernel 3.10.17 GA release with p13 Vivante

graphics and manufacturing image

TM


Freescale i.MX: Yocto Project Release Upstream

Freescale i.MX BSP releases are based on Yocto Project releases.

Each release is upstreamed into future Yocto release

Dora Daisy Dizzy Fido ‘ Yocto 1.9

Yocto Branches

• Community branches not tested by Freescale in release process

• Community might have additional patches

• i.MX can build with community or BSP release layer

QoriQ

i.MX 3.10.53QoriQ

i.MX 3.10.17i.MX 3.14.28 i.MX 3.14.38

New Chipsi.MX 3.10.53i.MX 3.10.17 i.MX 3.14.28

TM


Release 3.10.17-1.0.0 3.10.53-1.1.0 3.14.28-1.0.0

Graphics Graphics v4.6.9

DirectFB 1.6.2

Wayland 1.4

Xorg 1.14

fsl-gpu-sdk 1.1

Graphics v5.0.11p4.1

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

Graphics v5.0.11p4.4

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 2013.04

Kernel 3.10.17

Mfgtools —

fsl-image-manufacturing

image

U-Boot 2014.04

Kernel 3.10.53

Mfg tools —

fsl-image-mfgtool-initramfs

U-Boot 2014.04

Kernel 3.14.28

Mfg tools —

fsl-image-mfgtool-initramfs

New Hardware none 6 SoloX 6 Q/DL CPU2 Auto

Multimedia Gstreamer 0.1 Gstreamer 1.0 and 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

Qt5.2.1 support on X11, FB and

Wayland

Toolchain +

Yocto Project

Gcc 4.8.1 on dora Gcc 4.8.2 on daisy Gcc 4.9.1 on dizzy

Documentation Split release notes Combined release notes and

user’s guides — fewer

documents

Same as 3.10.53

Freescale i.MX: Differences between releases

TM


Freescale i.MX: 3.14.28-1.0.0 Information

• 3.14.28-1.0.0 GA released in April 2015

• Supports all i.MX 6 released in 3.10.53-1.1.0 but with a kernel

upgrade to 3.14.28

• New license change and inclusion of Software Content Registers

that list origins and details of each release

TM


Freescale i.MX: 2015 new SoC and Release Information

• Includes multiple releases for following new SoC

− i.MX 6QP Sabre SD and Auto

Standalone Beta and standalone GA

− i.MX 6UL EVK

Standalone Beta with 7D and standalone GA

− i.MX 7D Sabre SD

Standalone alpha, beta with 6UL and consolidated GA

− 3.14.38-1.1.0 GA will include testing on all i.MX 6 Q/DL/SX/SL and new

SoC and 2015.04 U-Boot in late 2015

− Standalone means only tested on that board. Release might work on

other boards but not tested.

TM


Freescale BSP Releases: Setup i.MX Build

• Freescale BSP release requires using Freescale setup which calls

community setup. Must know which graphics backend. X11 is

default. Default machine is imx6qsabresd

• The machine name tells setup script which board you will be using

for development$ MACHINE=<machine-name> source fsl-setup-env.sh –b <build-directory>

• Example using Freescale i.MX6Q SABRE Auto and Framebuffer

$ DISTRO=imx-release-fb MACHINE=imx6qsabreauto source fsl-setup-env.sh –b build-

fb

TM


Freescale i.MX: Machine Decision to Setup Build

• Decide target machine to setup and build

• Machine Configurations define the properties for specific boards

• Machines align to specific product lines like i.MX and Layerscape

• Know which board and choose machine to configure system

• 3rd party i.MX boards are available in meta-freescale-extra

• i.MX reference boards are available on meta-freescale

Note: One build directory can support multiple machines.

TM


Freescale i.MX: i.MX Machines

• i.MX 6 Machine configurations

• Legacy i.MX machines include imx53qsb, imx28evk among others

• 3rd party boards in meta-freescale-extra such as Wandboard,

Nitrogen, RIoT, CuBox board among others

Machine Board Descriptions

imx6qsabresd, imx6qsabreauto i.MX 6Q SABRE SD and SABRE Auto

imx6dlsabresd, imx6dlsabreauto i.MX 6DL SABRE SD and SABRE Auto

imx6solosabresd imx6solosabreauto i.MX 6Solo SABRE SD and SABRE Auto

imx6sxsabresd, imx6sxsabreauto i.MX 6SoloX SABRE SD and SABRE Auto

imx6slevk i.MX 6SoloLite EVK

TM


Freescale i.MX: Machine Example

#@TYPE: Machine

#@NAME: Freescale i.MX6Q SABRE Smart Device

#@SOC: i.MX6Q

#@DESCRIPTION: Machine configuration for Freescale i.MX6Q SABRE Smart Device

#@MAINTAINER: Otavio Salvador <[email protected]>

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

SOC_FAMILY = "mx6:mx6q"

KERNEL_DEVICETREE = "imx6q-sabresd.dtb imx6q-sabresd-ldo.dtb imx6q-sabresd-hdcp.dtb \

imx6q-sabresd-enetirq.dtb imx6q-sabresd-uart.dtb"

UBOOT_CONFIG ??= "sd"

UBOOT_CONFIG[sd] = "mx6qsabresd_config,sdcard"

UBOOT_CONFIG[sata] = "mx6qsabresd_sata_config"

UBOOT_CONFIG[mfgtool] = "mx6qsabresd_config"

TM


Freescale i.MX: i.MX Target Yocto Project Images

What are some of the images available?

• 3.10.53 and 3.14.28 we have only 2 — with and with Qt5

• 3.10.17 (not shown) has image recipes based on graphics backend.

Targt image Description

core-image-minimal Kernel image command prompt

fsl-image-gui Only in 3.14.28 and 3.10.53

- Non QT image works on all backends.

- Supports full multimedia and graphics including demos and unit tests

fsl-image-qt5 Only in 3.10.53 and 3.14.28

- Adds everything from fsl-image-gui.

- Adds Qt5 base and examples.

- No supported for DirectFB.

$ bitbake <image>

Note: Community has additional image recipes.

TM


Freescale i.MX: 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/<machine>

$ cat proc/partitions

$ sudo dd if=fsl-image-gui-<machine>.sdcard of=<sd card device> bs=1M && sync

TM


Freescale i.MX: 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”>

− Look at machine configuration file to see possible UBOOT_CONFIG options.

i.MX 6 SoloX supports m4, qspi, emmc

$ bitbake u-boot-imx

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


Freescale i.MX: Build and Configure 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.14.28/mx6/defconfig

• To update config

$ bitbake –c menuconfig linux-imx

$ bitbake linux-imx

Kernel ach/arm/configs Recipe

Default Kernel imx_v7_defconfig linux-imx_<version>.bb

Manufacturing

image kernel

imx_v7_mfg_defconfig linux-imx-mfgtools_<version>.bb

TM


Freescale i.MX: Qt5 Features

• Freescale Graphics DirectFB does not support Qt5

• On 3.10.53 build fsl-image-qt5 to build an image with Qt5

• Fido uses QT 5.4, Dizzy uses QT 5.3, Daisy uses Qt 5.2

• Starting with 3.10.53 — Freescale i.MX binary provided for Qt5

player

• Features showcase performance and benchmarking integrated into

the Gstreamer 1.0 framework

TM


Freescale i.MX: Qt5 Licensing

• 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


Freescale i.MX: Gstreamer 1.0

• 3.10.53-1.1.0 was first GA release to include Freescale i.MX

Gstreamer 1.0 support. 3.14.28-1.0.0 continues support

• Community Gstreamer 1.0 gstreamer-imx

− This is not developed by Freescale - resides in community

− Not supported by Freescale

• Customers can choose which Gstreamer they want to use by use

MACHINE_GSTREAMER_1_0_PLUGIN

− MACHINE_GSTREAMER_1_0_PLUGIN_<soc> = “gst1.0-fsl-plugin”

TM


Freescale i.MX: Vivante Graphics

• i.MX supports 4 backends with Vivante 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 specified in local.conf

TM


Freescale i.MX: Graphics DISTRO_FEATURES Examples

• Table below shows the DISTRO_FEATURES for each backend

• Frame buffer does not have a specific distro feature but is the

absence of X11,DirectFB and Wayland

• Without any changes — 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


Freescale i.MX: License Agreement

• Freescale releases packages on external mirror

• Proprietary packages are packaged as self-extracting binaries with our 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

• Each release has a Software Content Register listing packages and license

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

TM


Freescale QorIQ

TM


Freescale QorIQ: Documentation

QorIQ SDK documentation:

[sdk_documentation/pdf/yocto]├── adt-manual.pdf├── bsp-guide.pdf├── dev-manual.pdf├── kernel-dev.pdf├── kernel-manual.pdf├── poky-ref-manual.pdf └── profile-manual.pdf

TM


Freescale QorIQ: SDK Release History

• SDK 1.4 is based off the Yocto 1.4 "dylan" release

• SDK 1.5 is based off Yocto 1.5 “dora” release

• SDK 1.6 is based off Yocto 1.6 “daisy” release

• SDK 1.7 will be based off Yocto 1.7 “dizzy”

• SDK 1.8 will be based off Yocto 1.8 “fido”

• Alignment of release numbering just coincidence

• Freescale has created QorIQ specific layers, that can be "plugged"

into the Yocto build system, allowing users to build for Freescale

target machines

TM


Freescale QorIQ: Something New For LS1021

• Distribution

− Previous SDK was a Distribution

− Full Linux and Tools release

− Twice a year releases

− All platforms, All packages

• BSP

− Leverages Yocto Project Poky Distribution

− Provides only changes over distro

− NPI support separately qualified

− Released with NPIs

• Sign of Things to Come

• For now, Both SDK and BSP are available.

TM


Freescale QorIQ: Start with the Yocto Distribution

Note Git Clone URL for Dizzy 1.7 releases

TM


Freescale QorIQ: Add the Layerscape LS1 BSP

Note Git clone URL for ls1021atwr BSP

TM


Freescale QorIQ: Build Setup

$ mkdir fsl-arm-yocto-bsp

$ mkdir fsl-arm-yocto-bsp/sources

$ cd sources

$ git clone -b dizzy git://git.yoctoproject.org/poky.git

$ git clone git://git.yoctoproject.org/meta-fsl-arm -b dizzy

$ cd ..

$ source poky/oe-init-build-env <build-dir>

Edit <build-dir>/conf/bblayers.conf and add this line

BBLAYERS += " ${BSPDIR}/sources/meta-fsl-arm“

Edit <build-dir>/conf/local.conf

• Change MACHINE to “ls1021aqds”

• Add line at the bottom

IMAGE_FSTYPES = "tar.gz ext2.gz ext2.gz.u-boot jffs2“

TM


Freescale QorIQ: : Machines

Layerscape machine configurations

Machine Board Descriptions

ls1021aqds LS1021AQDS board

ls1021atwr LS1021ATWR board

TM


Freescale QorIQ: Machine Example

#@TYPE: Machine

#@NAME: Freescale LS1021AQDS board

#@SOC: ls102xa

#@DESCRIPTION: Machine configuration for running LS1021AQDS in 32-bit mode

#@MAINTAINER: Zhenhua Luo [email protected]

require conf/machine/include/ls-base.inc

require conf/machine/include/tune-cortexa7.inc

SOC_FAMILY = "ls102xa“

UBOOT_CONFIG ??= "nor"

UBOOT_CONFIG[nor] = "ls1021aqds_nor_config"

UBOOT_CONFIG[qspi] = "ls1021aqds_qspi_config"

UBOOT_CONFIG[nor-secboot] = "ls1021aqds_nor_secboot_config"

UBOOT_CONFIG[lpuart] = "ls1021aqds_lpuart_config"

UBOOT_CONFIG[sdcard] = "ls1021aqds_sdcard_config“

QE_UCODE="iram_Type_A_LS1021a_r1.0.bin“

KERNEL_DEVICETREE = "ls1021a-qds.dtb“

SERIAL_CONSOLES ?= "115200;ttyS0 115200;ttyS1 115200;ttyEHV0 115200;ttyLP0 115200;ttyAMA0"

SERIAL_CONSOLES_CHECK ?= "${SERIAL_CONSOLES}"

USE_VT ?= "0"

mailto:[email protected]

TM


Freescale QorIQ: Build the LS1 BSP

Similar to building with ISOs.

Currently we do not provide a ‘fsl-image-*’ image so we need to provide more build components.

$ cd fsl-arm-yocto-bsp

$ source sources/poky oe-init-build-env <build-dir>

$ bitbake meta-toolchain

$ bitbake core-image-minimal

$ bitbake u-boot

$ bitbake rcw

$ bitbake gdb-cross

TM


BitBake

TM


BitBake: Description

BitBake

• BitBake is a build engine that follows recipes in a specific format in

order to perform sets of tasks. BitBake is a core component of the

Yocto Project

• Example bitbake <component>

TM


BitBake: Syntax Options

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

bitbake <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> D-D, –debug Can specify –D, –DD or –DDD to increase debug level

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


BitBake: Generating an Image

$ bitbake <image>

For each bitbake command, poky parses all the recipes in all

the layers to create a task list. After the parsing, the task list

will start. Tasks include configure, fetch, patch, compile,

install, deploy plus others. Each package will have several

tasks. To see log of each task, look in

tmp/work/<>/<package>/temp/log.do_<task>

For each task completed, poky stores that state information

in the sstate-cache so future builds don’t redo that task

again.

TM


BitBake: What Is Generated Image

• The generated image is inside the directory

<build-dir>/tmp/deploy/images/<machine>$ <build_dir>/tmp/deploy/images/<machine>

*** More file are in the directory but here is a sample ***

Rootfs - <image>-<machine>.ext3

SDCard - <image>-<machine>.sdcard

Kernel - <image>-<machine>.bin

SD card image is a bootable image that includes uboots and device trees. Ext3 is a the rootfs for NFS.

Also includes uboots, device trees. Generic names above are links to date stamped files. Each bitbake

generates a new time stamp with the generic names above pointing to most recent build.

Watch for multiple builds generating large files using up disk space. Check this directory to remove old builds

TM


BitBake: Common Tasks

Listing BitBake tasks for a recipe or image

$bitbake <package> -c listtasks

Useful tasks that you can run manually for most packages:

• Task sequence run for generic bitbake <package> :

fetch > unpack >patch > configure > compile > install > package >

package_write

• Bitbake can build multiple images/packages at same time

build clean cleansstate compile

configure install listtasks patch

populate_sysroot rm_work

TM


BitBake: Configure the Kernel

Example: bitbake linux-imx –c menuconfig

TM


BitBake: Dependency Graphs

• bitbake -g <target>

• bitbake -g -u depexp <target>

− pn-buildlist

− pn-depends.dot

− task-depends.dot

− package-depends.dot

• dot -Tpng -o pn-depends.png pn-

depends.dot

• Graph files not very useful. Use:

bitbake –g –u depexp <target>

TM


BitBake: Layer Management

• The BitBake layer management tool provides a view into the structure of recipes across a multi-layer project

$ bitbake-layers <command> [arguments]

The following list describes the available commands:

• help: Displays general help or help on a specified command.

• show-layers: Shows the current configured layers

• show-recipes: Lists available recipes and the layers that provide them

• show-overlayed: Lists overlayed recipes

• show-appends: Lists .bbappend files and the recipe files to which they apply

• show-cross-depends: Lists dependency relationships between recipes that cross layer boundaries

TM


Build Structure

TM


Build Structure: Make Image Files Accessible

After successful build of an images, Deploy the images to the tftp

directory accessible to the board’s u-boot

Example with QorIQ machine ls1021aqds

$ mkdir -p /tftpboot

$ cd <build-dir>/tmp/deploy/images

$ cp –r ls1021aqds /tftpboot

TM


Build Structure: What's in a File System Image

$ bitbake -g core-image-minimalLoading cache: 100%|################################################################|ETA: 00:00:00Loaded 1161 entries from dependency cache.Parsing recipes: 100%|################################################################|Time: 00:00:00Parsing of 859 .bb files complete (857 cached, 2 parsed). 1162targets, 41 skipped, 0 masked, 0 errors.NOTE: Resolving any missing task queue dependenciesNOTE: Preparing runqueueNOTE: PN dependencies saved to 'pn-depends.dot'NOTE: Package dependencies saved to 'package-depends.dot'NOTE: Task dependencies saved to 'task-depends.dot'

$ cat pn-depends.dot | grep -v \\-native | \grep -v digraph | grep -v \\} | grep –v fsl-image | \awk '{print $1}' | sort | uniq

TM


Build Structure: Viewing Dependencies Graphically

• The .dot file output for an image target is difficult to view (too big)

• See xdot pn-depends.dot

• Try a layerscape kernel package, like xdot linux-ls1

TM


Build Structure: Which Packages in core-image-* ?

An easier way…

• Check in

tmp/deploy/licenses/core-image-minimal-<target>-

<date>/package.manifest

• Also, look at license.manifest for a list of packages and associated

licenses

• Or look at individual subdirectories under tmp/deploy/licenses for

actual packages and license text

TM


Build Structure: Image Generation

<build-dir>/tmp/deploy/images/ Example: Layerscape├── fsl_fman_ucode_t4240qds_106_2_4.bin├── fsl-image-minimal-t4240qds-20121116160802.rootfs.ext2.gz.u-boot├── fsl-image-minimal-t4240qds.ext2.gz.u-boot -> fsl-image-minimal-t4240qds-20121116160802.rootfs.ext2.gz.u-boot├── [...]├── hv│ ├── hv│ ├── hv.bin│ ├── hv.map│ ├── hv.uImage│ └── hypervisor.config├── hv-cfg│ ├── README│ └── R_PPSXX_0xe│ └── hv-2p-lnx-lnx.dtb├── modules-3.0.48-rt70-r5-t4240qds.tgz├── rcw│ ├── README│ ├── R_PPSXN_0x10│ │ ├── rcw_13g_1500mhz_rev2.bin│ │ ├── [...]│ │ └── rcw_5g_1500mhz_rev3.bin│ ├── R_PPSXX_0xe│ └── R_RRRSS_0x16├── u-boot-T4240QDS.bin -> u-boot-T4240QDS-git-r26.bin├── u-boot-T4240QDS-git-r26.bin├── [...]├── uImage-3.0.48-r5-t4240qds-20121116160802.bin├── uImage-3.0.48-r5-t4240qds-20121116160802.dtb├── uImage-3.0.48-r5-t4240qds-usdpaa-20121116160802.dtb├── uImage-t4240qds.bin -> uImage-3.0.48-r5-t4240qds-20121116160802.bin├── uImage-t4240qds.dtb -> uImage-3.0.48-r5-t4240qds-20121116160802.dtb└── uImage-t4240qds-usdpaa.dtb -> uImage-3.0.48-r5-t4240qds-usdpaa-20121116160802.dtb

FMan microcode

RFS image files and symlinks

Embedded hypervisor image

HV configuration device tree

Reset Configuration Word images

Kernel image, dtb's and symlinks

u-boot images and symlinks

TM


Build Structure: Image Generation: File System Content

Layerscape Example <build-dir>/tmp/work/ls1021aqds-poky-Linux-gnueabi/core-image-minimal/1.0-r0/rootfs

├── bin├── boot├── dev├── etc├── home├── lib├── media├── mnt├── proc├── run├── sbin├── sys├── tmp├── usr└── var

The file content of the generated rootfs can be

inspected in the ${WORKDIR}/rootfs of the image

TM


Build Structure: Understanding Tmp Directory

• A build environment has a ./tmp directory, or ${TMPDIR}, which

receives all the build output

<build-dir>/tmp├── buildstats├── cache├── deploy│ ├── images│ ├── licenses│ ├── rpm│ └── sdk├── log├── pkgdata├── sstate-control├── stamps├── sysroots│ ├── i686-linux│ ├── t4240qds│ └── t4240qds-tcbootstrap└── work├── all-fsl_networking-linux├── i686-linux├── t4240qds-fsl_networking-linux└── ppce6500-fsl_networking-linux

Generated image files (kernel, u-boot, rcw, rfs, ...)

Produced installable .rpm files of built packages

Shared header files and libraries

TM


<build-dir>/tmp├── buildstats├── cache├── ccache├── deploy│ ├── images│ ├── licenses│ └── rpm├── pkgdata├── sstate-control├── stamps├── sysroots│ ├── i686-linux│ ├── t4240qds│ └── t4240qds-tcbootstrap├── work│ ├── all-fsl_networking-linux│ ├── t4240qds-fsl_networking-linux│ ├── ppce6500-fsl_networking-linux│ ├── x86_64-linux└── work-shared└── gcc-4.7.2+fsl-r19

Build Structure: Understanding Tmp Directory (cont.)

• A working directory ${WORKDIR}, is

created for each package.

All tasks execute from a work

directory.

• Working directories are grouped in

sub-folders :

− <machine>-fsl_networking-linux: board specific target side packages

like rcw, kernel, u-boot, ...

− <core>-fsl_networking-linux :

non-board specific packages,

compiled for the target architecture

− <host>-*

Package working directories per architecture and board

TM


Board Bring-up

TM


Board Bringup: i.MX Bring-up

Power cable to board

Display

SD Card

USB OTG connection for Serial Console

• Root password is :root

• Refer to i.MX User’s Guide for more details

• Change U-boot from Default in image

− sudo dd if=<U-Boot image> of=/dev/sdx bs=512

seek=2 conv=fsync

• Change Device Tree

− setenv fdt_file 'imx6q-sabresd.dtb'

TM


Board Bring-up: QorIQ Verify Physical Connections

Power cable to board (T4240QDS or

LS1021aQDS)

PSU switch set to on

CW TAP JTAG cable to board COP/JTAG

connector

CW TAP Network Connected to Router

CW TAP Power Connected

Ethernet from board RGMII port to Router

Serial cable from board lower (on T4) upper (on

LS1) RS-232 port to CW Tap

TM


Board Bring-up: QorIQ Power On

• Start putty to CW tap term server / LS1021A

Serial Port

• Default baud rate is 115200

• Hit Reset Button on board

• Escape out of u-boot automatic boot

• Stop at U-Boot prompt

• =>

TM


Board Bring-up: QorIQ U-Boot Checks

• Check the network settings and update :

=> print=> setenv ipaddr 192.168.2.100 => setenv serverip 192.168.2.3=> setenv ethact=eTSEC3=> setenv ethprime=eTSEC3

Save the updated current environment in flash :

=> saveenv

Test network connectivity

=> ping $serverip

TM


Board Bring-up: QorIQ LS1021aQDS Memory Map

TM


Board Bring-up: QorIQ Reprogram U-Boot on LS1021

NOTE: avoid programming flash bank 0. Potential to brick board.

=> qix

Make sure tftpserver is running on host and enabled in firewall

=> setenv serverip 192.168.2.3

=> setenv ipaddr 192.168.2.100

=> tftp 82000000 ls1021aqds/u-boot-ls1021aqds.bin

=> erase 63f80000 63ffffff

=> cp.b 82000000 63f80000 80000

=> qix altbank

=> !! New u-boot comes up !!

TM


Board Bring-up: QorIQ Reprogram RCW

Select RCW to use, Insure it is in tftpboot directory

We want to use ./NNR_PSS_NN_60/rcw_1000_usb2.bin

=> <Reset Board>



=> tftp 82000000 ls1021aqds/rcw/ls1021aqds/NNR_PSS_NN_60/rcw_1000.bin

=> erase 64000000 6401ffff

=> cp.b 82000000 64000000 $filesize

=> qix altbank

=> !! New RCW comes up !!

TM


Board Bring-up: QorIQ Prepare to Boot Linux

• Switch to alternate flash bank

• => qix altbank• Set environment variables:=> setenv ramboot tftp \$loadaddr \$bootfile\; tftp \$fdtaddr \$fdtfile\; tftp \$ramdiskaddr \$ramdiskfile\; bootm \$loadaddr \$ramdiskaddr \$fdtaddr=> setenv ramdiskaddr 88000000=> setenv ramdiskfile ls1021aqds/core-image-minimal-ls1021aqds.ext2.gz.u-boot=> setenv loadaddr 82000000=> setenv bootfile ls1021aqds/uImage-ls1021aqds.bin=> setenv fdtaddr 8f000000=> setenv fdtfile ls1021aqds/uImage-ls1021aqds.dtb

TM


Board Bring-up: QorIQ — Boot Environment Variables

• More environment variables:



=> setenv netmask 255.255.255.0

=> setenv gatewayip 192.168.2.1

=> setenv ethact eTSEC3

=> setenv ethprime eTSEC3

=> saveenv

TM


Board Bring-up: QorIQ SMP Linux Boot Log Excerpts

Boot to Linux

=> run ramboot

Review the output for relevant and interesting

sections

Poky (Yocto Project Reference Distro) 1.7 ls1021aqds /dev/ttyS0

Log into the target system :

ls1021aqds login: rootroot@ls1021aqds:~#

TM


Board Bring-up: QorIQ A Few Quick Checks

# more /proc/cpuinfoprocessor : 0model name : ARMv7 Processor rev 5 (v7l)Features : swp half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae

CPU implementer : 0x41CPU architecture: 7CPU variant : 0x0CPU part : 0xc07CPU revision : 5

processor : 1model name : ARMv7 Processor rev 5 (v7l)Features : swp half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae

CPU implementer : 0x41CPU architecture: 7CPU variant : 0x0CPU part : 0xc07CPU revision : 5

Hardware : Freescale Layerscape LS1021ARevision : 0000Serial : 0000000000000000

TM


Board Bring-up: QorIQ Test The Network

• Available interfaces:

root@p4080ds:~# ip link1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueuelink/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:002: can0: <NOARP40000> mtu 16 qdisc noop qlen 10link/[280]3: can1: <NOARP40000> mtu 16 qdisc noop qlen 10link/[280]4: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000link/ether 00:e0:0c:00:80:00 brd ff:ff:ff:ff:ff:ff5: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000link/ether 00:e0:0c:00:80:01 brd ff:ff:ff:ff:ff:ff6: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000link/ether 00:e0:0c:00:80:02 brd ff:ff:ff:ff:ff:ff7: sit0: <NOARP> mtu 1480 qdisc nooplink/sit 0.0.0.0 brd 0.0.0.0

eth2 is the top SGMII port on the main PCB (eTSEC3)

TM


Board Bring-up: QorIQ Test Network Connection

• Assign the same IP address as for ipaddr in u-boot

ifconfig eth2 192.168.2.100

# ping 192.168.2.1PING 192.168.2.1 (192.168.2.1): 56 data bytes64 bytes from 192.168.2.1: icmp_seq=0 ttl=64 time=0.672 ms64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=0.325 ms--- 192.168.2.1 ping statistics ---2 packets transmitted, 2 packets received, 0% packet lossround-trip min/avg/max/stddev = 0.310/0.357/0.672/0.111 ms

TM


Board Bring-up: QorIQ Check Interrupts

Way too many cpus to show correctly on this slide. This is from a P4080DS

# cat /proc/interruptsCPU0 CPU129: 0 0 GIC 29 arch_timer30: 31770 31773 GIC 30 arch_timer107: 9 0 GIC 107 fsl-ifc118: 256 0 GIC 118 serial120: 126 0 GIC 120 2180000.i2c125: 0 0 GIC 125 xhci-hcd:usb1126: 11952 0 GIC 126 mmc0135: 2 0 GIC 135 1710000.jr136: 0 0 GIC 136 1720000.jr137: 0 0 GIC 137 1730000.jr138: 0 0 GIC 138 1740000.jr167: 0 0 GIC 167 eDMA189: 11 0 GIC 189 eth2_g0_tx190: 4 0 GIC 190 eth2_g0_rx191: 0 0 GIC 191 eth2_g0_er201: 0 0 GIC 201 ds3232205: 0 0 GIC 205 gianfar_ptp209: 0 0 GIC 209 PCIe0211: 0 0 GIC 211 PCIe0-msiIPI0: 0 1 CPU wakeup interruptsIPI1: 0 0 Timer broadcast interruptsIPI2: 1221 1458 Rescheduling interruptsIPI3: 0 0 Function call interruptsIPI4: 2 3 Single function call interruptsIPI5: 0 0 CPU stop interruptsErr: 0

TM


BitBake and GITIntro

TM


BitBake and Git: Overview

• Freescale kernel and u-boot source released on git.freescale.com

• In addition for QorIQ git tar balls are provided, which include the

entire patch commit history

• Yocto Project uses git commands when needed, but hides these

from the user

• To get started with git:

− git project: git-scm.com

− git cheat sheet: git.jk.gs

− gitk repo browser: kernel.org/pub/software/scm/git/docs/gitk.html

TM


BitBake and GIT: Where are the Patch Files?

• For a package provide as a git repo, patches are identified in the git

commit history

− For non-git packages patches may be contained in one of the package

recipe folders

• To extract the patch files from an installed git tree:

− Install the package source from the git tar ball

− Enter the installed package's git folder

− List the commits with git log

− Identify the <since>..<until> commit range of interest

− Generate the patch files with git format-patch

TM


BitBake and GIT: Which Patches Apply for a Package?

• To query for all applied patches, e.g. for busybox:

$ bitbake -e busybox | grep ^SRC_URI | tr -s ' ' '\n' | \tr -s '\t' '\n' | grep patchfile://udhcpscript.patchfile://udhcpc-fix-nfsroot.patchfile://B921600.patchfile://get_header_tar.patchfile://busybox-appletlib-dependency.patchfile://run-parts.in.usr-bin.patchfile://watch.in.usr-bin.patchfile://busybox-udhcpc-no_deconfig.patchfile://busybox-1.19.4-ubi-user-h.patch

• Note: for packages installed from a git repo use git log

TM


• Integrating Patches into Yocto Project recipe− In recipe directory, create sub-directory to hold patch

− In recipe (or bbappend) add SRC_URI += “file::/<patch name>”

− At top if using bbappend put

− FILESEXTRAPATHS_prepend := "${THISDIR}/<patch directory name>“

− Check log.do_fetch to make sure patch is picked up

• To install the sources of a package:

$ bitbake -c patch <pkg>

Any earlier tasks that must be completed before do_patch will be implicitly executed first

• Eventually, sources will be installed into:

${WORKDIR}/<src folder>

BitBake and GIT: Installing Package SourcesExample : u-boot

TM


BitBake and GIT: Installing Package Sources (Continued)Example : u-boot (Continued)

$ cd build_t4240qds_release$ bitbake -c patch u-boot[...]

$ cd tmp/work/t4240qds-fsl_networking-linux/u-boot-git-r26$ lsdeploy-rpms license-destdir pkgdata sstate-install-deploy tempdeploy-u-boot package pseudo sstate-install-deploy-rpmgit packages-split shlibs sstate-install-package

$ ls gitapi config.mk drivers lib nand_spl rules.mkarch COPYING dts MAINTAINERS net snapshot.commitboard CREDITS examples MAKEALL onenand_ipl splboards.cfg disk fs Makefile post toolscommon doc include mkconfig README

u-boot supplied as a git repo tar ball source folder is called git

TM


Customization

TM


Customization: Adding Kernel 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 (i.MX Example)

• bitbake –c compile –f linux-imx

• bitbake –c deploy –f linux-imx

• New device tree should be in tmp/deply/images/<machine>

• Create patch for new device tree and add to kernel recipe so changes are not lost

4. Update uboot

• Change the fdt_file parameter to the new device tree.dtb

TM


Customization: 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

• QorIQ provides kernel and uboot — linux-lsl and u-boot-ls1

• 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


Customization: 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

• Examples:

− PREFERRED_VERSION_u-boot-imx_mx6 = "2014-04"

− PREFERRED_VERSION_linux-imx_mx6 = "3.14.28”

− PREFERRED_VERSION_imx-lib_mx6 = "3.14.28-1.0.0”

− PREFERRED_VERSION_imx-test_mx6 = "3.14.28-1.0.0“

TM


Customization: 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.

• i.MX Example — SOC_FAMILY = "mx6:mx6sl“

• Layerscape Example — SOC_FAMILY = "ls102xa”

• 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


Customization: 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 = “3.14.28”

• 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


Customization: Examples of Definitions using SOC

• Community settings define common providers and versions

• Communty definitions

• Release — 3.14.28-1.0.0 Settings

• 3.14.28 — Definitions

• Look at directfb in layer.conf how we override community directfb

version in imx-base.inc

• MACHINE_SOCARCH_SUFFIX — defines common machine sets

• MACHINE_SOCARCH_FILTER — defines common dependencies

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=dizzy_3.14.28-1.0.0_GA

TM


Customization: Debugging

• Each BitBake 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 Project Working directory

− Example: U-Boot i.MX working directory

<build-dir>/tmp/work/<machine>-poky-linux-gnueabi/u-boot-imx/2014.04-r0/

Log output — temp

Note that on fido, kernel is in work-shared

− Machine dependent components will go into machine working directories

− Non-Kernel dependent components will go into poky working directories

− Some are combined into like working directory like graphics so same

output used for multiple machines

TM


Customization: Toolchains

• Yocto Project Poky updates the toolchains on each release

• Look in poky/meta/recipes-devtools/gcc/gcc-<version>.inc

• Can switch to last one by setting GCC_VERSION in local.conf

• For i.MX hardware floating point is Default

− DEFAULTTUNE_mx6 ?= "cortexa9hf-neon“

− Only hardware floating point binaries get full test before release.

• For i.MX, to change to software floating point set in local.conf

− DEFAULTTUNE_mx6 = "cortexa9-neon“

• For QorIQ, separate toolchain provided by Freescale

• Notes:

− Any changes to toolchain require a clean build

TM


Customization: Sharing Downloads

• Share the download folder

− In default build, downloads is created in <build-dir>

− To share across multiple build directories, set DL_DIR in local.conf

− DL_DIR = “<directory path>”

− Multiple builds will share common downloads, reducing disk space and

improving speed of builds

− Problems when running multiple builds at same time. If one build does a

clean all on a component used by another build, it will cause other build

to fail if running at same time and dependent on same component

TM


Customization: Sharing sstate-cache

• 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

− Note this will not work if you have multiple builds running at same time

TM


Customization: Reducing Disk Usage

• 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 creates extra build task rm_work that deletes the source and

build and leaves only logs and final output and build — increases

build time slightly but reduces disk usage

INHERIT += rm_work

TM


Customization: Add packages to a build

Three options:

1. local.conf — Add CORE_IMAGE_EXTRA_INSTALL

CORE_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


Customization: DISTRO_FEATURES

• Distro features defined in poky with base set. Can add or remove

distro features in local.conf

• Poky distro in poky/meta/conf/distro/include/default-distrovars.inc

• DISTRO_FEATURES used to enable features for a build

• Example used in 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

TM


Customization: Custom Layers

• Great way to separate customizations

• Create new recipes for new software

• Update existing software with patches or configurations through

bbappends

• Check on layer priority as defined in the layer.conf

• Each layer is integrated into build once added to <build-

dir>/conf/bblayers.conf

TM


Customization: Custom Layer Creation

• The Yocto Project provides a script that can be used to create a

new layer called yocto-layer

• Layers can also be created manually

• The script will walk you through setting up the new layer

− The layer priority

− Whether or not to create a sample recipe.

− Whether or not to create a sample append file.

Use the yocto-layer create sub-command to create a new general layer. In

its simplest form, you can create a layer as follows:

$ yocto-layer create mylayer

TM


Customization: BBappends, Packagegroups and Images

Bbappends

• Allow updates to existing recipes.

• Add patches, change definitions for build, or update installs

• Use <component>_%.bbappend to use for any version

• Using a version will take precedence over other layers

Package Groups

• Allow groups of packages to be classed together

Custom Images

• Allows custom images including unique set of packages or package groups

TM


QorIQ Emulation

TM


QorIQ Emulation: Yocto ADT

• New Feature for SDK 2.0

• Unsupported but useful now

• Integrates Yocto, QorIQ SDK, Eclipse,

QEMU, Git, QCS and more

TM


QorIQ Emulation: Install Eclipse and Base Plugins

• Can use existing eclipse installation or create a new one

• $ wget http://ftp.ussg.iu.edu/eclipse/technology/epp/downloads/release/kepler/SR2/eclipse-standard-kepler-SR2-linux-gtk-x86_64.tar.gz

• $ tar zxvf eclipse-standard-kepler-SR2-linux-gtk-x86_64.tar.gz

• Launch the Eclipse IDE

• $ ./eclipse/eclipse

• Select "Help” -> “Install New Software" menu

• Input or select “Kepler — http://download.eclipse.org/releases/kepler” in "Work with:" dropbox

• Expand “Linux Tools" and select the LTTng — Linux Tracing Toolkit boxes

• Expand "Mobile and Device Development" and select C/C++ Remote Launch, Remote System Explorer End-user Runtime, Remote System Explorer User Actions, Target Management Terminal, TCF Remote System Explorer add-in, and TCF Target Explorer

• Expand "Programming Languages" and select C/C++ Autotools Support and C/C++ Development Tools boxes

• Complete the installation and restart the Eclipse IDE

http://ftp.ussg.iu.edu/eclipse/technology/epp/downloads/release/kepler/SR2/eclipse-standard-kepler-SR2-linux-gtk-x86_64.tar.gz

TM


QorIQ Emulation: Install Yocto Project Plugin

• Start the Eclipse IDE

• In Eclipse, select "Help” -> “Install New Software" menu

• Click "Add..." button in the "Work with:" area

• Input http://downloads.yoctoproject.org/releases/eclipse-plugin/1.6.1/kepler in the URL field and provide a meaningful name in

the "Name" field

• Click "OK" to add the entry in "Work with:" dropbox

• Select the entry for the plug-in from the "Work with:" dropbox

• Select Yocto Project ADT Plug-in, Yocto Project Bitbake Commander Plug-in and Yocto Project Documentation plug-in

• Complete the remaining software installation steps, and then restart the

Eclipse IDE to finish the installation of the plug-in

TM


QorIQ Emulation: LS1 QEMU vs Generic QEMUARM

• LS1 QEMU not currently available

• Will use default QEMUARM for demo

• Will soon (?) be a ls1021aqemu target

• Implies that the kernel in QEMUARM is a different build then on the

LS1021AQDS

• Appropriate for Generic Application Development

TM


QorIQ Emulation: Generate Yocto ADT Targets for QEMU

$ cd <workspace>/poky

$ source ./oe-init-build-env build-qemuarm

$ cd build-qemuarm

$ MACHINE="qemuarm" bitbake meta-toolchain

$ MACHINE="qemuarm" bitbake core-image-sato-sdk

$ MACHINE=“qemuarm” bitbake meta-ide-support

$ runqemu-extract-sdk tmp/deply/images/qemuarm/core-image-sato-sdk-qemuarm.tar.bz2 ./qemuarm-sato

TM


QorIQ Emulation: Setup Default Yocto ADT Settings

Select “Window -> Preferences" menu.

Select “Yocto Project ADT”

Select “Build system derived toolchain”

Enter “Toolchain Root Location:”

Enter “Sysroot Location:”

Select “QEMU”

Enter “Kernel:”

Click “OK”

TM


QorIQ Emulation: Create New Project

Select "File -> New -> Project" menu.

Select “C Project”. Click “Next”

TM


QorIQ Emulation: Create New C Project

Enter Project Name and Select: hellofaes

Open “Yocto Project ADT Autotools Project”

Select “Hello World ANSI C Autotools Project”

Click “Next”

TM


QorIQ Emulation: Update Basic Settings

Fill in Fields as Appropriate

Click “Finish”

TM


QorIQ Emulation: Build hellofaes QEMU Executable

Click on“Project” “Build All”

TM


QorIQ Emulation: Configure and Run QEMU

Click “Run” “External Tools” “External Tools Configuration”

Click “Run”

Subsequent Runs

will appear in

External Tools

Menu

TM


QorIQ Emulation: QEMUARM Bringup

NOTE: IP Address used by emulator

(192.168.7.8)

TM


QorIQ Emulation: Configure Debug Settngs

Enter “Remote Absolute File Path for C/C++ Application:

Click on “Connection:” “New…”

TM


QorIQ Emulation: Select Remote System Type and IP

Select TCF, Then Click NextType in IP Address from Simulator Screen192.168.7.8

Click “Finish”

TM


QorIQ Emulation: Launch hellofaes Application in QEMU

Select Connection: 192.168.7.8

Click “Debug”

TM


QorIQ Emulation: Authenticate Application

We haven’t added any user to the QEMU Instance.

The default is “root”, no password

TM


QorIQ Emulation: Debug Perspective

TM


QorIQ ADT with Target Board

TM


QorIQ ADT with Target Board: Configure and Build SDK

$ cd <workspace>/poky

$ source oe-init-build-env build

edit conf/local.conf

EXTRA_IMAGE_FEATURES = “debug-tweaks eclipse-debug”

$ bitbake core-image-minimal

$ cp tmp/deploy/images/ls1021aqds/core-image-minmal-ls1021aqds.ext2.gz.u-boot /tftpboot/ls1021aqds

Reboot board

$ # Configure IP Address on Board

$ ifconfig eth2 192.168.2.100

TM


QorIQ ADT with Target Board: Create a Build Configuration

Click on Project in

Explorer Pane

Then Click “Project” “Build Configurations” “Manage…”

Then Click “New…”

TM


QorIQ ADT with Target Board: Create Configuration

Enter Name: ls1021aqds

Check Existing configuration Build(GNU)

Click OK

TM


QorIQ ADT with Target Board: Set Active Configuration

Select ls1021aqds

Click Set Active

Click OK

TM


QorIQ ADT with Target Board: Configure Build Settings

Check “Use project specific settings

Add “Toolchain Root Location:”

Add Sysroot Location:

Select External Hardware

Click “OK”

TM


QorIQ ADT with Target Board: Create Debug Configuration

Click on “C/C++ Remote Application

Click on “New” Button

TM


QorIQ ADT with Target Board: Configure Debug

Click on

Connection:New…

TM


QorIQ ADT with Target Board: Configure TCF

Enter Host name: 192.168.2.100(address of board)

Click Finish

TM


Complete Debug Configuration

Select C/C++ Application by

Clicking on “Search Project…”

Select Connection:192.168.2.100

Enter Remote Absolute file path for C/C++ Application /usr/bin/hellofaes

Select “Debugger”

Tab

TM


Complete Debug Configuration

Set GDB debugger: to

<build-dir>tmp/sysroots/x86_64-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-gdb

Click “Debug”

TM


QorIQ ADT with Target Board: Debug on Target Hardware

TM


QorIQ ADT with Target Board: Switch Build Configurations

For QEMUARM

Select Project => Build Configurations => Set Active => Build (GNU)Select “Run” => “Debug Configurations”Select hellofaes_gdb_arm-poky-linux-gnueabiClick “Debug”

For LS1021AQDS

Select Project => Build Configurations => Set Active => ls1021aqdsSelect “Run” => “Debug Configurations”Select hellofaes ls1021aqdsClick “Debug”

TM


Device Trees

TM


Device Trees: On-target Device Trees — u-boot and fdt

=> fdtfdt - flattened device tree utility commands

Usage:fdt addr <addr> [<length>] - Set the fdt location to <addr>fdt boardsetup - Do board-specific set upfdt move <fdt> <newaddr> <length> - Copy the fdt to <addr> and make it activefdt resize - Resize fdt to size + padding to 4k addrfdt print <path> [<prop>] - Recursive print starting at <path>fdt list <path> [<prop>] - Print one level starting at <path>fdt get value <var> <path> <prop> - Get <property> and store in <var>fdt get name <var> <path> <index> - Get name of node <index> and store in <var>fdt get addr <var> <path> <prop> - Get start address of <property> and store in <var>fdt get size <var> <path> [<prop>] - Get size of [<property>] or num nodes and store in <var>fdt set <path> <prop> [<val>] - Set <property> [to <val>]fdt mknode <path> <node> - Create a new node after <path>fdt rm <path> [<prop>] - Delete the node or <property>fdt header - Display header infofdt bootcpu <id> - Set boot cpuidfdt memory <addr> <size> - Add/Update memory nodefdt rsvmem print - Show current mem reservesfdt rsvmem add <addr> <size> - Add a mem reservefdt rsvmem delete <index> - Delete a mem reservesfdt chosen [<start> <end>] - Add/update the /chosen branch in the tree<start>/<end> - initrd start/end addrNOTE: Dereference aliases by omiting the leading '/', e.g. fdt print ethernet0.

TM


Device Trees: On-target Device Trees — u-boot and fdt

• Reset the board into u-boot and interrupt the countdown

• Use fdt to access the hardware device tree:

• => tftp $fdtaddr $fdtfile

=> fdt addr $fdtaddr make FDT in flash active

=> fdt list list top level

=> fdt list /cpus list /cpus node

=> fdt list /cpus/PowerPC,e6500@11 list last cpu node

=> fdt rm /cpus/PowerPC,e6500@11 remove last cpu node

• Print the u-boot variable: => printenv ramboot

• copy-paste its value

• remove the subcommand that performs tftp of the fdt

• Boot by hitting return

• how many cores were initialized by Linux ? (was 24, now 22)

TM


Device Trees: On-target Device Trees — Linux

Initialize the target network with ifconfig

# ifconfig fm1-mac5 192.168.2.100

• May need to remove known host 192.168.2.100 from .ssh/known-hosts

• # mkdir /dtc

• On Host, Put the dtc utility in the rootfs :

$ cd <sdk>/build_t4240qds_release$ source SOURCE_THIS$ bitbake dtc$ cd tmp/work/ppce6500-fsl_networking-linux/dtc/1.3.0+gitAUTOINC+e4b497f367a3b2ae99cc52089a14a221b13a76ef-r6.1/package$ scp -r * root@target:/dtc

TM


Device Trees: On-Target Device Trees (Cont)

• Capture the FDT passed to the Linux kernel ...

# /dtc/usr/bin/dtc -I fs /proc/device-tree > ~/fdt.dts

... and copy it to the Linux host

• $ scp [email protected]:fdt.dts /tftpboot/ftf/t4240qds/[email protected]'s password:fdt.dts 100% 129KB 128.9KB/s 00:00

TM


Device Trees: Installing QorIQ Configuration Suite

• Download from below link:

− http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=PE_

QORIQ_SUITE&fpsp=1&tab=Design_Tools_Tab

• Provides Eclipse plugins, Codewarrior plugins, and integrated

packages

• Configuration Suite Installer 3.0.4 for Eclipse 3.7.x (Indigo) and Eclipse 4.2 (Juno)

• Also works for Kepler

• Follow instructions in README.html

http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=PE_QORIQ_SUITE&fpsp=1&tab=Design_Tools_Tab

TM


Device Trees: QCS Device Trees Editor

• Launch Eclipse

$ eclipse &

• Create a new project:

File New QorIQ Configuration Project

Project name: FDT

Processor : T4240QDS Rev1.0

Components Device Tree Editor

Import configuration : /tftpboot/ftf/t4240qds/fdt.dts

Finish

TM


QCS Device Trees Editor

• In project FDT open Inspector Pinned for :

Embedded Components DT1:HWDeviceTreeand maximize the view

• Navigate the Device Tree Nodes (left panel)

• Check per node Device Tree Properties (right panel)

• Open the Interrupts tab (right panel)

• Navigate the DT1HWDeviceTree.dts synchronized source view

TM


Device Trees Editing — QCS

• Create a QCS Device Tree Editor project FDT_Source

• Import a kernel device tree source file:<sdk>/build_t4240qds_release/tmp/work/t4240qds-fsl_networking-linux/linux-qoriq-sdk/3.8-r11.1/git/arch/powerpc/boot/dts/t4240qds.dts

• In a Component Inspector, browse the Include tree

• Individual include files can be viewed as source

• Open Window Preferences Processor Expert Device Tree Settings

• set DTC location to:

<sdk>/build_t4240qds_release/tmp/sysroots/x86_64-linux/usr/bin/dtc

• Close window and hit Project >> Generate Processor Export Code button (demo has syntax errors)

TM


Debug Help

TM


Debug Help: Fetch Failures

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

TM


Debug Help: Patch Failures


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


Debug Help: Version Issues


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.

TM


Debug Help: Compiler Failures


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.

TM


Debug Help: Parser Failures


Bitbake parser error Check recipes, includes and conf files for an invalid variable.

- Missing quote

- Variable referenced without being assigned

- Missing a continuation line or using a continuation line \

incorrectly.

TM


Debug Help: Install Failures


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.

TM

© 2015 Freescale Semiconductor, Inc. | External Use

www.Freescale.com

http://www.freescale.com/

http://www.freescale.com/

https://twitter.com/Freescale




https://www.facebook.com/freescale




introduction to yocto project™ tools for i.mx and qoriq ... · freescale i.mx bsp releases are...

Documents