How do I

Q: How do get the package manager binaries on my target rootfs?

A: Make sure your image has IMAGE_FEATURES += "package-management" included.

Q: How do I create my own source download mirror ?

A: Make a complete build with these variables set in your conf/local.conf:

 SOURCE_MIRROR_URL ?= "file:///source_mirror/sources/"
 INHERIT += "own-mirrors" 
 BB_GENERATE_MIRROR_TARBALLS = "1" 

After a complete build, copy all *files* (not symlinks) in your download directory to the desired source mirror directory. Test by setting the variables below in conf/local.conf:

 SOURCE_MIRROR_URL ?= "file:///source_mirror/sources/"
 INHERIT += "own-mirrors" 
 BB_GENERATE_MIRROR_TARBALLS = "1" 
 BB_NO_NETWORK = "1"

If you are building with BB_NO_NETWORK and using external layers that are not part of the base Yocto distribution, be aware that recipes which:

1. Specify a Git repo as the source, and,
2. Specify the revision to be built using a tag name

will cause your build to abort when Bitbake tries to run git ls-remote to resolve the tag name and is unable to access the network. So don't specify SRC_URI like this:

SRC_URI = "git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git;protocol=git;tag=v${PV}"

Instead, use:

SRC_URI = "git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git;protocol=git"
SRCREV = "8885ced062131214448fae056ef453f094303805"

Before putting together your pre-mirror, this command can be used from your top-level source directory to identify recipes that might be problematic with BB_NO_NETWORK enabled:

find -name "*.inc" -o -name "*.bb" | xargs grep -li "git;tag="

Q: How do I put Yocto on a hard drive?

A: bitbake core-image-sato or core-image-sato-sdk

