YoctoProject 2018 官方完整手册

4星 · 超过85%的资源需积分: 43 119 浏览量更新于2024-07-19 8 收藏 8.2MB PDF 举报

"yocto 2018 年最新官方完整pdf文档，包含624页详细内容，主要来源为YoctoProject Mega-Manual的2.4.1版本，由Scott Rifenbark撰写并由Linux Foundation授权，遵循Creative Commons Attribution-ShareAlike 2.0 UK: England & Wales许可协议。该文档适用于2018年的Yocto Project，提供了关于该开源项目及其工具链、构建系统和开发环境的全面指导。" 《Yocto项目2018年官方指南》是为Yocto Project 2.4.1版本编写的详尽参考资料，旨在帮助开发者理解和利用这个开放源代码项目进行嵌入式Linux系统的构建。Yocto项目是一个开放源代码工具集，主要用于创建定制的Linux发行版，特别适合于硬件设备制造商和软件开发者，他们需要为特定硬件平台打造个性化的Linux操作系统。该手册涵盖了多个关键主题，包括： 1. **Yocto项目概述**：介绍项目的起源、目标和架构，以及它如何通过BitBake、OpenEmbedded Core和 Poky等组件协同工作。 2. **环境设置**：详细说明如何安装必要的软件包，配置开发环境，以及获取和构建Yocto项目源代码。 3. **BitBake**：讲解BitBake的基本概念，它是Yocto项目的核心构建工具，负责解析食谱（recipes）和元数据，执行编译和打包任务。 4. **食谱（Recipes）**：深入探讨食谱的结构和编写规则，食谱是定义如何构建软件包的文件，包括依赖关系、编译选项等。 5. **元数据（Metadata）**：解释了元数据的重要性，它是描述软件包、层和构建变量的集合，使得构建过程可以自动化和可定制化。 6. **层（Layers）**：讨论了层的概念，层允许组织和管理食谱，支持不同项目和团队之间的协作，以及保持软件包更新和兼容性。 7. **Poky**：Poky是Yocto项目的参考实现，提供了一整套构建系统和基础设施，包括BitBake和各种工具。 8. **设备树（Device Trees）**：介绍了设备树在构建嵌入式系统中的作用，用于描述硬件配置，使内核能正确识别和驱动硬件。 9. **构建和调试**：提供了构建不同类型的映像（如开发、目标和SDK映像）的步骤，以及如何调试构建过程中的问题。 10. **软件包管理**：讨论了如何添加、删除和管理软件包，以及如何处理版本和依赖关系。 11. **高级主题**：涵盖了自定义构建策略、多架构支持、性能优化、持续集成和发布流程等更深入的内容。此外，手册还提供了错误报告和社区参与的指引，鼓励用户向Yocto Project的讨论组或Freenode #yocto频道反馈问题，共同推进项目的改进和发展。《Yocto项目2018年官方指南》是一份宝贵的资源，对于那些希望深入了解和使用Yocto项目构建定制化嵌入式Linux系统的人来说，它是不可或缺的学习材料。

2018/1/27 Yocto Project Mega-Manual

http://www.yoctoproject.org/docs/2.4.1/mega-manual/mega-manual.html 16/426

to use Patchwork to track the status of patches and also to automatically preview patches.

The following sections provide procedures for submitting a change.

3.3.1. Using Scripts to Push a Change Upstream and Request a Pull¶

Follow this procedure to push a change to an upstream "contrib" Git repository:

Note

You can find general Git information on how to push a change upstream in the Git Community Book.

1. Make Your Changes Locally: Make your changes in your local Git repository. You should make small, controlled, isolated

changes. Keeping changes small and isolated aids review, makes merging/rebasing easier and keeps the change history clean

should anyone need to refer to it in future.

2. Stage Your Changes: Stage your changes by using the git add command on each file you changed.

3. Commit Your Changes: Commit the change by using the git commit command. Make sure your commit information follows

standards by following these accepted conventions:

Be sure to include a "Signed-off-by:" line in the same style as required by the Linux kernel. Adding this line signifies that you,

the submitter, have agreed to the Developer's Certificate of Origin 1.1 as follows:

Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I

have the right to submit it under the open source license

indicated in the file; or

(b) The contribution is based upon previous work that, to the best

of my knowledge, is covered under an appropriate open source

license and I have the right under that license to submit that

work with modifications, whether created in whole or in part

by me, under the same open source license (unless I am

permitted to submit under a different license), as indicated

in the file; or

person who certified (a), (b) or (c) and I have not modified

it.

(d) I understand and agree that this project and the contribution

