レイヤ
# レイヤを作る
$ bitbake-layers create-layer <レイヤパス>
# BBLAYERS.confに登録する
$ bitbake-layers add-layer <レイヤパス>
# レイヤ一覧を確認
$ bitbake-layers show-layers
レシピ
# 作業用レシピを作る
$ devtool add <リポジトリURL> -B <branch名>
# 作業用レシピの一覧表示
$ devtool status
# 作業用レシピを削除
$ devtool reset <レシピ名>
# 作業用レシピをレイヤに登録
$ devtool finish <レシピ名> <レイヤパス>
# レシピ一覧を表示
$ bitbake-layers show-recipes
レシピの依存関係を知りたい
以下を実行すると、build/task-depends.dotファイルができる。これがレシピの依存関係を表している
$ bitbake -g <recipe name>
タスク
# タスク一覧を表示
bitbake <recipe name> -c listtasks
パッケージ
packages-split/
libexample/ <-- ${PN} のファイル
libexample-dev/ <-- ${PN}-dev のファイル
libexample-doc/ <-- ${PN}-doc のファイル
- libexample/：実行ファイルや動的ライブラリ
- libexample-dev/：ヘッダーファイルや開発用シンボリックリンク、静的ライブラリ
- libexample-doc/：ドキュメント関連ファイル
上記より、開発用リンク(xxx.so)はlibexampleに含めることができない。
# パッケージ一覧表示
$ bitbake <レシピ名> -e | grep ^PACKAGES=
# パッケージ内のファイル確認
## 事前にレシピをIMAGE_INSTALLに加え、ファイルをpackageに含めた後、以下のコマンドで確認可能
$ oe-pkgdata-util list-pkg-files <パッケージ名>
パッチの作り方
- 修正したいソースコードをbuild/workspace/sources内にfetchする
# 編集したいソースコードをfetchするレシピを指定 $ devtool modify <レシピ名> - fetchしてきたソースコードを修正し、コミット。プッシュはしない。
- bbappendファイルとパッチを指定したレイヤに加える。不要なパッチは削除してOK
$ devtool finish <レシピ名> <レイヤ名> - パッチの先頭にUpstream-Statusを追加する
※これをしないと、追加の修正をするため、次回devtool modifyしたときエラーが出るyourpatch.patchUpstream-Status: Inappropriate [embedded specific] ...
Github Copilot
Upstream-Status は、Yocto プロジェクトのパッチファイルに含めるメタデータフィールドで、パッチの上流（オリジナルのプロジェクト）へのステータスを示します。このフィールドは、パッチがどのように扱われるべきか、または既にどのように扱われているかを明確にするために使用されます。
Upstream-Status の値には以下のようなものがあります：
Accepted: パッチが上流プロジェクトに受け入れられた。
Backport: パッチが上流プロジェクトに既に存在し、古いバージョンにバックポートされた。
Denied: パッチが上流プロジェクトに提出されたが拒否された。
Inappropriate: パッチが上流プロジェクトに適用されるべきではない（例えば、特定のビルド環境にのみ関連する変更）。
Pending: パッチが上流プロジェクトに提出され、まだレビュー中である。
Submitted: パッチが上流プロジェクトに提出されたが、まだ受け入れられていない。
ライセンス情報が知りたい
build/tmp/deploy/licenses内にライセンス情報がある
yoctoレシピ内でシンボリックリンク張る時の注意点
リンク先を相対パスで指定するようにする。
⇒絶対パスだと、ビルド環境に大きく依存する。
NG例）私の環境では/homeはroot権限になってたので、/home/machine-idが作成されず、ビルドエラー発生
$ ln -s /home/machine-id ${IMAGE_ROOTFS}${sysconfdir}/machine-id
OK例）yoctoのrootfsの/homeに作成
$ ln -s ../home/machine-id ${IMAGE_ROOTFS}${sysconfdir}/machine-id
レシピ内でmakefileで使う環境変数の定義の仕方
makefile内で使う環境変数をレシピ内で定義するためには、レシピ内に以下を記載してあげればいい
以下例
EXTRA_OEMAKE += "'LDFLAGS=-L/pf/lib'"
ただし、makeコマンドではなくoe_runmakeコマンドでmake実行をしないと反映されないので注意
do_compile() {
make # これNG
oe_runmake # これOK
}
makefile内で${LDFLAGS}と書くと「-L/pf/lib」と置換される
bitbakeで各taskを実行する方法
$ bitabake <レシピ名> --runall=<タスク>
例
$ bitbake <レシピ名> --runall=patch
$ bitbake <レシピ名> --runall=fetch
sstate-cacheを使わずにbitbake
$ bitbake <レシピ名> --no-setscene
環境変数
# 環境変数を表示
$ bitbake <レシピ名> -e
WORKDIR
build/tmp/work/.../<レシピ名>/<バージョン>/
よくフェッチしたリポジトリにアクセスするため、以下のように定義されることが多い
S = ${WORKDIR}/git
デフォルトはSとB一緒で、do_install実行時とかの作業ディレクトリとなる
カーネルモジュールのビルド
Makefile
obj-m += hello.o
KDIR := /home/ubuntu/shared/pi-build/tmp/work/raspberrypi4_64-poky-linux/linux-raspberrypi/6.6.22+git/linux-raspberrypi4_64-standard-build
PWD := $(shell pwd)
all:
make -C $(KDIR) M=$(PWD) modules
clean:
make -C $(KDIR) M=$(PWD) clean
その他/気づき
- bbclass内でdo_install:appendとかの追記が可能
- bbclassを修正後、一度cleanallして実行しないと、キャッシュが利用されるので注意