Yocto V3.5开发指南：从零开始构建嵌入式Linux系统

需积分: 50 43 浏览量更新于2024-07-05 1 收藏 12.11MB PDF 举报

Yocto用户使用完全手册 - V3.5 是一本针对开源社区Yocto Project的专业指南，该项目专注于帮助开发者构建基于Linux内核的定制系统，特别适用于ARM、PPC、MIPS和X86等嵌入式硬件平台。手册的核心内容聚焦在快速入门步骤，指导用户如何通过Yocto Project构建一个名为Poky的参考嵌入式操作系统。在这个手册中，作者假设读者正在使用的是具备最新Ubuntu发行版的本地Linux系统作为开发主机（Build Host）。如果你的开发机器不是Linux系统，例如Windows 10，可以利用Cross Platform Support (CROS) 和 Poky容器来执行这些步骤。CROS允许你在非Linux环境下进行Yocto开发，但请注意，Yocto Project不兼容Windows Subsystem for Linux（WSL）的早期版本，只支持WSL v2，因此推荐升级到WSL v2以获得更好的官方支持。手册详细介绍了以下关键知识点： 1. **Yocto Project简介**：Yocto Project是一个开源框架，其目标是简化嵌入式系统的软件开发流程，包括定制Linux内核、配置开发环境、集成应用程序和构建固件映像。 2. **快速构建流程**：文档会引导读者完成从获取Yocto源代码、设置开发环境、选择或创建元层（Meta Layer）、配置配方（Recipes）直到最终生成镜像的整个过程。 3. **硬件特定配置**：手册强调了针对不同硬件平台的配置，确保构建出适合特定硬件的定制系统，这涉及到硬件抽象层（HAB）的选择和配置，以支持ARM、PPC等架构。 4. **开发主机环境搭建**：对于Windows用户，提供了使用Windows Subsystem for Linux v2作为开发环境的详细指导，包括设置Poky容器和必要的配置步骤。 5. **兼容性和注意事项**：明确指出了Yocto Project与WSL版本的关系，推荐使用WSL v2以确保最佳性能和官方支持。 Yocto用户完全手册V3.5是一本实用的指南，不仅适合新用户快速上手，也对有经验的开发者深入定制嵌入式Linux系统提供了宝贵的参考资料。通过阅读此手册，用户可以掌握如何充分利用Yocto Project的强大功能，为他们的嵌入式项目开发带来便利。

Releases According to a Strict Schedule: Major releases occur on a six-month cycle predictably

in October and April. The most recent two releases support point releases to address

common vulnerabilities and exposures. This predictability is crucial for projects based on the

Yocto Project and allows development teams to plan activities.

Rich Ecosystem of Individuals and Organizations: For open source projects, the value of

community is very important. Support forums, expertise, and active developers who

continue to push the Yocto Project forward are readily available.

Binary Reproducibility: The Yocto Project allows you to be very specific about dependencies

and achieves very high percentages of binary reproducibility (e.g. 99.8% for core-image-

minimal ). When distributions are not specific about which packages are pulled in and in

what order to support dependencies, other build systems can arbitrarily include packages.

License Manifest: The Yocto Project provides a license manifest for review by people who

need to track the use of open source licenses (e.g. legal teams).

2.1.2 Challenges

Here are challenges you might encounter when developing using the Yocto Project:

Steep Learning Curve: The Yocto Project has a steep learning curve and has many different

ways to accomplish similar tasks. It can be difficult to choose between such ways.

Understanding What Changes You Need to Make For Your Design Requires Some Research:

Beyond the simple tutorial stage, understanding what changes need to be made for your

particular design can require a significant amount of research and investigation. For

information that helps you transition from trying out the Yocto Project to using it for your

project, see the “What I wish I’d known about Yocto Project” and “Transitioning to a custom

environment for systems development” documents on the Yocto Project website.

Project Workflow Could Be Confusing: The Yocto Project workflow <overview-

manual/development-environment:the yocto project development environment> could be

confusing if you are used to traditional desktop and server software development. In a

