Presentation is loading. Please wait.

Presentation is loading. Please wait.

Agenda Introduction Freescale i.MX Releases Get Started Debugging Tips

Similar presentations


Presentation on theme: "Agenda Introduction Freescale i.MX Releases Get Started Debugging Tips"— Presentation transcript:

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 - https://www.yoctoproject.org/ The Yocto Project is an open source collaboration project that provides templates, tools and methods to help you create custom Linux-based systems for embedded products regardless of the hardware architecture. The Yocto Project hosts other projects as well, including the Poky build system, Autobuilder automated build and test system, and the Embedded GLIBC (EGLIBC)C library.

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: https://www.yoctoproject.org/tools-resources/projects/openembedded-core 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 (http://ossystems.com.br/ or https://www.slideshare.net/secret/cmdMnute8kNFUK) Mail list for the project: https://lists.yoctoproject.org/listinfo/meta-freescale

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 http://commondatastorage.googleapis.com/git-repo-downloads/repo > ~/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 https://github.com/Freescale/fsl-community-bsp-platform 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 https://github.com/Freescale/meta-fsl- 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 https://lists.yoctoproject.org/listinfo/meta-freescale i.MX Community https://community.freescale.com/community/imx/content Click on Content->Yocto Project Documents has tips for getting started

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 https://github.com/Freescale/meta-fsl-arm- extra/tree/master/conf/machine Vendor machine kernel recipes and other vendor specific recipes. https://github.com/Freescale/meta-fsl-arm-extra/tree/master/recipes- 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 https://github.com/Freescale/meta-fsl-arm/blob/dizzy/recipes-kernel/linux/linux-imx_ bb https://github.com/Freescale/meta-fsl-arm/blob/dizzy/recipes-kernel/linux/linux-imx /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 - https://github.com/Freescale/meta-fsl- 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 https://github.com/Freescale/meta-fsl-demos/blob/dizzy/recipes-graphics/fsl-gpu- sdk/fsl-gpu-sdk_1.1.bb - DEPENDS = "${WL_DEPENDS}" DEPENDS_append_mx6q = " virtual/libgles1 virtual/libgles2" DEPENDS_append_mx6dl = " virtual/libgles1 virtual/libgles2" WL_DEPENDS = '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 – https://github.com/Freescale/meta-fsl-arm/blob/master/recipes-multimedia/alsa/alsa- 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 https://github.com/Freescale/meta-fsl-arm/blob/master/recipes-graphics/gpu-viv- 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 https://lists.yoctoproject.org/listinfo/meta-freescale i.MX Community https://community.freescale.com/community/imx/content Click on Content->Yocto Project Documents has tips for getting started

111 Yocto Project Community

112 Yocto Project : Community Upstreaming
Be active member of community Build on master branch repo init -u https://github.com/Freescale/fsl-community-bsp-platform -b master repo sync Add patch to meta-fsl-arm/meta-fsl-demos Generate patch using git format patch mkdir patch git format-patch –M –o patch –subject-prefix=“meta-fsl-arm][PATCH” code/yocto Git send- to meta-freescale For git send- make sure [send ] is set in .gitconfig

113


Download ppt "Agenda Introduction Freescale i.MX Releases Get Started Debugging Tips"

Similar presentations


Ads by Google