2020-10-11

本文详细介绍了Yocto项目的架构及配置方法,包括名词解释、目录结构解析、配置文件详解等内容,帮助读者深入理解Yocto项目的构建过程。

Yocto详解

XiaoBaWu 2016-10-20 14:21:00  44725  已收藏 40

分类专栏: 【Linux用户态使用】 文章标签: linux 开源项目

版权

Yocto详解

参考:http://www.yoctoproject.org/docs/2.1/mega-manual/mega-manual.html#creating-a-general-layer-using-the-yocto-layer-script 这篇文章第五章不错

1.名词解释

  • Yocto:Yocto是这个开源项目的名称,该项目旨在帮助我们自定义Linux系统
  • Poky:Poky有两个含义。第一个含义是用来构建Linux的构建系统,值得注意的该Poky仅仅是一个概念,而非一个实体:它包含了 BitBake工具、编译工具链、BSP、诸多程序包或层,可以认为Poky即是Yocto的本质;此外Poky还有另外一层意思,使用Poky系统得到的默认参考 Linux 发行版也叫Poky(当然,我们可以对此发行版随意命名)。Poky的两个含义千万不能混淆
  • Metadata:元数据集,所谓元数据集就是发行版内各基本元素的描述与来源
    • Recipes:.bb/.bbappend文件,配方文件,描述了从哪获取软件源码,如何配置,如何编译。bbappend和bb的区别主要在于bbappend是基于bb的,功能是对相应的bb文件作补充和覆盖,有点类似于“重写”的概念
    • Class:.bbclass文件
    • Configuration:.conf文件,即配置文件,我们可以用它来改变构建方式
  • Layers:即各种meta-xxx目录,将Metadata按层进行分类,有助于项目的维护
  • Bitbake:一个任务执行引擎,用来解析并执行Metadata
  • Output:即各种输出image

  • 总结:假如用烹饪一桌酒席来形容构建发行版,则Yocto就是饭店名,Poky就是厨房(以及提供作为参考的菜的搭配套餐),Metadata就是烹饪资源(.bb/.bbappend表示配方/配方上的贴士,.conf表示厨房里的管事的小组长),Layers就是菜谱的分类(如川菜谱、粤菜谱),Bitbake就是厨师,Output就是得到的一桌酒席

2.Yocto的架构

假设现在有一个已经构建好的Yocto环境。有关Yocto的具体操作和环境构建详见Yocto的使用实例

  • 假设我们的项目名称叫imx6_avi,那么进入我们的项目目录,查看,其结构为
