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

本站公众号
   欢迎关注本站公众号,获取更多程序园信息
开发小院