轉自：https://blog.csdn.net/qq_28992301/article/details/52872209
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，那么進入我們的項目目錄，查看，其結構為
首先來分析一下目錄結構，不難發現主要有三級構成：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。
這里寫圖片描述
這些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指令實現
————————————————
版權聲明：本文為CSDN博主「XiaoBaWu」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/qq_28992301/article/details/52872209