are public and that a record of the contribution (including all

personal information I submit with it, including my sign-off) is

maintained indefinitely and may be redistributed consistent with

this project or the open source license(s) involved.

Provide a single-line summary of the change. and, if more explanation is needed, provide more detail in the body of the

commit. This summary is typically viewable in the "shortlist" of changes. Thus, providing something short and descriptive that

gives the reader a summary of the change is useful when viewing a list of many commits. You should prefix this short

description with the recipe name (if changing a recipe), or else with the short form path to the file being changed.

For the body of the commit message, provide detailed information that describes what you changed, why you made the change,

and the approach you used. It might also be helpful if you mention how you tested the change. Provide as much detail as you

can in the body of the commit message.

Note

You do not need to provide a more detailed explanation of a change if the change is minor to the point of

the single line summary providing all the information.

If the change addresses a specific bug or issue that is associated with a bug-tracking ID, include a reference to that ID in your

detailed description. For example, the Yocto Project uses a specific convention for bug references - any commit that addresses a

specific bug should use the following form for the detailed description. Be sure to use the actual bug-tracking ID from Bugzilla

for

bug-id

Fixes [YOCTO #

bug-id

]

detailed description of change

4. Push Your Commits to a "Contrib" Upstream: If you have arranged for permissions to push to an upstream contrib repository,

push the change to that repository:

$ git push

upstream_remote_repo

local_branch_name

For example, suppose you have permissions to push into the upstream meta-intel-contrib repository and you are

working in a local branch named

your_name

/README. The following command pushes your local commits to the meta-intel-

contrib upstream repository and puts the commit in a branch named

your_name

/README:

$ git push meta-intel-contrib

your_name

/README

5. Determine Who to Notify: Determine the maintainer or the mailing list that you need to notify for the change.

Before submitting any change, you need to be sure who the maintainer is or what mailing list that you need to notify. Use either

these methods to find out:

2018/1/27 Yocto Project Mega-Manual

http://www.yoctoproject.org/docs/2.4.1/mega-manual/mega-manual.html 17/426

Maintenance File: Examine the maintainers.inc file, which is located in the Source Directory at

meta/conf/distro/include, to see who is responsible for code.

Search by File: Using Git, you can enter the following command to bring up a short list of all commits against a specific file:

git shortlog --

filename

Just provide the name of the file for which you are interested. The information returned is not ordered by history but does

include a list of everyone who has committed grouped by name. From the list, you can see who is responsible for the bulk of

the changes against the file.

Examine the List of Mailing Lists: For a list of the Yocto Project and related mailing lists, see the "Mailing lists" section in the

Yocto Project Reference Manual.

6. Make a Pull Request: Notify the maintainer or the mailing list that you have pushed a change by making a pull request.

The Yocto Project provides two scripts that conveniently let you generate and send pull requests to the Yocto Project. These scripts

are create-pull-request and send-pull-request. You can find these scripts in the scripts directory within the

Source Directory (e.g. ~/poky/scripts).

Using these scripts correctly formats the requests without introducing any whitespace or HTML formatting. The maintainer that

receives your patches either directly or through the mailing list needs to be able to save and apply them directly from your emails.

Using these scripts is the preferred method for sending patches.

First, create the pull request. For example, the following command runs the script, specifies the upstream repository in the contrib

directory into which you pushed the change, and provides a subject line in the created patch files:

$ ~/poky/scripts/create-pull-request -u meta-intel-contrib -s "Updated Manual Section Reference in README"

Running this script forms *.patch files in a folder named pull-

PID

in the current directory. One of the patch files is a cover

letter.

Before running the send-pull-request script, you must edit the cover letter patch to insert information about your change.

After editing the cover letter, send the pull request. For example, the following command runs the script and specifies the patch

directory and email address. In this example, the email address is a mailing list:

$ ~/poky/scripts/send-pull-request -p ~/meta-intel/pull-10565 -t meta-intel@yoctoproject.org

You need to follow the prompts as the script is interactive.

Note

For help on using these scripts, simply provide the -h argument as follows:

$ poky/scripts/create-pull-request -h

$ poky/scripts/send-pull-request -h

3.3.2. Using Email to Submit a Patch¶

You can submit patches without using the create-pull-request and send-pull-request scripts described in the previous

section. However, keep in mind, the preferred method is to use the scripts.

Depending on the components changed, you need to submit the email to a specific mailing list. For some guidance on which mailing list

to use, see the beginning of this section. For a description of all the available mailing lists, see the "Mailing Lists" section in the Yocto

Project Reference Manual.

Here is the general procedure on how to submit a patch through email without using the scripts:

