【linux】Yocto的介绍

一、概念及介绍

Yocto项目是一个开源协作项目，可帮助开发人员创建基于Linux的定制系统，这些系统专为嵌入式产品而设计，无论产品的硬件架构如何。Yocto Project提供灵活的工具集和开发环境，允许全球的嵌入式设备开发人员通过共享技术，软件堆栈，配置和用于创建这些定制的Linux映像的最佳实践进行协作。

 全球数以千计的开发人员发现Yocto Project在系统和应用程序开发，归档和管理优势以及用于速度，占用空间和内存利用率的自定义方面都具有优势。该项目是提供嵌入式软件堆栈的标准。该项目允许软件定制和多个硬件平台的构建交换以及可以维护和扩展的软件堆栈。 

Yocto：Yocto是这个开源项目的名称，该项目旨在帮助我们自定义Linux系统
Poky：Poky有两个含义。第一个含义是用来构建Linux的构建系统，值得注意的该Poky仅仅是一个概念，而非一个实体：它包含了 BitBake工具、编译工具链、BSP、诸多程序包或层，可以认为Poky即是Yocto的本质；此外Poky还有另外一层意思，使用Poky系统得到的默认参考 Linux 发行版也叫Poky（当然，我们可以对此发行版随意命名）。Poky的两个含义千万不能混淆
Metadata：元数据集，所谓元数据集就是发行版内各基本元素的描述与来源
Recipes：.bb/.bbappend文件，配方文件，描述了从哪获取软件源码，如何配置，如何编译。bbappend和bb的区别主要在于bbappend是基于bb的，功能是对相应的bb文件作补充和覆盖，有点类似于“重写”的概念
Class：.bbclass文件，包含在配方文件之间共享的有用信息。比如autotools该类，其中包含Autotools使用的任何应用程序的常用设置。Yocto项目参考手册中的“ 类 ”一章提供了有关类及其使用方法的详细信息。https://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-classes
Configuration：.conf文件，即配置文件，我们可以用它来改变构建方式，比如conf/local.conf可以配置机器配置选项，分发配置选项，编译器调整选项，常规通用配置选项和用户配置选项 。conf/bblayers.conf中可以添加用到的layer层路径，从而在编译时将他们添加进去。
Layers：即各种meta-xxx目录，将Metadata按层进行分类，有助于项目的维护，包含相关元数据（即指令集）的存储库，它们告诉OpenEmbedded构建系统如何构建目标。图层保存特定硬件的所有配置。隔离特定于硬件的配置允许通过使用不同的层来共享其他元数据，其中元数据可能在多个硬件中是通用的。
Bitbake：一个任务执行引擎，用来解析并执行Metadata
Output：即各种输出image
总结：假如用烹饪一桌酒席来形容构建发行版，则Yocto就是饭店名，Poky就是厨房（以及提供作为参考的菜的搭配套餐），Metadata就是烹饪资源（.bb/.bbappend表示配方/配方上的贴士，.conf表示厨房里的管事的小组长），Layers就是菜谱的分类（如川菜谱、粤菜谱），Bitbake就是厨师，Output就是得到的一桌酒席

二、YOCTO的架构

灰色框是构建发行版的输出目录，里面包含构建环境时自动生成的两个.conf文件（即配置文件–你想要构建什么机型的发行版，以及所包想要实现的功能的文件路径），灰色框左边黄色框中所列出的四个选项（商业软件、用户界面、中间件、板级支持包）都可以将他们的路径添加到bblayers.conf中。这样在编译发行版时才可以把这些信息包含进去。灰色框中的蓝色框中是构建输出的一些文件，如参考映像，许可证，打包文件，SDK等）。最下面的黑色框则是构建发行版的一些基础文件，也就是下载到电脑上的POKY文件，它提供了一个构建Linux开发版的基础环境。

  每个目录下主要有三级目录构成：meta-xxx -> recipes-yyy -> zzz/ttt.bb。

 meta-xxx就是layer（菜谱的分类如川菜谱、粤菜谱，xilinx、freescale），recipes-yyy就是Metadata（具体某一本菜谱），zzz就是菜谱上具体的一个配方。

 meta-xxx有的可以从官方下载，然后拿过来经过配置后直接可使用，下载网址：http://git.yoctoproject.org/cgit/cgit.cgi/

 比如我们的目标板是P2020，那么我们可以下载meta-fsl,如果目标板是zynq7，那么我们就需要下载meta-xilinx。

三、优缺点

优点：

支持架构多： Yocto项目支持Intel，ARM，MIPS，AMD，PPC和其他架构。大多数ODM，OSV和芯片供应商都创建并提供支持其硬件的BSP。如果您有自定义芯片，则可以创建支持该体系结构的BSP。

除了大量的架构支持外，Yocto项目还通过Quick EMUlator（QEMU）完全支持各种设备仿真。

