Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "Confidential and Proprietary TM The Yocto Project and Linux ® Software Development for i.MX Application Processors AMF-SHB-T1056 March.2015 Jay Marcinczyk."— Presentation transcript:

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

2 TM Confidential and Proprietary 1 Agenda Introduction Freescale i.MX Releases Get Started Debugging Tips Internet of Things Advanced

3 TM Confidential and Proprietary 2 What is the Yocto Project It's not an embedded Linux distribution, it creates a custom one for you - https://www.yoctoproject.org/ 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.

4 TM Confidential and Proprietary 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

5 TM Confidential and Proprietary 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

6 TM Confidential and Proprietary 5 Yocto Project Introduction: Development Environment Source:

7 TM Confidential and Proprietary 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:

8 TM Confidential and Proprietary 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

9 TM Confidential and Proprietary 8 Yocto Project Freescale i.MX Releases

10 TM Confidential and Proprietary 9 Yocto Project Freescale i.MX Releases: History ReleaseDescription L on DaisyGraphics v5, i.MX 6 SoloX, new Uboot, Gstreamer 1.0 L on DoraPost GA graphics update with updated kernel L on DoraPost 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 DoraKernel GA release with p13 Vivante graphics and manufacturing image

11 TM Confidential and Proprietary 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

12 TM Confidential and Proprietary 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.

13 TM Confidential and Proprietary 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

14 TM Confidential and Proprietary 13 Yocto Project Freescale i.MX Releases: Contents ContentsDescription recipes-kernelKernel recipes-bspU-Boot, imx-test, imx-lib, imx-vpu, imx- kobs, imx-uuc, firmware, recipes-graphicsgpu-viv-bin, xorg-driver, wayland recipes-multimedialibfslcodec, libfslparser, libfslvpuwrap, gstreamer, alsa recipes-corebusybox, eglibc, udev recipes-fslImage and package group recipes-qtQt5 package groups and demos

15 TM Confidential and Proprietary 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 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.

16 TM Confidential and Proprietary 15 Differences Between and GA releases Release GraphicsGraphics v4.6.9 DirectFB Wayland 1.4 Xorg 1.14 fsl-gpu-sdk 1.1 Graphics v OpenGLES 3.0 APIs, DirectFB Wayland 1.6 Xorg 1.15 and 1.16 fsl-gpu-sdk 2.0 6slevk fixes for all backends U-Boot and KernelU-Boot Kernel Mfgtools – fsl-image-manufacturing image U-Boot Kernel Mfg tools – fsl-image-mfgtool-initramfs New Hardwarenone6 SoloX introduction MultimediaGstreamer 0.1Gstreamer 1.0 and 0.1 QtQt4 with demo support for Qt5.2.1 on X11 Qt5.2.1 support on X11, FB and Wayland Toolchain + Yocto ProjectGcc on doraGcc on daisy DocumentationSplit release notesCombined release notes and user’s guides – fewer documents

17 TM Confidential and Proprietary 16 Yocto Project : Qt5 Qt5 on _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.

18 TM Confidential and Proprietary 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.

19 TM Confidential and Proprietary 18 Yocto Project : Gstreamer 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.

20 TM Confidential and Proprietary 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.

21 TM Confidential and Proprietary 20 Yocto Project : Get Started

22 TM Confidential and Proprietary 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 Step 2 – Install Repo $ mkdir ~/bin $ curl > ~/bin/repohttp://commondatastorage.googleapis.com/git-repo-downloads/repo $ PATH=$PATH:~/bin $ chmod a+x ~/bin/repo

23 TM Confidential and Proprietary 22 Yocto Project Build: Step 3 – Initialize Repo and Start Download 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. $ mkdir fsl-release-bsp $ cd fsl-release-bsp $ repo init -u git://git.freescale.com/imx/fsl-arm-yocto-bsp.git -b imx _gagit://git.freescale.com/imx/fsl-arm-yocto-bsp.git $ repo sync

24 TM Confidential and Proprietary 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

25 TM Confidential and Proprietary 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.

26 TM Confidential and Proprietary 25 Yocto Project Build: Community Manifest

27 TM Confidential and Proprietary 26 Yocto Project Build: i.MX Release Manifest

