FAQ

Yocto Project Public Messages and FAQ

Last edited: 10 November, 2011

Q: What is the Yocto Project?

A: The Yocto Project provides open source, high-quality infrastructure and tools to help developers create their own custom Linux distributions for any hardware architecture and across multiple market segments. The Yocto Project is intended to provide a helpful starting point for developers. The Yocto Project hosts other projects as well, including the Poky build system, Autobuilder automated build and test system, and the Embedded GLIBC (EGLIBC)C library. The Linux Foundation welcomes the participation of embedded vendors, developers, and other open source projects.

Q: What does the Linux Foundation hope to achieve with the Yocto Project?

A: This year’s annual survey of embedded developers conducted by Embedded Market Forecasters reported that the two primary factors contributing to embedded developers’ choice of Operating Systems (OS) in their designs are cost (44.6%) and the availability of source code (33.1%). These factors have contributed to the explosion of demand for Linux in embedded devices. Until now, embedded vendors and their partners relied on deep customization, requiring developers to wrestle with rapidly changing software and difficult build and maintenance cycles. The Linux Foundation recognized that an opportunity existed for a collaboratively developed, open source project that would build high-quality tools for the embedded Linux ecosystem.

Q: How does the Yocto Project help Linux reach a wider embedded audience?

A: This set of collaboratively developed, open source development tools focused on the embedded segment speeds embedded vendors’ time to market by establishing a shared build infrastructure. This enables Linux across the widest possible spectrum of devices, projects, and platforms. The Yocto Project has a great start on the code required to solve these problems.

Q: Isn’t the Yocto Project just yet another Linux distribution?

A: No. The Yocto Project is a set of tools and components, including a highly configurable build system, that enables developers to construct their own custom distributions, targeted for specific embedded devices. It is not, itself, a Linux distribution. Rather, it is capable of outputting an image for a particular embedded device without dictating the composition of the Linux distribution actually built or the hardware architecture used.

Q: What benefits does the Yocto Project provide embedded developers and how is the Yocto Project superior to existing, similar tools?

A: Unlike build systems based on shell scripts or makefiles, the Yocto Project automates the fetching of sources from a variety of upstream sources or from local project repositories. Updating to a new version of a package is often as easy as renaming a recipe file. It has a powerful customization architecture that allows the choice of a wide variety of footprint sizes as well as control over the choice or absence of components such as graphics subsystems, visualization middleware, and services.

A complete set of Linux package versions is specified in the metadata for the project; these versions are known to work correctly together. A robust effort within the project is dedicated to keeping this selection of packages fresh and up-to-date. Unlike other systems, however, only a single version of each package is typically provided with the project at any given time. This ensures that the packages are known to work well together, while providing the freedom to replace them at any time as the needs of a given embedded project mature.

The Yocto Project is package-format agnostic; it supports both major Linux packaging systems (.rpm and .deb), as well as the embedded-friendly ipkg format. The Yocto Project is also architecturally agnostic, supporting all major embedded architectures: ARM, 32- and 64-bit x86, PowerPC, and MIPS.

The Yocto Project shares the core build tool (BitBake) and metadata syntax with OpenEmbedded, particularly the core set of components known as openembedded-core. This commonality provides automatic familiarity for developers already using OpenEmbedded. However, the learning curve for getting started with the Yocto Project is shallower. It is easier for new users to create a working distribution with the Yocto Project, and more work is being done currently on this subject with the new Hob graphical user interface.

When a distribution is created with the Yocto Project, the build tool creates an application development SDK tailored to that distribution. This SDK can plug into the Eclipse IDE or it may be run as a command-line development system, complete with cross tools for the host and development tools for the device being developed.

Q: How does the existing embedded workflow compare to the Yocto Project and where can embedded developers save time?

A: Existing embedded developers have many systems from which to choose. Once a system is chosen and a device's OS has been created, it can often be very difficult and time consuming to trim the distribution to an appropriate footprint size and assemble a working set of components. Then, for the developer’s next project, if updated components are needed, perhaps for bug fixes, security fixes, or new hardware support, the developer typically must start over, with little ability to re-use prior work on distributions. The Yocto Project solves these problems by providing a single focus for embedded development, requiring less time to get a working and up-to-date distribution together. In addition, if commercial support is desired, it is quite simple to transition to a supporting operating system vendor (OSV) who offers products and services compatible with the Yocto Project. All of the major embedded Linux OSVs are active members of the Yocto Project.

Q: Does the Yocto Project have a special governance model, or is it be managed as an open source project?

A: The Yocto Project is governed as an open source project working group under the auspices of the Linux Foundation. The Yocto Project Advisory Board consists of representatives from the major sponsoring organizations. This group advises the project on direction and provides resources, but all decisions are made by the project's Maintainers. In addition, there are Interest Groups who drive project feature requirements and provide direction on various aspects of project governance, including finances and infrastructure, and an Architect who coordinates the work of the Maintainers and sets project direction under the guidance of the Advisory Board and its subgroups.

Q: Why not just call this project Poky? What has changed between Poky and the Yocto Project?

A: The Yocto Project is an umbrella project. Accordingly, it includes a number of projects and resources specifically intended for facilitating development with Linux on embedded devices, and it is an appropriate place for larger organizations to collaborate on the development of build infrastructure for embedded Linux. Poky is one of the the largest components of the Yocto Project, and Poky continues as an independent, open source project developing the build system used by the Yocto Project, as well as by other open source projects.

