wiki:Yocto/Building

NOTE In conjunction with the Yocto BSP, please be sure to use the latest bootloader for proper operation. Bootloader Instructions Here

Yocto

References:

Building Yocto & Installing Gateworks Yocto BSP (ventana product family)

The following versions of Yocto are supported:

  • Yocto v2.3 (Pyro) Poky 17.0 released on 05/25/2017 (Under Testing)
    • using the gateworks_fslc_3.14_1.0.x_ga kernel
    • gstreamer-1.12 with many optional plugins enabled
    • gstreamer-imx-0.12.0
    • gcc-6.3.0
    • libc: musl-1.1.16
  • Yocto v1.8 (Fido) Poky 13.0 released on 05/19/2017 (Recommended - stable)
    • gateworks_fslc_3.14_1.0.x_ga kernel
    • gstreamer-1.4.5
    • gstreamer-imx-0.11.1
    • gcc-4.9.2
    • libc: uClibc-0.9.3

Old Releases

  • Yocto v1.7 (Dizzy) Poky 12.0 released on 02/25/2015
    • using the gateworks_3.10.17_1.0.0_ga kernel
  • Yocto v1.6 (Daisy) Poky 11.0 released on 4/25/2014
    • using the gateworks_3.10.17_1.0.0_ga kernel
  • Yocto v1.3 (Danny) Poky 8.0 released on 10/24/2012
    • using the gateworks_3.0.35_4.0.0 kernel

The Gateworks Ventana Yocto BSP provides a layer of package recipes that replace or override recipes in the upstream Yocto project such as:

  • kernel
  • bootloader
  • filesystem images
  • support utilities

For details on Yocto releases please see:

Pre-Compiled Yocto Binaries

For convenience Gateworks has some pre-built ubi files available. Note that you need to download a UBI image appropriate for the FLASH size on your board. Gateworks Ventana boards come with either 256MB NAND Flash or 2GB NAND Flash. You can see the size output from the bootloader over the serial console.

Installation instructions here

Most recent releases:

  • Yocto 2.3 (Pyro) 20170525: (testing)
    • Multimedia: (supports gstreamer video in/out encode/decode)
      • ubi 256MB FLASH (sha256sum:e2b41e2ab9d0c7829996249b1bf04cb902cbdc1d300a1d4411d9f96540a2f91a)
      • ubi 2GB FLASH (sha256sum:055b7644b1db05b96e33f948e1f314d39e7745fb1fd08dab248fe39f975c6eb2)
      • rootfs tarball (sha256sum:aa8db12b24a091db994d5cba1357e608b03be71c947a040954d70bd0ce7636d4)
  • Yocto 1.8.2 (Fido) 20170519: (stable)
    • Multimedia: (supports gstreamer video in/out encode/decode, but no GUI desktop)
      • ubi 256MB FLASH (sha256sum:761aa3e9aed6a781502550028e8ba676fa5cd7e4b09ca5a4e1465a349ae43149)
      • ubi 2GB FLASH (sha256sum:f5977fd53e3bbd15ddd9c327a4c5183282b1dba8578564cd7766d1ceec23a0e2)
      • rootfs tarball (sha256sum:9baf018982caed1528288a78b2fb3f142b453faf1bfab35894d591e0d306025d)
    • GUI: (supports gstreamer video in/out encode/decode and SATO X11 desktop with Matchbox window manager and Midori web browser)
      • ubi 2GB FLASH (sha256sum:6e799c99f8474e09ff7be11758f4141228cdecbd54ebc364fcd232686fe4e9c0)
      • rootfs tarball (sha256sum:a37cf51c390320668042052e4fefabf6907426172cf43abe84de38cfcaf120bc)

