"Yocto3.0使用手册：PDF文档及版权信息"

需积分: 0 74 浏览量更新于2023-12-23 收藏 10.12MB PDF 举报

Yocto 3.0是一个开源项目，为嵌入式Linux系统的开发提供了丰富的工具和资源。使用手册文档（PDF）提供了对Yocto 3.0的全面介绍和使用说明。本文档由Scott Rifenbark和Scotty's Documentation Services, INC编写，并在2010年至2019年间由Linux Foundation发布。本文档的版权归Linux Foundation所有，并允许在Creative Commons Attribution-Share Alike 2.0 UK: England许可下复制、分发和/或修改。 Yocto 3.0是一个面向嵌入式Linux系统的项目，旨在提供开发人员所需的工具和资源来定制和构建自己的Linux发行版。使用手册文档（PDF）提供了对Yocto 3.0的全面介绍，包括安装、配置、构建和调试等内容。本文档的目标读者是嵌入式系统开发人员和Linux系统管理员。在本文档中，读者将了解Yocto 3.0的基本概念和体系结构，包括元数据、层、类、变量和任务。此外，本文档还介绍了如何安装和配置Yocto 3.0，包括所需的软件和工具。读者还将学习如何使用Yocto 3.0构建定制的Linux发行版，并可以根据自己的需求添加、删除或修改软件包和组件。本文档还提供了关于如何在Yocto 3.0中调试和优化嵌入式Linux系统的详细说明。读者将了解如何使用Yocto 3.0中的工具和技术来进行性能分析、跟踪和调试，以及优化系统的启动时间和资源利用率。最后，本文档还介绍了Yocto 3.0中一些高级特性和技术，如多架构支持、容器化应用程序开发和部署、实时系统支持等。读者将了解如何利用这些特性和技术来满足不同嵌入式系统的需求，包括物联网设备、嵌入式计算机、工业自动化设备等。总之，使用手册文档（PDF）提供了对Yocto 3.0全面的介绍和使用说明，适合嵌入式系统开发人员和Linux系统管理员阅读和参考。通过阅读本文档，读者将能够更好地了解和掌握Yocto 3.0的使用和潜力，从而更高效地开发和定制嵌入式Linux系统。

"Poky", which is pronounced Pock-ee, is the name of the Yocto Project's reference distribution or Reference OS Kit. Poky

contains the OpenEmbedded Build System (BitBake and OpenEmbedded-Core) as well as a set of metadata to get you

started building your own distro. In other words, Poky is a base specification of the functionality needed for a typical

embedded system as well as the components from the Yocto Project that allow you to build a distribution into a usable

binary image.

Poky is a combined repository of BitBake, OpenEmbedded-Core (which is found in meta), meta-poky, meta-yocto-bsp,

and documentation provided all together and known to work well together. You can view these items that make up the

Poky repository in the Source Repositories.

Note

If you are interested in all the contents of the poky Git repository, see the "Top-Level Core Components"

section in the Yocto Project Reference Manual.

The following figure illustrates what generally comprises Poky:

BitBake is a task executor and scheduler that is the heart of the OpenEmbedded build system.

meta-poky, which is Poky-specific metadata.

meta-yocto-bsp, which are Yocto Project-specific Board Support Packages (BSPs).

OpenEmbedded-Core (OE-Core) metadata, which includes shared configurations, global variable definitions, shared

classes, packaging, and recipes. Classes define the encapsulation and inheritance of build logic. Recipes are the logical

units of software and images to be built.

Documentation, which contains the Yocto Project source files used to make the set of user manuals.

Note

While Poky is a "complete" distribution specification and is tested and put through QA, you cannot use it

as a product "out of the box" in its current form.

To use the Yocto Project tools, you can use Git to clone (download) the Poky repository then use your local copy of the

reference distribution to bootstrap your own distribution.

Note

Poky does not contain binary files. It is a working example of how to build your own custom Linux

distribution from source.

Poky has a regular, well established, six-month release cycle under its own version. Major releases occur at the same

time major releases (point releases) occur for the Yocto Project, which are typically in the Spring and Fall. For more

