Yocto Project 3.0 官方手册

需积分: 10 181 浏览量更新于2024-07-16 收藏 9.79MB PDF 举报

"Yocto Project Mega-Manual-2020-02-06.pdf 是Yocto Project的官方最新手册，作者为Scott Rifenbark，由Linux Foundation授权，遵循Creative Commons Attribution-ShareAlike 2.0 UK: England & Wales许可。该手册适用于Yocto Project的3.0版本。为了获取最新版本的手册，用户应直接访问Yocto Project的官方文档页面，因为这些在线版本通常比从Yocto Project发布TAR文件中提取的手册更新。如果通过网络搜索找到的手册，可能存在版本过时的问题，用户可以通过查看Releases页面来确认所有Yocto Project的主要版本，并选择对应版本的手册。" **Yocto Project介绍** Yocto Project是一个开放源代码项目，它提供了一套工具、库和过程，用于构建定制的Linux发行版，特别是针对嵌入式设备。该项目基于BitBake构建系统，旨在简化和标准化跨平台的Linux开发流程。 **主要知识点** 1. **BitBake**: BitBake是Yocto Project的核心组件，负责编译和构建软件包。它解析名为“配方”（Recipe）的文本文件，这些文件定义了如何构建特定软件包及其依赖关系。 2. **OpenEmbedded**: Yocto Project基于OpenEmbedded项目，后者是一个构建系统，包含大量的软件包和配置选项，用于创建自定义Linux发行版。 3. ** Poky**: Poky是Yocto Project的一个核心组件，它是一个小型的参考Linux发行版，包含了构建其他发行版所需的基础设施和工具。 4. **Layer**: 在Yocto Project中，Layers是一种组织构建元数据的方式，允许开发者在不修改基础层的情况下添加或修改功能。常见的Layer包括Core Layer、Meta-oe、Meta-toolchain等。 5. **Image Types**: Yocto Project支持构建不同类型的镜像，如Live CDs、SD卡映像、虚拟机映像等，这些映像可以根据目标设备的需求进行定制。 6. **Devtool**: Devtool是Yocto Project提供的一个工具，简化了开发者在开发环境中创建、管理和调试本地源代码的工作流程。 7. **Docker Integration**: Yocto Project可以与Docker集成，提供了一个名为`oe-docker`的工具，使得开发者可以在Docker容器内构建Yocto环境，以保持环境一致性。 8. **Device Trees**: Yocto Project利用Device Tree来描述硬件结构，使得操作系统能够适配不同硬件平台。 9. **Board Support Packages (BSP)**: BSP是针对特定硬件平台的软件集合，包括驱动程序、固件和其他必要的组件，使得Yocto Project能运行在特定硬件上。 10. **Target and Host**: Yocto Project区分了目标系统（Target System）和主机系统（Host System）。主机系统用于构建软件，而目标系统是最终运行Yocto构建的Linux发行版的硬件平台。了解和掌握这些知识点对于在嵌入式Linux领域使用Yocto Project进行系统开发至关重要。通过深入学习和实践，开发者可以高效地构建定制化的嵌入式Linux系统，满足特定项目的需求。

/
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
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.
3.3. Yocto Project Source Repositories¶
The Yocto Project team maintains complete source repositories for all Yocto Project files at http://git.yoctoproject.org. This
web-based source code browser is organized into categories by function such as IDE Plugins, Matchbox, Poky, Yocto Linux
Kernel, and so forth. From the interface, you can click on any particular item in the "Name" column and see the URL at the
bottom of the page that you need to clone a Git repository for that particular item. Having a local Git repository of the
Source Directory, which is usually named "poky", allows you to make changes, contribute to the history, and ultimately
enhance the Yocto Project's tools, Board Support Packages, and so forth.
For any supported release of Yocto Project, you can also go to the Yocto Project Website and select the "DOWNLOADS" item
from the "SOFTWARE" menu and get a released tarball of the poky repository, any supported BSP tarball, or Yocto Project
tools. Unpacking these tarballs gives you a snapshot of the released files.
Notes
The recommended method for setting up the Yocto Project Source Directory and the files for
supported BSPs (e.g., meta-intel) is to use Git to create a local copy of the upstream
repositories.

