This chapter introduces the Yocto Project and gives you an idea of what you need to get started. You can find enough information to set your development host up and build or use images for hardware supported by the Yocto Project by reading the Yocto Project Quick Start located on the Yocto Project website. The remainder of this chapter summarizes what is in the Yocto Project Quick Start and provides some higher level concepts you might want to consider.

The Yocto Project is an open-source collaboration project focused on embedded Linux developers. The project provides a recent Linux kernel along with a set of system commands, libraries, and system components suitable for the embedded developer. The Yocto Project also features the Sato reference User Interface should you be dealing with devices with restricted screens. You can use the Yocto Project, which uses the BitBake build tool, to develop complete Linux images and user-space applications for architectures based on ARM, MIPS, PowerPC, x86 and x86-64. You can perform target-level testing and debugging as well as test in a hardware emulated environment. And, if you are an Eclipse user, you can install an Eclipse Yocto Plug-in to allow you to develop within that familiar environment.

Here is what you need to get set up to use the Yocto Project: Host System: You need a recent release of Fedora, OpenSUSE, Debian, or Ubuntu. You should have a reasonably current Linux-based host system. You should also have about 100 gigabytes of free disk space if you plan on building images. Packages: Depending on your host system (Debian-based or RPM-based), you need certain packages. See the The Packages section in the Yocto Project Quick start for the exact package requirements. Yocto Project Release: You need a release of the Yocto Project. You can get set up with local Yocto Project files one of two ways depending on whether you are going to be contributing back into the Yocto Project source repository or not. Regardless of the method you use, this manual will refer to the resulting hierarchical set of files as "the local Yocto Project files." Tarball Extraction: If you are not going to contribute back into the Yocto Project you can simply download the Yocto Project release you want from the website’s download page. Once you have the tarball, just extract it into a directory of your choice. For example, the following command extracts the Yocto Project 1.1 release tarball into the current working directory and sets up a file structure whose top-level directory is named poky-1.1: $ tar xfj poky-1.1.tar.bz2 This method does not produce a poky Git repository. You end up simply with a local snapshot of Yocto Project files that are based on the particular release in the tarball. Git Repository Method: If you are going to be contributing back into the Yocto Project you should probably use Git commands to set up a local poky Git repository of the Yocto Project. Doing so creates a Git repository with a complete history of changes and allows you to easily submit your changes upstream to the project. The following transcript shows how to clone the poky Git repository into the current working directory. The command creates the repository in a directory named poky. For information on the Yocto Project and Git, see Git in Working with Open Source Code. $ git clone git://git.yoctoproject.org/poky Initialized empty Git repository in /home/scottrif/poky/.git/ remote: Counting objects: 107624, done. remote: Compressing objects: 100% (37128/37128), done. remote: Total 107624 (delta 73393), reused 99851 (delta 67287) Receiving objects: 100% (107624/107624), 69.74 MiB | 483 KiB/s, done. Resolving deltas: 100% (73393/73393), done. For another example of how to set up your own local Git repositories see this wiki page, which describes how to create both poky and meta-intel Git repositories. Supported Board Support Packages (BSPs): The same considerations exist for BSPs. You can get set up for BSP development one of two ways: tarball extraction or with a local Git repository. Regardless of the method you use, the Yocto Project uses the following BSP layer naming scheme: meta-<BSP_name> where <BSP_name> is the recognized BSP name. Here are some examples: meta-crownbay meta-emenlow meta-n450 Tarball Extraction: You can download any released BSP tarball from the same download site. Once you have the tarball just extract it into a directory of your choice. Again, this method just produces a snapshot of the BSP layer in the form of a hierarchical directory structure. Git Repository Method: If you are working with a poky Git repository you should also set up a meta-intel Git repository. Typically, you set up the meta-intel Git repository inside the poky Git repository. For example, the following transcript shows the steps to clone the meta-intel Git repository inside the poky poky Git repository. $cd poky $ git clone git://git.yoctoproject.org/meta-intel.git Initialized empty Git repository in /home/scottrif/poky/meta-intel/.git/ remote: Counting objects: 1325, done. remote: Compressing objects: 100% (1078/1078), done. remote: Total 1325 (delta 546), reused 85 (delta 27) Receiving objects: 100% (1325/1325), 1.56 MiB | 330 KiB/s, done. Resolving deltas: 100% (546/546), done. The same wiki page referenced earlier covers how to set up the meta-intel Git repository. Eclipse Yocto Plug-in: If you are developing using the Eclipse Integrated Development Environment (IDE) you will need this plug-in. See the Setting up the Eclipse IDE section in the Yocto Application Development Toolkit (ADT) User’s Guide for more information.

The build process creates an entire Linux distribution, including the toolchain, from source. For more information on this topic, see the Building an Image section in the Yocto Project Quick Start. The build process is as follows: Make sure you have the Yocto Project files as described in the previous section. Initialize the build environment by sourcing a build environment script. Make sure the conf/local.conf configuration file is set up how you want it. This file defines the target machine architecture and and other build configurations. Build the image using the BitBake command. If you want information on Bitbake, see the user manual at . Optionally, you can run the image in the QEMU emulator.

Another option you have to get started is to use a pre-built binary. This scenario is ideal for developing software applications to run on your target hardware. To do this you need to install the stand-alone Yocto toolchain tarball and then download the pre-built kernel that you will boot using the QEMU emulator. Next, you must download the filesystem for your target machine’s architecture. Finally, you set up the environment to emulate the hardware then start the emulator. You can find details on all these steps in the Using Pre-Built Binaries and QEMU section in the Yocto Project Quick Start.