注意:该目录省略了很多不必要的细节,只把重要的文件显示了出来
imx6_avi_super
    |__Makefile
    |__build
    |   |__cache
    |   |__conf
    |       |__bblayers.conf
    |       |__local.conf   
    |
    |__sources
        |__base
        |__cache
        |   |__conf
        |       |__bblayers.conf(和build目录中的一样)
        |       |__local.conf(和build目录中的一样)
        |
        |
        |__meta-avi(放硬件无关的内容,主要和文件系统相关的东西)
        |   |__classes
        |   |__conf
        |   |   |__distro
        |   |   |   |__imx6.conf
        |   |   |__layer.conf
        |   |
        |   |__recipes-core
        |   |   |__busybox
        |   |   |__images
        |   |   |   |__avi-common-package.inc
        |   |   |   |__avi-image-core.inc
        |   |   |   |__avi-image-core.bb
        |   |   |   |__avi-image.inc
        |   |   |__ifupdown
        |   |   |__openssh-keys
        |   |
        |   |__recipes-qt
        |   |__recipes-graphics
        |   |__recipes-devtools
        |       
        |
        |__meta-imx6-avi
        |   |__conf
        |   |   |__machine
        |   |       |__layer.conf
        |   |       |__include
        |   |           |__imx6-avi-super.conf
        |   |           |__imx6-avi_mini.conf
        |   |           
        |   |__recipes-bsp
        |   |   |__u-boot
        |   |       |__u-boot-imx6-avi.bb
        |   |
        |   |__recipes-core
        |   |   |__images
        |   |       |__avi-image-core.bbappend
        |   |
        |   |__recipes-kernel          
        |       |__linux                                                                      
        |           |__linux-imx6-avi/   
        |           |    |__defconfig          
        |           |__linux-imx6-avi.bb 
        |
        |
        |__meta-Exynos-avi
        |__meta-qt5-avi
        |__meta-fsl-arm
        |__meta-openembedded
        |__meta-qt5
        |__poky
            |__meta-skeketon
            |__meta-yocto
            |__meta
                |__classes
                |__conf
                |__recipes-bsp
                |
                |__recipes-connectivity
                |   |__dhcp
                |   |__nfs-utils
                |
                |__recipes-devtools
                |__recipes-core
  • 首先来分析一下目录结构,不难发现主要有三级构成:meta-xxx->recipes-yyy->zzz/ttt.bb。比如:meta-avi-> recipes-core->openssh-keys
  • meta-xxx就是layer(菜谱的分类如川菜谱、粤菜谱),recipes-yyy就是Metadata(具体某一本菜谱),zzz就是菜谱上具体的一个配方
  • 从目录中不难看出,主要有这么几个layer

    • meta-avi:由我们创建并维护。和avi有关的项目需要的配方。可以认为这个目录中的配方都是通用的、与平台无关的内容
    • meta-imx6-avi:由我们创建并维护。imx6平台avi项目需要的配方
    • meta-Exynos-avi:由我们创建并维护。Exynos平台avi项目需要的配方
    • meta-qt5-avi:由我们创建并维护。avi项目中qt5需要的配方
    • meta-fsl-arm:飞思卡尔官方推出的配方大全
    • meta-openembedded:openembedded推出的配方大全
    • meta-qt5:qt5官方推出的qt5配方大全
    • poky中的一堆meta:yocto官方推出的参考配方。虽然这些meta被放在了poky里面,但是还是不影响使用的,他们具有和上面那些meta相同的地位,如下图

    不难看出,这里面很多的layer只是我们照搬过来的,目的是为了借用里面现成的配方(可以认为这些layer充当了“库”),而真正由我们维护的仅仅是几个名字中带有avi的layer,而且它们是依赖于那些充当“库”的layer的。如下图
    【图二】

  • 介绍完了layer,那么问题来了,那么是否可以认为,这些layer全部被enable了呢?答案固然是否定的,我们的项目是imx6_avi_super,显然不可能去包含meta-Exynos-avi这个三星平台专用的layer
  • 具体的layer选择由imx6_avi_super/sources/conf/bblayers.conf负责,直观位置在前面目录中可以体现。仔细观察该文件,重点在BBLAYERS这个变量,里面有一些layer,这些layer就被enable了。不难发现这里面并没有meta-Exynos-avi,这也恰好印证了我们建立开发环境(repo sync)时,从git仓库中拉的是imx6_avi_super这个项目对应的Poky。
LCONF_VERSION = "6"

BBPATH = "${TOPDIR}"
BSPDIR := "/home/username/yocto/imx6_avi_super"
BBFILES ?= ""
BBLAYERS = " \
${BSPDIR}/sources/poky/meta \
${BSPDIR}/sources/poky/meta-yocto \
\
${BSPDIR}/sources/meta-openembedded/meta-oe \
${BSPDIR}/sources/meta-openembedded/meta-multimedia \
${BSPDIR}/sources/meta-qt5 \
${BSPDIR}/sources/meta-qt5-avi \
\
${BSPDIR}/sources/meta-fsl-arm \
\
${BSPDIR}/sources/meta-avi \
${BSPDIR}/sources/meta-imx6-avi \
"

这里写图片描述

  • 这些layer目前是被enable了,那么是否可以认为,这些layer中的配方也全部被使能了呢?答案固然是否定的,我们的发行版中不可能把所有的软件包放进去。在Yocto中,这个选择配置操作是由好多个conf、bb文件协同完成的,并不存在一个总的大纲,这也是和buildroot最大的不同之处(buildroot是由menuconfig来进行大纲式的配置)。可以理解为Yocto是“分封制”,皇帝说的不一定能落实,具体还是各种大小地方官说了算;而buildroot是“中央集权制”,皇帝一人说了算
  • 如何理解Yocto的配置方法?这要从发行版的定制流程说起。我们的目的很简单,是要得到uboot、kernel、rootfs这三个image;Yocto的目的也很简单,它要经过一级一级配置,逐步缩小配方,直至得到uboot、kernel、rootfs这三个image。每一级需要哪些配方,由该级对应的配置文件(conf/bb)决定。越上级的配置是越笼统的,越下级的配置越细致。如果下级的配置项相对于上级有补充或者冲突,则以下级的内容为准,可以认为下级会对上级进行“重写”。这其实有点类似交通法规
    这里写图片描述
    这里写图片描述
  • 有关构建的路线和流程:对于整个发行版构建,虽然每一级的配方由(conf/bb)决定,但是每一级路线和方向的选择,是由我们最终bitbake的对象决定的,比如我们最终bitbake avi-image-core,我们想要获得rootfs.img,那么:

    • 第一步Poky就会从local.conf开始,一路向下,一级一级配置,直到配置到和rootfs有关的那一堆bb,最终形成完整完全的配方
    • 然后获取配方需要的资源,比如各种软件包,比如kernel的源码
    • 最后把所有的资源编译出我们需要的镜像

  • 最后说一下bitbake,比如我们要选择编译rootfs.img,那么使用bitbake avi-image-core即可,但是很多时候并不直接采用这种做法。大多数情况下我们会在项目目录下写一个Makefile,里面包含各种各样的功能,内部以bitbake指令实现

