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

猜你喜欢

转载自blog.csdn.net/dragon101788/article/details/78979206