1. Make Your Changes Locally: Make your changes in your local Git repository. You should make small, controlled, isolated

changes. Keeping changes small and isolated aids review, makes merging/rebasing easier and keeps the change history clean

should anyone need to refer to it in future.

2. Stage Your Changes: Stage your changes by using the git add command on each file you changed.

3. Commit Your Changes: Commit the change by using the git commit --signoff command. Using the --signoff

option identifies you as the person making the change and also satisfies the Developer's Certificate of Origin (DCO) shown earlier.

When you form a commit, you must follow certain standards established by the Yocto Project development team. See Step 3 in the

previous section for information on how to provide commit information that meets Yocto Project commit message standards.

4. Format the Commit: Format the commit into an email message. To format commits, use the git format-patch

command. When you provide the command, you must include a revision list or a number of patches as part of the command. For

example, either of these two commands takes your most recent single commit and formats it as an email message in the current

directory:

$ git format-patch -1

$ git format-patch HEAD~

After the command is run, the current directory contains a numbered .patch file for the commit.

If you provide several commits as part of the command, the git format-patch command produces a series of numbered

files in the current directory – one for each commit. If you have more than one patch, you should also use the --cover option

with the command, which generates a cover letter as the first "patch" in the series. You can then edit the cover letter to provide a

2018/1/27 Yocto Project Mega-Manual
http://www.yoctoproject.org/docs/2.4.1/mega-manual/mega-manual.html 18/426
description for the series of patches. For information on the git format-patch command, see
GIT_FORMAT_PATCH(1) displayed using the man git-format-patch command.
Note
If you are or will be a frequent contributor to the Yocto Project or to OpenEmbedded, you might consider
requesting a contrib area and the necessary associated rights.
Import the Files Into Your Mail Client: Import the files into your mail client by using the git send-email command.
Note
In order to use git send-email, you must have the proper Git packages installed on your host. For
Ubuntu, Debian, and Fedora the package is git-email.
The git send-email command sends email by using a local or remote Mail Transport Agent (MTA) such as msmtp,
sendmail, or through a direct smtp configuration in your Git ~/.gitconfig file. If you are submitting patches through
email only, it is very important that you submit them without any whitespace or HTML formatting that either you or your mailer
introduces. The maintainer that receives your patches needs to be able to save and apply them directly from your emails. A good
way to verify that what you are sending will be applicable by the maintainer is to do a dry run and send them to yourself and then
save and apply them as the maintainer would.
The git send-email command is the preferred method for sending your patches using email since there is no risk of
compromising whitespace in the body of the message, which can occur when you use your own mail client. The command also has
several options that let you specify recipients and perform further editing of the email message. For information on how to use the
git send-email command, see GIT-SEND-EMAIL(1) displayed using the man git-send-email command.
Chapter 4. Common Tasks¶
1. Understanding and Creating Layers
1.1. Layers
1.2. Creating Your Own Layer
1.3. Following Best Practices When Creating Layers
1.4. Making Sure Your Layer is Compatible With Yocto Project
1.5. Enabling Your Layer
1.6. Using .bbappend Files in Your Layer
1.7. Prioritizing Your Layer
1.8. Managing Layers
1.9. Creating a General Layer Using the bitbake-layers Script
2. Customizing Images
2.1. Customizing Images Using local.conf
2.2. Customizing Images Using Custom IMAGE_FEATURES and EXTRA_IMAGE_FEATURES
2.3. Customizing Images Using Custom .bb Files
2.4. Customizing Images Using Custom Package Groups
2.5. Customizing an Image Hostname
3. Writing a New Recipe
3.1. Overview
3.2. Locate or Automatically Create a Base Recipe
3.3. Storing and Naming the Recipe
3.4. Running a Build on the Recipe
3.5. Fetching Code
3.6. Unpacking Code
3.7. Patching Code
3.8. Licensing
3.9. Dependencies
3.10. Configuring the Recipe
3.11. Using Headers to Interface with Devices
3.12. Compilation
3.13. Installing
3.14. Enabling System Services
3.15. Packaging
3.16. Sharing Files Between Recipes
3.17. Properly Versioning Pre-Release Recipes
3.18. Post-Installation Scripts
3.19. Testing
3.20. Examples
3.21. Following Recipe Style Guidelines
4. Adding a New Machine
4.1. Adding the Machine Configuration File
4.2. Adding a Kernel for the Machine
4.3. Adding a Formfactor Configuration File
5. Finding Temporary Source Code
6. Using Quilt in Your Workflow
7. Using a Development Shell
8. Using a Development Python Shell
9. Building Targets with Multiple Configurations
10. Working With Libraries
10.1. Including Static Library Files
10.2. Combining Multiple Versions of Library Files into One Image
10.3. Installing Multiple Versions of the Same Library
11. Enabling GObject Introspection Support
11.1. Enabling the Generation of Introspection Data
11.2. Disabling the Generation of Introspection Data
11.3. Testing that Introspection Works in an Image
11.4. Known Issues
12. Optionally Using an External Toolchain
13. Creating Partitioned Images Using Wic