For steps on how to use the "DOWNLOADS" page, see the "Using the Downloads Page" section in the Yocto Project

Development Tasks Manual.

3.4. Git Workflows and the Yocto Project¶

Developing using the Yocto Project likely requires the use of Git. Git is a free, open source distributed version control system

used as part of many collaborative design environments. This section provides workflow concepts using the Yocto Project

and Git. In particular, the information covers basic practices that describe roles and actions in a collaborative development

environment.

Note

If you are familiar with this type of development environment, you might not want to read this

section.

The Yocto Project files are maintained using Git in "branches" whose Git histories track every change and whose structures

provide branches for all diverging functionality. Although there is no need to use Git, many open source projects do so.

For the Yocto Project, a key individual called the "maintainer" is responsible for the integrity of the "master" branch of a

given Git repository. The "master" branch is the “upstream” repository from which final or most recent builds of a project

occur. The maintainer is responsible for accepting changes from other developers and for organizing the underlying branch

structure to reflect release strategies and so forth.

Note

For information on finding out who is responsible for (maintains) a particular area of code in the Yocto

Project, see the "Submitting a Change to the Yocto Project" section of the Yocto Project Development

Tasks Manual.

The Yocto Project poky Git repository also has an upstream contribution Git repository named poky-contrib. You can

see all the branches in this repository using the web interface of the Source Repositories organized within the "Poky

Support" area. These branches hold changes (commits) to the project that have been submitted or committed by the Yocto

Project development team and by community members who contribute to the project. The maintainer determines if the

changes are qualified to be moved from the "contrib" branches into the "master" branch of the Git repository.

Developers (including contributing community members) create and maintain cloned repositories of upstream branches. The

cloned repositories are local to their development platforms and are used to develop changes. When a developer is satisfied

with a particular feature or change, they "push" the change to the appropriate "contrib" repository.

Developers are responsible for keeping their local repository up-to-date with whatever upstream branch they are working

against. They are also responsible for straightening out any conflicts that might arise within files that are being worked on

simultaneously by more than one person. All this work is done locally on the development host before anything is pushed to

a "contrib" area and examined at the maintainer’s level.

A somewhat formal method exists by which developers commit changes and push them into the "contrib" area and

subsequently request that the maintainer include them into an upstream branch. This process is called “submitting a patch”

or "submitting a change." For information on submitting patches and changes, see the "Submitting a Change to the Yocto

Project" section in the Yocto Project Development Tasks Manual.

In summary, a single point of entry exists for changes into a "master" or development branch of the Git repository, which is

controlled by the project’s maintainer. And, a set of developers exist who independently develop, test, and submit changes

to "contrib" areas for the maintainer to examine. The maintainer then chooses which changes are going to become a

permanent part of the project.

While each development environment is unique, there are some best practices or methods that help development run

smoothly. The following list describes some of these practices. For more information about Git workflows, see the workflow

topics in the Git Community Book.

Make Small Changes: It is best to keep the changes you commit small as compared to bundling many disparate

changes into a single commit. This practice not only keeps things manageable but also allows the maintainer to more

easily include or refuse changes.

Make Complete Changes: It is also good practice to leave the repository in a state that allows you to still successfully

build your project. In other words, do not commit half of a feature, then add the other half as a separate, later commit.

Each commit should take you from one buildable project state to another buildable state.

Use Branches Liberally: It is very easy to create, use, and delete local branches in your working Git repository on the

development host. You can name these branches anything you like. It is helpful to give them names associated with the

particular feature or change on which you are working. Once you are done with a feature or change and have merged it

into your local master branch, simply discard the temporary branch.

Merge Changes: The git merge command allows you to take the changes from one branch and fold them into