28 TM Confidential and Proprietary 27 Yocto Project Build: Step 4 - Configure the build environment What are the supported boards? i.MX Reference Boards i.MX6Qimx6qsabresd imx6qsabreauto i.MX6DualLiteimx6dlsabresd imx6dlsabreauto i.MX6Soloimx6solosabresd imx6solosabreauto i.MX6SoloLiteimx6slevk i.MX6SoloXimx6sxsabresd imx6sxsabreauto (in ) i.MX53imx53qsb i.MX28Imx28evk $ 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

29 TM Confidential and Proprietary 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

30 TM Confidential and Proprietary 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"

31 TM Confidential and Proprietary 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

32 TM Confidential and Proprietary 31 Yocto Project Build: Step 6 – Build a Target 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 imageDescription core-image-minimalKernel image command prompt core-image-satoKernel build with GUI fsl-image-guiOnly in Non QT image works on all backends fsl-image-qt5Only in Freescale image QT image works on X11, Wayland and FB backends (not DirectFB) fsl-image-x11Only in Qt4 image fsl-image-westonOnly in Weston Wayland fsl-image-fbOnly in Frame buffer image recipe fsl-image-dfbOnly in DirectFB image recipe $ bitbake

33 TM Confidential and Proprietary 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 X11MACHINE=imx6qsabresd source fsl-setup-release.sh –b build-x11 –e x11 Frame BufferMACHINE=imx6qsabresd source fsl-setup-release.sh –b build-fb –e fb DirectFBMACHINE=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

34 TM Confidential and Proprietary 33 Yocto Project Build: Step 7 - Deploy image on the target Build image resides in /tmp/deploy/images/ Contents are sdcard, kernel, uboot, rootfs Note multiple sd card images take up disk space Keep track of tmp/deploy/images/ 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= bs=1M && sync

35 TM Confidential and Proprietary 34 Yocto Project Build: Build and Deploy U-Boot Look in machine configuration for U-Boot options (below are just a few examples.) Default is SD boot, so no change needed for SD boot To change, add line to /conf/local.conf − UBOOT_CONFIG=“ $ bitbake u-boot-imx –c deploy U-Boot TypeLocal.conf SD bootUBOOT_CONFIG = “sd” EIM NORUBOOT_CONFIG = “eimnor” SPI NORUBOOT_CONFIG = “spinor” SATAUBOOT_CONFIG = “sata” NANDUBOOT_CONFIG = “nand”

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

37 TM Confidential and Proprietary 36 Yocto Project Build: Adding new device trees 1. Create device tree in kernel source arch/arm/boot/dts 2. Update machine configuration files with new name Note that device tree source is extension dts Binary device tree is extension dtb − KERNEL_DEVICETREE = “ “ 3. Build kernel bitbake –c compile –f linux-imx bitbake –c deploy –f linux-imx New device tree should be in tmp/deply/images/ 4. Update uboot Change the fdt_file parameter to the new device tree.dtb

38 TM Confidential and Proprietary 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

39 TM Confidential and Proprietary 38 Yocto Project Debugging Tips

40 TM Confidential and Proprietary 39 Yocto Project Debugging Tips: Bitbake commands bitbake commandDetails bitbake –c cleanall Cleans downloads and all cache entries for component. Cleans out all entries in working directory! bitbake –c cleansstate Cleans cache but does not remove the download entry. Cleans out all entries in working directory! bitbake –c compile –f Forces a recompile of a component. Use after making changes in working directory. bitbake –c configure –f Forces a reconfigure – useful in kernel if defconfig is changed bitabke –c menuconfig linux-imxRuns the menu config for the kernel btibake -vVerbose output on command line (same as what is in the log) bitbake -kContinue past build breaks until a dependency requires stopping bitbake -c deploy –fDeploys a component to the rootfs with force – sometimes Yocto thinks a component is already deployed so this forces it bitbake -gLists a dependency tree for component bitbake -c populate_sdkGenerates an SDK script to reproduce the rootfs and build environment for non-Yocto Project build systems

41 TM Confidential and Proprietary 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“

42 TM Confidential and Proprietary 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 = " “

43 TM Confidential and Proprietary 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“

44 TM Confidential and Proprietary 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.