desktop development environment, there are mechanisms to easily pull and install new

packages, which are typically pre-compiled binaries from servers accessible over the

Internet. Using the Yocto Project, you must modify your configuration and rebuild to add

additional packages.

Working in a Cross-Build Environment Can Feel Unfamiliar: When developing code to run on a

target, compilation, execution, and testing done on the actual target can be faster than

running a BitBake build on a development host and then deploying binaries to the target for

test. While the Yocto Project does support development tools on the target, the additional

step of integrating your changes back into the Yocto Project build environment would be

required. Yocto Project supports an intermediate approach that involves making changes on

the development system within the BitBake environment and then deploying only the

updated packages to the target.

The Yocto Project OpenEmbedded Build System produces packages in standard formats (i.e.

RPM, DEB, IPK, and TAR). You can deploy these packages into the running system on the

target by using utilities on the target such as rpm or ipk .

Initial Build Times Can be Significant: Long initial build times are unfortunately unavoidable

due to the large number of packages initially built from scratch for a fully functioning Linux

system. Once that initial build is completed, however, the shared-state (sstate) cache

mechanism Yocto Project uses keeps the system from rebuilding packages that have not

been “touched” since the last build. The sstate mechanism significantly reduces times for

successive builds.

2.2 The Yocto Project Layer Model

The Yocto Project’s “Layer Model” is a development model for embedded and IoT Linux creation

that distinguishes the Yocto Project from other simple build systems. The Layer Model

simultaneously supports collaboration and customization. Layers are repositories that contain

related sets of instructions that tell the OpenEmbedded Build System what to do. You can

collaborate, share, and reuse layers.

Layers can contain changes to previous instructions or settings at any time. This powerful

override capability is what allows you to customize previously supplied collaborative or

community layers to suit your product requirements.

You use different layers to logically separate information in your build. As an example, you could

have BSP, GUI, distro configuration, middleware, or application layers. Putting your entire build

into one layer limits and complicates future customization and reuse. Isolating information into

layers, on the other hand, helps simplify future customizations and reuse. 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.

Note

Use Board Support Package (BSP) layers from silicon vendors when possible.

Familiarize yourself with the Yocto Project curated layer index or the OpenEmbedded layer

index. The latter contains more layers but they are less universally validated.

Layers support the inclusion of technologies, hardware components, and software

components. The Yocto Project Compatible designation provides a minimum level of

standardization that contributes to a strong ecosystem. “YP Compatible” is applied to

appropriate products and software components such as BSPs, other OE-compatible layers,

and related open-source projects, allowing the producer to use Yocto Project badges and

branding assets.

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 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 Yocto Project Board Support Package

