Yocto Packages

Please read the great Yocto Reference manual before proceeding:

Often a developer will want to add a new package such as tcpdump or openvpn, or other standard packages.

There are presumably many ways to do this, some of which are better than others.

GUI Method

A GUI for bitbake is called Hob. See more information here

At Gateworks, we use bitbake and opkg via the shell.

Using bitbake and opkg (shell commands)

The opkg command can install and remove .ipk packages based on package feeds much like other Linux distros (Ubuntu and Debian use apt to manage .deb packages, Fedora uses rpm to manage .rpm packages)

If properly configured, opkg will download packages from an online package repository and deal with package dependencies for you.

Package Feed types

Note that packages are split into feeds based on their type called 'feeds'

On the target, the /etc/opkg/arch.conf file lists all types appropriate for your target and prioritizes them in case a package exists in multiple feeds.

On the build host, packages are placed into directories for each feed.

Some examples of standard feeds include:

  • all - packages that are applicable for all targets (ie scripts, text files, cross-platform data files)
  • armv7a - packages that are applicable for the armv7a instruction set only (ie compiled applications)
  • armv7a-vfp-neon - packages that are applicable for the armv7a instruction set using NEON hardware floating point
  • ventana - packages that are applicable to the ventana machine target (ie kernel and kernel modules)

Package Building (using bitbake)

The bitbake tool is used to build packages and images and is part of the OpenEmbedded? build system used by the Yocto Linux distribution.

The following steps provide an example of building a package (in this case e2fsprogs):

  1. Find package you want. You can use bitbake-layers show-recipes to search for packages:
    bitbake-layers show-recipes e2fsprogs
    Parsing recipes..done.
    === Available recipes: ===
      meta                 1.42.9
    • if you don't know what the package name is, try using grep for something less specific:
      bitbake-layers show-recipes | grep e2f
      Parsing recipes..done.
  1. Compile and build package with bitbake command:
    bitbake e2fsprogs
  1. The built package .ipk will be placed somewhere in the tmp/deploy/ipk path depending on the package architecture the package recipe specified. You can use find to search for the package by name:
    find tmp/deploy/ipk/ -name "e2fsprogs*"
  • Notice that the e2fsprogs package gets placed in the cortexa9hf-vfp-neon feed because it is a compiled application tuned for an ARM Cortex-A9 with hard-float
  • Notice above each package may be broken into sub-packages as above. There are some common sub-packages split out and often a recipe will split out certain tools into sub-packages if you may want some but not all of its components - it is up to the creator of the recipe to decide what is split out. Here are some common sub-packages:
    • -dev packages include library headers and static libraries required for building applications using that package or library on the target
    • -doc packages include the man pages etc
    • -dbg packages include non-stripped versions of the executables necessary for using a debugger on the target such as gdb

Installing packages on target with opkg

You can use the opkg command on the target to install packages.

You have the option of downloading your .ipk files manually and using opkg to install them one at a time, or you can provide opkg a URL and it will attempt to fetch the file for you.

Additionally, you can configure opkg to point to online package feed directory repositories and it will download them for you including their dependencies.


  1. Transfer desired .ipk file to Gateworks board that is running Yocto already. Use a tool such as wget. Note that opkg will fetch URLs for you if you provide a proper URI such as http://<server>/...
  1. Use the opkg install command to install on target.
    opkg install e2fsprogs-mke2fs_1.42.1-r4_armv7a-vfp-neon.ipk
    2a. This case there was a error because this package has dependencies that are not installed. Please install these first.
    root@ventana:~# opkg install e2fsprogs-mke2fs_1.42.1-r4_armv7a-vfp-neon.ipk
    Installing e2fsprogs-mke2fs (1.42.1-r4) to root...
    Collected errors:
     * satisfy_dependencies_for: Cannot satisfy the following dependencies for e2fsprogs-mke2fs:
     *      libcom-err2 (>= 1.42.1) *       libe2p2 (>= 1.42.1) *   libext2fs2 (>= 1.42.1) *
     * opkg_install_cmd: Cannot install package e2fsprogs-mke2fs.
    2b. After installing the dependencies, try again
    root@ventana:~# opkg install e2fsprogs-mke2fs_1.42.1-r4_armv7a-vfp-neon.ipk Installing e2fsprogs-mke2fs (1.42.1-r4) to root...
    Configuring e2fsprogs-mke2fs.
  2. Test package
    root@ventana:~# mk
    mkdir         mkfs.ext2     mkfs.ext4dev  mkfs.ubifs    mktemp
    mke2fs        mkfs.ext3     mkfs.jffs2    mknod
    mkfifo        mkfs.ext4     mkfs.minix    mkswap
    root@ventana:~# mkfs.ext4
    Usage: mkfs.ext4 [-c|-l filename] [-b block-size] [-C cluster-size]
            [-i bytes-per-inode] [-I inode-size] [-J journal-options]
            [-G flex-group-size] [-N number-of-inodes]
            [-m reserved-blocks-percentage] [-o creator-os]
            [-g blocks-per-group] [-L volume-label] [-M last-mounted-directory]
            [-O feature[,...]] [-r fs-revision] [-E extended-option[,...]]
            [-t fs-type] [-T usage-type ] [-U UUID] [-jnqvFKSV] device [blocks-count]