information on the Yocto Project release schedule and cadence, see the "Yocto Project Releases and the Stable Release

Process" chapter in the Yocto Project Reference Manual.

Convert web pages and HTML files to PDF in your applications with the Pdfcrowd HTML to PDF API Printed with Pdfcrowd.com

Much has been said about Poky being a "default configuration." A default configuration provides a starting image

footprint. You can use Poky out of the box to create an image ranging from a shell-accessible minimal image all the way

up to a Linux Standard Base-compliant image that uses a GNOME Mobile and Embedded (GMAE) based reference user

interface called Sato.

One of the most powerful properties of Poky is that every aspect of a build is controlled by the metadata. You can use

metadata to augment these base image types by adding metadata layers that extend functionality. These layers can

provide, for example, an additional software stack for an image type, add a board support package (BSP) for additional

hardware, or even create a new image type.

Metadata is loosely grouped into configuration files or package recipes. A recipe is a collection of non-executable

metadata used by BitBake to set variables or define additional build-time tasks. A recipe contains fields such as the

recipe description, the recipe version, the license of the package and the upstream source repository. A recipe might also

indicate that the build process uses autotools, make, distutils or any other build process, in which case the basic

functionality can be defined by the classes it inherits from the OE-Core layer's class definitions in ./meta/classes.

Within a recipe you can also define additional tasks as well as task prerequisites. Recipe syntax through BitBake also

supports both _prepend and _append operators as a method of extending task functionality. These operators inject code

into the beginning or end of a task. For information on these BitBake operators, see the "Appending and Prepending

(Override Style Syntax)" section in the BitBake User's Manual.

2.6. The OpenEmbedded Build System Workflow¶

The OpenEmbedded build system uses a "workflow" to accomplish image and SDK generation. The following figure

overviews that workflow:

Following is a brief summary of the "workflow":

1. Developers specify architecture, policies, patches and configuration details.

2. The build system fetches and downloads the source code from the specified location. The build system supports

standard methods such as tarballs or source code repositories systems such as Git.

3. Once source code is downloaded, the build system extracts the sources into a local work area where patches are

applied and common steps for configuring and compiling the software are run.

4. The build system then installs the software into a temporary staging area where the binary package format you

select (DEB, RPM, or IPK) is used to roll up the software.

5. Different QA and sanity checks run throughout entire build process.

6. After the binaries are created, the build system generates a binary package feed that is used to create the final root

file image.

Convert web pages and HTML files to PDF in your applications with the Pdfcrowd HTML to PDF API Printed with Pdfcrowd.com

7. The build system generates the file system image and a customized Extensible SDK (eSDK) for application

development in parallel.

For a very detailed look at this workflow, see the "OpenEmbedded Build System Concepts" section.

2.7. Some Basic Terms¶

It helps to understand some basic fundamental terms when learning the Yocto Project. Although a list of terms exists in

the "Yocto Project Terms" section of the Yocto Project Reference Manual, this section provides the definitions of some

terms helpful for getting started:

Configuration Files: Files that hold global definitions of variables, user-defined variables, and hardware configuration

information. These files tell the Open-Embedded build system what to build and what to put into the image to support

a particular platform.

Extensible Software Development Kit (eSDK): A custom SDK for application developers. This eSDK allows

developers to incorporate their library and programming changes back into the image to make their code available to

other application developers. For information on the eSDK, see the Yocto Project Application Development and the

Extensible Software Development Kit (eSDK) manual.

Layer: A collection of related recipes. Layers allow you to consolidate related metadata to customize your build.

Layers also isolate information used when building for multiple architectures. Layers are hierarchical in their ability to

override previous specifications. You can include any number of available layers from the Yocto Project and customize

the build by adding your layers after them. You can search the Layer Index for layers used within Yocto Project.

For more detailed information on layers, see the "Understanding and Creating Layers" section in the Yocto Project

Development Tasks Manual. For a discussion specifically on BSP Layers, see the "BSP Layers" section in the Yocto

Project Board Support Packages (BSP) Developer's Guide.

