View source for 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 <code>conf/local.conf</code>:

  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 <code>conf/local.conf</code>:
  
  SOURCE_MIRROR_URL ?= "file:///source_mirror/sources/"
  INHERIT += "own-mirrors" 
  BB_GENERATE_MIRROR_TARBALLS = "1" 
  BB_NO_NETWORK = "1"

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

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

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

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

Instead, use:

 <nowiki>SRC_URI = "git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git;protocol=git"</nowiki>
 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 <code>BB_NO_NETWORK</code> 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

# have a suitable partition on the disk - say partition #3
# this partition will show up as sde3 on my host machine and sda3 on the atom
# mkfs.ext3 /dev/sde3
# mount /dev/sde3 /mnt/target
# mount -o loop tmp/deploy/images/core-image-sato-sdk.ext3 /mnt/target-ext3
# cp -a /mnt/target-ext3/* /mnt/target
# 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&reg; Atom&trade; 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 [https://wiki.yoctoproject.org/wiki/Build_Performance 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 <code>conf/local.conf</code> :

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 this line 'INCOMPATIBLE_LICENSE = "GPLv3"' in your <code>conf/local.conf</code> :

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 <code>conf/local.conf</code> :

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 tool is available from 2.2 release (poky/meta/recipes-devtools/cve-check-tool)

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

 # INHERIT += "cve-check"

Source and run:
 # bitbake -c cve_check openssl   
 # bitbake core-image-sato   
 # bitbake -k -c cve_check universe  


Log files are created under 
  unzip/1_6.0-r5/cve/cve.log
  gnutls/3.5.3-r0/cve/cve.log
  glibc/2.24-r0/cve/cve.log
  glibc-initial/2.24-r0/cve/cve.log
  ...

Example of log file:
  PACKAGE NAME: perl
  PACKAGE VERSION: 5.22.1
  CVE: CVE-2016-1238
  CVE STATUS: Patched
  CVE SUMMARY:  ....
  ....
  CVSS v2 BASE SCORE: 7.2
  VECTOR: LOCAL
  MORE INFORMATION: https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-1238

==Q: How do I build a wic image? ==
'''A:'''  Append "wic" to IMAGE_FSTYPES  in your <code>conf/local.conf</code> :

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