1. have a suitable partition on the disk - say partition #3
2. this partition will show up as sde3 on my host machine and sda3 on the atom
3. mkfs.ext3 /dev/sde3
4. mount /dev/sde3 /mnt/target
5. mount -o loop tmp/deploy/images/core-image-sato-sdk.ext3 /mnt/target-ext3
6. cp -a /mnt/target-ext3/* /mnt/target
7. grub-install --recheck --root-directory=/mnt/target /dev/sde

If grub install passed, copy the following to /mnt/target/boot/grub/grub.cfg

set default="0"
set timeout="30"

menuentry 'Yocto SDK' {
      insmod part_msdos
      insmod ext2
      set root='(hd0,msdos3)'
      linux /boot/bzImage root=/dev/sda3
}

Thats it - this should boot.

Q: How do I put my recipe into Yocto?

A: Let's use the Hello World example from Section 3.1.2 of the Yocto Project Reference Manual and expand on it.

• In this example, I'll start with a new meta layer named "meta-jfa" in the Yocto Project files directory, which is named "poky". Then, I will add the new recipe and build the image, which is named "core-image-minimal". I will build it using the autotooled package option. Once built, the image will have the “hello” application.

Step One

Create the following directory structure in the ~/poky directory. I'll use my initials to denote the layer and recipe name:

mkdir meta-jfa
mkdir meta-jfa/conf
mkdir meta-jfa/recipes-jfa
mkdir meta-jfa/recipes-jfa/hello

Step Two

Next, to make sure the recipe gets searched and located, I'll create the layer.conf file in the meta-jfa/conf directory as follows:

# We have a conf and classes directory, add to BBPATH 
BBPATH := "${BBPATH}:${LAYERDIR}" 
# We have a packages directory, add to BBFILES 
BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \ 
           ${LAYERDIR}/recipes-*/*/*.bbappend" 
BBFILE_COLLECTIONS += "jfa" 
BBFILE_PATTERN_jfa := "^${LAYERDIR}/" 
BBFILE_PRIORITY_jfa := "5"

Step Three

Now I need to put the recipe (.bb) file into the right directory. So, I will put the file hello_2.7.bb into the meta-jfa/recipes-jfa/hello directory. I picked version 2.7 of the hello program by going to the gnu site for the application (ftp://ftp.gnu.org/gnu/hello/) and downloading it to checkout the version I wanted to include. hello-2.7.tar.gz is the most current. I downloaded it locally and expanded it to look at the license information. The hello_2.7.bb file contains the following:

DESCRIPTION = "GNU Helloworld application" 
SECTION = "examples" 
LICENSE = "GPLv3+" 
LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504" 
PR = "r0" 
SRC_URI = "${GNU_MIRROR}/hello/hello-${PV}.tar.gz" 
inherit autotools gettext 

Here is some explanation for a few of the recipe statements:

• LIC_FILES_CHKSUM = is required and, using file location defaults, points to the COPYING file that is part of the tarball that is downloaded from the SRC_URI address. The md5= part of the statement is generated by running “md5sum COPYING” against the COPYING file I downloaded to examine.
• ${PV} in the SRC_URI statement is picked up from the part of the recipe file name after the “_”. In this case PV =2.7.

Step Four

The recipe is built, so now I can run it:

cd ~/poky
source oe-init-build-env build-hello.  

Step Five

Before I can use BitBake I need to edit two files. Sourcing the oe-init-build-env file above leaves me in the build-hello directory. Before issuing the bitbake command I need to edit the files conf/local.conf and conf/bblayers.conf in that build-hello directory. The bblayers.conf needs to have the one line added to include the layer you created.

# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf 
# changes incompatibly 
LCONF_VERSION = "4" 
BBFILES ?= "" 
BBLAYERS = " \ 
  /home/jim/poky/meta \ 
  /home/jim/poky/meta-yocto \ 
  /home/jim/poky/meta-jfa \
"

Step Six

The conf/local.conf file needs to have the parallel processing lines edited to speed up the baking on multicore systems. I can do that by uncommenting the BB_NUMBER_THREADS and PARALLEL_MAKE variables. Generally, I would set them equal to twice the number of cores used by my host machine. By default, the MACHINE variable is set to qemux86 and for this example is fine. I need to add a line to include the hello package I am building into the image by adding the following line:

IMAGE_INSTALL:append = " hello"

Step Seven

Now I can bake it with this command:

bitbake core-image-minimal

Step Eight

Once the image is built, I can test it by starting the QEMU emulator:

runqemu qemux86

Step Nine

Once the emulator comes up, login as root with no password. Then, at the prompt, enter "hello" to run your application.

Q: How do I setup Intel® Atom™ Processor E6xx based system for media playback?

A: To playback media files on an Atom E6xx processor, you need to have the EMGD GFX driver installed. There is a README on this installation in the meta-crownbay directory. However, the official support for EMGD with accelerated 3D and media decode is scheduled for release 1.2, but is in the git repository now, so you need to start with branch, "master" of both the poky and meta-intel repository. And you will need the Intel Crownbay reference platform for the Atom E6xx processor or similar hardware.

Step 1

Follow the Appendix A example in the Yocto Project Development Manual, but instead of editing out the crownbay references and using the crownbay-noemgd, you do the opposite.

One edit you need to add to the Appendix A instructions is for the file ~/poky/meta-intel/meta-mymachine/conf/mymachine.conf. You need to add the following statement to include audio features needed for the audio part of the videos:

MACHINE_FEATURES += "alsa"

Step 2

In the Appendix A example a couple of changes are needed to the conf/local.conf and conf/bblayers.conf file edits from the standard example. The bblayers.conf file BBLAYERS statement should look like below, except correct the absolute path to match your system:

BBLAYERS ?= " \
 /home/jim/poky/meta \
 /home/jim/poky/meta-yocto \
 /home/jim/poky/meta-intel \
 /home/jim/poky/meta-intel/meta-mymachine \
 "

The local.conf file should have some statements in addition to what the Appendix A used:

LICENSE_FLAGS_WHITELIST = "license_emgd-driver-bin_1.10"

# The 2 statements below allow the playing of MP3 files. 
# Not specific to videos, but usually included on media use systems.
LICENSE_FLAGS_WHITELIST += "commercial"
POKY_EXTRA_INSTALL += "gst-fluendo-mp3"

# add debug development tweaks and test applications, which include amixer, aplay, arecord, etc.
EXTRA_IMAGE_FEATURES = "debug-tweaks tools-testapps"

Step 3

After bitbaking the core-image-sato image, I put the .ext3 image on a hard drive per the above How Do I. I also added some h.264, mp4, m4a, and mp3 files to play with before moving the hard drive to the target hardware system.

I used both the Sato GUI Music and Video players to play the files.

That's all there is to it.

Q: How do I tweak my build system and BitBake configuration for optimal build time as well as provide some guidance on how to collect build metrics and identify bottlenecks. ?

A: You should read the Build Performance wiki page. It provides general tips, a description of the bb-matrix script used for collecting relevant build metrics, a description of how to enable buildstats to generate build performance log data, and a description of how best to apply parallelism to the build.

Q: How do I get the networking to function on an Acer Aspire One n450 based netbook when using the meta-n450 BSP?

A: While the n450 BSP will boot on the Acer AO532h netbook, the BSP does not enable the Atheros AR5B95 Wireless and AR8132 fast ethernet adapters. The Linux Yocto 3.2 kernel has these drivers, but they are not enabled. All you have to do is to create a Config Fragment file with a .cfg extension in a new directory called 'linux-yocto' in the BSP recipes-kernel/linux directory. The new 'linux-yocto' directory will be at the same level as the linux-yocto_3.2.bbappend file. You will also need to add the following statement to the .bbappend file:

SRC_URI += "file://myconfig.cfg"

The recipes-kernel/linux/linux-yocto/myconfig.cfg needs to contain the following 2 lines:

CONFIG_ATH9K_PCI=y

CONFIG_ATL1C=y

Q: How do I build the build appliance?

A: Update the MACHINE variable to "qemux86-64" or "qemux86" in your conf/local.conf :

Then, run this command:

 # bitbake build-appliance-image

The resulting images (*.vmdk, *.vmx, *.vmxf) will be present in the "tmp/deploy/images" folder ie:

 # unzip Yocto_Build_Appliance.zip
 # cd Yocto_Build_Appliance
 # ls 
   Yocto_Build_Appliance.vmdk  
   Yocto_Build_Appliance.vmx  
   Yocto_Build_Appliance.vmxf

Q: How do I build an image without GPLv3 Licensed packages ?

A: Add the line 'INCOMPATIBLE_LICENSE = "GPLv3"' in your conf/local.conf and ensure you have the GPLv2 replacement libraries. (Caveat emptor; they are not as well maintained.) From the Yocto Mega-Manual 2.4;

"If you use INCOMPATIBLE_LICENSE to exclude GPLv3 or set PREFERRED_VERSION to substitute a GPLv2 version of a GPLv3 recipe, then you must add the meta-gplv2 layer to your configuration."

Then, build the image:

 # bitbake <image-name>

Q: How do I ensure that I am using the latest upstream version of the package?

A: Add this line 'INHERIT += "distrodata"' in your conf/local.conf :

After that, run this command in the build directory:

 # bitbake -c checkpkg <package>

Then, check the 'Version' and 'Upver' fields in the below listed file:

 # gedit tmp/log/checkpkg.csv

If those versions are same, then we have the latest upstream version of package

Q: How do I get a list of CVEs patched?

A: cve-check is available from 2.2 release (meta/recipes-core/meta/cve-update-nvd2-native.bb is used for acessing the new NVD database 2.0 API, meta/classes/cve-check.bbclass implements the check of recipes against CVEs).

To run it just inherit the class in conf/local.conf file:

# INHERIT += "cve-check"

Examples:

1. To check for CVEs in openssl

# bitbake -c cve_check openssl

2. To check for all recipes build for core-image-sato

# bitbake core-image-sato   
# bitbake -k -c cve_check universe  

Log files are created under tmp/log/cve/

 ...
 libmicrohttpd_cve.json
 libmicrohttpd-native_cve.json
 libmnl_cve.json
 libmnl-native_cve.json
 libmodule-build-perl_cve.json
 ...

Example of log file:

 {
 "version": "1",
 "package": [
   {
     "name": "zstd",
     "layer": "meta",
     "version": "1.5.5",
     "products": [
       {
         "product": "zstandard",
         "cvesInRecord": "Yes"
       }
     ],
     "issue": [
       {
         "id": "CVE-2019-11922",
         "summary": "A race condition in the one-pass compression functions of Zstandard prior to version 1.3.8 could allow an attacker to write bytes out of bounds if an output buffer smaller than the recommended size was used.",
         "scorev2": "6.8",
         "scorev3": "8.1",
         "vector": "NETWORK",
         "vectorString": "AV:N/AC:M/Au:N/C:P/I:P/A:P",
         "status": "Patched",
         "link": "https://nvd.nist.gov/vuln/detail/CVE-2019-11922"
       },
  ...

Q: How do I build a wic image?

A: Append "wic" to IMAGE_FSTYPES in your conf/local.conf :

Then, build the target image type as usual:

 # bitbake <target-image-type>

The resulting images (*.wic) will be present in the "tmp/deploy/images" folder. E.g. if you build for core-image-minimal for qemzx86-64 you should find a file like: core-image-minimal-qemux86-64.rootfs.wic