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，那么进入我们的项目目录，查看，其结构为

1. 注意：该目录省略了很多不必要的细节，只把重要的文件显示了出来

2. imx6_avi_super

3. |__Makefile

4. |__build

5. | |__cache

6. | |__conf

7. | |__bblayers.conf

8. | |__local.conf

9. |

10. |__sources

11. |__base

12. |__cache

13. | |__conf

14. | |__bblayers.conf(和build目录中的一样)

15. | |__local.conf(和build目录中的一样）

16. |

17. |

18. |__meta-avi(放硬件无关的内容，主要和文件系统相关的东西)

19. | |__classes

20. | |__conf

21. | | |__distro

22. | | | |__imx6.conf

23. | | |__layer.conf

24. | |

25. | |__recipes-core

26. | | |__busybox

27. | | |__images

28. | | | |__avi-common-package.inc

29. | | | |__avi-image-core.inc

30. | | | |__avi-image-core.bb

31. | | | |__avi-image.inc

32. | | |__ifupdown

33. | | |__openssh-keys

34. | |

35. | |__recipes-qt

36. | |__recipes-graphics

37. | |__recipes-devtools

38. |

39. |

40. |__meta-imx6-avi

41. | |__conf

42. | | |__machine

43. | | |__layer.conf

44. | | |__include

45. | | |__imx6-avi-super.conf

46. | | |__imx6-avi_mini.conf

47. | |

48. | |__recipes-bsp

49. | | |__u-boot

50. | | |__u-boot-imx6-avi.bb

51. | |

52. | |__recipes-core

53. | | |__images

54. | | |__avi-image-core.bbappend

55. | |

56. | |__recipes-kernel

57. | |__linux

58. | |__linux-imx6-avi/

59. | | |__defconfig

60. | |__linux-imx6-avi.bb

61. |

62. |

63. |__meta-Exynos-avi

64. |__meta-qt5-avi

65. |__meta-fsl-arm

66. |__meta-openembedded

67. |__meta-qt5

68. |__poky

69. |__meta-skeketon

70. |__meta-yocto

71. |__meta

72. |__classes

73. |__conf

74. |__recipes-bsp

75. |

76. |__recipes-connectivity

77. | |__dhcp

78. | |__nfs-utils

79. |

80. |__recipes-devtools

81. |__recipes-core

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19
• 20
• 21
• 22
• 23
• 24
• 25
• 26
• 27
• 28
• 29
• 30
• 31
• 32
• 33
• 34
• 35
• 36
• 37
• 38
• 39
• 40
• 41
• 42
• 43
• 44
• 45
• 46
• 47
• 48
• 49
• 50
• 51
• 52
• 53
• 54
• 55
• 56
• 57
• 58
• 59
• 60
• 61
• 62
• 63
• 64
• 65
• 66
• 67
• 68
• 69
• 70
• 71
• 72
• 73
• 74
• 75
• 76
• 77
• 78
• 79
• 80
• 81
• 82

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19
• 20
• 21
• 22
• 23
• 24
• 25
• 26
• 27
• 28
• 29
• 30
• 31
• 32
• 33
• 34
• 35
• 36
• 37
• 38
• 39
• 40
• 41
• 42
• 43
• 44
• 45
• 46
• 47
• 48
• 49
• 50
• 51
• 52
• 53
• 54
• 55
• 56
• 57
• 58
• 59
• 60
• 61
• 62
• 63
• 64
• 65
• 66
• 67
• 68
• 69
• 70
• 71
• 72
• 73
• 74
• 75
• 76
• 77
• 78
• 79
• 80
• 81
• 82

• 首先来分析一下目录结构，不难发现主要有三级构成：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。

1. LCONF_VERSION = "6"

2.  

3. BBPATH = "${TOPDIR}"

4. BSPDIR := "/home/username/yocto/imx6_avi_super"

5. BBFILES ?= ""

6. BBLAYERS = " \

7. ${BSPDIR}/sources/poky/meta \

8. ${BSPDIR}/sources/poky/meta-yocto \

9. \

10. ${BSPDIR}/sources/meta-openembedded/meta-oe \

11. ${BSPDIR}/sources/meta-openembedded/meta-multimedia \

12. ${BSPDIR}/sources/meta-qt5 \

13. ${BSPDIR}/sources/meta-qt5-avi \

14. \

15. ${BSPDIR}/sources/meta-fsl-arm \

16. \

17. ${BSPDIR}/sources/meta-avi \

18. ${BSPDIR}/sources/meta-imx6-avi \

19. "

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19

• 这些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：