2018/1/27 Yocto Project Mega-Manual
http://www.yoctoproject.org/docs/2.4.1/mega-manual/mega-manual.html 19/426
13.1. Background
13.2. Requirements
13.3. Getting Help
13.4. Operational Modes
13.5. Using an Existing Kickstart File
13.6. Examples
14. Building an Initial RAM Filesystem (initramfs) Image
15. Flashing Images Using bmaptool
16. Making Images More Secure
16.1. General Considerations
16.2. Security Flags
16.3. Considerations Specific to the OpenEmbedded Build System
16.4. Tools for Hardening Your Image
17. Creating Your Own Distribution
18. Creating a Custom Template Configuration Directory
19. Building a Tiny System
19.1. Overview
19.2. Goals and Guiding Principles
19.3. Understand What Contributes to Your Image Size
19.4. Trim the Root Filesystem
19.5. Trim the Kernel
19.6. Remove Package Management Requirements
19.7. Look for Other Ways to Minimize Size
19.8. Iterate on the Process
20. Building Images for More than One Machine
21. Working with Packages
21.1. Excluding Packages from an Image
21.2. Incrementing a Package Version
21.3. Handling Optional Module Packaging
21.4. Using Runtime Package Management
21.5. Generating and Using Signed Packages
21.6. Testing Packages With ptest
22. Working with Source Files
22.1. Setting up Effective Mirrors
22.2. Getting Source Files and Suppressing the Build
23. Building Software from an External Source
24. Selecting an Initialization Manager
24.1. Using systemd Exclusively
24.2. Using systemd for the Main Image and Using SysVinit for the Rescue Image
25. Selecting a Device Manager
25.1. Using Persistent and Pre-Populated/dev
25.2. Using devtmpfs and a Device Manager
26. Using an External SCM
27. Creating a Read-Only Root Filesystem
27.1. Creating the Root Filesystem
27.2. Post-Installation Scripts
27.3. Areas With Write Access
28. Performing Automated Runtime Testing
28.1. Enabling Tests
28.2. Running Tests
28.3. Exporting Tests
28.4. Writing New Tests
28.5. Installing Packages in the DUT Without the Package Manager
29. Debugging With the GNU Project Debugger (GDB) Remotely
30. Debugging with the GNU Project Debugger (GDB) on the Target
31. Debugging Parallel Make Races
31.1. The Failure
31.2. Reproducing the Error
31.3. Creating a Patch for the Fix
31.4. Testing the Build
32. Maintaining Open Source License Compliance During Your Product's Lifecycle
32.1. Providing the Source Code
32.2. Providing License Text
32.3. Providing Compilation Scripts and Source Code Modifications
33. Using the Error Reporting Tool
33.1. Enabling and Using the Tool
33.2. Disabling the Tool
33.3. Setting Up Your Own Error Reporting Server
This chapter describes fundamental procedures such as creating layers, adding new software packages, extending or customizing images,
porting work to new hardware (adding a new machine), and so forth. You will find that the procedures documented here occur often in
the development cycle using the Yocto Project.
1. Understanding and Creating Layers¶
The OpenEmbedded build system supports organizing Metadata into multiple layers. Layers allow you to isolate different types of
customizations from each other. You might find it tempting to keep everything in one layer when working on a single project. However,
the more modular your Metadata, the easier it is to cope with future changes.
To illustrate how layers are used to keep things modular, consider machine customizations. These types of customizations typically reside
in a special layer, rather than a general layer, called a Board Support Package (BSP) Layer. Furthermore, the machine customizations
should be isolated from recipes and Metadata that support a new GUI environment, for example. This situation gives you a couple of
layers: one for the machine configurations, and one for the GUI environment. It is important to understand, however, that the BSP layer
can still make machine-specific additions to recipes within the GUI environment layer without polluting the GUI layer itself with those
machine-specific changes. You can accomplish this through a recipe that is a BitBake append (.bbappend) file, which is described
later in this section.
Note
For general information on BSP layer structure, see the Board Support Packages (BSP) - Developer's Guide.

2018/1/27 Yocto Project Mega-Manual