映像和代码传输轻松： Yocto项目输出可以轻松地在架构之间移动，而无需迁移到新的开发环境。此外，如果使用Yocto项目创建图像或应用程序而发现自己无法支持它，那么商业Linux供应商（如Wind River，Mentor Graphics，T​​imesys和ENEA）可以接受它并提供持续支持。这些供应商提供使用Yocto项目构建的产品。（个人觉得比较重要，但不太理解）

灵活性： 公司以多种不同的方式使用Yocto项目。一个示例是创建内部Linux发行版，作为公司可以跨多个产品组使用的代码库。通过自定义和分层，项目组可以利用基础Linux发行版创建适合其产品需求的分发。

适用于约束嵌入式和物联网设备： 与完整的Linux发行版不同，您可以使用Yocto项目精确创建嵌入式设备所需的内容。只需添加设备绝对需要的功能支持或包。对于具有显示硬件的设备，可以使用可用的系统组件（如X11，GTK+，Qt，Clutter和SDL（以及其他））来创建丰富的用户体验。对于没有显示器或您要使用其他UI框架的设备，可以选择不安装这些组件。

全面的工具链功能： 支持的体系结构的工具链可满足大多数用例。但是，如果目标硬件支持的功能不属于标准工具链，则可以通过指定特定于平台的调整参数轻松自定义该工具链。而且，如果需要使用第三方工具链，Yocto项目中内置的机制可以实现这一点。

策略机制规则： 关注机制而不是策略确保可以根据设计需求自由设置策略，而不是采用某些系统软件提供商强制执行的决策。

使用层模型： Yocto项目层基础架构将相关功能分组到单独的包中。可以根据需要将这些分组功能逐步添加到项目中。使用图层隔离和分组功能可降低项目复杂性和冗余，可以轻松扩展系统，进行自定义并保持功能有序。

支持部分构建： 可以根据需要构建和重建单个程序包。Yocto Project通过其共享状态缓存（sstate）方案实现此 目的。能够单独构建和调试组件简化了项目开发。

稳定更新：主要版本 在10月和4月可预测的六个月周期内发布 。最新的两个版本支持点发布，以解决常见的漏洞和风险。这种可预测性对于基于Yocto项目的项目至关重要，并允许开发团队规划活动。

丰富的个人和组织生态系统： 对于开源项目，社区的价值非常重要。支持论坛，专业知识以及继续推动Yocto项目推进的积极开发人员随时可用。

二进制再现性： Yocto项目允许对依赖性非常具体，并实现非常高的二进制可重复性百分比（例如，99.8％ core-image-minimal）。如果发行版没有具体说明哪些包被提取以及支持依赖项的顺序，则其他构建系统可以任意包含包。

许可证清单： Yocto项目提供许可证清单， 供需要跟踪开源许可证使用的人员（例如法律团队）进行审核。

不足：

学习内容多： Yocto项目具有陡峭的学习曲线，并且有许多不同的方法来完成类似的任务。当存在完成给定任务的不同方法时，可能难以选择如何进行。

了解需要为特定的设计做出哪些更改需要一些研究： 除了简单的教程阶段，了解需要对特定设计进行哪些更改可能需要大量的研究和调查。

项目工作流程繁琐： 如果习惯于传统的桌面和服务器软件开发 ， Yocto项目工作流程可能会繁琐。在桌面开发环境中，存在轻松拉取和安装新包的机制，这些新包通常是可通过因特网访问的服务器的预编译二进制文件。使用Yocto项目，必须修改配置并重建以添加其他包。

在交叉构建环境中工作可能会感到不熟悉： 在开发在目标上运行的代码时，在实际目标上完成的编译，执行和测试可能比在开发主机上运行BitBake构建然后将二进制文件部署到目标进行测试更快。虽然Yocto项目确实支持目标上的开发工具，但是需要将更改集成回Yocto Project构建环境的附加步骤。

Yocto Project Openembedded构建系统以标准格式（即RPM，DEB，IPK和TAR）生成包。可以使用目标上的实用程序（如rpm或） 将这些程序包部署到目标上的正在运行的系统中ipk。

初始构建时间可能很长： 不幸的是，很长的初始构建时间是不可避免的，因为最初从头开始为大型Linux系统构建的大量软件包。但是，一旦初始构建完成，Yocto Project使用的共享状态（sstate）缓存机制将使系统不会重建自上次构建以来尚未“触及”的软件包。sstate机制显着减少了连续构建的时间。

四、Yocto项目相关的组件和工具

以下是Yocto项目开发图像和应用程序的工具：（开发工具）

CROPS:CROPS是一个利用Docher容器的开源跨平台开发框架 。CROPS提供了一个易于管理，可扩展的环境，允许为Windows，Linux和Mac OS X主机上的各种体系结构构建二进制文件。