3.配置文件详解

上一节简单介绍了Yocto是如何配置我们的项目,这一节开始分析具体的配置文件

  • local.conf:

未完待续

你遇到的问题是: > **SPI 输出的时间尺度不对,比如 `window_start` 和 `window_end` 的时间跨度看起来不是30天。** 我们来看你的输出示例: ``` dekad_start window_start window_end 2020-01-21 2019-12-23 2020-01-31 ``` 这里 `window_start = 2019-12-23`, `window_end = 2020-01-31`,这显然不是一个30天的窗口,而是一个月的跨度,说明你的 **SPI窗口定义逻辑出现了问题**。 --- ## ❗问题定位:窗口定义错误 你在代码中这样定义窗口: ```python window_end = dekad_start window_start = dekad_start - pd.Timedelta(days=29) ``` 但你在筛选窗口数据时却用了: ```python window_data = df[(df['date'] > window_start) & (df['date'] <= dekad_end)] ``` ### ✅ 正确逻辑应是: ```python window_data = df[(df['date'] >= window_start) & (df['date'] <= window_end)] ``` 因为你定义了: ```python window_end = dekad_start window_start = dekad_start - pd.Timedelta(days=29) ``` 所以窗口应该是: ``` [dekad_start - 29天, dekad_start] ``` 但是你用了 `dekad_end` 作为窗口结束时间,而 `dekad_end` 是 **每旬的结束时间(10日、20日、月底)**,这会导致窗口被错误地扩展到整旬结束日,而不是当前旬的开始日。 --- ## ✅ 正确代码应为: ```python window_end = dekad_start window_start = dekad_start - pd.Timedelta(days=29) window_data = df[(df['date'] >= window_start) & (df['date'] <= window_end)] ``` 而不是: ```python window_data = df[(df['date'] > window_start) & (df['date'] <= dekad_end)] ``` --- ## 🧪 示例说明 以 `dekad_start = 2020-01-21` 为例: ```python window_start = 2020-01-21 - 29天 = 2019-12-23 window_end = 2020-01-21 ``` 正确的窗口是: ``` [2019-12-23, 2020-01-21] # 共30天 ``` 如果你用了 `dekad_end = 2020-01-31`,那么窗口变成了: ``` [2019-12-23, 2020-01-31] # 39天,错误 ``` --- ## ✅ 修改建议(修复窗口筛选逻辑) 将: ```python window_data = df[(df['date'] > window_start) & (df['date'] <= dekad_end)] ``` 改为: ```python window_data = df[(df['date'] >= window_start) & (df['date'] <= window_end)] ``` 同时确保 `window_end = dekad_start` 是正确的。 --- ## ✅ 建议添加调试打印语句 你可以在循环中加入调试信息,帮助你检查窗口是否正确: ```python print(f"dekad_start: {dekad_start}, window_start: {window_start}, window_end: {window_end}") ``` 输出示例: ``` dekad_start: 2020-01-21 00:00:00, window_start: 2019-12-23 00:00:00, window_end: 2020-01-21 00:00:00 ``` 确保 `window_start` 到 `window_end` 确实是30天。 --- ## ✅ 总结 | 问题 | 原因 | 修复方法 | |------|------|-----------| | 时间窗口跨度错误 | 使用了 `dekad_end` 而非 `window_end` | 改为使用 `window_start` 到 `window_end` | | 数据边界错误 | 使用了 `>` 而非 `>=` | 改为 `>= window_start` | | 窗口天数不对 | 没有检查窗口是否正好30天 | 添加调试输出 | --- ##
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值