45 TM Confidential and Proprietary 44 Yocto Project Debugging Tips: Examples Community settings https://github.com/Freescale/meta-fsl- arm/blob/master/conf/machine/include/imx-base.inc https://github.com/Freescale/meta-fsl- arm/blob/master/conf/machine/include/imx-base.inc Release – Settings release.git/tree/imx/meta-fsl-arm/conf/layer.conf?h=daisy_ _beta 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

46 TM Confidential and Proprietary 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_ shows output of task − run.do_ shows content of task Yocto Working directory − Example: Kernel working directory  /tmp/work/imx6qsabresd-poky-linux-gnueabi/linux-imx/ r0/  Log output -- /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.

47 TM Confidential and Proprietary 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.

48 TM Confidential and Proprietary 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.

49 TM Confidential and Proprietary 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 BackendDISTRO_FEATURES in local.conf X11DISTRO_FEATURES_add = “x11” DISTRO_FEATURES_remove = “wayland directfb” Frame BufferDISTRO_FEATURES_remove = “x11 wayland directfb” DirectFBDISTRO_FEATURES_add = “directfb” DISTRO_FEATURES_remove = “x11 wayland” WaylandDISTRO_FEATURES_add = “wayland” DISTRO_FEATURES_remove = “x11 directfb”

50 TM Confidential and Proprietary 49 Yocto Project Debugging Tips: Reducing Build Time Share the download folder − In local.conf − DL_DIR = “ ” − Multiple builds will share common downloads, reducing disk space and improving speed Share the state folder − SSTATE_DIR = “ ” − 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

51 TM Confidential and Proprietary 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

52 TM Confidential and Proprietary 51 Yocto Project: Internet of Things

53 TM Confidential and Proprietary 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

54 TM Confidential and Proprietary 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 3 rd party solution using Java

55 TM Confidential and Proprietary 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 Two modes − Legacy mode – default switch setting − AVB mode – software not in BSP

56 TM Confidential and Proprietary 55 Yocto Project: Advanced T0948 Session

57 TM Confidential and Proprietary 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

58 TM Confidential and Proprietary 57 Yocto Project Creating Custom Machines and Layers

59 TM Confidential and Proprietary 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

60 TM Confidential and Proprietary 59 Yocto Project: Custom Machine Configurations How to Build − Two options – change build configuration or specify with bitbake 1. Existing build – edit local.conf and change MACHINE to new machine 2. MACHINE=imx6newboard.conf bitbake linux-imx Creates new working directory for kernel, uboot and other recipes tied to SOC family restrictions setup-environment only looks in layers that are in bblayers.conf Might have to copy machine conf file into meta-fsl-arm/conf/machine to be found

61 TM Confidential and Proprietary 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 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 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.

62 TM Confidential and Proprietary 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"

63 TM Confidential and Proprietary 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

64 TM Confidential and Proprietary 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 /conf/bblayer.conf BBLAYERS += " ${BSPDIR}/sources/meta-fsl-bsp-release/imx/meta-fsl-demos "

65 TM Confidential and Proprietary 64 Yocto Project Kernel and U-Boot Configurations

66 TM Confidential and Proprietary 65 Yocto Project Build: Build and Deploy Kernel 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 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 $ bitbake linux-imx

67 TM Confidential and Proprietary 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 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_ bb − https://github.com/Freescale/meta-fsl-arm/blob/dizzy/recipes-kernel/linux/linux-imx /mx6/defconfig https://github.com/Freescale/meta-fsl-arm/blob/dizzy/recipes-kernel/linux/linux-imx /mx6/defconfig

68 TM Confidential and Proprietary 67 Yocto Project Build: Adding new device trees 1. Create device tree in kernel source arch/arm/boot/dts 2. Update machine configuration files with new name Note that device tree source is extension dts Binary device tree is extension dtb − KERNEL_DEVICETREE = “ “ 3. Build kernel bitbake –c compile –f linux-imx bitbake –c deploy –f linux-imx New device tree should be in tmp/deply/images/ 4. Update uboot Change the fdt_file parameter to the new device tree.dtb

69 TM Confidential and Proprietary 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/ − U-Boot - Change the fdt_file parameter to the new device tree.dtb

70 TM Confidential and Proprietary 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 6 th parameter to specify customer’s directory name under board/freescale – in this case mx6q_customer. Modify the 8 th 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.