Old Releases

  • Yocto 1.8.2 (Fido) 20160328-1730:
    • Multimedia: (supports gstreamer video in/out encode/decode, but no GUI desktop)
      • ubi 256MB FLASH (sha256sum:a012d6ffb287221e686de973870e4232fe54f08d208f9ce5a436933ecff02606)
      • ubi 2GB FLASH (sha256sum:be735f02f0a68b9cca797cd62e71b9de2ecea3ab6e64c23e3406b175c160f25a)
      • rootfs tarball (sha256sum:94734c2c442427deb1df537d1da9abebb9b6e5dab2891c3a35e8ac200540dd07)
    • GUI: (supports gstreamer video in/out encode/decode and SATO X11 desktop with Matchbox window manager and Midori web browser)
      • ubi 2GB FLASH (sha256sum:96d229507a82022a9da7e91998b55dea706619c09548821d69712b97dc76919a)
      • rootfs tarball (sha256sum:12aecb6b2e38ba9f55c1986e8bb27c057521f96be1cb63227748db4cf3e8e7a3)
  • Yocto 1.8.1 (Fido) 20160223-1730:
    • Multimedia:
      • ubi 256MB FLASH (sha256sum:82aadb23405b286ffb934fa73d8205a9ac61249e38cacdae45d57fab49582afb)
      • ubi 2GB FLASH (sha256sum:f2847825989455b8d8eee0ecf1a58b4eae026b0f8498c829620fe96c41624493)
      • rootfs tarball (sha256sum:d17b603d3f81aad31aa4e642a03cf057c1ba21726d51f929fe027283d70624cf)
    • GUI:
      • ubi 2GB FLASH (sha256sum:e1df74be24d85b3c671f97c0c3f57189c5b40b62725c8acb9a7bffb6cb948e7e)
      • rootfs tarball (sha256sum:640e9b46715d098c272112cd477fb0b62fa7c11e26b59e2a8a10658231c52efb)
  • Yocto 1.7.1 (Dizzy) 20150904-1730:
    • Multimedia:
      • ubi 256MB FLASH (sha256sum:85bff50eca91596a19180a8e3c18132871c66efd44e4e7ba411ce15592191413)
      • ubi 2GB FLASH (sha256sum:34ec5c06c770b5eb286169afaa76285141965f6ddc56b4aa396742e427defd8e)
      • rootfs tarball (sha256sum:82e6643ee93927e19183325d4c584eb777803e39f108f6aa6932b654b5d6902f)
    • GUI:
      • ubi 2GB FLASH (sha256sum:4c53aae441c8ffda882e1c662e7a6d1e3f31484fae5b09089f454c5459ce16aa)
      • rootfs tarball (sha256sum:52967b45a3d3eb1b5ca2051200eae0f787e254c5f4d92ad2e07f2101907aa470)
  • Yocto 1.6.2 (Daisy) 20150221_0538:
    • Multimedia:
      • ubi 256MB FLASH (sha256sum:c05a6cca542bd2004cf51bc161d5c73b1e63322a9a543c6f566a8e876ec9274a)
      • ubi 2GB FLASH (sha256sum:10b27d97025df0c389972995497381a5e8e15beb79915f35c760aa0439370b7a)
      • rootfs tarball (sha256sum:b383e6bcc4543719423c318cae588897fde36d5f68f4b1f989054bd287f7557b)
    • GUI:
      • ubi 2GB FLASH (sha256sum:908162a6740d0086d268a905d26bb28f79f3eb21c0b0da205dda98d44267b54f)
  • Yocto 1.3.2 (Danny) 20140502:
    • Multimedia:
      • ubi 256MB FLASH (sha256sum:ff2118d68433ffa8995741c902ed035b02c85aaea0125d0e9d6e3e09f245e5c6)
      • rootfs tarball (sha256sum:4bec68e7040e151845358b1539830c164f29ffab6883233267ff1aa12813af34)

Version History:

  • Yocto v2.3:
  • Yocto v1.8:
    • Yocto 1.8.2 (Fido) 20170519
      • kernel: 3.14.48-1.0.x_ga+yocto+g3ae25e0
      • wireless drivers from linux-backports: 20160122
      • updated /etc/network/interfaces to specify nl80211 driver instead of deprecated wext
      • fix u-boot script for 4GiB boards
      • added GW560x support
      • added GW551x-C support
      • added spidev support
      • fix memory corruption in crypto driver
      • changed shutdown behavior to call system restart (avoid hang on overtemp)
      • added io4 ADC rail to gsc hwmon driver
      • added additional firmware for iwlwifi-7260
      • added iptables package
    • Yocto 1.8.2 (Fido) 20160328-1730:

Older History

  • Yocto v1.8:
    • Yocto 1.8.1 (Fido) 20160223-1730:
      • kernel: 3.14.48-1.0.x_ga+yocto+g7a5ffca6
      • wireless drivers from linux-backports: 20150129
      • fixed: gsc_update no longer erases user EEPROM data
      • fixed: VPU firmware update to resolve various encoding timeouts
      • fixed: FEC ethernet tx queue stalls
      • fixed: NAND stability issue
      • fixed: PWM pinmux
      • fixed: mxc_v4l2_capture initialization
      • fixed: reboot fix for GW5100 A/B revisions
      • updated: bootscript updated to v1.06 to remove LVDS display detection
      • added: added user controllable quality steps to gst-variable-rtsp-server
      • added: gpsd
      • added: crda
      • added: ethtool
      • added: hostapd-conf
      • added: SPI for GW522x
      • added: USB serial drivers
      • added: 7" LVDS display touchscreen controller (gt9x)
      • added: use GSC for power-down and restart
    • Yocto 1.8 (Fido) 20150904-2139:
      • Initial Gateworks Yocto v1.8 release
      • kernel: 3.14.48-1.0.x_ga+yocto+g4ba0a59
      • wireless drivers from linux-backports: 20150129
        • much improved ath10k performance/support including adhoc
      • added gstreamer 1.0 / gstreamer-imx
      • added avc8000 8x D1 miniPCIe capture card support
      • added gsc-update
      • added uboot-envtools
      • added gwsoc (GW16113) support)
  • Yocto v1.7:
    • Yocto 1.7.1 (Dizzy) 20150904-1730:
      • kernel: 3.10.17-1.0.0_ga+yocto+g4078cea
      • wireless drivers from linux-backports: 20141221
      • default to ldo-enabled mode
      • i2c: add retries on i2c nak's
      • gsc: fix gsc hwmon negative temperature readings
      • video: mxc: add support for HDMI interlace out
      • add UHS-I support
      • enable SATA_AHCI support
      • enable PCA953x IRQ
      • update IMX6SDL voltage set-points
      • disable PCIe Gen2
      • imx-thermal: set thresholds based on CPU temperature grade
      • tda1997x: default to yuv422smp capture mode for 1080p60Hz
      • tda1997x: fixed ITU709 colorimetry colorspace conversion
      • sgtl5000: fix audio pop
    • Yocto 1.7.1 (Dizzy) 20150221-0225:
      • Initial Gateworks Yocto v1.7 release
      • kernel: 3.10.17-1.0.0_ga+yocto+g4d177f6
  • Yocto v1.6:
    • Yocto 1.6.2 - 20150221_0538:
      • added support for GW551x, GW552x
      • added cryptodev module
      • wireless drivers:
        • updated drivers to compat-wireless_20141221
        • use internal regdb
      • kernel: 3.10.17-1.0.0_ga+yocto+g4d177f6
        • added support for DLC800FIGT3 8in XGA (1024x768) capacitive multi-touch touchscreen
        • added support for DLC700JMGT4 7in WSVGA (1024x600) capacitive multi-touch touchscreens
        • bumped IMX6Q/IMX6DL operating point voltages for VDD_ARM/VDD_SOC
        • added GSC drivers (Watchdog / Input)
        • fix gpio input state detect for PCA953x port expanders
        • added support for GW551x, GW552x
        • HDMI input:
          • fixed EDID handling
          • add supoprt for HDMI input in 16bit YUV422 mode (requires alternate device-tree configuration)
          • fix audio output format details and constrain samplerate
        • disable IMX6 busfreq driver
        • add i210 support
        • add GW16103 support
        • GW51xx: fix invalid PPS gpio
        • disable evbug driver
        • add LTC3676 PMIC support and ldo-bypass mode for GW53xx/GW52xx/GW51xx/GW551x/GW552x) (lowers overall power-reduction and thermal envelope)
    • Yocto 1.6.1 - 20141024:
      • kernel: 3.10.17-1.0.0_ga+yocto+gb5914e9
      • occasional PCIe link issue resolved
      • video sink issue resolved for same resolution input/output
      • dual-display HDMI+CVBS fixed
      • GW16082 support fixed
      • PCIe IRQ slot mapping issue fixed
      • GW5400 stability issue fixed
  • Yocto v1.3:
    • Yocto v1.3.2 - 20140502:
      • kernel: gateworks_3.0.35-4.4.0-gaabbed9

For instructions on flashing UBI files, please see this section.

Obtaining and Compiling the Source Code

The following build instructions refer to Debian GNU/Linux 7.4 and Ubuntu 12.04 - 16.04.

Please make sure the following packages are installed

sudo apt-get install chrpath libsdl-dev texinfo curl build-essential git subversion diffstat gawk
  1. fetch the repo tool (if you don't have it already in your path):
    mkdir ~/bin
    curl http://commondatastorage.googleapis.com/git-repo-downloads/repo > ~/bin/repo
    chmod a+x ~/bin/repo
    
  1. Setup source repos:
    PATH=${PATH}:~/bin
    mkdir ~/ventana-yocto
    cd ventana-yocto
    repo init -u https://github.com/Gateworks/gateworks-yocto-bsp-platform -b pyro
    
    • in the above command pyro is the name of the branch that refers to Yocto v2.3
  1. (optional) pin the repo versions to the latest version which was known to have been successfully built by the Gateworks nightly build server:
    wget http://dev.gateworks.com/yocto/2.3/snapshot.xml # fetch the pinned manifest from the last successful nightly build
    mv snapshot.xml .repo/manifest.xml # copy over the generic un-pinned manifest
    
    • the repo init command will fetch a repo 'manifest' which refers to various source repositories and branches but will fetch the latest changes from those branches (which occasionally may fail to build due to upstream errors common with community based projects). The Gateworks nightly build server posts the manifest pinned to the specific revision used in the build on completion of a successful build. You can also use a snapshot from a previously released pre-built binary by using the other snapshot files in http://dev.gateworks.com/yocto/2.3
  1. Download latest sources:
    repo sync -c -j8
    
    • the -c parameter tells repo to just pull down the current branch specified by the manifest file (thus is more network and disk usage efficient)
    • the -j parameter tells repo to use multiple processes (8 in this example) which will speed up fetching
    • you can later repeat the repo sync to pull down the latest sources specified for the repo manifest file for the current branch specified in the repo init in step 2 above
  1. Activate bitbake environment. You will have to accept license agreement.
    . ./setup-environment build
    
    • do this every time for a new shell when you wish to use bitbake
  1. (optional) configure build (we add this for our pre-built images):
    • add support for commercial licensed recipes: adds gstreamer1.0-plugins-ugly containing a52dec, dvdlpcmdec, dvdsub, lame, mpg123, rmdemux, singmux)
      # add commercial license support if desired
      echo 'LICENSE_FLAGS_WHITELIST += "commercial"' >> conf/local.conf
      
    • add support for additional gstreamer plugins:
      cat << EOF >> conf/local.conf
      PACKAGECONFIG_append_pn-gstreamer1.0-plugins-base = " cdparanoia opus "
      PACKAGECONFIG_append_pn-gstreamer1.0-plugins-good = " dv1394 jack libv4l2 vpx wavpack "
      PACKAGECONFIG_append_pn-gstreamer1.0-plugins-bad = " assrender dc1394 faac faad fluidsynth kms libmms libssh2 modplug openal opencv openjpeg opusparse resindvd rsvg rtmp schroedinger srtp voaacenc voamrwbenc webp "
      PACKAGECONFIG_append_pn-gstreamer1.0-plugins-ugly = " amrnb amrwb cdio dvdread x264 "
      EOF
      
    • you should also consult the local.conf section to see other useful configuration options
  1. Build a filesystem image recipe. gateworks-image-multimedia is recommended.
    • For a detailed description of the Gateworks specific images, please see the images page.
      bitbake gateworks-image-multimedia
      
    • This could take several hours depending on your Internet speed and development host
    • core-image-minimal results in 1.8GB of downloaded sources, 14GB of space used in build/tmp, and takes ~70mins on a Quad-core 2.5GHz build host, not accounting for your network connection.
    • By default, images, kernels, etc are found in tmp/deploy/images/ventana
  1. Grab .ubi file which contains both kernel and root filesystem and program it to the board with instructions below:
    tmp/deploy/images/ventana/gateworks-image-multimedia-ventana_normal.ubi
    tmp/deploy/images/ventana/gateworks-image-multimedia-ventana_large.ubi
    

