Initialize the Build Environment: Run the oe-init-build-env environment setup script to define Yocto Project's build environment on your build host.

     $ source oe-init-build-env
                    

Among other things, the script creates the Build Directory, which is build in this case and is located in the Source Directory. After the script runs, your current working directory is set to the Build Directory. Later, when the build completes, the Build Directory contains all the files created during the build.

Examine Your Local Configuration File: When you set up the build environment, a local configuration file named local.conf becomes available in a conf subdirectory of the Build Directory. For this example, the defaults are set to build for a qemux86 target, which is suitable for emulation. The package manager used is set to the RPM package manager.

     SSTATE_MIRRORS = "\
     file://.* http://sstate.yoctoproject.org/dev/PATH;downloadfilename=PATH \n \
     file://.* http://sstate.yoctoproject.org/2.4/PATH;downloadfilename=PATH \n \
     file://.* http://sstate.yoctoproject.org/2.5/PATH;downloadfilename=PATH \n \
     "
                        

Start the Build: Continue with the following command to build an OS image for the target, which is core-image-sato in this example:

     $ bitbake core-image-sato
                    

For information on using the bitbake command, see the "BitBake" section in the Yocto Project Overview and Concepts Manual, or see the "BitBake Command" section in the BitBake User Manual.

Simulate Your Image Using QEMU: Once this particular image is built, you can start QEMU, which is a Quick EMUlator that ships with the Yocto Project:

     $ runqemu qemux86
                    

If you want to learn more about running QEMU, see the "Using the Quick EMUlator (QEMU)" chapter in the Yocto Project Development Tasks Manual.

Exit QEMU: Exit QEMU by either clicking on the shutdown icon or by typing Ctrl-C in the QEMU transcript window from which you evoked QEMU.

Find a Layer: Lots of hardware layers exist. The Yocto Project Source Repositories has many hardware layers. This example adds the meta-altera hardware layer.

Clone the Layer Use Git to make a local copy of the layer on your machine. You can put the copy in the top level of the copy of the Poky repository created earlier:

     $ cd ~/poky
     $ git clone https://github.com/kraj/meta-altera.git
     Cloning into 'meta-altera'...
     remote: Counting objects: 25170, done.
     remote: Compressing objects: 100% (350/350), done.
     remote: Total 25170 (delta 645), reused 719 (delta 538), pack-reused 24219
     Receiving objects: 100% (25170/25170), 41.02 MiB | 1.64 MiB/s, done.
     Resolving deltas: 100% (13385/13385), done.
     Checking connectivity... done.
                    

The hardware layer now exists with other layers inside the Poky reference repository on your build host as meta-altera and contains all the metadata needed to support hardware from Altera, which is owned by Intel.

Change the Configuration to Build for a Specific Machine: The MACHINE variable in the local.conf file specifies the machine for the build. For this example, set the MACHINE variable to "cyclone5". These configurations are used: https://github.com/kraj/meta-altera/blob/master/conf/machine/cyclone5.conf.

Add Your Layer to the Layer Configuration File: Before you can use a layer during a build, you must add it to your bblayers.conf file, which is found in the Build Directory's conf directory.

Use the bitbake-layers add-layer command to add the layer to the configuration file:

     $ cd ~/poky/build
     $ bitbake-layers add-layer ../meta-altera
     NOTE: Starting bitbake server...
     Parsing recipes: 100% |##################################################################| Time: 0:00:32
     Parsing of 918 .bb files complete (0 cached, 918 parsed). 1401 targets, 123 skipped, 0 masked, 0 errors.
                    

You can find more information on adding layers in the "Adding a Layer Using the bitbake-layers Script" section.