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/<machine>.conf: This file is the machine configuration; in our case, this is qemuarm.conf
conf/distro/<distro>.conf: This file is the distribution policy; by default, this is he poky.conf file
然后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> | grep ^S=
   查找某target的工作路径       bitbake -e <target> | grep ^WORKDIR=
13.3    devshell task可帮助开发者
   bitbake -c devshell <target>
   该命令将解压并patch源代码，并在新终端中打开，且自动设置好环境。
13.4    列出某个recipe的tasks
   bitbake -c listtasks <target>
   重现错误
   bitbake -f <target>
   强制只运行该特定task
   bitbake -c compile -f <target>
13.5    出现build error时，可到build/tmp/work目录下找到对应target中的temp目录，下面有两个文件log.do_<task>.<pid>和run.do_<task>.<pid>，通常我们只需要看log文件就可以解决问题，对于复杂的可能需要查看run文件。对于Python task没有这两个文件，但是会在终端上打印出log信息。
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 <target>
   使用dependency explorer显示依赖关系   bitbake -g -u depexp <target>

（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 <target>
       b. 让bitbake去fetch，unpack，patch该包       bitbake -c patch <target>
       c. 进入解压目录，然后修改，可使用git帮忙管理   bitbake -c devshell <target>
       d. 重新build                   bitbake -C compile <target>
           注意：这里使用了-C，表示编译该task后，再编译所有的task。等效于
               bitbake -c compile <target>
               bitbake <target>
       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 <package> | grep ^WORKDIR=
   该工作路径下会有如下子目录：
   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 <output_dir>   -->   创建一个目录，包含所有配置的layers，未覆盖的recipes，append文件

（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. 依赖关系

yocto 一些细节相关推荐

[ 物联网篇 ] 14 - 联发科MTK8516 Yocto技巧
MTK8516 提供的SDK通过Yocto来进行构建, 由于Yocto入门门槛较高,刚开始也才过不少坑,这里记录下. Yocto中相关.bb文件中如何添加打印在recipes中加入打印信息,有两种方 ...
Yocto基本概念及介绍
Yocto详解参考:http://www.yoctoproject.org/docs/2.1/mega-manual/mega-manual.html#creating-a-general-laye ...
4.Yocto项目概念
目录 4.1约克托项目组件 4.1.1比特贝克 4.1.2食谱recips 4.1.3类class 4.1.4配置conf 4.2层layer 4.3开放式构建系统概念 4.3.1用户配置 4.3.2 ...
Yocto系列讲解[实战篇]44 - bb文件中函数实操演示(2)
By: fulinux E-mail: fulinux@sina.com Blog: https://blog.csdn.net/fulinus 喜欢的盆友欢迎点赞和订阅! 你的喜欢就是我写作的动力! ...
yocto（一）——yocto介绍
本文参考yocto官方手册,如有理解不当之处,欢迎留言指出. 项目概述和概念手册:https://docs.yoctoproject.org/overview-manual/index.html 项目 ...
yocto bsp-开发人员指南
1. yocto bsp-开发人员指南板级支持包 (BSP) 是定义如何支持特定硬件设备.设备集或硬件平台的信息集合. BSP 包括有关设备上存在的硬件功能的信息和内核配置信息以及所需的任何其他硬件 ...
yocto编译linux,好实用！用 Yocto 在 Ubuntu 上创建最小化 Linux 发行版
导读本文主要聚焦在如何使用 Yocto 在 Ubuntu 上创建一个最小化的 Linux 发行版.Yocto 项目在嵌入式 Linux 的世界非常著名,这是因为它用起来非常灵活.方便.Yocto 的 ...
yocto,poky,qemu
Yocto ,(本意Yocto是最小的计量单位,幺(科托),10^-24[1])是一个开源社区.它通过提供模版.工具和方法帮助开发者创建基于linux内核的定制系统,支持ARM, PPC, MIPS, ...
物联网技术周报第 126 期: 使用 Yocto 构建 Raspberry Pi 系统
\ 看新闻很累?看技术新闻更累?试试下载InfoQ手机客户端,每天上下班路上听新闻,有趣还有料! \ \\ 新闻 \\ \ <构建天气数据交易平台,WeatherBlock要将个人气象站变成&q ...

yocto 一些细节

yocto 一些细节相关推荐

最新文章

热门文章