Notes:

  • to download any updates and rebuild, repeat the above starting with step 3
  • to re-activate a new shell repeat the above starting with step 4 (you can only have 1 shell activated at a time - you need to activate a new shell if you have exited a previously activated shell)
  • to clean a specific recipe use bitbake -f -c clean <recipe>. Note that to represent the kernel you can use the virtual recipe name 'virtual/kernel'
    • Note: After cleaning a recipe, rebuild with the --no-setscene command line argument to bitbake, e.g. bitbake --no-setscene <recipe>
  • to clean all built items (but not remove downloaded sources or the sstate-cache) you can rm -rf tmp
  • to clean everything and start over you can remove the entire build directory and repeat the above starting with step 4 (this will remove all downloaded sources as well)

Useful References:

Troubleshooting build failures

The OpenEmbedded build system does a fairly good job of reporting build errors in a sane way to help you diagnose the problem.

In general, for each package that failed, you will see three lines of output from bitbake for each package. For example, the following shows a 'fetch error' for the evtest_1.25 package:

ERROR: Function failed: Fetcher failure for URL: 'http://cgit.freedesktop.org/~whot/evtest/snapshot/evtest-1.25.tar.bz2;name=archive'. Unable to fetch URL from any source.
ERROR: Logfile of failure stored in: /usr/src/tharvey/nightly/yocto/danny/20140820_8bd8be2d/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/evtest-1.25-r0/temp/log.do_fetch.23170
ERROR: Task 452 (/usr/src/tharvey/nightly/yocto/danny/20140820_8bd8be2d/sources/meta-openembedded/meta-oe/recipes-support/evtest/evtest_1.25.bb, do_fetch) failed with exit code '1'

The first ERROR line here shows the cause of the issue, the second shows where the detailed log of the failure is, and the third simply says what package and task failed. If you need assistance understanding a particular error, you will want to provide the three lines above as well as the log file pointed to in the second line.

Fetch failure

The most common build failure (of any linux build system) is failure to be able to fetch sources for the 100's of OpenSource? projects the build system uses from the Internet. This can be caused by a network issue on your end, a network issue on the source package sites end, or a site/file that has been permanently moved/removed.

If this occurs you will see an 'ERROR: Function failed: Fetcher failure' message such as the following output from bitbake:

ERROR: Function failed: Fetcher failure for URL: 'http://cgit.freedesktop.org/~whot/evtest/snapshot/evtest-1.25.tar.bz2;name=archive'. Unable to fetch URL from any source.

If you encounter such an error the most obvious thing to make sure your Internet connection is solid and try first is simply bitbake your desired package again. If it occurs again, its likely an issue on the site that the package URI specifies as the package source. This could be a temporary issue, or the site/file could have been permanently moved/removed for some reason and your either building an older BSP or the package source simply hasn't been updated to deal with the change (as I mentioned, this is a common issue).

To combat this issue, there are mirrors where you may be able to find the missing file(s). Note that Gateworks provides such a mirror that it tries to keep updated at http://dev.gateworks.com/sources. Once you find the file, copy it to your download directory, touch the file indicating the fetch is done (the source file with a .done on the end) and bitbake your package again. For example, the above shows a failure to fetch the evtest-1.25.tar.bz2 file:

wget http://dev.gateworks.com/sources/evtest-1.25.tar.bz2
cp evtest-1.25.tar.bz2 downloads/
touch downloads/evtest-1.25.tar.bz2.done
bitbake gateworks-image-multimedia

Upstream Breakage

It is not uncommon for community based projects such as Yocto to encounter build failures after changes because of the complexity of the build system. In some cases breakage may occur simply because of collisions between upstream Yocto repos and the packages that Gateworks overrides.

If you are building an 'un-pinned' release (you are not using a snapshot of the manifest file which has sha revisions for each repository) and you encounter a build failure, you may want to switch to a manifest file that produced a successful build by the Gateworks nightly build server. Manifests point to source code repositories by network server and branch, but typically do not pin the branch to a specific repository commit. A 'pinned' snapshot can be used instead that does specify a specific commit of each repository and branch. Refer to step 3 in the instructions above

Keeping up to date and/or pinning source with repo

When building projects that use multiple source repositories any repository may change and thus make your working directory out of date. Because Yocto uses several package feeds with their own repositories this can make it difficult to keep in sync - this is where the repo tool comes in handy.

The repo sync command will update all repositories with upstream changes:

repo sync --quiet

You can override the default Manifest by using a local manifest file if you want to keep in sync with the upstream manifest yet make some minor change like pin a specific project or add a couple of projects. Reasons for doing this could be:

  • adding new projects
  • pinning certain projects
  • removing certain projects

To use a local manifest create .repo/local_manifest.xml and it will be merged with .repo/manifest.xml by the repo tool whenever the manifest is used. You can use the remove-project directive to remove a project that you don't want and even add it back with your own choices if you want something different. For example:

<?xml version="1.0" encoding="UTF-8"?>
<manifest>
   <remove-project path="hardware/qcom/display" name="CyanogenMod/android_hardware_qcom_display" />
   <project path="hardware/qcom/display" name="WinSuk/android_hardware_qcom_display" />
</manifest>

The repo manifest command will create a snapshot of your current project's manifest allowing you to create a pinned version that can be used later to create a working directory with the various projects at the exact same state as your current working directory:

repo manifest -o snapshot.xml -r

This snapshot can then be copied over .repo/manifest.xml in a different build directory to pin the repository sources.

The Gateworks nightly build server creates a manifest snapshot like this and uploads the latest successful build to http://dev.gateworks/com/yocto so that it can be used to re-create a successful nightly build.

References:

Updating and rebuilding

From time to time the various repositories including in the Yocto build (a combination of Gateworks packages, community packages, Freescale community packages, and Yocto community packages) will get updates to various packages to add features or resolve issues.