another branch. This process is especially helpful when more than a single developer might be working on different parts

of the same feature. Merging changes also automatically identifies any collisions or "conflicts" that might happen as a

result of the same lines of code being altered by two different developers.

Manage Branches: Because branches are easy to use, you should use a system where branches indicate varying levels

of code readiness. For example, you can have a "work" branch to develop in, a "test" branch where the code or change is

tested, a "stage" branch where changes are ready to be committed, and so forth. As your project develops, you can

merge code across the branches to reflect ever-increasing stable states of the development.

Use Push and Pull: The push-pull workflow is based on the concept of developers "pushing" local commits to a remote

repository, which is usually a contribution repository. This workflow is also based on developers "pulling" known states of

the project down into their local development repositories. The workflow easily allows you to pull changes submitted by

other developers from the upstream repository into your work area ensuring that you have the most recent software on

which to develop. The Yocto Project has two scripts named create-pull-request and send-pull-request

that ship with the release to facilitate this workflow. You can find these scripts in the scripts folder of the Source

Directory. For information on how to use these scripts, see the "Using Scripts to Push a Change Upstream and Request a

Pull" section in the Yocto Project Development Tasks Manual.

Patch Workflow: This workflow allows you to notify the maintainer through an email that you have a change (or patch)

you would like considered for the "master" branch of the Git repository. To send this type of change, you format the patch

and then send the email using the Git commands git format-patch and git send-email. For information on

how to use these scripts, see the "Submitting a Change to the Yocto Project" section in the Yocto Project Development

Tasks Manual.

3.5. Git¶

The Yocto Project makes extensive use of Git, which is a free, open source distributed version control system. Git supports

distributed development, non-linear development, and can handle large projects. It is best that you have some fundamental

understanding of how Git tracks projects and how to work with Git if you are going to use the Yocto Project for development.

This section provides a quick overview of how Git works and provides you with a summary of some essential Git commands.

Notes

For more information on Git, see http://git-scm.com/documentation.

If you need to download Git, it is recommended that you add Git to your system through your

distribution's "software store" (e.g. for Ubuntu, use the Ubuntu Software feature). For the Git

download page, see http://git-scm.com/download.

For information beyond the introductory nature in this section, see the "Locating Yocto Project

Source Files" section in the Yocto Project Development Tasks Manual.

3.5.1. Repositories, Tags, and Branches¶

As mentioned briefly in the previous section and also in the "Git Workflows and the Yocto Project" section, the Yocto Project

maintains source repositories at http://git.yoctoproject.org. If you look at this web-interface of the repositories, each item is

a separate Git repository.

Git repositories use branching techniques that track content change (not files) within a project (e.g. a new feature or

updated documentation). Creating a tree-like structure based on project divergence allows for excellent historical

information over the life of a project. This methodology also allows for an environment from which you can do lots of local

experimentation on projects as you develop changes or new features.

A Git repository represents all development efforts for a given project. For example, the Git repository poky contains all

changes and developments for that repository over the course of its entire life. That means that all changes that make up all

releases are captured. The repository maintains a complete history of changes.

You can create a local copy of any repository by "cloning" it with the git clone command. When you clone a Git

repository, you end up with an identical copy of the repository on your development system. Once you have a local copy of a

repository, you can take steps to develop locally. For examples on how to clone Git repositories, see the "Locating Yocto

Project Source Files" section in the Yocto Project Development Tasks Manual.

It is important to understand that Git tracks content change and not files. Git uses "branches" to organize different

development efforts. For example, the poky repository has several branches that include the current "zeus" branch, the

"master" branch, and many branches for past Yocto Project releases. You can see all the branches by going to

http://git.yoctoproject.org/cgit.cgi/poky/ and clicking on the [...] link beneath the "Branch" heading.

Each of these branches represents a specific area of development. The "master" branch represents the current or most

recent development. All other branches represent offshoots of the "master" branch.