Installing packages using package feeds with opkg

Setting up a package feed is the easiest way to install packages, but it does require setting up a web server on your build host and adding in a feed conf file.


  1. Install and configure a web server on your build host. For example, to install and configure lighttpd on Ubuntu:
    # install the package
    sudo apt-get install lighttpd
    # add an alias for 'yocto' to your build hosts directory:
    sudo sh -c 'echo "alias.url += ( \"/yocto\" => \"/usr/src/yocto/build/tmp/deploy/ipk\" )" >> /etc/lighttpd/lighttpd.conf'
  1. On your target, point to the various feeds on your hosts build directory. For example, if your build host is at and you setup the alias above as 'yocto' to point to your build/tmp/deploy/ipk directory:
    FEEDS="all armv7at2hf-neon armv7at2hf-neon-mx6qdl ventana"
    for feed in $FEEDS; do
      echo "feed:$feed"
      echo "src/gz $feed $URL/$feed" >> /etc/opkg/opkg.conf
    • For Yocto 1.8 use 'FEEDS="all cortexa9hf-vfp-neon cortexa9hf-vfp-neon-mx6qdl ventana"'
  1. update your feeds and install:
    opkg update
    opkg install e2fsprogs-mke2fs
    • you will need to update your feeds with opkg update each time they change on your build host (ie you have built something new)

Package Development Workflow

In order to modify a package, several common steps must be taken. Please see this below guide as a sample of what you can expect:

  1. Create a new package (if not modifying an existing one)
  2. activate a bitbake shell and build the package (performs all necessary steps per package recipe to fetch,patch,configure,compile,install,package and results in an ipk in build/tmp/deploy)
    bitbake <package>
  3. edit source in packages WORKDIR
    • This will be in build/tmp/work in a subdirectory based on the feed for that package. For example packages that are independent of architecture, machine, etc (ie shell scripts, text files) will be in tmp/work/all-poky/linux and packages that are independent of machine but dependent on architecture (ie compiled apps or libs) will be in an arch specific subdir such as tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi and packages that depend on the 'ventana' machine such as the kernel or kernel modules, will be in the tmp/work/ventana-poky-linux-gnueabi subdir.
  4. force bitbake (-f flag and --no-setscene) to re-execute the 'compile' task (-ccompile) as bitbake won't know that source files have been changed in the WORKDIR and bitbake <package> will think its already done
    bitbake -f --no-setscene -ccompile <package>
    • this forces all tasks dependent on the 'compile' tasks will now be flagged as dirty
    • the --no-setscene argument tells bitbake to not use various cache files
    • if you are copying build objects to your target manually from the package WORKDIR you can do that now, and simply repeat steps 3 and 4 until you are done with your development
  5. bitbake the package to complete all remaining tasks to create an ipk
    bitbake <package>
  6. if using opkg to get the updated package on your target, update the package indexes
    bitbake package-index
    • if only using opkg for package updates you can now repeat steps 3, 4, 5, and 6 until you are done with your development
  7. if re-flashing the filesystem image rebuild that as well:
    bitbake gateworks-image-test
    • Note that bitbake stores filesystem images in the DEPLOY directory by timestamp, and they will never be removed. You may want to rm -rf tmp/deploy/images/ventana/gateworks-image-test* prior to rebuilding to keep disk space down
    • if using ubi filesystem for package updates you can now repeat steps 3, 4, 5, 6, and 7 until you are done with your development