Q: What is the difference between OpenEmbedded and the Yocto Project?

A: The Yocto Project and OpenEmbedded share a core collection metadata called openembedded-core. However, the two organizations remain separate, each with its own focus. OpenEmbedded provides a comprehensive set of metadata for a wide variety of architectures, features, and applications. The Yocto Project focuses on providing powerful, easy-to-use, well-tested tools, metadata, and board support packages (BSPs) for a core set of architectures and specific boards.

Q: Who defines the root filesystem and metadata?

A: Metadata represents the versions of the various components in a distribution, such as the particular versions of the Linux kernel or libraries. The project supplies an example set of metadata that can generate several example distributions. The actual metadata used for the construction of a custom distribution may be supplied by a commercial vendor or created by an embedded developer. The root filesystem is defined in the metadata for a given build of a distribution.

Q: What are the criteria for baseline metadata?

A: The project has selected several major embedded architectures (32- and 64-bit x86, ARM, MIPS, and PowerPC) and footprint sizes (minimal, sato, lsb). Metadata has been created that generates a working build for these architectures and footprints while providing up-to-date and modern versions of the various open source components. We also supply metadata for a number of other components ("world"), which can be pulled into a custom distribution.

Q: What tool sets are included in the Yocto Project? When will they be available?

A: The development tool chain is based on GCC. However, if a project contributor wished to add metadata that uses another tool chain, the project would be happy to consider it.

Q: What about graphics drivers? Will they be validated and integrated?

A: Yes.

Q: How will graphics IP in GPL drivers be handled?

A: The BSPs supplied in the open source project are generally focused on open source code.

Q: Where do BSPs come from? Who creates them? What if they need to include proprietary information?

A: A small set of example BSPs has been created and is maintained for our supported architectures. Commercial Linux vendors, OSVs, silicon suppliers, and board vendors may supply their own BSPs. Proprietary information can be delivered in a BSP, and its distribution is handled by the supplier.

Q: Are there tools that allow the removal of a package from the build?

A: Yes. The recipe for a given distribution can be modified to remove a package. An end developer may add or remove packages from the specified path in the build process. This allows for a completely customized Linux distribution.

Q: How can one view the dependencies of packages and the resulting growth in code size as packages are added?

A: There are tools within BitBake which enable this.

“bitbake -g targetname” creates depends.dot and task-depends.dot files in the current directory. These files show which packages and tasks depend on which other packages and tasks and are useful for debugging purposes.

"bitbake -g -u depexp targetname" shows results in a more human-readable, GUI style. A simple mount of the resulting root image will show how much storage space is being used.

In addition, the Hob is a new graphical user interface for BitBake which makes these tools much easier to use.

Q: What is the path for upgrading just drivers, or for upgrading drivers and related updates to the kernel?

A: For a given 6-month release of the Yocto Project, the version of the kernel is frozen 6 weeks before release.

Q: How often is the kernel updated? How will we know what version of the kernel is used in any particular Yocto Project release?

A: Given the release cycle for the kernel, every 6-month release of the Yocto Project usually has a new kernel. Specific announcements are made on the Yocto Project mailing list and blogs. In addition, the release notes for any release contains specific information about which kernel is included with that release.

Q: Is the kernel included in the Yocto Project?

A: Metadata referring to a particular kernel version is provided in Yocto Project releases. Of course, patches to the kernel (as with any of the source code in the project) can be applied by the developer. The Yocto Project’s kernel patching system is based on "git" and looks for patches in a git branch.

Q: What are some possible debugging targets?

A: QEMU is the target for emulation. Several actual hardware targets are also supported, as well as software emulators for various hardware models as provided by silicon vendors.

Q: What is the overall support plan for the Yocto Project?

A: Security patches and critical bug fixes are supplied one release back. No tool chain or kernel changes are allowed for these updates. Support for longer periods of time can be supplied by commercial OSVs.

Q: What is meant by automated test capability?

A: The Yocto Project includes a standard framework for testing on target devices. This allows many existing tests to be reused across projects, reducing rework.

Q: If a customer wants a commercial distribution of the Yocto Project, are there potential candidates for productization and commercial distribution?

A: Yes, all major commercial OSVs currently participate in the Yocto Project.

Q: For which software development boards is the Yocto Project validated?

A: Version 1.1 was validated against:

• ARM Beagleboard C4 and xM
• Several Intel Atom SoCs
• PowerPC - fsl-mpc8315e-rdb
• MIPS - Ubiquity Networks Router Station Pro

Q: Is user interface development possible with the Yocto Project?

A: User Interface development is supported with the Yocto Project. The distribution resulting from a Yocto Project build is just like any other Linux distribution. Developers may build graphical interfaces using frameworks like QT, Clutter, or GTK+, all of which are included.

Q: Is the Yocto Project a project or a product? How much customer effort is required to productize the Yocto Project?

A: The Yocto Project is an open source project with support provided by the open source community. Products can be created by OSVs who use the Yocto Project as their upstream or by customers who create their own “roll your own” Linux products from the Yocto Project.

Q: Who may I contact for further questions regarding the Yocto Project?

A: For any additional questions, please contact Jeff Osier-Mixon, the Yocto Project Community Manager.