The repo tool which manages the set of repositories in your yocto directory (based on a package manifest) can 'sync' all repos to the latest state using the following in the main yocto directory (the directory containing the sources and build subdirs:

./repo sync

Following a sync, you can bitbake your filesystem image again to build a new filesystem with all updates:

# activate a bitbake shell if not already done
. ./setup-environment build
bitbake gateworks-image-multimedia
  • build the filesystem image of your liking

If you want to start clean you can remove the following:

rm -rf bitbake.* buildhostory cache sstate-cache tmp

local.conf

Many customization's can occur in your local.conf file residing in the build directory. A template is created automatically when you source the setup-environment script when you prepare a Yocto distribution for building based on the MACHINE and/or the DISTRO you have selected.

  • build threads (defaults to 8 appropriate for a quad-core machine):
    BB_NUMBER_THREADS = '8'
    PARALLEL_MAKE = '-j 8'
    
  • select package manager:
    PACKAGE_CLASSES = "package_ipk"
    
    • can be 'package_ipk' (opkg), 'package_rpm', 'package_deb', 'package_tar'
  • Inherit rm_work to save hard disk space, exclude things you want kept around for development:
    # Inherit rm_work to save hard disk space by removing the build directory after a package is built
    INHERIT += "rm_work"
    
    # exclude packages that you may be actively developing:
    RM_WORK_EXCLUDE += " \
            gstreamer1.0 \
            gstreamer1.0-plugins-base \
            gstreamer1.0-plugins-good \
            gstreamer1.0-plugins-bad \
            gstreamer1.0-plugins-ugly \
            gstreamer1.0-rtsp-server \
    "
    
  • set DL_DIR to something common to multiple projects hosted on your machine (downloads will be ~10GB)
    DL_DIR ?= "/usr/src/dl/"
    
  • Add extra packages to images (feature based):
    EXTRA_IMAGE_FEATURES += "ssh-server-dropbear package-management"
    
  • Add extra packages (package based):
    IMAGE_INSTALL_append = " \
            v4l-utils \
            bash \
            strace \
            gdb \
            gdbserver \
            valgrind \
    "
    
  • Remove extra packages (ie override what distro may be selecting):
    DISTRO_FEATURES_remove = " wayland x11 "
    

Layers

OpenEmbedded Core contains a base layer of recipes, classes and associated files that is meant to be common among many different OpenEmbedded derived systems including the Yocto project. This meta-data is co-maintained by the Yocto Project and the OpenEmbdded Project.

The Android repo tool is used to work with a manifest of various GIT repo's that contain the meta-data layers.

Various 'layers' of meta-data can be used together by specifying layer priority based on paths. The configuration of layers exists in your build/conf/bblayers.conf file and can be modified via the bitbake-layers application (recommended) or by hand.

Additionally the bitbake-layers application can add additional meta layers to your configuration for you based on the OpenEmbedded layer index: https://layers.openembedded.org/. This is controlled by BBLAYERS_FETCH_DIR which by default is weakly set to ${COREBASE} (so you can override it in local.conf) which defaults to sources/poky meaning when it fetches layers and the layers they depend on, they will be cloned into that directory.

For the Gateworks BSP the default layer configuration looks like this:

BBLAYERS = " \
  ${BSPDIR}/sources/poky/meta \
  ${BSPDIR}/sources/poky/meta-poky \
  \
  ${BSPDIR}/sources/meta-openembedded/meta-oe \
  ${BSPDIR}/sources/meta-openembedded/meta-python \
  ${BSPDIR}/sources/meta-openembedded/meta-networking \
  ${BSPDIR}/sources/meta-openembedded/meta-multimedia \
  \
  ${BSPDIR}/sources/meta-freescale \
  ${BSPDIR}/sources/meta-freescale-3rdparty \
  ${BSPDIR}/sources/meta-freescale-distro \
  ${BSPDIR}/sources/meta-gateworks \
  ${BSPDIR}/sources/meta-gstreamer1.0 \
  "

Layer prioritization comes from the layer.conf file in each layer. This file sets a priority level and the BBFILES variable which identifies recipes.

Examples:

  • show layers:
    $ bitbake-layers show-layers
    layer                 path                                      priority
    ==========================================================================
    meta                  /usr/src/ventana/yocto/pyro-2.3/sources/poky/meta  5
    meta-poky             /usr/src/ventana/yocto/pyro-2.3/sources/poky/meta-poky  5
    meta-oe               /usr/src/ventana/yocto/pyro-2.3/sources/meta-openembedded/meta-oe  6
    meta-multimedia       /usr/src/ventana/yocto/pyro-2.3/sources/meta-openembedded/meta-multimedia  6
    meta-freescale        /usr/src/ventana/yocto/pyro-2.3/sources/meta-freescale  5
    meta-freescale-3rdparty  /usr/src/ventana/yocto/pyro-2.3/sources/meta-freescale-3rdparty  4
    meta-freescale-distro  /usr/src/ventana/yocto/pyro-2.3/sources/meta-freescale-distro  4
    meta-python           /usr/src/ventana/yocto/pyro-2.3/sources/meta-openembedded/meta-python  7
    meta-networking       /usr/src/ventana/yocto/pyro-2.3/sources/meta-openembedded/meta-networking  5
    meta-gateworks        /usr/src/ventana/yocto/pyro-2.3/sources/meta-gateworks  6
    meta-gstreamer1.0     /usr/src/ventana/yocto/pyro-2.3/sources/meta-gstreamer1.0  6
    

References:

Distros

Distrubutions are configurations that dictate policy decisions such as alternative packages, compile-time options, and other low-level configurations.

You can find available distros by looking for recipes within distro directories:

find sources/ -name distro -exec ls {} \;

Here's a rundown of what's available in the layers used by the FSL Community BSP:

  • sources/meta-freescale-distro/conf/distro presents 2 sets of distros which basically configure a graphic backend between directfb, x11, wayland, and xwayland:
    • The 'fslc-*' distros inherit from the 'poky' distro but uses bluez5 for bluetooth (vs bluez4) and further tune the compiler flags for IMX processors and select the graphic backend
      • fslc-framebuffer: Removes conflicting backends (x11 wayland directfb)
      • fslc-wayland: Removes conflicting backends (directfb, x11) and adds wayland
      • fslc-x11: Removes conflicting backends (directfb, wayland) and adds x11
      • fslc-xwayland: Removes conflicting backends (directfb) and adds x11, wayland
  • The 'fsl-*' distros inherit from the above fslc-* distros and further set the bootloader/kernel/gstreamer plugin to freescale variants appropriate for Freescale reference boards only
    • fsl-framebuffer: Removes conflicting backends (x11 wayland directfb)
    • fsl-wayland: Removes conflicting backends (directfb, x11) and adds wayland
    • fsl-x11: Removes conflicting backends (directfb, wayland) and adds x11
    • fsl-xwayland: Removes conflicting backends (directfb) and adds x11, wayland
  • sources/poky/meta-poky/conf/distro
    • poky - Yocto Project Reference Distro
    • poky-tiny: A tiny Linux system comprised of a kernel tailored to support a specific MACHINE and busybox
    • poky-bleeding - bumps some preferred package versions to versions that are perhaps not as well tested (glib/atk/pango/gtk)
  • sources/poky/meta/conf/distro

References:

Images

Images are recipes that create filesystem images from a set of packages.

Because they have the word 'image' in their recipe name by convention, you can list all available images with bitbake-layers:

bitbake-layers show-recipes "*image*" | grep ':' # list all possible images

Some notable images:

  • core-image-minimal - A minimal root filesystem image with console
  • core-image-x11 - A very basic X11 image with a terminal
  • core-image-sato - Image with Sato, a mobile environment and visual style for mobile devices. The image supports X11 with a Sato theme, Matchbox window manager, Pimlico applications, and contains terminal, editor, and file manager.
  • gateworks-image-minimal - core-image-minimal + some tools specific to gateworks boards
  • gateworks-image-multimedia - gateworks-image-minimal + a fairly full installation of gstreamer for audio/video capture and playback

References:

Disk usage and keeping things clean

Yocto builds can chew up a lot of disk space (true really of any OS build system).

Bitbake will keep copies of all workdirs for old packages, so over time if you update recipes (or repo sync which may update recipes) your disk usage will grow. You can safely remove the old packages manually from build/tmp if you wish, or use bitbake -cclean <recipe.bb> to clean specific recipes (note that bitbake -cclean <package> will only clean the current preferred version, not old packages).

Another thing that can cause disk usage bloat is filesystem images. Each time you build a filesystem image (ie gateworks-image-*) bitbake will create a new one with a timestamp in build/tmp/deploy/images/ and the build system will keep around several artifacts such as the filesystem tarball, the ubifs, and the ubi (thus a filesystem image resulting in a 100MB UBI actually chews up over 300MB of disk space each time you build it depending on compression). Its very likely that if you are re-building an image, you probably don't care about the old ones, so you might want to get in the habit of removing them before building. For example, if you want to build gateworks-image-multimedia:

rm -rf build/tmp/deploy/images/gateworks-image-multimedia* ;# remove old images we don't care about
bitbake gateworks-image-multimedia ;# build a new one

For Yocto, all temporary files will be in build/tmp so if you want to clear out everything and start over you can:

rm -rf build/tmp

You might also want to clean out your downloads directory

Additionally take a look at the rm_work class in local.conf

Building / Updating / Adding Packages

Please read more Yocto/packages

Building a toolchain and/or SDK

See Yocto/SDK for information about a pre-built downloadable SDK

You can use bitbake to create a toolchain (cross-compiler) or an Software Development Kit (SDK) comprised of a cross-toolchain and libs.

Toolchain:

bitbake meta-toolchain

SDK (contains meta-toolchain as well as -dev and -dbg packages with headers and libs):

bitbake -cpopulate_sdk gateworks-image-multimedia
  • The produced SDK will be a self-extracting shell-script in tmp/deploy/sdk that contains all the include headers and libs for the packages in the image - you can build an SDK for any image by replacing 'gateworks-image-multimedia' with any other buildable filesystem image.

Patches

The process of sending patches upstream and/or asking for assistance depends on the layer and is typically described in the README's for the various layers:

Other layers:

The layers you are using can be found in your build/conf/bblayers.conf and you can also use the bitbake-layers show-layers command to list them with their prorities:

$ bitbake-layers show-layers
layer                 path                                      priority
==========================================================================

meta                  /usr/src/ventana/yocto/morty-2.2/sources/poky/meta  5
meta-poky             /usr/src/ventana/yocto/morty-2.2/sources/poky/meta-poky  5
meta-oe               /usr/src/ventana/yocto/morty-2.2/sources/meta-openembedded/meta-oe  6
meta-multimedia       /usr/src/ventana/yocto/morty-2.2/sources/meta-openembedded/meta-multimedia  6
meta-freescale        /usr/src/ventana/yocto/morty-2.2/sources/meta-freescale  5
meta-freescale-3rdparty  /usr/src/ventana/yocto/morty-2.2/sources/meta-freescale-3rdparty  4
meta-freescale-distro  /usr/src/ventana/yocto/morty-2.2/sources/meta-freescale-distro  4
meta-python           /usr/src/ventana/yocto/morty-2.2/sources/meta-openembedded/meta-python  7
meta-networking       /usr/src/ventana/yocto/morty-2.2/sources/meta-openembedded/meta-networking  5
meta-gateworks        /usr/src/ventana/yocto/morty-2.2/sources/meta-gateworks  6

The following table shows the layer name, path, GIT repo, and maillist details for the layers used in the Gateworks BSP:

Layer Path repo maillist
meta poky/meta https://git.yoctoproject.org/git/poky https://lists.yoctoproject.org/listinfo/poky poky@…
meta-poky poky/meta-poky https://git.yoctoproject.org/git/poky https://lists.yoctoproject.org/listinfo/poky poky@…
meta-oe meta-openembedded/meta-oe https://github.com/openembedded/meta-openembedded http://lists.openembedded.org/mailman/listinfo/openembedded-core openembedded-core@…
meta-multimedia meta-openembedded/meta-multimedia https://github.com/openembedded/meta-openembedded http://lists.openembedded.org/mailman/listinfo/openembedded-core openembedded-core@…
meta-python meta-openembedded/meta-python https://github.com/openembedded/meta-openembedded http://lists.openembedded.org/mailman/listinfo/openembedded-core openembedded-core@…
meta-networking meta-openembedded/meta-networking https://github.com/openembedded/meta-openembedded http://lists.openembedded.org/mailman/listinfo/openembedded-core openembedded-core@…
meta-freescale meta-freescale https://git.yoctoproject.org/git/meta-freescale https://lists.yoctoproject.org/listinfo/meta-freescale meta-freescale@…
meta-freescale-3rdparty meta-freescale-3rdparty https://github.com/Freescale/meta-freescale-3rdparty https://lists.yoctoproject.org/listinfo/meta-freescale meta-freescale@…
meta-freescale-distro meta-freescale-distro https://github.com/Freescale/meta-freescale-distro https://lists.yoctoproject.org/listinfo/meta-freescale meta-freescale@…
meta-gstreamer1.0 meta-gstreamer1.0 https://github.com/dv1/meta-gstreamer1.0
meta-gateworks meta-gateworks https://github.com/Gateworks/meta-gateworks meta-gateworks@lists.gateworks.com

References:

Installing Firmware

NAND FLASH

There are 2 options:

  1. TFTP Server (recommended, faster, but requires network connection) - Read below
  2. JTAG Programmer (more steps and slower, requires no network)- Link here

Boards with a NAND FLASH large enough to accommodate your image (Ventana boards have a 256MB NAND flash by default which is large enough for fsl-image-multimedia) can have the UBI filesystem created by the build process placed on them. A ubi image will be built in tmp/deploy/images directory alongside the kernel and filesystem tarballs. The ubi image will end with _normal.ubi which is suitable for standard NAND flash sizes on Ventana boards. If you have a Ventana with a 2GB or larger NAND device, you need to build for the 'large' NAND flash layout which you can do by changing the UBI_CONFIG variable in sources/meta-gateworks/conf/machine/ventana.conf from 'normal' to 'large' which will result in a ubi image ending with _large.ubi.

To install firmware to a Ventana board using Serial/ENET, do the following:

First, get yourself into a sane state:

  • Copy your UBI file to a proper location that your tftpserver has access to
  • connect to the serial console of the target board (instructions may be found here if you are unfamiliar with this)
  1. Connect your target board to your network, set ipaddress and serverip in uboot
    # Break out of the bootloader
    setenv ipaddr <localip>
    setenv serverip <serverip>
    
    For Example:
    setenv ipaddr 192.168.1.211
    setenv serverip 192.168.1.14
    
    • Note eth0 should be used which is natively supported. On special boards like the GW5520, both ports are ran off PCI, thus PCI needs to be enabled in the bootloader as shown here
  1. Modify the boot variables to point to the image file on the tftp server and update:
    # Note: Adjust file path/name to match file structure on your tftpserver
    setenv image_rootfs gateworks-image-gui-ventana.ubi
    
  1. Run the nand update script to pull the image from the tftp server and load it:
    run nand_update
    
    • Troubleshooting
      • Be sure that the tftp server is working properly and started on the host PC
      • An error such as 'ERROR: Need valid 'usbnet_devaddr' to be set at drivers/usb/gadget/ether.c:2362/usb_eth_init()' is simply because the ethernet transfer failed and it is attempting to use the USB network which needs to be configured.
  1. Once it is done loading, type the command boot
    boot
    
  1. The login is root with no default password.

Installing on Removable storage: mSATA/USB/uSD

For this, do not use the .ubi file. Use the tarball, for example: gateworks-image-gui-ventana.tar.bz2

To image the built firmware onto a removable flash device such as an mSATA disk, uSD card, or USB stick you can use the following script which creates a single ext4 partition for rootfs.

DISK=/dev/sdc
# create a single Linux partition
printf ",,L,,\n" | sudo sfdisk -uS ${DISK}
# format it as ext4
sudo mkfs.ext4 ${DISK}1
# mount it
sudo mount ${DISK}1 /mnt/disk
# untar the filesystem image
sudo tar -C /mnt/disk -xvf tmp/deploy/images/ventana/gateworks-image-gui-ventana.tar.bz2
sudo umount /mnt/disk
  • Notes:
    • set DISK to the appropriate device on your Linux Host (it may very well differ from /dev/sdc). If you do not do this, you risk overwriting your OS partition. Once the flash device is plugged into the computer, you can find the device by typing mount and examining the output. For example if A flash stick with 1 partition shows as /dev/sdc1 then the block device is /dev/sdc (the 1 is the first partition)

Using the latest bootloader and bootloader env scripts simply placing this removable media in a Ventana board will boot it.

See above for pre-built rootfs tarballs of our latest releases

Last modified 4 months ago Last modified on 06/06/17 12:11:34

Attachments (2)

Download all attachments as: .zip