When you create a local copy of a Git repository, the copy has the same set of branches as the original. This means you can

use Git to create a local working area (also called a branch) that tracks a specific development branch from the upstream

source Git repository. in other words, you can define your local Git environment to work on any development branch in the

repository. To help illustrate, consider the following example Git commands:

$ cd ~

$ git clone git://git.yoctoproject.org/poky

$ cd poky

$ git checkout -b zeus origin/zeus

In the previous example after moving to the home directory, the git clone command creates a local copy of the

upstream poky Git repository. By default, Git checks out the "master" branch for your work. After changing the working

directory to the new local repository (i.e. poky), the git checkout command creates and checks out a local branch

named "zeus", which tracks the upstream "origin/zeus" branch. Changes you make while in this branch would ultimately

affect the upstream "zeus" branch of the poky repository.

It is important to understand that when you create and checkout a local working branch based on a branch name, your local

environment matches the "tip" of that particular development branch at the time you created your local branch, which could

be different from the files in the "master" branch of the upstream repository. In other words, creating and checking out a

local branch based on the "zeus" branch name is not the same as checking out the "master" branch in the repository. Keep

reading to see how you create a local snapshot of a Yocto Project Release.

Git uses "tags" to mark specific changes in a repository branch structure. Typically, a tag is used to mark a special point

such as the final change (or commit) before a project is released. You can see the tags used with the poky Git repository

by going to http://git.yoctoproject.org/cgit.cgi/poky/ and clicking on the [...] link beneath the "Tag" heading.

Some key tags for the poky repository are jethro-14.0.3, morty-16.0.1, pyro-17.0.0, and zeus-

22.0.0. These tags represent Yocto Project releases.

When you create a local copy of the Git repository, you also have access to all the tags in the upstream repository. Similar to

branches, you can create and checkout a local working Git branch based on a tag name. When you do this, you get a

snapshot of the Git repository that reflects the state of the files when the change was made associated with that tag. The

most common use is to checkout a working branch that matches a specific Yocto Project release. Here is an example:

$ cd ~

$ git clone git://git.yoctoproject.org/poky

$ cd poky

$ git fetch --tags

$ git checkout tags/rocko-18.0.0 -b my_rocko-18.0.0

In this example, the name of the top-level directory of your local Yocto Project repository is poky. After moving to the

poky directory, the git fetch command makes all the upstream tags available locally in your repository. Finally, the

git checkout command creates and checks out a branch named "my-rocko-18.0.0" that is based on the upstream

branch whose "HEAD" matches the commit in the repository associated with the "rocko-18.0.0" tag. The files in your

repository now exactly match that particular Yocto Project release as it is tagged in the upstream Git repository. It is

important to understand that when you create and checkout a local working branch based on a tag, your environment

matches a specific point in time and not the entire development branch (i.e. from the "tip" of the branch backwards).

3.5.2. Basic Commands¶

Git has an extensive set of commands that lets you manage changes and perform collaboration over the life of a project.

Conveniently though, you can manage with a small set of basic operations and workflows once you understand the basic

philosophy behind Git. You do not have to be an expert in Git to be functional. A good place to look for instruction on a

minimal set of Git commands is here.

剩余574页未读，继续阅读

紫枫术河

粉丝: 0

Yocto Project 3.0 官方手册

Yocto Project Mega-Manual：嵌入式Linux开发指南

Yocto项目学习与开发的完整参考资料包

"The Yocto Project User Manual PDF: A Quick Start Guide for Building Customized Linux Distributions

Yocto Project Mega-Manual .pdf

the-yocto-project-user-manual-pdf

Embedded-Linux-Development-Using-Yocto-Project-Cookbook-Second-Edition

Yocto Project Reference Manual.pdf

yocto-raspberry-pi:基于Yocto Project的Raspberry Pi系统

yocto-core-stack-源码.rar

fsl-arm-yocto-bsp-imx-4.1-krogoth.zip

最新资源