yocto 一些细节
参考Embedded_Linux_Projects_Using_Yocto_Project_Cookbook.pdf
(1)
source oe-init-build-env qemuarm
该命令设置整个project的环境。后面的qemuarm表示将构建一个qemuarm的目录，即“build”目录
(2)
Poky包含了一些默认的target，可通过如下命令列出
> ls meta*/recipes*/images/*.bb
meta/recipes-core/images/build-appliance-image_8.0.bb
meta/recipes-core/images/core-image-base.bb
meta/recipes-core/images/core-image-minimal.bb
meta/recipes-core/images/core-image-minimal-dev.bb
meta/recipes-core/images/core-image-minimal-initramfs.bb
meta/recipes-core/images/core-image-minimal-mtdutils.bb
meta/recipes-extended/images/core-image-full-cmdline.bb
meta/recipes-extended/images/core-image-lsb.bb
meta/recipes-extended/images/core-image-lsb-dev.bb
meta/recipes-extended/images/core-image-lsb-sdk.bb
meta/recipes-extended/images/core-image-testmaster.bb
meta/recipes-extended/images/core-image-testmaster-initramfs.bb
meta/recipes-graphics/images/core-image-clutter.bb
meta/recipes-graphics/images/core-image-directfb.bb
meta/recipes-graphics/images/core-image-weston.bb
meta/recipes-graphics/images/core-image-x11.bb
meta/recipes-qt/images/qt4e-demo-image.bb
meta/recipes-rt/images/core-image-rt.bb
meta/recipes-rt/images/core-image-rt-sdk.bb
meta/recipes-sato/images/precedingcore-image-sato.bb
meta/recipes-sato/images/core-image-sato-dev.bb
meta/recipes-sato/images/core-image-sato-sdk.bb
meta-skeleton/recipes-multilib/images/core-image-multilib-example.bb
可参考Yocto Project Reference Manual查看不同image的描述
core-image-minimal : This is the smallest BusyBox-, sysvinit-, and udev-based console-only image
core-image-full-cmdline : This is the BusyBox-based console-only image with full hardware support and a more complete Linux system, including bash
core-image-lsb: This is a console-only image that is based on Linux Standard Base compliance
core-image-x11: This is the basic X11 Windows-system-based image with a graphical terminal
core-image-sato: This is the X11 Window-system-based image with a SATO theme and a GNOME Mobile desktop environment
core-image-weston: This is a Wayland protocol and Weston reference compositor-based image
有些images带有如下后缀
dev : These images are suitable for development work, as they contain headers and libraries.
sdk : These images include a complete SDK that can be used for development on the target.
initramfs: This is an image that can be used for a RAM-based root filesystem, which can optionally be embedded with the Linux kernel.
（3） 构建image之前，需要配置MACHINE参数，修改文件conf/local.conf。
执行bitbake core-image-minimal 构建image
（4） bitbake执行一个target时，它首先解析下面的配置文件
conf/bblayers.conf : This file is used to find all the configured layers
conf/layer.conf: This file is used on each configured layer
meta/conf/bitbake.conf: This file is used for its own configuration
conf/local.conf: This file is used for any other configuration the user may have or the current build
conf/machine/
conf/distro/
然后bitbake再解析目标recipe及其依赖。 输出是一些独立的task，然后bitbake按顺序执行。
compositor
（5） 很多开发者不会对每个包的build output感兴趣，所以推荐在conf/local.conf文件中加入如下配置
INHERIT += "rm_work"
但是这样会影响所有的包，不利于开发和调试，可使用RM_WORK_EXCLUDE来排除一些包，比如我希望进行BSP开发，则
RM_WORK_EXCLUDE += "linux-yocto u-boot"
（6） 构建完成后，可在poky/qemuarm/tmp/deploy/images/qemuarm目录中找到image文件
默认情况下，不会删除deploy目录下的images，你可以在conf/local.conf中加入如下配置删除先前同版本的image
RM_OLD_IMAGE = "1"
然后通过runqumu qemuarm core-image-minimal在Host上面使用QEMU仿真一下。
（7）除了meta，meta-yocto，meta-yocto-bsp layer之外，Yocto Project可以扩展其他layer，一些可用的layer可参考http://layers.openembedded.org/，嵌入式产品的开发通常需要你自己扩展出一个支持自身平台的layer
（8） 你可能经常同时有几个项目在开发，不同的硬件，不同的target，在这种情况下，可通过分享downloads目录来优化编译时间。
设置conf/local.conf中的DL_DIR
bitbake搜索路径 downloads --> PREMIRRORS --> upstream source --> MIRRORS
（9） OE build system 怎么获取源代码的呢？
顺序 local download directory --> PREMIRRORS --> upstream source --> MIRRORS
一些其他的参数：
BB_NO_NETWORK = "1" --- 从本地获取源
BB_FETCH_PREMIRRORONLY = "1" --- 只从PREMIRRORS获取
BB_GENERATE_MIRROR_TARBALLS = "1" --- 告知build system生成mirror tarballs，如果你希望创建一个mirror server就有用，否则浪费时间。
（10） 分享shared state cache， 新建一个项目时，只需要创建新的配置文件，然后从新开始编译，包括工具链、本地工具等等。
yocto为每个input data计算了一个checksum，一旦input data变化，该task就需要rebuild。
但是分享state cache可能会导致错误，推荐每个项目使用独立的state cache。
修改conf/local.conf的SSTATE_DIR
（11） build history 在conf/local.conf中加入
INHERIT += "buildhistory" 开启build history功能
BUILDHISTORY_COMMIT = "1" 使build history以本地git仓库形式存储
BUILDHISTORY_FEATURES = "image" 仅追踪image的修改历史
（12） build statistics， 在conf/local.conf中加入
USER_CLASSES ?= "buildstats" 开启build统计功能，可统计主机系统信息，rootfs位置和大小，build时间，平均CPU使用率，Disk占用。
（13） Debugging the build system
13.1 查找recipes是否支持，比如所busybox
find -name “*busybox*”
13.2 dumping bitbake 环境
查找某target的源代码路径 bitbake -e
查找某target的工作路径 bitbake -e
13.3 devshell task可帮助开发者
bitbake -c devshell
该命令将解压并patch源代码，并在新终端中打开，且自动设置好环境。
13.4 列出某个recipe的tasks
bitbake -c listtasks
重现错误
bitbake -f
强制只运行该特定task
bitbake -c compile -f
13.5 出现build error时，可到build/tmp/work目录下找到对应target中的temp目录，下面有两个文件log.do_
13.6 在recipes中加入打印信息，有两种方式
一种是Python形式，该形式可在console上打印出来: bb.plain, bb.note, bb.warn, bb.error, bb.fatal, bb.debug
另一种是bash形式，该形式会在temp目录下的log中包含，需要inherit logging(base.bbclass会包含，通常不需要特意添加): bbplain, bbnote, bbwarn, bberror, bbfatal, bbdebug
13.7 打印包当前和provided版本 bitbake --show-versions
将target的依赖关系保存为dot文件 bitbake -g
使用dependency explorer显示依赖关系 bitbake -g -u depexp
（14） 使用Yocto的三种开发流程
14.1 External development
该情况下不使用yocto build system，只使用yocto toolchain和包自身的build system，其源代码可使用如下两种方法集成到yocto中： 一个recipe，fetch一个released tarball； 一个recipe，fetch一个仓库。 此种方法比较适合U-Boot和Linux Kernel开发，第三方的包可以使用这种方法。
14.2 Working directory development
该情况下，我们使用build目录下的tmp/work工作目录。当Yocto构建包时，使用工作目录extract，patch，configure，build，package源代码。我们可以直接在该目录下修改。当偶尔需要调试第三方包的时候，我们通常使用这种方法。
工作流程如下：
a. 删除build目录下原本关于该包的内容 bitbake -c cleanall
b. 让bitbake去fetch，unpack，patch该包 bitbake -c patch
c. 进入解压目录，然后修改，可使用git帮忙管理 bitbake -c devshell
d. 重新build bitbake -C compile
注意：这里使用了-C，表示编译该task后，再编译所有的task。等效于
bitbake -c compile
bitbake
e. 使用目标系统的包管理系统安装该修改的包，并测试。
f. 将第c步骤的改动生成patch，加入到recipes的bbappend文件中。
14.3 External source development
该情况下，使用yocto build system来build一个包含源码的外部目录。通常是该source已经被集成到yocto build system的情况下使用。工作流程类似于14.2
（15） 包依赖中带有-native的表示这些包被host使用。
比如bb文件中包含如下语句： DEPENDS += "lzop-native bc-native" 表示lzop和bc将会被host使用。
（16） SCR_URI表示从该地址fetch source code
（17） 可以从http://downloads.yoctoproject.org/releases/yocto/yocto-*.*.*/toolchain/路径中下载一些工具链
（18） 设备树是一种描述系统物理设备的数据结构，它将被传到kernel。
CPU不能发现的设备可通过Linux kernel的平台设备API进行处理。传统包含硬件特性的平台数据被固化到kernel source中，现在使用device tree来代替，平台客制化就只需要修改设备树，而不需要修改kernel了。设备树最初在PowerPC架构上使用，然后被ARM或其他架构采用，除了x86。
设备树使用human-readable设备树语法文本文件.dts。DTS文件被编译成Device Tree Binary DTB blobs，具有如下属性：
a. 是浮动的，因此内部不适用指针
b. 允许动态节点的插入和移除
c. size小
DTB可以附在kernel上，也可以让U-Boot这类bootloader传给kernel，后者比较常见。
编译使用的是Device Tree Compiler（DTC），kernel源码scripts/dtc中包含。
（19） 在build/tmp/work目录下会分4个目录：
all-poky-linux: 架构无关的包
armv5te-poky-linux-gnueabi: 架构有关的包
qemuarm-poky-linux-gnueabi: mechine特定的包
x86_64-linux: 主机使用的包
（20） 找到某个包的工作路径 bitbake -e
该工作路径下会有如下子目录：
deploy-rpms: 最终包存放的地方，我们可以将这些包复制到target并安装。这些包会被复制到build/tmp/deploy目录，当构建rootfs时使用
image: 执行do_install task安装的目的目录。可通过修改recipe的D配置参数
package: 包含真实的包内容
package-split: recipes可将包内容分成几个包，通过PACKAGES变量指定。默认包含如下：
a. dbg 用于调试
b. dev 用于开发，比如头文件和库
c. staticdev 静态编译的库和头文件
d. doc 文档存放的地方
f. locale 位置
可通过FILES变量来选择安装哪些包。
（21） 当yocto构建完所有的包后，会执行do_rootfs任务，可执行如下命令，找到rootfs位置
bitbake -e core-image-sato | grep ^IMAGE_ROOTFS=
注意IMAGE_ROOTFS变量不能被配置和改变。该路径中的内容后续会按照IMAGE_FSTYPES变量的类型生成对应的image
（22） bitbake-layers show-layers --> 显示已配置的layers
bitbake-layers show-recipes --> 显示所有可用的recipes
bitbake-layers show-overlayed --> 显示所有被覆盖的recipes
bitbake-layers show-appends --> 显示所有可用的append文件
bitbake-layers flatten
（23） 选择特定的provider， 可加入 PREFERRED_PROVIDER_virtual/kernel = "linux-imx"
选择特定的版本，可加入 PREFERRED_VERSION_linux-imx_mx6 = "3.10.17"
指定不使用某版本 DEFAULT_PREFERENCE = "-1"
（24） 当加入一个新recipe时，需要考虑
1. source code 存放在哪里
2. source code是git模式还是压缩包模式
3. source code的License
4. 编译架构 makefile、bitbake...
5. 需要配置么
6. 可否交叉编译，需要打patch么
7. 放到rootfs的那个位置
8. 依赖关系