71 TM Confidential and Proprietary 70 Yocto Project Build: Build and Deploy Uboot Look in machine configuration for uboot options Default is SD boot, so no change needed for SD boot To change, add line to /conf/local.conf − UBOOT_CONFIG=“ $ bitbake u-boot-imx –c deploy Uboot TypeLocal.conf SD bootUBOOT_CONFIG = “sd” EIM NORUBOOT_CONFIG = “eimnor” SPI NORUBOOT_CONFIG = “spinor” SATAUBOOT_CONFIG = “sata” NANDUBOOT_CONFIG = “nand”

72 TM Confidential and Proprietary 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

73 TM Confidential and Proprietary 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

74 TM Confidential and Proprietary 73 Yocto Project Recipe Structure

75 TM Confidential and Proprietary 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?

76 TM Confidential and Proprietary 75 Yocto Project: Recipes – Recipe Name and Version Recipe name is _.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 - (hyphen between component and version) are automatically found − If not packaged in this format must set the S variable − S="${WORKDIR}/${PN}-${PV}-beta“

77 TM Confidential and Proprietary 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}“

78 TM Confidential and Proprietary 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 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 /  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 _.bbappend or _%.bbappend if patch applies to all versions − In recipe  FILESEXTRAPATHS_prepend_mx6 := "${THISDIR}/${PN}:"  SRC_URI_append_mx6 = " file:// ” Having trouble getting patches applied − Look at fetch and patch log and run files to verify what directories are being searched.

79 TM Confidential and Proprietary 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

80 TM Confidential and Proprietary 79 Yocto Project: Recipe – Reference Variables VariableDescription ${PN}Part Name – component name taken from recipe name ${PV}Version taken from recipe name ${WORKDIR}Working directory under tmp that component is downloaded, built and packaged ${FSL_ARM_GIT_SERVER}Location of external mirror for Freescale packages ${libdir}Location of destination for libraries ${includedir}Location of destination for include headers ${D}Destination working directory ${SOLIBS}Use for.so extensions for libraries Poky defines many variables to use recipes in bitbake.conf Sources/poky/meta/conf/bitbake.conf Use these variables in recipes – Don’t redefine in recipe

81 TM Confidential and Proprietary 80 Yocto Project: Recipe – Variables to Set VariableDescription SRC_URILocation 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 SRCREVCommit hash – use only for git source SOnly set if path of source is not in format - EXTRA_OEMAKEAllows recipe to override or set specific compile time defines or includes paths COMPATIBLE_MACHINERestrict recipe to specific SOC family or chips DESCRIPTIONDescription of component built by recipe LICENSELicense of component LICENSE_FILES_CHKSUMValidates md5sum of license provided by component Licenses can point to specific lines of licenses in headers – see gpu-viv-bin as example.

82 TM Confidential and Proprietary 81 Yocto Project: Recipe – Optional Variables to Set VariableDescription DEPENDSSet dependencies on other components required to build first RDEPDENDSSet runtime dependencies PESet only if versioning schema changes like to FILESSpecifies files to install into rootfs otherwise might get a QA error PROVIDESstates packages being provided by recipe – required for virtual packages like kernel, libegl PACKAGESSets 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

83 TM Confidential and Proprietary 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

84 TM Confidential and Proprietary 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_ = “${libdir}/libComponent${SOLIBS} − FILES_ = “${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.inchttps://github.com/Freescale/meta-fsl- arm/blob/master/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc

85 TM Confidential and Proprietary 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 +=

86 TM Confidential and Proprietary 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)}"

87 TM Confidential and Proprietary 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”

88 TM Confidential and Proprietary 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 − _%.bbappend Applies to all 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 for patch that applies to all versions  Or - for patch that applies to specific versions

89 TM Confidential and Proprietary 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  For patches in -  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“file://add-imx6-support.patch Example – https://github.com/Freescale/meta-fsl-arm/blob/master/recipes-multimedia/alsa/alsa- lib_%25.bbappend

90 TM Confidential and Proprietary 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 https://github.com/Freescale/meta-fsl-arm/blob/master/recipes-graphics/gpu-viv- bin-mx6q/gpu-viv-bin-mx6q.inc

91 TM Confidential and Proprietary 90 Yocto Project SOC customization

92 TM Confidential and Proprietary 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.patchfile://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_ _betahttp://git.freescale.com/git/cgit.cgi/imx/meta- fsl-bsp-release.git/tree/imx/meta-fsl-arm/recipes-bsp/imx-test/imx- test_ bb?h=daisy_ _beta

