Yocto1构建嵌入式Linux系统
Posted 码农编程录
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Yocto1构建嵌入式Linux系统相关的知识，希望对你有一定的参考价值。
文章目录
- 1.获取Yocto软件源码
- 2.初始化Yocto构建目录
- 3.构建嵌入式Linux系统
- 4.Yocto开发环境
1.获取Yocto软件源码
利用bitbake工具编译uboot，linux内核源码，根文件系统，将这三者组成一个完成的嵌入式发行版（distro），主要目的在硬件平台上运行linux系统，编译多用ubuntu，sudo apt-get install openssh-server（安装ssh）。Repo管理所有git仓库，将多个git组合在一起，形成一个完整的大版本。https://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#detailed-supported-distros。
mkdir /home//Linux/Yocto/fsl-release-yocto进入，curl http://commondatastorage.googleapis.com/git-repo-downloads/repo > ./repo。由于网络原因，通过curl下载repo工具往往比较慢。可以通过清华的源进行下载：curl https://mirrors.tuna.tsinghua.edu.cn/git/git-repo -o repo （多出一个repo文件不可执行），chmod a+x repo。
Yocto项目采用repo管理各个git库的方式进行管理。因此，除了使用repo工具外，还需要使用到Git。使用Git前，需要设置Git的用户名和密码，在fsl-release-yocto文件夹里执行git config设置用户名和邮箱。切换至Yocto工作路径/home/Linux/Yocto/fsl-release-yocto，然后使用如下repo命令，获取Yocto项目（克隆NXP官方fsl-arm-yocto-bsp.git项目的imx-linux-zeus分支）： ./repo init -u https://source.codeaurora.org/external/imx/imx-manifest -b imx-linux-zeus -m imx-5.4.47-2.2.0.xml。
注意：由于国内的原因，直接运行上面repo init命令时，会出现fatal: Cannot get https://gerrit.googlesource.com/git-repo/clone.bundle的错误，这是因为repo运行时，会去google服务器请求最新版本，解决方式是在本地环境变量中指定repo服务器地址，可以使用清华的镜像源进行更新，即将如下内容复制到你的~/.bashrc里：export REPO_URL=“https://mirrors.tuna.tsinghua.edu.cn/git/git-repo/” 。并重启Ubuntu即可。
输入上述命令./repo init -u https://source.codeaurora.org/external/imx/imx-manifest -b imx-linux-zeus -m imx-5.4.47-2.2.0.xml后，会提示/usr/bin/env: ‘python’: No such file or directory，这是因为Ubuntu20.04中已经移除了python2的原因，直接使用的是Python3。因此，使用命令： sudo ln -s /usr/bin/python3 /usr/bin/python，将python连接为Python3即可。再次输入./repo....xml ，克隆完成后，输入几次y确认一些信息即可。通过ls -a命令，可以看到在fsl-release-yocto路径下有.repo隐藏目录，进入.repo：
可以看到，在.repo目录下的manifests中的文件，定义了imx-linux-zeus分支下使用到的哪些Git库。最后在fsl-release-yocto路径下，运行./repo sync命令，获取Yocto项目（repo将会从网上下载很多东西）。需要注意的是，在./repo sync获取Yocto源码的过程中，由于网速等原因，会出现下载失败或下载“卡死”的情况，此时，可按Ctrl+c终止，再次输入./repo sync命令，即可继续从断点处下载。
获取Yocto项目源码成功后，会在Yocto工作路径/home/jason/Linux/Yocto/fsl-release-yocto路径下得到imx-setup-release.sh、setup-environment、sources等文件。其中：
imx-setup-release.sh：该脚本用于初始化Yocto构建嵌入式Linux系统工作环境。
setup-environment：该脚本根据运行imx-setup-release.sh脚本时输入的参数，设置Yocto工作环境。
sources文件夹：在该文件夹下存放了很多文件、源码以及编译工具，用于构建嵌入式Linux系统。
meta-bsp - meta-fsl-arm, poky, meta-openembedded层的一些更新软件。
meta-sdk - meta-freescale-distros以及发行版的一些更新软件。
meta-ml：机器学习相关的软件。
base：该文件夹下主要存放了bblayers.conf和setup-environment，构建Yocto工作环境时用到。
meta-clang：C语言家族前端和LLVM编译器后端。
meta-freescalse-3rdparty：第三方板卡支持软件。
meta-browser：提供了几种浏览器，如gnome、mozilla。
meta-freescale：提供了一些基于Freescale ARM官方参考板的基础支持软件。
meta-imx：
meta-freescalse-distro：官方提供的一些嵌入式Linux发行版。
meta-nxp-demo-experience：NXP官方提供的一些demo。
meta-python2： python2相关的软件。
meta-rust：rust相关的软件。
meta-openembedded：OE内核的一些集合，定义了构建Yocto使用到的一些工具软件。
meta-qt5：QT5相关的软件。
meta-timesys：提供Vigiles工具来查看和通知BSP漏洞。
poky：Yocto的基础发行版，在此版本基础上进行构建自己的嵌入式Linux发行版。
需要注意的是，对于i.MX板卡的配置，主要是在meta-imx以及meta-freescale中定义的，包括Linux内核、U-Boot以及一些板级硬件配置信息。
2.初始化Yocto构建目录
2.1 imx-setup-release.sh脚本运行
通过repo获取了Yocto项目源码（NXP官方的index: imx-manifest.git项目的imx-linux-zeus分支）之后，还需要初始化Yocto构建目录，用于Yocto构建嵌入式Linux系统的工作环境（实际上是创建一些文件夹、初始化一些变量值，得到的配置文件，用于构建特定的嵌入式Linux发行版本）。 在repo获取的Yocto项目源码路径(/home/jason/Linux/Yocto/fsl-release-yocto)下，Freescales提供了imx-setup-release.sh脚本。该脚本用于初始化Yocto构建目录，如下方法执行imx-setup-release.sh脚本（先使用chmod 777分配可执行权限）：
DISTRO=<distro name> MACHINE=<machine name> source imx-setup-release.sh -b <build dir>
DISTRO=fsl-imx-fb MACHINE=imx6ull14x14evk source imx-setup-release.sh -b build
// 创建了一个基于imx6ull14x14evk硬件平台，嵌入式Linux系统发行版为fsl-imx-fb的Yocto构建环境，位于/home/jason/Linux/Yocto/fsl-release-yocto/build路径下
完成了Yocto构建目录的初始化，该脚本运行结束后，自动生成build文件夹，并自动切换至build路径，后续系统的构建过程就是在该build文件夹下完成的。同时在build文件夹下，还会生成一个conf文件夹： 该conf文件夹中有两个重要的文件：bblayers.conf和local.conf两个配置文件，后面将会详细解析:
<build dir>/conf/bblayer.conf：该配置文件定义了构建嵌入式Linux系统发行版所需要使用的metalayers。
<build dir>/conf/local.conf：该配置文件定义了MACHINE和DISTRO的配置项。
2.2 imx-setup-release.sh脚本解析
imx-setup-release.sh脚本运行时，需要输入3个主要参数：
DISTRO=fsl-imx-fb
MACHINE=imx6ull14x14evk
-b build
总体来说，imx-setup-release.sh脚本通过这3个参数来确定了构建环境，其中，-b build生成了一个build文件夹，用于存放Yocto在构建系统过程中产生的临时文件、构建日志以及最终生成的安装文件等。同时Yocto根据DISTRO（发行版本）和MACHINE（硬件平台）这两个参数，找到相对应的配置文件（.conf），这些配置文件定义了所需构建的嵌入式Linux系统的功能和状态。
在imx-setup-release.sh脚本中，有如下几个地方需要了解： 第22行，设置了变量PROGNAME为“setup-environment”，在imx-setup-release.sh脚本所在的路径下，有一个名叫setup-environment的shell脚本，在imx-setup-release.sh脚本中，会调用setup-environment脚本。
第59行，通过脚本参数-b build，设置变量BUILD_DIR为build（-b build传入build），用于创建工作目录。
第119行，通过脚本参数 DISTRO=fsl-imx-fb，设置变量DISTRO为fsl-imx-fb，用于设置嵌入式Linux系统的发型版本设置，在移植部分会详细讲解DISTRO。
第156行，通过DISTRO和MACHINE两个参数，调用PROGNAME脚本即setup-environment脚本。关于setup-environment脚本，下一小节中会进行描述。
第169~195行，比较重要的部分，将使用到的Layers写入build/conf/bblayers.conf文件中，用于设置构建嵌入式Linux系统所使用到的Layers。关于Layers的概念，后续章节会详细描述。
2.2.1 setup-environment脚本解析
在imx-setup-release.sh脚本中，会通过DISTRO=$FSLDISTRO MACHINE=$MACHINE . ./$PROGNAME $BUILD_DIR调用setup-environment脚本。输入 ./setup-environment -h命令，查看setup-environment脚本帮助信息，该信息列出了Yocto路径下支持的MACHINE。
在setup-environmet脚本中，第92行，通过MACHINE变量值找到相应的.conf文件，该.conf文件用来配置嵌入式Linux发行版。在/home//Linux/Yocto/fsl-release-yocto/sources路径下，有很多的meta-xxx文件夹，在这些文件夹中有各种不同的machine和distro文件夹，在这两个文件下下面有不同的配置文件。通过imx-setup-release.sh脚本，就能确定所使用的是哪个machine、distro文件夹里的配置文件，用于配置所需构建的嵌入式Linux发行版。
总的来说，imx-setup-release.sh脚本，主要实现了以下三个重要功能，用于配置所需构建的嵌入式Linux系统的发行版：
1.创建Yocto构建工作环境，新建build文件夹并进入，还创建了conf文件夹
2.将layers、machine、distro等信息写入配置文件：
<build dir>/conf/bblayer.conf：该配置文件定义了构建嵌入式Linux系统发行版所需要使用的metalayers。
<build dir>/conf/local.conf：该配置文件定义了MACHINE和DISTRO的配置项。
3.根据DISTRO和MACHINE这两个参数，找到相应路径下的配置文件(.conf)。这些配置文件定义了需要构建的嵌入式Linux的功能和状态。
DISTRO= fsl-imx-fb ：sources/meta-imx/meta-sdk/conf/distro/fls-imx-fb.conf 在该文件中定义了一些变量，用于配置嵌入式Linux发行版
MACHINE= imx6ull14x14evk ：sources/meta-imx/meta-imx/meta-bsp/conf/machine/imx6ull14evk.conf 在该文件中定义了一些变量，用于配置嵌入式Linux运行的硬件平台。
后续在根据不同的硬件板卡及软件需求定义相应的嵌入式Linux发行版时，会详细的描述如何修改imx-setup-release.sh脚本，以及相关的MACHINE、DISTRO对应的.conf文件的修改。
3.构建嵌入式Linux系统
通过NXP提供的imx-setup-release.sh脚本，创建了一个工作空间后，就可以在该工作空间(build)文件夹下构建嵌入式Linux系统镜像文件，用于烧录到最终的开发板中。
3.1 BitBake构建系统
Yocto项目中，采用的是BitBake工具来构建嵌入式Linux系统的。通过repo获取了Yocto项目的同时，也一起获取BitBake工具，直接使用即可。使用BitBake的最主要目的是生成一些安装包、内核、SDK以及一个完整的嵌入式Linux发行版（包括：U-Boot、Kernel、Rootfs、DeviceTree）。这些安装包或目标文件就构成了一个完整的嵌入式Linux发行版，可通过Freescale提供的工具，将其生成一个SD卡镜像文件，用于烧写至开发板中。
运行imx-setup-release.sh脚本后，会自动生成一个build文件夹，进入该文件夹，运行bitbake命令：bitbake imx-image-multimedia
BitBake命令格式为：bitbake target，其中Freescale提供了几个target镜像文件，可供选择，需要注意的是，镜像文件支持的功能越多，（根）文件系统就越大： 实际yocto提供了poky项目，在这基础上构建了嵌入式系统，增加了额外功能，基于poky构建提供的镜像实际都是一些基础东西，实际工程中不会用到。
/home/Linux/Yocto/fsl-release-yocto ：source imx-setup-release.sh也可进入build目录，/build/bitbake -h
这里选的是imx-image-multimedia。实际上，通过运行bitbake imx-image-multimedia命令，bitbake会找到/sources/meta-imx/meta-sdk/recipes-fsl/images路径下的imx-image-multimedia.bb文件，根据imx-image-multimedia.bb文件中的配置进行系统的构建。同时在/sources/meta-imx/meta-sdk/recipes-fsl/images路径下还可以看到fsl-image-core.bb等文件，与上表中提到的镜像文件相对应。运行bitbake imx-image-multimedia命令后，就开始使用bitbake工具构建嵌入式Linux系统： 将构建整个嵌入式系统分成一个个task进行的，这些task主要根据bb文件下配置产生不同task编译来构建不通功能
在build文件夹下，运行bitbake命令“bitbake imx-image-multimedia” 后：开始构建系统。系统构建完成后，会在~/Linux/yocto/fsl-release-yocto/build/tmp/deploy/images/imx6ull14x14evk路径下输出manifest文件， 这个文件里包含了对应文件系统中已安装的软件包。同时该路径下还生成了一些其他文件：
3.2 BitBake构建系统过程简要解析
3.2.1 解析Metadata基本配置
BitBake构建的第一步是解析Metedata基本配置文件，这些基本配置文件确定了所构建嵌入式Linux系统发行版的一些功能及特征。在了解解析Metadata基本配置之前，需要先了解几个概念。
Metadata
Yocto由一些Metadata组成，具体来说，通过repo获取Yocto项目后，在source目录下有一些文件夹，这些文件夹就是一个个的metadata。如下图所示，在这些文件夹中包含了许多的文件，用于构建嵌入式Linux系统。
从上图可以看出，在sources目录下有一些meta开头的meta-xxx文件夹，但是，针对不同的嵌入式Linux发行版的需求，需要使用不同的metadata，有可能需要增加新的metadata，也有可能减少一些metadata。对于使用那些metadata（meta-xxx文件夹）是由在通过imx-setup-release.sh脚本初始化构建目录时确定的，在使用imx-setup-release.sh脚本时，会创建一个build文件夹，在build/conf路径下，生成了一个bblayers.conf的配置文件，BitBake工具会根据该bblayers.conf文件中的定义，确定使用那些metadata用于构建嵌入式Linux发行版，例如：
如下oe-setup-builddir就是imx-setup-release.sh，这脚本就会把metadate用到的哪些内容echo到bblayers.conf，写进去后就用bitbake根据bblays.conf文件找到相对应使用的metadata去构建系统。
recipes、conf、classes
在Metadata中，有许多文件存放于source/meta-xxx文件夹下，用于构建嵌入式Linux系统发行版。如下图所示：
classes：该文件夹下的.bbclass文件，包含了一些在不同的metadata之间共享的信息，以及编译信息的抽象，例如：如何编译Linux内核。
conf：该conf文件夹下的layer.conf文件定义了该metadata中使用的哪些.bb、.bbappend文件等参与构建嵌入式Linux系统。
recipes-xxx：该文件夹中有许多的.bb或.bbappend文件，这些文件定义了构建嵌入式Linux系统需要的软件包或源码等，主要包括：软件包的基本信息：作者、主页、License等。
版本信息。
依赖文件。
从哪下载以及如何下载软件包。
软件包补丁信息:是否需要补丁、补丁下载地址及方式等。
如何配置、如何编译软件包、安装位置等。
备注：可以通过BitBake提供的命令查看当前使用的配置文件和class文件：
bitbake -e > mybb.log
查看mybb.log文件即可。
3.2.2 解析Recipes
BitBake解析了Metadata基本配置之后，BitBake根据build/conf/bblayers.conf中定义的所使能的layers（meta-xxx），找到对应meta-xxx文件夹下的conf文件夹下的layer.conf文件，在该layer.conf文件中，通过BBFILES和BBPATH指定了当前layer下所使用的Recipes，说白了就是通过BBPATH告诉BitBake在哪些路径下，找到哪些.bb和.bbappend文件（即BBFILES），通过这些BBFILES告诉BitBake，会使用哪些软件包或源码构建嵌入式Linux发行版。
通常来说，bbFILES以PN（package name）加PV（package version）命名，如：something_1.2.3.bb，PN=something，PV= 1.2.3。关于bbFILES将是构建嵌入式Linux系统的关键知识点，在后面移植过程中，会详细的讲解。
当recipe解析完成后，会生成一个“任务列表”，接下来就是BitBake根据“任务列表”（BBFILES中定义的内容数据等）进行系统的构建。实际上，在构建系统过程中，就是以一个个task的形式进行的。
3.2.3 Providers供应者
在解析了Recipes之后，将会生成一个“任务列表”，BitBake根据该“任务列表”开始编译目标文件。BitBake会查找每一个Recipes对应的PROVIDES列表（哪个厂家提供的哪个模块来参与构建）。例如，假设一个名为keyboard_1.0.bb的recipe，在keyboard_1.0.bb中包含了PROVIDES += “fullkeyboard”，那么对于recipes的PROVIDES列表，keyboard_1.0.bb是隐式的定义，而fullkeyboard.bb是显示的定义，该recipe中的功能将由fullkeyboard.bb确定。
3.2.4 Preferences优先级
对于确定所使用的目标recipe，PROVIDES列表仅仅是其中的一部分。由于目标recipe有可能会有多个PROVIDES，BitBake通过识别PROVIDES的优先级确定最终使用的provides。 例如，对于virtual/kernel来说，通常会有多个providers，通过类似下面的配置选择最优的providers：PREFERRED_PROVIDER_virtual/kernel = “linux-yocto”，此外还存在一种情况，同一个providers有多个版本的recipe文件。这时，一般情况下BitBake将会选择使用最新版本的的recipe文件，除非有其他特殊的设置。例如：
存在一个a_1.1.bb文件，对于该文件其PN为“a”，PV为“1.1”；同时，存在另外一个a_1.2.bb文件，那么BitBake将默认采用a_1.2.bb构建系统。然后，如果在.conf文件中定义了PREFERRED_PROVIDER_a = “1.1”，那么BitBake将会采用a_1.1.bb文件构建系统。
3.2.5 Dependencies（依赖关系）
BitBake构建系统时，都会分为多个任务执行，例如：fetch, unpack, patch, configure以及compile 。对于构建系统所使用的主机是多核的情况，BitBake内部会对各任务的依赖关系进行处理，不需要用户干预。
3.2.6 任务列表
BitBake通过providers和dependencies计算出需要运行的任务及各任务之间的顺序。BitBake构建任务的运行受限于bb_NUMBER_THREADS变量的值，而该值又由构建系统所使用的主机的内核数量确定。 只要有满足依赖关系以及准备好的任务需要运行，并且当前运行任务的数量没有超过线程的阈值。BitBake就会继续派生线程来运行该任务。
3.2.7 执行任务
BitBake通过运行$T/run.do_taskname.pid脚本来执行任务。一般来说，构建系统的任务管理是由BitBake自己管理的，不需要用户进行干预。
3.2.8 校验（签名）
校验和是任务输入的唯一签名。 任务的签名可用于确定任务是否需要运行。 因为是任务输入中的更改触发了运行任务，所以BitBake需要检测给定任务的所有输入。通常来说，这部分工作也是由BitBake自己完成的，不需要用户进行干预。
4.Yocto开发环境
4.1 Yocto系统组成
User Configuration：用户配置信息，用于控制构建过程中使用到的Metadata。
Metadata Layers：Metadata Layers中包含许多Recipes，用于设置需要使用哪些软件包、源码，以及这些软件包、源码的配置、编译、安装方式。
Source Files：构建系统所使用到的软件包、源码，这些软件包、源码有多种获取途径，DL_DIR变量。
Build System：主要指BitBake获取源码、打补丁、编译、安装、生成目标文件的过程。
Images：构建嵌入式Linux系统生成的目标文件，用于最终的嵌入式Linux系统。
application Development SDK：Yocto还可以用于构建交叉编译工具。
4.1.1 User Configuration
build/conf路径下的bblayers.conf和local.conf两个文件（就是User Configuration）都是有imx-setup-release.sh脚本生成的。BitBake在构建系统时会使用到这两个文件中的变量，但是如果需要更改配置，是通过imx-setup-release.sh脚本中修改，不建议直接修改这两个文件。
bblayers.conf文件确定了BitBake将使用哪些Metadata（layers）构建系统，主要由变量BBLAYERS确定。例如，在imx-setup-release.sh脚本中有如下定义：
local.conf提供了一些基本的变量，定义了构建环境，如：MACHINE、DISTRO、DL_DIR等，这些变量也是通过imx-setup-release.sh脚本确定的。
MACHINE：目标平台选取，例如：imx6ull14x14evk。
DISTRO：基于目标平台确定的嵌入式Linux发行版本。
PACKAGE_CLASSES：定义生成的目标文件格式类型，例如：PACKAGE_CLASSES ?= “package_rpm package_deb package_ipk package_tar” 等。
BB_DISKMON_DIRS：该变量定义了工作路径下各文件夹的大小。
DL_DIR：定义了下载文件的存放路径。BitBake在构建系统过程中，需要下载各种软件源码、工具软件等，这些下载的软件或者软件源码就存放在DL_DIR变量定义的路径下，例如：DL_DIR ?= "$BSPDIR/downloads/"所对应的就是/Linux/Yocto/fsl-release-yocto/downloads。
4.1.2 Metadata
Metadata元数据，是BitBake构建嵌入式Linux系统过程中所使用的最基础的数据。Metadata一定程度上来说就是指的Layers，两个概念在一定的场景下表示的是同一个含义。在build/conf/bblayers.conf文件中定义了所使用的Layers，对应的就是使用Metadata下的文件。Metadata具体表现为一个个以meta-xxx的文件夹，位于在sources目录下，在meta-xxx文件夹下主要有三种类型的文件夹：classes、conf和recipes。这三个文件夹下分别存储不同的文件：
classes：classes文件夹下主要存放的是.bbclass文件，.bbclass文件保存了通用的函数或变量，使其能够在其他recipes中通过inherit关键字引用。
conf：conf文件夹下主要存放layer.conf、conf/distro/distro.conf以及distro.conf中包含的inc文件。这些文件主要用于定义当前layer的一些基本信息。如：使用哪些.bb文件等。
recipes：meta-xxx文件夹下有许多的recipes文件夹，recipes文件夹下主要存放.bb、.bbapped文件，.bb、.bbapped主要定义了构建系统所使用到的软件包、源代码、补丁文件以及这些软件包、源代码的配置、编译、安装方法。
如下所使用软件如内核文件从哪个地方SRC_URI获取并参与系统构建。do_install()告诉linux内核去安装在哪些位置，把相应头文件安装在哪个地方去。
4.1.3 Sources
Yocto在构建系统image文件时，需要使用到一些第三方软件包或源码等，这些软件包或源码就叫做sources files，例如：bluez-5.37.tar.xz、connman-1.31.tar.xz等。通常sources files有三种来源：Upstream Project Release、Local Projects、SCMs。一般来说，对于参与系统构建过程中一些稳定发布版的第三方软件，通常采用压缩包（tarballs）的方式。对于需要在构建系统过程中不断修改调试的第三方软件，通常采用通过SCM（例如git）管理软件源码的方式，参与到系统构建过程中。
在每个recipe中存在一个SRC_URI变量，该变量定义了recipe所使用到的软件包或源码地址。BitBake就是通过SRC_URI所指向的地址获取相应的软件包或源码的。 需要注意的是，Yocto提供了DL_DIR变量，用于指定下载的source files存放地址，构建系统搜索source files时，BitBake首先搜索download路径下是否有相应的source files，如果没有，再在通过其他路径搜索。通过这种机制，可以减少了由于网络原因导致的构建时间过长。
Upstream project releases：其他项目软件包通常以存档文件的方式存在(tarball、zip文件)。Local Projects：本地提供的而一些软件包。SCM（Source Control Manageers）：通过Git等版本管理工具获取的软件包等。当采用SCM获取源码时，BitBake在构建系统过程中的do_fetch任务时，将根据recipe中定义的SRC_URI变量以及SRCREV变量，通过SCM工具克隆或Check Out源码参与构建系统。
4.1.4 Package Feeds
生成的中间文件类型是由build/local.conf文件中的PACKAGE_CLASSES变量确定的，如：ipk、rpm等。最终BitBake会将这些中间文件生成最终需要使用的image文件，其中有几个文件夹下的内容是需要了解下：DEPLOY_DIR：指的是build/tmp/deploy，在该路径下存放最终生成的嵌入式Linux镜像文件。 bitbake是会调用do_package_write打包生成最终img文件。
4.1.5 BitBake
BitBake（蓝色）是构建系统的工具。BitBake根据用户的配置信息，自动的从不同的地方获取软件包或源文件，将其按照一定的规则构建出最终使用的Image文件（嵌入式Linux发行版）。BitBake的工作过程中，是以一个个task的形式存在的，主要包括：Source Fetching、Patching、Configuration andCompilation、Package Splitting、Image Generation、SDK Generation（可选）。
Source Fetching：BitBake工作的第一步就是获取源文件。BitBake会根据Recipe中定义的SRC_URI找到相应的源文件，将其下载并解压。该过程主要在build/tmp/work目录下完成。
TMPDIR：构建系统过程中使用到的临时文件存放的地方，通常来说，就是build/tmp路径
PACKAGE_ARCH：构建系统所使用的架构，如：cortexa7hf-neon、x86_64等
TARGET_OS：目标操作系统，如：linux-gnueabi、linux等
PN：安装包名称
PV：安装包版本号
PR：安装包修正版本号
Patching：一旦获取并解压缩了源代码，BitBake就会定位补丁文件（如果有）并将它们应用到源文件中，BitBake通过SRC_URI变量找到补丁文件（.patch或.diff）。BitBake按照查找补丁的顺序为单个Recipe查找并应用多个补丁。
Configuration and Compilation ：修补源代码后，BitBake将执行配置和编译源代码的任务，主要包括三个Tasks：这三个Task所对应的方法，在对应的Recipe中的.bb或.bbappend文件中都可以redifine：
do _configure：不同的source code配置不同，BitBake会根据recipe中.bb或.bbappend文件中定义的配置方法进行配置。当然也支持使用autotools。
do_compile：配置完成后，就开始执行编译过程。
do_install：编译完成后，开始执行安装过程。将安装在image路径下。
Package Splitting：在配置并编译了源代码之后，OpenEmbedded构建系统将分析结果并将输出拆分为软件包。分析过程涉及以下各项：拆分出调试信息，查看包之间的共享库依赖关系，以及包之间的关系。do_packagedata任务根据分析结果创建软件包，以便OpenEmbedded可以生成最终软件包。
Image Generation：拆分软件包并将其存储在Package Feeds区域（也就是bulid/tmp路径下），OpenEmbedded将使用BitBake生成根文件系统镜像。
Image文件生成过程包括多个阶段，并取决于多个任务和变量。do_rootfs任务创建Image文件所使用的根文件系统（文件和目录结构），do_rootfs任务使用几个关键变量来确定创建实际安装软件包列表：
IMAGE_INSTALL：列出要安装的基本程序包。
PACKAGE_EXCLUDE：指定不应安装的软件包。
IMAGE_FEATURES：指定要包含在image文件中的功能。 这些功能大多数都映射到其他软件包进行安装。
PACKAGE_CLASSES：指定要使用的软件包，并且确定软件包在Package Feeds中的位置。
IMAGE_LINGUAS：确定要安装的语言支持包。
PACKAGE_INSTALL：最终安装到Image文件中的软件包列表。
BitBake通过变量IMAGE_ROOTFS指向构造的根文件系统的位置，并根据PACKAGE_INSTALL变量指定的最终安装的软件包列表，从而创建最终的根文件系统。在生成的根文件系统目录下，manifest文件（.manifest）列出了根文件系统中所安装的软件。
SDK Generation：OpenEmbedded构建系统使用BitBake生成两个软件开发工具包（SDK）安装程序脚本，包括标准的SDK和可扩展的SDK。可以通过生成的SDK安装脚本，安装相应的SDK。
4.1.6 Images
OpenEmbedded构建系统生成的image是可以在目标设备上启动的BootLoader、Linux Kernel、Device Tree、根文件系统：
生成的文件位于：build/tmp/deploy/images/machine/ 文件夹下。主要包含：kernel-image（内核文件）。root-filesystem-image（根文件系统文件）。BootLoader（boot文件）。
4.1.7 application Development SDK
构建系统的同时，还可以构建应用软件开发SDK。根据是否构建标准SDK（例如，bitbake -c populate_sdk）或可扩展的SDK（例如bitbake -c populate_sdk_ext映像名称），SDK生成过程会有所不同。
输出的形式是自解压SDK安装程序（ .sh）。当运行SDK安装程序（ .sh）时将安装该SDK。该SDK由交叉开发工具链，库、头文件以及一个SDK环境设置脚本组成。 运行此安装程序基本上可以进行设置交叉编译环境。 SDK对应的交叉编译环境主要运行在主机上，用于编译目标文件。 另一方面，库和头文件视为“目标”部分，是为目标硬件平台构建的，在目标硬件平台上运行时，需要将这些库和头文件拷贝至目前硬件平台的系统中。
4.2 Yocto开发过程
Yocto的开发一般包括：创建Layers、添加新的软件包、扩展或定制系统镜像以及移植到新的硬件平台（增加新的MACHINE）等。
4.2.1 创建Layers
Yocto使用的是OpenEmbeded来构建系统，并且支持以Metadata的形式来组织管理构建系统所使用的软件包、源代码、配置信息等。Metadata一定程度上可以理解为Layers，实际上就是一个个的文件夹（这些文件夹通常以meta-xxx的形式命名）。采用Layers的方式管理源数据，有利于保持模块化的设计方式，一个Layer包含了一些特定功能所需要的源数据，各Layer之间互不干扰，当所构建的系统需要的功能发生变化时，只需要修改该功能对应的Layer即可，保持了功能的独立性及模块化设计。
创建Layers的步骤
1.查看已存在的Layers：通常来说，http://layers.openembedded.org/layerindex/layers/ 列出了目前已经存在的公共的开放的Metadata，当需要创建新的Layer时，可以先在该网站上查看下是否已经有了现成的Metadata可供使用，如果有，直接使用即可。如果没有，就需要自己新创建。
2.创建一个文件夹，用来存放Layer里的数据，通常将该文件夹命名为meta-xxx。例如：meta-mylayer、meta-GUI_XYZ、meta-mymachine等。
3.创建Layer配置文件。在新创建的Layer文件夹下（例如：meta-mylayer）创建conf/layer.conf 文件，该layer.conf文件基本框架如下：
# 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 += "mylayer"
BBFILE_PATTERN_mylayer = "^$LAYERDIR/"
BBFILE_PRIORITY_mylayer = "5"
LAYERVERSION_mylayer = "3
. BBPATH：将新增加的Layer路径增加至全局变量bbPATH中，BitBake在构建系统时，会根据该变量找到相对应的Layer。
. BBFILES：将新增加的Layer中的Recipe文件（即：.bb或.bbappend文件）增加至全局变量bbFILES中，BitBake在构建系统时，会根据该变量找到对应的recipe文件。
. BBFILE_COLLECTIONS：将layer名字追加到bbFILE_COLLECTIONS变量，即将Layer的文件夹名字meta-xxx中的xxx赋值给bbFILE_COLLECTIONS 即可。
. BBFILE_PATTERN：bbFILE_PATTERN变量为正则表达式，用来匹配bbFILES所在的层，按照基本框架修改即可。
. BBFILE_PRIORITY：Layer的优先级。当不同的Layer中定义了相同的recipe时，将按照bbFILE_PRIORITY所对应的高优先级使用相对应的recipe文件。
. LAYERVERSION：定义了Layer的版本信息。
4.增加内容。根据Layer的类型，有的Layer会增加machine和distro配置，因此，需要在Layer下的conf/machine/文件中添加机器配置，在该层的conf/distro/文件中添加发行版配置。
创建Layers时的一些原则
考虑到创建的Layers易于维护，且不会影响到其他Layer，创建Layers时，应该遵循一些原则：避免覆盖其他Layer中的recipe。也就是说，尽量不要将其他Layer中的整个recipe复制到新创建的Layer中，并对其进行修改。而是采用追加文件.bbappend文件的方式，覆盖仅需要修改的部分。
避免重复包含文件。对于需要包含文件的recipe，使用.bbappend文件或者使用相对于原始Layer的相对路径在进行应用，例如：使用require recipes-core/package/file.inc代替require file.inc。
使能Layer
创建了新的Layer需要使能之后才能参与到系统的构建过程中。在build/conf/bblayers.conf中定义了参与构建系统使用到的Layers。对于iMX6ULL，Freescale官方提供了imx-setup-release.sh脚本用于修改build/conf/bblayers.conf文件，在初始化Yocto构建目录时，调用imx-setup-release.sh脚本。因此，修改imx-setup-release.sh脚本即可，修改方式如下：
新增加的echo "bbLAYERS += " $BSPDIR/sources/meta-bird-imx6ull “” >> $BUILD_DIR/conf/bblayers.conf就是将build/conf/bblayers.conf中的bbLAYERS变量增加新增的meta-bird-imx6ull。
使用.bbappend文件
用于将Metadata附加到其他recipes的recipes称为BitBake附加文件。 BitBake附加文件使用.bbappend文件类型后缀，而要附加Metadata的相应的recipes则使用.bb文件类型后缀。通过.bbappend文件，可以使得创建的Layer在不拷贝其他recipe到新建的Layer中的情况下，以附加或改写的方式改变其他Layer中的内容。
直观来看，就是新建的Layer中的.bbappend文件，与需要修改或附件额外内容的.bb文件处于不同的Layer。 附件文件（.bbappend）必须和对应的recipes（.bb）文件名（或文件名与版本号）一致。在构建系统过程中，当BitBake检测到某个.bbappend文件没有对应的.bb文件时，将会报错。
设置Layer优先级
每一个Layer都分配了一个优先级。当在不同的Layer中，出现了同样的recipe时，Layer中分配的优先级的值越大，将优先使用该Layer中的recipe。优先级的值同样会影响到.bbappend文件。如BBFILE_PRIORITY_mylayer = “5”。 需要注意的是：有可能会出现低版本但是拥有高优先级的recipe优先执行的情况。
Layers管理
BitBake提供了Layer管理工具，用来查看Layers的一些基本信息。使用方式如下： $ bitbake-layers command [arguments]
可以使用的命令如下:
help：帮助命令。
show-layers: 显示当前配置的Layer。
show-recipes: 显示可用的recipes以及recipes提供的layers。
show-overlayed: 显示覆盖的recipes。高优先级Layer中的recipe将覆盖其他低优先级Layer中相同的recipes。
show-appends: 显示.bbappend文件，以及对应的recipe文件。
show-cross-depends: 显示不同Layer中recipes的依赖关系。
增加COPYING.MIT和README文件
在Layer中，增加相应的COPYING.MIT文件和README文件是比较推荐的做法。
4.2.2 自定义系统镜像文件
实际工程应用中，需要根据不同的需求定制化系统。该小节概要性的描述了定制化系统的几种方法，先对定制化系统的方法有个整体性的认识，后续章节会对定制化系统的详细步骤进行讲解。Yocto提供了几种定制化系统的方法，可以根据实际应用场景选择不同的方法。
通过local.conf增加软件包
通过直接修改build/conf路径下的local.conf配置文件增加软件包是最简单的定制系统的方法之一。同时由于是直接修改local.conf文件，这种方法一般来说仅适用于在系统image文件中增加软件包。当使用local.conf文件中的变量增加软件包时，需要注意的是，增加的软件包对于所有的系统image文件都有效。
例如在local.conf文件中增加如下语句，将在生成的系统image文件中安装“strace”软件：IMAGE_INSTALL_append = " strace" （注：等号与软件包名“strace”之间的空格是必须的）。
同样的，修改local.conf中的IMAGE_INSTALL_append将影响所有的image文件。如果需要只针对某一特定的image文件有效，可以通过扩展语句的方式实现，如：IMAGE_INSTALL_append_pn-core-image-minimal = " strace"，采用该方式，新增加的strace软件只对core-image-minimal 系统image文件有效。
通过IMAGE_FEATURES、EXTRA_IMAGE_FEATURES增加软件包
另一种增加软件包的方法是通过IMAGE_FEATURES、EXTRA_IMAGE_FEATURES变量。尽管IMAGE_FEATURES、EXTRA_IMAGE_FEATURES这两个变量在用法上几乎一致，但是，在实际使用过程中，IMAGE_FEATURES一般用于recipes内，而EXTRA_IMAGE_FEATURES一般用于build/conf路径下的local.conf文件中。总的来说，这两个变量最终都是通过修改IMAGE_INSTALL变量来实现的，该方法在实际过程中并不常用。
通过.bb文件定制系统镜像
比较常用的一种定制系统镜像的方法是使用.bb文件。可以通过创建一个recipe来定义镜像文件需要增加的软件包。例如在新创建的.bb文件中，增加如下代码：IMAGE_INSTALL = "packagegroup-core-x11-base package1 package2" ， inherit core-image
另一种方法，是通过在已经存在的系统镜像文件上进行修改。例如：如果想构建一个基于core-image-sato的系统镜像文件，但是，需要额外的增加strace软件包，可以通过拷贝/sources/poky/meta/recipes-sato/images/core-image-sato.bb文件，将其命名为一个新的.bb文件，然后在新的.bb文件中通过增加以下代码，实现strace软件包的增加：IMAGE_INSTALL += "strace" （推荐使用这种方法）。
通过Package Groups定制系统镜像
对于复杂的应用，可以使用package groups的方式定制系统镜像。例如：/sources/poky/meta/recipes-core/packagegroups/packagegroup-base.bb文件。
自定义主机名
一般来说主机名和系统中配置的主机名（/etc/hostname）是一致的。例如：如果MACHINE等于“qemux86”，那么写入/etc/hostnam的主机名就是“qemux86”。可以通过修改Recipe base-files中的hostname变量来实现自定义主机名。例如，可以在某一个.bbappend文件中使用如下代码：hostname=“myhostname”，或者在配置文件中使用如下代码：hostname_pn-base-files = “myhostname”。
4.2.3 创建Recipes
Metadata（Layer）是由一些Recipes组成的。从形式上来看，Recipes是在metadata文件夹下的一些文件夹（同样的惯例以recipes-xxx命名）。recipes-xxx文件夹中的recipes（.bb文件）是Yocto工程的最基础组成部分。OpenEmbedded构建系统使用的软件包等组件都是在recipe中定义的。
创建基础Recipes
有两种比较简便易行的创建新的recipes的方法：
recipetool：Yocto提供的工具，基于源文件自动创建基础recipe。
Exitsing Recipes：在一个功能需求相似的已有recipe基础上修改。
教程中着重讲解第二种方式。通常，recipe中定义了一些变量用于定义需要使用的软件包，其基本框架如下：
DESCRIPTION = ""
HOMEPAGE = ""
LICENSE = ""
SECTION = ""
DEPENDS = ""
LIC_FILES_CHKSUM = ""
SRC_URI = ""
存储和命名Recipes
创建了基础的recipes之后，需要按照一定的目录框架将recipes放在合适的位置，以确保OpenEmbedded构建系统时能够找到。OpenEmbedded是通过Layer（meta-xxx文件夹）下的conf/layer.conf中的变量BBFILES找到构建过程中所使用的recipes。其典型的应用如下：BBFILES += "$LAYERDIR/recipes-//.bb \\ $LAYERDIR/recipes-//.bbappend"，因此必须确保新创建的recipe在layer中的正确路径。 此外对于recipe文件的命名，也应该按照一定的规则：basename_version.bb，使用小写字母字符，并且不包括保留的后缀-native，-cross，-initial或-dev。
编译Recipes
对于新创建的recipe，往往需要不断的修改编译、反复迭代才能逐步实现完善最终的功能。在使用fls-setup-release.sh脚本初始化Yocto构建目录后，将自动进入build目录，在该路径下，通过如下命令即可编译recipe：$ bitbake basename，其中basename是recipe的文件名。在编译过程中，OpenEmbedded编译系统会为每一个recipe创建一个临时的文件夹，用来存放解压文件、日志文件等。每一个recipe的临时文件夹都按照如下的方式组织：
BASE_WORKDIR ?= "$TMPDIR/work"
WORKDIR = "$BASE_WORKDIR/$MULTIMACH_TARGET_SYS/$PN/$EXTENDPE$PV-$PR"
例如：假设生成的系统架构为qemux86-poky-linux，recipe文件为foo_1.3.0.bb ，那么，将生成如下的文件：
/build/tmp/work/qemux86-poky-linux/foo/1.3.0-r0，该路径下还可看到image、packages-spilt和temp等文件夹。编译之后，可以通过查看这些文件夹里的内容确定编译过程是否正确。
获取源码
构建系统的过程，实际上是将一些软件源码编译成系统镜像文件的过程，因此recipe的第一步是定义如何获取相关的软件源码。在recipe中，通过SRC_URI变量定义了软件源码的位置。BitBake编译系统镜像文件的过程可以分为几个任务分步完成的，其中一个任务do_fetch会根据SRC_URI变量值的前缀确定使用哪个fetcher从什么地方获取软件源码。获取源码结束后，do_patch任务也会根据SRC_URI变量值来打补丁。
recipe中的SRC_URI定义了软件源码的唯一地址。推荐在SRC_URI变量中定义的软件源码地址包含$PV的方式，以便在获取软件源码过程中使用recipe文件名中定义的版本，同时，后续当需要升级软件版本时，只需要将recipe文件名进行版本号升级即可。例如：meta/recipes-devtools/cdrtools/cdrtoolsnative_3.01a20.bb的recipe中，SRC_URI变量值使用了“PV”值。
SRC_URI = "ftp://ftp.berlios.de/pub/cdrecord/alpha/cdrtools-$PV.tar.bz2"
还可以通过SCM（Source Control Managers）获取软件源码，例如Git。对于Git来说，还需要在recipe中定义SRCREV和SRCPV变量值，例如：meta/recipeskernel/blktrace/blktrace_git.bb:
SRCREV = "d6918c8832793b4205ed3bfede78c2f915c23385"
PR = "r6"
PV = "1.0.5+git$SRCPV"
SRC_URI = "git://git.kernel.dk/blktrace.git \\
file://ldflags.patch"
其中SRCPV = “$@bb.fetch2.get_srcrev(d)”，此外如果SRC_URI指向的软件源码地址不是从SCM，而是远程服务器或其他地址的软件源码包，则需要定义相对应的软件源码包校验值，以便BitBake在编译时通过校验值确定软件包的完整性。例如：
SRC_URI = "$DEBIAN_MIRROR/main/a/apmd/apmd_3.2.2.orig.tar.gz;name=tarball \\
$DEBIAN_MIRROR/main/a/apmd/apmd_$PV.diff.gz;name=patch
SRC_URI[tarball.md5sum] 以上是关于Yocto1构建嵌入式Linux系统的主要内容，如果未能解决你的问题，请参考以下文章
Linux——Linux驱动之使用输入子系统设计按键驱动实战（输入子系统基本概念代码获取上报信息相关函数解析）