devtool： 此命令行工具作为可扩展SDK（eSDK）的一部分，是其基础。可以使用devtool来帮助构建，测试和打包eSDK中的软件。可以使用该工具有选择地将构建的内容集成到OpenEmbedded构建系统构建的映像中。

devtool命令有许多子命令，可以添加，修改和升级配方。与OpenEmbedded构建系统一样，“recipes”代表其中的软件包devtool。使用devtool add，会自动创建配方。当使用devtool modify，使用指定的现有配方来确定获取源代码的位置以及如何修改。在这两种情况下，都会设置一个环境，以便在构建配方时使用受控制的源树，以便可以根据需要更改源。默认情况下，新配方和源都进入eSDK下的“workspace”目录。该devtool upgrade命令更新现有配方，以便可以为更新的源文件集构建它。

可扩展软件开发套件（eSDK）： eSDK提供了针对特定图像内容定制的交叉开发工具链和库。eSDK可以轻松地将新应用程序和库添加到映像，修改现有组件的源，测试目标硬件上的更改，以及集成到OpenEmbedded构建系统的其余部分。eSDK提供工具链，并辅以devtool 为Yocto项目环境量身定制的强大命令集。

有关eSDK的信息，可以参阅Yocto项目应用程序开发和可扩展软件工具包（esdk）手册。链接在此：https://www.yoctoproject.org/docs/2.5/sdk-manual/sdk-manual.html#sysroot

Eclipse ™IDE插件： 此插件可以使用方便的Eclipse集成开发环境（IDE），yocto允许在EclipseIDE中使用Yocto项目进行开发。可以在Eclipse中工作，将输出交叉编译，部署和执行到QEMU仿真以及实际目标硬件上。

该环境还支持性能增强工具，允许执行远程分析，跟踪，电源数据收集，延迟数据收集以及性能数据收集。（目前还没有用到，以后会用到的吧，原先用VxWorks的时候，就听到我师父他们在研究怎么使用类似的功能，留个问号 ‘?’）

启用插件后，标准Eclipse函数会自动使用跨工具链和目标系统库。可以使用任何这些库构建应用程序。

Toaster： Toaster是Yocto Project OpenEmbedded构建系统的Web界面。Toaster可以配置，运行和查看有关构建的信息。

以下列表包含使用Yocto项目帮助生产相关活动的工具：（制作工具）

Auto Upgrade Helper： 此实用程序与BitBake和OE-Core结合使用时，会自动为基于上游发布的新配方的配方生成配方升级。

Recipe Reporting System： 配方报告系统跟踪Yocto项目可用的配方版本。该系统的主要目的是帮助管理维护配方并提供项目的动态概述。 Open Index是一个索引OpenEmbedded-Core层的网站。http://layers.openembedded.org/layerindex/branch/master/layers/

Patchwork：最初由OzLabs发起的项目的一个分支。该项目是一个基于网络的跟踪系统，旨在简化将贡献纳入项目的过程。Yocto项目使用Patchwork作为组织工具来处理补丁，每个版本的补丁数量为数千。

Cross-Prelink：与在运行时执行此操作相比，预链接是预先计算动态链接器生成的加载地址和链接表的过程。提前执行此操作会在启动应用程序时提高性能，并减少许多应用程序共享的库的内存使用量。

Pseudo： Pseudo是fakeroot的YoctoProject实现， 用于在看似具有root权限的环境中运行命令。(我觉得大概功能也就相当于sudo吧)

在构建期间，可能需要执行需要系统管理员权限的操作。例如，文件所有权或权限可能需要定义。Pseudo是一种可以直接使用或通过环境变量使用的工具LD_PRELOAD。这两种方法都允许这些操作成功，就像系统管理员权限存在一样，即使它们不存在。

以下列表包含与OpenEmbedded构建系统关联的组件 ：

BitBake： BitBake是Yocto项目的核心组件，OpenEmbedded构建系统使用它来构建image。

BitBake是一个通用的任务执行引擎，它允许shell和Python任务在复杂的任务间依赖性约束下工作时高效并行地运行。简而言之，BitBake是一个构建引擎，它通过以特定格式编写的配方来执行，以执行任务集。

OpenEmbedded-Core： OpenEmbedded-Core（OE-Core）是OpenEmbedded派生系统（包括Yocto项目）使用的公共元数据层（即配方，类和相关文件）。Yocto项目和OpenEmbedded项目都维护OpenEmbedded-Core。

Yocto项目在整个Yocto项目源存储库参考系统（Poky）中集成了OE-Core Metadata。Yocto Project Version 1.0之后，Yocto Project和OpenEmbedded同意共同工作并共享一个共同的核心元数据集（OE-Core），其中包含以前在Poky中发现的大部分功能。这种合作实现了长期的OpenEmbedded目标，拥有更严格控制和质量保证的核心。

