1. 說明:
yocto 自己的 東西都放在 source 目錄。
yocto mantain 的 linux kernel 也有獨立目錄。
meta-yocto-kernel-extras 說是一堆bitbake file (*.bbappend) 用來 build local kernel 用。
一般clone 下來修改,指向local 的 kernel.
這個 通常 clone 在 source 目錄下。
bsp -- 名稱就是 meta-<bsp>
2. build image
首先要有 source 目錄,和裡面的東西。
接著用 source 目錄裡的 oe-init-build-env 初始化yocto 自己需要的環境變數。
他會產生 build 目錄,然後去卻認,修改 build 目錄下 local.conf
local.conf 包含幾個重要的環境變數:
MACHINE: processor
DL_DIR: download source code/packages 的目錄
build 命令就是 bitbake
3. Open Source Environment
共同開發,可以利用 share state cache (sstate), 大家用 nfs share 共同的 sstate folder, 來避免重複編譯。
3.4 Yocto Project Term
Append Files (*.bbappend) : 用來 append 在某個 .bb file , 對該bb file 做修正 (overwrite), bbapend 和他要修正的 bb file 的filename 要一樣,只有副檔名不同。而且要在同一目錄。
BitBake : 負責執行task 的工具。
Build Directory : ..
Classes (*.bbclass) : 一些共用的檔案可以被很多人用的,可以被定義為 class,
Configuration File (*.conf) : 該 project, 目錄相關的變數定義
Layer : 一堆 recipes 組成 Layer。
Metadata : Bitbake 吃的檔案,用來決定動作,有: recipes, classes, configuration files
OE-core : 從 openembedded 繼承來的 metadata
Package : BitBake 針對某個recipes build 出來的東西。就是該 recipes 的 package
Recipes : (*.bb) : 告訴bitbake 怎模 build package 的檔案,包含 fetch , dep, config, make.. install
Task : BitBake 動作的單位..do_fetch, do_compile, do_patch ...
Yocto 的使用方式
可以分為五種:
- System Developement : 就是做 BSP 的人,...還包瓜改kernel
- User Application Developement : 開發 Ap
- Temporary Source Code Modification : 有時後會了加速開發過程,值接修改 local 的 source code..
- Image Development Using Hob : ? 用 Hob 來 build image.-- Hob 是 openembedded 的 toool
- Using Development Shell : 大概是包含所有環境變數的 shell 吧,..
System Development Workflow - BSP
Modifying Temporary Source Code
就是直接修改在 Build Directory 里的 package source code
然後 recompile 那個 project
測試完成後再用 quilt 或 git 來做出 OOXX
4.3.1 Finding the Temporary Source Code
build recipes的時候解開的 source 會在 Build Directory 中用環境變數 S 定義的 folder 中。
就是在:
S = "${WORKDIR}/${BP}"其中..
The BP represents the base recipe name, which consists of the name and version: BP = "${BPN}-${PV}"然後 WORKDIR 更複雜:
${TMPDIR}/work/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR} TMPDIR: The top-level build output directory MULTIMACH_TARGET_SYS: The target system identifier PN: The recipe name EXTENDPE: The epoch - (if PE is not specified, which is usually the case for most recipes, then EXTENDPE is blank) PV: The recipe version PR: The recipe revision舉例來說, MACHINE=qemux86-poky-linux , recipes name 是 foo_1.3.0-rb.bb 的 packages sources 會解開在..
poky/build/tmp/work/qemux86-poky-linux/foo/1.3.0-r0
Workflow
一樣,都是直接修改 source code 後,用
$ bitbake -c compile -fbuild 完,測試完後,開始對 source code 做 patch
建議使用 quilt 或 git
產生完 patch 後,全部放到 packager recipes 的 *.bb 或 *.bbappend 所在目錄,
create 一個 folder files/ 下,
然後修改 *.bb, 把 SRC_URI 加上這些 patch file:
SRC_URI += "file://my_changes.patch"
4.5 Using a Developement Shell
當要 debug 某個 package 的 build 動作時,可以進入這個 shell 模式,
這個 模式會幫你把所有 environment variable 都是依照 package 的 config 設好,source code 解開。
然後開啟 shell prompt 讓你操作所有的 build command (例如自己 patch, 自己 make)
進入的、方法,例如,要對 alsa-lib 做 build debug, 可以用:
$bitbake alsa-lib -c devshell之後就會進入 alsa-lib 的 working source folder:
~/fsl-release-bsp/build-fb/tmp/work/cortexa9hf-neon-mx6qdl-poky-linux-gnueabi/alsa-lib/1.1.0-r0/alsa-lib-1.1.0$然後你用 echo $PATH 可以看到 cross-tool 位置在裡面,所以可以直接make
沒有留言:
張貼留言