http://www.yoctoproject.org/docs/2.4.1/mega-manual/mega-manual.html 20/426

4.1.1. Layers¶

The Source Directory contains both general layers and BSP layers right out of the box. You can easily identify layers that ship with a

Yocto Project release in the Source Directory by their folder names. Folders that represent layers typically have names that begin with

the string meta-.

Note

It is not a requirement that a layer name begin with the prefix meta-, but it is a commonly accepted standard in

the Yocto Project community.

For example, when you set up the Source Directory structure, you will see several layers: meta, meta-skeleton, meta-

selftest, meta-poky, and meta-yocto-bsp. Each of these folders represents a distinct layer.

As another example, if you set up a local copy of the meta-intel Git repository and then explore the folder of that general layer, you

will discover many Intel-specific BSP layers inside. For more information on BSP layers, see the "BSP Layers" section in the Yocto Project

Board Support Package (BSP) Developer's Guide.

4.1.2. Creating Your Own Layer¶

It is very easy to create your own layers to use with the OpenEmbedded build system. The Yocto Project ships with scripts that speed up

creating general layers and BSP layers. This section describes the steps you perform by hand to create a layer so that you can better

understand them. For information about the layer-creation scripts, see the "Creating a New BSP Layer Using the yocto-bsp Script" section

in the Yocto Project Board Support Package (BSP) Developer's Guide and the "Creating a General Layer Using the bitbake-layers

Script" section further down in this manual.

Follow these general steps to create your layer without the aid of a script:

1. Check Existing Layers: Before creating a new layer, you should be sure someone has not already created a layer containing the

Metadata you need. You can see the OpenEmbedded Metadata Index for a list of layers from the OpenEmbedded

community that can be used in the Yocto Project.

2. Create a Directory: Create the directory for your layer. While not strictly required, prepend the name of the folder with the string

meta-. For example:

meta-mylayer

meta-GUI_xyz

meta-mymachine

3. Create a Layer Configuration File: Inside your new layer folder, you need to create a conf/layer.conf file. It is easiest

to take an existing layer configuration file and copy that to your layer's conf directory and then modify the file as needed.

The meta-yocto-bsp/conf/layer.conf file demonstrates the required syntax:

# We have a conf and classes directory, add to BBPATH

BBPATH .= ":${LAYERDIR}"

# We have recipes-* directories, add to BBFILES

BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \

${LAYERDIR}/recipes-*/*/*.bbappend"

BBFILE_COLLECTIONS += "yoctobsp"

BBFILE_PATTERN_yoctobsp = "^${LAYERDIR}/"

BBFILE_PRIORITY_yoctobsp = "5"

LAYERVERSION_yoctobsp = "3"

Here is an explanation of the example:

The configuration and classes directory is appended to BBPATH.

Note

All non-distro layers, which include all BSP layers, are expected to append the layer directory to the

BBPATH. On the other hand, distro layers, such as meta-poky, can choose to enforce their own

precedence over BBPATH. For an example of that syntax, see the layer.conf file for the meta-

poky layer.

The recipes for the layers are appended to BBFILES.

The BBFILE_COLLECTIONS variable is then appended with the layer name.

The BBFILE_PATTERN variable is set to a regular expression and is used to match files from BBFILES into a particular

layer. In this case, LAYERDIR is used to make BBFILE_PATTERN match within the layer's path.

The BBFILE_PRIORITY variable then assigns a priority to the layer. Applying priorities is useful in situations where the

same recipe might appear in multiple layers and allows you to choose the layer that takes precedence.

The LAYERVERSION variable optionally specifies the version of a layer as a single number.

Note the use of the LAYERDIR variable, which expands to the directory of the current layer.

Through the use of the BBPATH variable, BitBake locates class files (.bbclass), configuration files, and files that are included

with include and require statements. For these cases, BitBake uses the first file that matches the name found in BBPATH.

This is similar to the way the PATH variable is used for binaries. It is recommended, therefore, that you use unique class and

configuration filenames in your custom layer.

剩余425页未读，继续阅读

os从业人员

粉丝: 58
资源: 8

YoctoProject 2018 官方完整手册

yocto工程开发手册（中文）

yocto 超详细教程，看完必会搭建linux系统

Yocto 项目概述和概念手册.pdf

yocto之目录结构介绍.pdf

Yocto Project.zip_c/C++_yocto_yocto pdf_项目文档

Yocto3.0的使用手册文档（PDF）

Yocto Kernel编译过程分析完整log

yocto-slides.pdf

yocto环境创建.pdf

20个Yocto实际使用问题.pdf

最新资源