共享一组核心元数据使Poky成为OE-Core之上的集成层。Yocto项目结合了各种组件，如BitBake，OE-Core，脚本“集合”，以及其构建系统的文档。

要使用Yocto Project工具和组件，还要下载（clone）Poky并使用它来引导构建自己的发行版。

五、发行版的定制流程

开发人员指定体系结构，策略，补丁和配置详细信息。

构建系统从指定位置获取并下载源代码。构建系统支持标准方法，如tarball或源代码存储库系统，如Git。

下载源代码后，构建系统将源提取到应用修补程序的本地工作区，并运行配置和编译软件的常用步骤。

然后，构建系统将软件安装到临时暂存区域，在该区域中，您选择的二进制包格式（DEB，RPM或IPK）用于汇总软件。

在整个构建过程中运行不同的QA和健全性检查。

创建二进制文件后，构建系统会生成二进制包源，用于创建最终的根文件映像。

构建系统生成文件系统映像和用于并行应用程序开发的自定义可扩展SDK（eSDSK）。

构建的工作流程包含几个功能区域：

User Configuration： 可用于控制构建过程的元数据。

Metadata Layers： 提供软件，机器和发行版元数据的各种层。

Source Files： 上游版本，本地项目和SCM。

Build System： BitBake 控制下的进程 。该块扩展了BitBake如何获取源代码，应用补丁程序，完成编译，分析包生成的输出，创建和测试包，生成图像以及生成交叉开发工具。

Package Feeds： 包含输出包（RPM，DEB或IPK）的目录，随后用于构建系统生成的映像或软件开发工具包（SDK）。如果启用了运行时包管理，还可以使用Web服务器或其他方式复制和共享这些订阅源，以便于在运行时扩展或更新设备上的现有图像。

Images： 工作流程生成的图像。

Application Development SDK： 与图像一起生成或使用BitBake单独生成的交叉开发工具

  根据发行版的定制流程。最终目的，是要得到 uboot、kernel、rootfs这三个image；Yocto的目的也很简单，它要经过一级一级配置，逐步缩小配方，直至得到uboot、kernel、rootfs这三个image。每一级需要哪些配方，由该级对应的配置文件（conf/bb）决定。越上级的配置是越笼统的，越下级的配置越细致。如果下级的配置项相对于上级有补充或者冲突，则以下级的内容为准，可以认为下级会对上级进行“重写”。  

有关构建的路线和流程：对于整个发行版构建，虽然每一级的配方由（conf/bb）决定，但是每一级路线和方向的选择，是由我们最终bitbake的对象决定的，BitBake需要一些基本配置文件才能完成构建。这些文件是*.conf文件。最低限度必需的文件作为示例文件驻留 在build/conf。比如我们最终bitbake avi-image-core，我们想要获得rootfs.img，那么：

第一步Poky就会从local.conf开始，一路向下，一级一级配置，直到配置到和rootfs有关的那一堆bb，最终形成完整完全的配方
然后获取配方需要的资源，比如各种软件包，比如kernel的源码
最后把所有的资源编译出我们需要的镜像

在conf/local.conf文件提供了许多定义构建环境的基本变量。

Target Machine Selection（目标机器选择）: 由 MACHINE 控制.

Download Directory（下载目录）: 由 DL_DIR 控制.

Shared State Directory（共享状态目录）:由 SSTATE_DIR 控制.

Build Output（构建输出）: 由 TMPDIR 控制.

Distribution Policy（分配策略）: 由 DISTRO 控制 .

Packaging Format（打包格式）: 由 PACKAGE_CLASSES 控制.

SDK Target Architecture（SDK目标架构）: 由 SDKMACHINE 控制.

Extra Image Packages（额外的image包）: 由 EXTRA_IMAGE_FEATURES 控制.

bblayers.conf文件告诉BitBake在构建期间要考虑哪些层。默认情况下，此文件中列出的图层包含构建系统最低限度需要的图层。但是，必须手动添加已创建的任何自定义图层。

  bitbake是一个强大的工具，比如说我们一次性编译所有内容，内核、文件系统等，我们可以bitbake core-image-minimal ;或者我们要单独编译内核呢？有这么一个命令：bitbake linux-xlnx -C compile，生成内核镜像和设备树文件；或者单独编译u-boot，bitbake -c compile -f u-boot-imx；bitbake -c deploy -f u-boot-imx（指定编译生成的u-boot镜像到deploy）；或者单独编译交叉开发工具链，可扩展SDK（ bitbake -c populate_sdk_ext imagename）或标准SDK（例如 bitbake -c populate_sdk imagename）。。。其实这个bitbake的功能还挺多的，可以有时间单独写一篇关于介绍bitbake的使用。