93 TM Confidential and Proprietary 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“

94 TM Confidential and Proprietary 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

95 TM Confidential and Proprietary 94 Yocto Project Images and Package Groups

96 TM Confidential and Proprietary 95 Yocto Project : Add packages to a build Three options: 1. local.conf – Add CORE_IMAGE_EXTRA_INSTALL CORE_IMAGE_EXTRA_INSTALL += “ “ 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

97 TM Confidential and Proprietary 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_ _betahttp://git.freescale.com/git/cgit.cgi/imx/meta-fsl-bsp- release.git/tree/imx/meta-fsl-demos/recipes-fsl/images/fsl-image- gui.bb?h=daisy_ _beta

98 TM Confidential and Proprietary 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_ _betahttp://git.freescale.com/git/cgit.cgi/imx/meta-fsl-bsp- release.git/tree/imx/meta-fsl-demos/recipes- fsl/packagegroup?h=daisy_ _beta

99 TM Confidential and Proprietary 98 Yocto Project Debugging

100 TM Confidential and Proprietary 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_ shows output of task − run.do_ shows content of task Yocto Working directory − Example: Kernel working directory  /tmp/work/imx6qsabresd-poky-linux-gnueabi/linux-imx/ r0/  Log output -- /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.

101 TM Confidential and Proprietary 100 Yocto Project : Debugging Fetch issues Common ProblemsHow to Solve Failure fetch packageLook 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 ( / / / Failure to find a patchCheck 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 errorsSometimes 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

102 TM Confidential and Proprietary 101 Yocto Project : Debugging Patch issues Common ProblemsHow to Solve Patch not appliedCheck 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 applyCheck 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.

103 TM Confidential and Proprietary 102 Yocto Project : Debugging Version issues Common ProblemsHow to Solve Wrong component builtSome components have multiple providers (kernel, uboot for example) Make sure to set PREFERRED_PROVIDERS PREFERRED_PROVIDER_virtual/kernel_mx6 = “linux-imx” Wrong version builtSome 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.

104 TM Confidential and Proprietary 103 Yocto Project : Debugging Compiler issues Common ProblemsHow 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 rebuildingCache thinks component is already built so must force it to recompile bitbake -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.

105 TM Confidential and Proprietary 104 Yocto Project : Debugging Install Common ProblemsHow to Solve QA Error in build about files built but not installed Recipes needs a FILES_ lines to install Error on installingIn build install must create the directories. Install –d creates a directory Install is creating subdirectory in /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 rootfsCheck 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.

106 TM Confidential and Proprietary 105 Yocto Project Debugging Tips: Bitbake commands bitbake commandDetails bitbake –c cleanall Cleans downloads and all cache entries for component. Cleans out all entries in working directory! bitbake –c cleansstate Cleans cache but does not remove the download entry. Cleans out all entries in working directory! bitbake –c compile –f Forces a recompile of a component. Use after making changes in working directory. bitbake –c configure –f Forces a reconfigure – useful in kernel if defconfig is changed bitabke –c menuconfig linux-imxRuns the menu config for the kernel btibake -vVerbose output on command line (same as what is in the log) bitbake -kContinue past build breaks until a dependency requires stopping bitbake -c deploy –fDeploys a component to the rootfs with force – sometimes Yocto thinks a component is already deployed so this forces it bitbake -gLists a dependency tree for component bitbake -c populate_sdkGenerates an SDK script to reproduce the rootfs and build environment for non-Yocto Project build systems

107 TM Confidential and Proprietary 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"

108 TM Confidential and Proprietary 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 = " “

109 TM Confidential and Proprietary 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

110 TM Confidential and Proprietary 109 Yocto Project Debugging Tips: Reducing Build Time Share the download folder − In local.conf − DL_DIR = “ ” − Multiple builds will share common downloads, reducing disk space and improving speed Share the state folder − SSTATE_DIR = “ ” − 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

111 TM Confidential and Proprietary 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

112 TM Confidential and Proprietary 111 Yocto Project Community

113 TM Confidential and Proprietary 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 masterhttps://github.com/Freescale/fsl-community-bsp-platform − 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

114 TM © 2014 Freescale Semiconductor, Inc. | External Use


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

Similar presentations


Ads by Google