Developer’s Guide.

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 names.

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, if you were to examine the tree view of the  poky  repository, you will see several 
layers:  meta ,  meta-skeleton ,  meta-selftest ,  meta-poky , and  meta-yocto-bsp . Each of these 
repositories represents a distinct layer.
For procedures on how to create layers, see the “Understanding and Creating Layers” section in 
the Yocto Project Development Tasks Manual.
2.3 Components and Tools  
The Yocto Project employs a collection of components and tools used by the project itself, by 
project developers, and by those using the Yocto Project. These components and tools are open 
source projects and metadata that are separate from the reference distribution (Poky) and the 
OpenEmbedded Build System. Most of the components and tools are downloaded separately.
This section provides brief overviews of the components and tools associated with the Yocto 
Project.
2.3.1 Development Tools  
Here are tools that help you develop images and applications using the Yocto Project:
CROPS: CROPS is an open source, cross-platform development framework that leverages 
Docker Containers. CROPS provides an easily managed, extensible environment that allows 
you to build binaries for a variety of architectures on Windows, Linux and Mac OS X hosts.
devtool: This command-line tool is available as part of the extensible SDK (eSDK) and is its 
cornerstone. You can use  devtool  to help build, test, and package software within the eSDK. 
You can use the tool to optionally integrate what you build into an image built by the 
OpenEmbedded build system.
The  devtool  command employs a number of sub-commands that allow you to add, modify, 
and upgrade recipes. As with the OpenEmbedded build system, “recipes” represent software 
packages within  devtool . When you use  devtool add , a recipe is automatically created. 
When you use  devtool modify , the specified existing recipe is used in order to determine 
where to get the source code and how to patch it. In both cases, an environment is set up so 
that when you build the recipe a source tree that is under your control is used in order to 
allow you to make changes to the source as desired. By default, both new recipes and the 
source go into a “workspace” directory under the eSDK. The  devtool upgrade  command 
updates an existing recipe so that you can build it for an updated set of source files.
You can read about the  devtool  workflow in the Yocto Project Application Development and 
Extensible Software Development Kit (eSDK) Manual in the “Using devtool in Your SDK 
Workflow” section.
Extensible Software Development Kit (eSDK): The eSDK provides a cross-development toolchain 
and libraries tailored to the contents of a specific image. The eSDK makes it easy to add new 
applications and libraries to an image, modify the source for an existing component, test 
changes on the target hardware, and integrate into the rest of the OpenEmbedded build 
system. The eSDK gives you a toolchain experience supplemented with the powerful set of 
devtool  commands tailored for the Yocto Project environment.
For information on the eSDK, see the Yocto Project Application Development and the 
Extensible Software Development Kit (eSDK) Manual.
Toaster: Toaster is a web interface to the Yocto Project OpenEmbedded build system. Toaster 
allows you to configure, run, and view information about builds. For information on Toaster, 
see the Toaster User Manual.

2.3.2 Production Tools

Here are tools that help with production related activities using the Yocto Project:

Auto Upgrade Helper: This utility when used in conjunction with the OpenEmbedded Build

System (BitBake and OE-Core) automatically generates upgrades for recipes that are based

on new versions of the recipes published upstream. See Using the Auto Upgrade Helper

(AUH) for how to set it up.

Recipe Reporting System: The Recipe Reporting System tracks recipe versions available for

Yocto Project. The main purpose of the system is to help you manage the recipes you

maintain and to offer a dynamic overview of the project. The Recipe Reporting System is built

on top of the OpenEmbedded Layer Index, which is a website that indexes OpenEmbedded-

Core layers.

Patchwork: Patchwork is a fork of a project originally started by OzLabs. The project is a web-

based tracking system designed to streamline the process of bringing contributions into a

project. The Yocto Project uses Patchwork as an organizational tool to handle patches, which

number in the thousands for every release.

AutoBuilder: AutoBuilder is a project that automates build tests and quality assurance (QA).

By using the public AutoBuilder, anyone can determine the status of the current

development branch of Poky.

Note

AutoBuilder is based on buildbot.

A goal of the Yocto Project is to lead the open source industry with a project that automates

testing and QA procedures. In doing so, the project encourages a development community

that publishes QA and test plans, publicly demonstrates QA and test plans, and encourages

development of tools that automate and test and QA procedures for the benefit of the

development community.

You can learn more about the AutoBuilder used by the Yocto Project Autobuilder here.

Cross-Prelink: Prelinking is the process of pre-computing the load addresses and link tables

generated by the dynamic linker as compared to doing this at runtime. Doing this ahead of

time results in performance improvements when the application is launched and reduced

memory usage for libraries shared by many applications.

Historically, cross-prelink is a variant of prelink, which was conceived by Jakub Jelínek a

number of years ago. Both prelink and cross-prelink are maintained in the same repository

albeit on separate branches. By providing an emulated runtime dynamic linker (i.e. glibc -

derived ld.so emulation), the cross-prelink project extends the prelink software’s ability to

prelink a sysroot environment. Additionally, the cross-prelink software enables the ability to

work in sysroot style environments.

The dynamic linker determines standard load address calculations based on a variety of

factors such as mapping addresses, library usage, and library function conflicts. The prelink

tool uses this information, from the dynamic linker, to determine unique load addresses for

executable and linkable format (ELF) binaries that are shared libraries and dynamically

linked. The prelink tool modifies these ELF binaries with the pre-computed information. The