If you are ultimately trying to produce a patch that will persist for the package you will want to use something like quilt to track your patch in step 3. Then, when your development cycle is complete you can:

  1. take the resulting patch(es) produced by quilt and place them in an appropriate directory for that package (something thats in the filespath)
  2. add the patches to the SRC_URI of the package
  3. bump the package revision (PR) (or equivalent) so that bitbakes dependency system knows the package needs to be rebuilt in its entirety
  4. push your new recipe to your version control subsystem (or share it via mailist or public repository)

Alternatively if you are trying to 'upstream' your patches (which you should do to avoid future maintenance on your part):

  1. take the resulting patch(es) produced by quilt or git and submit them to the projects mailist
  2. once your patches are upstreamed you can update the package recipe SRCREV to pull the updated version from source control (or create a new recipe if appropriate). If you create a new recipe (because the version of the package changes) or bump the SRCREV (because the recipe pulls 'un-released' source from a source control repository) you don't need to bump the package revision (PR) as bitbake tracks the package by version.

Adding Packages to Image

There are several methods to adding packages in Yocto. The simplest method is to add it to your local.conf file. Please see below for an example.

  1. Build Yocto according to the instructions at Yocto/Building
  2. Add the following line to the conf/local.conf file
    IMAGE_INSTALL_append = " <package>"
    1. Note package would be replaced by something such as tcpdump or openvpn, etc
      IMAGE_INSTALL_append = " tcpflow tcpdump openvpn"
  3. Recompile by using the bitbake command as explained on the Building page here
  4. Look for the .ipk file in the location tmp/deploy/ipk/armv7a-vfp-neon folder.
    > find ./tmp/deploy/ipk -name "*openvpn*.ipk"
  5. There are a few ipk files, however they are for dev, doc, and dbg (debug). For main purposes, use the main one (eg openvpn_2.1.3-r0_armv7a-vfp-neon.ipk)
  6. Place this file onto the Ventana board through a method such as wget. Then install using the opkg install command
    root@ventana:/tmp# wget
    --2014-02-19 04:27:59--
    Connecting to connected.
    HTTP request sent, awaiting response... 200 OK
    Length: 208174 (203K)
    Saving to: 'openvpn_2.1.3-r0_armv7a-vfp-neon.ipk'
    100%[======================================>] 208,174     --.-K/s   in 0.02s
    2014-02-19 04:27:59 (12.9 MB/s) - 'openvpn_2.1.3-r0_armv7a-vfp-neon.ipk' saved [208174/208174]
    root@ventana:/tmp# opkg install openvpn_2.1.3-r0_armv7a-vfp-neon.ipk
    Installing openvpn (2.1.3-r0) to root...
    openvpn: unsatisfied recommendation for kernel-module-tun
    Configuring openvpn.

Modifying Packages through BB configuration File

Let's use the gst-plugins-bad package as an example for modifying an existing .bb file.

Location: sources/poky/meta/recipes-multimedia/gstreamer/

Open this file, and modify it. In this example, we want to be sure that the mpegtsdemux is built and added, so inside the file, we add mpegtsdemux into the EXTRA_OECONF variable under the --with-plugins flag

EXTRA_OECONF += "--disable-examples --disable-experimental --disable-sdl --disable-cdaudio --disable-directfb \
                 --with-plugins=musicbrainz,wavpack,ivorbis,mpegvideoparse,mpegtsdemux --disable-vdpau --disable-apexsink \

After modifying the file, save it.

Then, build the package individually like in the examples above on this page:

bitbake gst-plugins-bad

The artifacts will be in the usual location:


Kernel Configuration

Bitbake Menu Config

You can modify the kernel configuration using the 'menuconfig' task. For example:

bitbake -c menuconfig linux-gateworks-imx

This stores a modified config file in the kernel's work-dir (it will not be persistent if you clean or remove the workdir).

You can then build the kernel with the following command:

bitbake -c compile linux-gateworks-imx

See the yocto documentation for more info


Please consult the Yocto project website for more information regarding their OS.

Last modified 7 weeks ago Last modified on 08/08/17 12:03:00