Metadata: A key element of the Yocto Project is the Metadata that is used to construct a Linux distribution and is

contained in the files that the OpenEmbedded build system parses when building an image. In general, Metadata

includes recipes, configuration files, and other information that refers to the build instructions themselves, as well as

the data used to control what things get built and the effects of the build. Metadata also includes commands and data

used to indicate what versions of software are used, from where they are obtained, and changes or additions to the

software itself (patches or auxiliary files) that are used to fix bugs or customize the software for use in a particular

situation. OpenEmbedded-Core is an important set of validated metadata.

OpenEmbedded Build System: The terms "BitBake" and "build system" are sometimes used for the OpenEmbedded

Build System.

BitBake is a task scheduler and execution engine that parses instructions (i.e. recipes) and configuration data. After a

parsing phase, BitBake creates a dependency tree to order the compilation, schedules the compilation of the included

code, and finally executes the building of the specified custom Linux image (distribution). BitBake is similar to the

make tool.

During a build process, the build system tracks dependencies and performs a native or cross-compilation of the

package. As a first step in a cross-build setup, the framework attempts to create a cross-compiler toolchain (i.e.

Extensible SDK) suited for the target platform.

OpenEmbedded-Core (OE-Core): OE-Core is metadata comprised of foundation recipes, classes, and associated

files that are meant to be common among many different OpenEmbedded-derived systems, including the Yocto

Project. OE-Core is a curated subset of an original repository developed by the OpenEmbedded community that has

been pared down into a smaller, core set of continuously validated recipes. The result is a tightly controlled and

quality-assured core set of recipes.

You can see the Metadata in the meta directory of the Yocto Project Source Repositories.

Packages: In the context of the Yocto Project, this term refers to a recipe's packaged output produced by BitBake

(i.e. a "baked recipe"). A package is generally the compiled binaries produced from the recipe's sources. You "bake"

something by running it through BitBake.

Convert web pages and HTML files to PDF in your applications with the Pdfcrowd HTML to PDF API Printed with Pdfcrowd.com

It is worth noting that the term "package" can, in general, have subtle meanings. For example, the packages referred
to in the "Required Packages for the Build Host" section in the Yocto Project Reference Manual are compiled binaries
that, when installed, add functionality to your Linux distribution.
Another point worth noting is that historically within the Yocto Project, recipes were referred to as packages - thus,
the existence of several BitBake variables that are seemingly mis-named, (e.g. PR, PV, and PE).
Poky: Poky is a reference embedded distribution and a reference test configuration. Poky provides the following:
A base-level functional distro used to illustrate how to customize a distribution.
A means by which to test the Yocto Project components (i.e. Poky is used to validate the Yocto Project).
A vehicle through which you can download the Yocto Project.
Poky is not a product level distro. Rather, it is a good starting point for customization.
Note
Poky is an integration layer on top of OE-Core.
Recipe: The most common form of metadata. A recipe contains a list of settings and tasks (i.e. instructions) for
building packages that are then used to build the binary image. A recipe describes where you get source code and
which patches to apply. Recipes describe dependencies for libraries or for other recipes as well as configuration and
compilation options. Related recipes are consolidated into a layer.
Chapter 3. The Yocto Project Development Environment¶
3.1. Open Source Philosophy
3.2. The Development Host
3.3. Yocto Project Source Repositories
3.4. Git Workflows and the Yocto Project
3.5. Git
3.5.1. Repositories, Tags, and Branches
3.5.2. Basic Commands
3.6. Licensing
This chapter takes a look at the Yocto Project development environment. The chapter provides Yocto Project
Development environment concepts that help you understand how work is accomplished in an open source environment,
which is very different as compared to work accomplished in a closed, proprietary environment.
Specifically, this chapter addresses open source philosophy, source repositories, workflows, Git, and licensing.
3.1. Open Source Philosophy¶
Open source philosophy is characterized by software development directed by peer production and collaboration through
an active community of developers. Contrast this to the more standard centralized development models used by
commercial software companies where a finite set of developers produces a product for sale using a defined set of
procedures that ultimately result in an end product whose architecture and source material are closed to the public.
Open source projects conceptually have differing concurrent agendas, approaches, and production. These facets of the
development process can come from anyone in the public (community) who has a stake in the software project. The
open source environment contains new copyright, licensing, domain, and consumer issues that differ from the more
traditional development environment. In an open source environment, the end product, source material, and
documentation are all available to the public at no cost.
A benchmark example of an open source project is the Linux kernel, which was initially conceived and created by Finnish
computer science student Linus Torvalds in 1991. Conversely, a good example of a non-open source project is the
Convert web pages and HTML files to PDF in your applications with the Pdfcrowd HTML to PDF API Printed with Pdfcrowd.com