result is faster loading and often lower memory consumption because more of the library

code can be re-used from shared Copy-On-Write (COW) pages.

The original upstream prelink project only supports running prelink on the end target device

due to the reliance on the target device’s dynamic linker. This restriction causes issues when

developing a cross-compiled system. The cross-prelink adds a synthesized dynamic loader

that runs on the host, thus permitting cross-prelinking without ever having to run on a read-

write target filesystem.
Pseudo: Pseudo is the Yocto Project implementation of fakeroot, which is used to run 
commands in an environment that seemingly has root privileges.
During a build, it can be necessary to perform operations that require system administrator 
privileges. For example, file ownership or permissions might need to be defined. Pseudo is a 
tool that you can either use directly or through the environment variable  LD_PRELOAD . Either 
method allows these operations to succeed even without system administrator privileges.
Thanks to Pseudo, the Yocto Project never needs root privileges to build images for your 
target system.
You can read more about Pseudo in the “Fakeroot and Pseudo” section.
2.3.3 Open-Embedded Build System Components  
Here are components associated with the OpenEmbedded Build System:
BitBake: BitBake is a core component of the Yocto Project and is used by the OpenEmbedded 
build system to build images. While BitBake is key to the build system, BitBake is maintained 
separately from the Yocto Project.
BitBake is a generic task execution engine that allows shell and Python tasks to be run 
efficiently and in parallel while working within complex inter-task dependency constraints. In 
short, BitBake is a build engine that works through recipes written in a specific format in 
order to perform sets of tasks.
You can learn more about BitBake in the BitBake User Manual.
OpenEmbedded-Core: OpenEmbedded-Core (OE-Core) is a common layer of metadata (i.e. 
recipes, classes, and associated files) used by OpenEmbedded-derived systems, which 
includes the Yocto Project. The Yocto Project and the OpenEmbedded Project both maintain 
the OpenEmbedded-Core. You can find the OE-Core metadata in the Yocto Project Source 
Repositories.
Historically, the Yocto Project integrated the OE-Core metadata throughout the Yocto Project 
source repository reference system (Poky). After Yocto Project Version 1.0, the Yocto Project 
and OpenEmbedded agreed to work together and share a common core set of metadata 
(OE-Core), which contained much of the functionality previously found in Poky. This 
collaboration achieved a long-standing OpenEmbedded objective for having a more tightly 
controlled and quality-assured core. The results also fit well with the Yocto Project objective 
of achieving a smaller number of fully featured tools as compared to many different ones.
Sharing a core set of metadata results in Poky as an integration layer on top of OE-Core. You 
can see that in this figure. The Yocto Project combines various components such as BitBake, 
OE-Core, script “glue”, and documentation for its build system.
2.3.4 Reference Distribution (Poky)  
Poky is the Yocto Project reference distribution. It contains the OpenEmbedded Build System 
(BitBake and OE-Core) as well as a set of metadata to get you started building your own 
distribution. See the figure in “What is the Yocto Project?” section for an illustration that shows 
Poky and its relationship with other parts of the Yocto Project.
To use the Yocto Project tools and components, you can download ( clone ) Poky and use it to 
bootstrap your own distribution.
Note

剩余701页未读，继续阅读

蜗牛狠邋遢

粉丝: 1
资源: 9

Yocto V3.5开发指南：从零开始构建嵌入式Linux系统

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

IMX7文档集合 Yocto使用教程

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

the-yocto-project-user-manual-pdf

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

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

yocto-core-stack-源码.rar

Yocto Project Mega-Manual-2020-02-06.pdf

Building-a-Yocto-image-for-Galileo-Gen-2-bord:为Galileo Gen 2 bord构建Yocto图像。 并安装其他软件包，例如OpenCV等

Yocto-for-Raspberry-Pi:Packt发行的适用于Raspberry Pi的Yocto的代码存储库

最新资源

Building-a-Yocto-image-for-Galileo-Gen-2-bord:为Galileo Gen 2 bord构建Yocto图像。并安装其他软件包，例如OpenCV等