Windows® family of operating systems developed by Microsoft® Corporation.
Wikipedia has a good historical description of the Open Source Philosophy here. You can also find helpful information on
how to participate in the Linux Community here.
3.2. The Development Host¶
A development host or build host is key to using the Yocto Project. Because the goal of the Yocto Project is to develop
images or applications that run on embedded hardware, development of those images and applications generally takes
place on a system not intended to run the software - the development host.
You need to set up a development host in order to use it with the Yocto Project. Most find that it is best to have a native
Linux machine function as the development host. However, it is possible to use a system that does not run Linux as its
operating system as your development host. When you have a Mac or Windows-based system, you can set it up as the
development host by using CROPS, which leverages Docker Containers. Once you take the steps to set up a CROPS
machine, you effectively have access to a shell environment that is similar to what you see when using a Linux-based
development host. For the steps needed to set up a system using CROPS, see the "Setting Up to Use CROss PlatformS
(CROPS)" section in the Yocto Project Development Tasks Manual.
If your development host is going to be a system that runs a Linux distribution, steps still exist that you must take to
prepare the system for use with the Yocto Project. You need to be sure that the Linux distribution on the system is one
that supports the Yocto Project. You also need to be sure that the correct set of host packages are installed that allow
development using the Yocto Project. For the steps needed to set up a development host that runs Linux, see the
"Setting Up a Native Linux Host" section in the Yocto Project Development Tasks Manual.
Once your development host is set up to use the Yocto Project, several methods exist for you to do work in the Yocto
Project environment:
Command Lines, BitBake, and Shells: Traditional development in the Yocto Project involves using the
OpenEmbedded build system, which uses BitBake, in a command-line environment from a shell on your development
host. You can accomplish this from a host that is a native Linux machine or from a host that has been set up with
CROPS. Either way, you create, modify, and build images and applications all within a shell-based environment using
components and tools available through your Linux distribution and the Yocto Project.
For a general flow of the build procedures, see the "Building a Simple Image" section in the Yocto Project Development
Tasks Manual.
Board Support Package (BSP) Development: Development of BSPs involves using the Yocto Project to create and
test layers that allow easy development of images and applications targeted for specific hardware. To development
BSPs, you need to take some additional steps beyond what was described in setting up a development host.
The Yocto Project Board Support Package (BSP) Developer's Guide provides BSP-related development information. For
specifics on development host preparation, see the "Preparing Your Build Host to Work With BSP Layers" section in the
Yocto Project Board Support Package (BSP) Developer's Guide.
Kernel Development: If you are going to be developing kernels using the Yocto Project you likely will be using
devtool. A workflow using devtool makes kernel development quicker by reducing iteration cycle times.
The Yocto Project Linux Kernel Development Manual provides kernel-related development information. For specifics on
development host preparation, see the "Preparing the Build Host to Work on the Kernel" section in the Yocto Project
Linux Kernel Development Manual.
Using Toaster: The other Yocto Project development method that involves an interface that effectively puts the Yocto
Project into the background is Toaster. Toaster provides an interface to the OpenEmbedded build system. The interface
enables you to configure and run your builds. Information about builds is collected and stored in a database. You can
use Toaster to configure and start builds on multiple remote build servers.
For steps that show you how to set up your development host to use Toaster and on how to use Toaster in general,
see the Toaster User Manual.
Convert web pages and HTML files to PDF in your applications with the Pdfcrowd HTML to PDF API Printed with Pdfcrowd.com