Yoctoを使った Linux Distro

の作り方とハマり方wata2ki

自己紹介 名前 : wata2ki (watatuki)

◦元はハードウェアで画像処理をやっていましたが、現在は組み込み屋をやっています

◦最近は Jetson-TK1/TX1向けのアンオフィシャル Yocto BSPを作り、そのうえでディスクトップ環境や別ボード向けのディストロを動かして遊んでいます

◦ GitHub https://github.com/watatuki

概要 今日は、 Yoctoを使ってディストロを作る方法と、それを公開するときに突き当たった問題について発表します

Yoctoとは？ L.F.(Linux Foundation)のプロジェクトで、正式名称は Yocto Project◦ https://www.yoctoproject.org/

Linuxのディストリビューションを作るのに必要なツール・データを提供◦最終的には pokyという名前のリファレンスディストロとして提供される

◦ OpenEmbedded(http://www.openembedded.org/)コミュニティ由来のプロジェクトで、ツールも共同開発している

GentooLinuxがクロスビルドになったようなもの

Yocto(Poky)の提供物とできること bitbake

◦ Yoctoの根幹となるツールで、クロスビルド環境を提供してくれる◦ ディストリビューションの構成するソフトのコンフィグやバージョンを Recipeで管理する

oe-core◦ bitbakeで使うレシピのセットで、 glibc, x.org, waylandからQtまで、様々なOSSを標準でビルドできるようにしてくれる

◦ クロスビルド用の gccも oe-coreが提供してくれる リファレンス BSP

◦ pokyが標準でサポートしているボード向けの BSP Qemu, x86, x86-64, beagleboneなど Linuxのカーネルや U-boot, OpenGL(mesa)をそのボード向けの設定でビルドできるようにするレシピの形で提供される

リファレンス BSPに関しては、少なくともビルドが通ることが確認されている (はず。。。 )

Yoctoのアーキテクチャ Yoctoでは、自分の作りたいディストロを layerを組み合わせて構築する

自分の作りたいディストロ

meta (oe-core layer)

meta-yocto (yocto layer)

meta-jetson (BSP layer)

meta-mydistro (my layer)

標準 Layer

meta-windowmng (layer)

BSP Layer　ターゲットボード用のカーネルや、ファームウェア等

さらに追加したいコンポーネントが入った Layerを積み上げる

Yoctoのアーキテクチャ (layer) Layerはレシピの集合体

◦ Qt5を提供するmata-qt5、自分専用レシピ集など、何らかの共通項でLayerを作るが、最初はあまりこだわらなくても良い

Layerは優先度を持っている◦異なるレイヤに同じレシピが存在した場合は、優先度が高いほうが採用される

◦自分用 Layerは、優先度を高くすると良い

meta-xxx(layer)glibc(recipe)mesa(recipe)x.org(recipe)

meta-xxx(layer) 優先度6 mesa(recipe)

meta(layer) 優先度 5glibc(recipe)mesa(recipe)

自分の作りたいディストロ

Yoctoのアーキテクチャ(recipe)-1 1つのレシピ (.bb)で 1つのソフトコンポーネント

◦ gitリポジトリや tarのアーカイブ１個につき 1レシピが基本◦特定のバージョン /リビジョンを指定する◦レシピに追加で当てたいパッチファイルを書くことで、ビルド時にパッチをあてることも可能

◦ configureオプションを指定することが可能 結構チェックが厳しいので、レシピを作るのは慣れるまでは苦労します｡｡｡｡

既存のレシピに追記することも可能 (.bbappend)◦既存のレシピ (たとえばmesa)の configureオプションを変えたい時などに使う 例えば、 pokyのmesaレシピは vmrgfx用のドライバが有効になっていないので、有効にするオプションを追加

Yoctoのアーキテクチャ(recipe)-2 クロスビルド用でないレシピ

◦ imageレシピ 最終的な rootfsイメージの構成を指定するレシピ

「ベースの X11が使える imageに qtをインストールしたイメージを作る」といった、最終的に自分の作りたい物を記述する

クロス SDKやターゲット SDKも同じように作ることが可能

◦バイナリインストール用レシピ SOCベンダ提供のレシピによくあるタイプ

OpenGLドライバがバイナリ提供なので、バイナリをダウンロードしてくれる

Yoctoを使ったクロスビルド

qt5

KernelOpenGL

busyboxglibc

x.orgbash

qt5-dev

OpenGL-dev

glibc-dev

x.org-devbash-dev

Packages(target)

image

KernelOpenGL

busyboxglibc

x.orgbash

meta

meta-jetson

meta-mydistro

meta-qt5

myimage

qt5

KernelOpenGL

busyboxglibc

x.orgbash

mySDK

recipe/layers

gcc Packages(host)gcc

SDK　image

qt5

KernelOpenGL

busyboxglibc

x.orgbash

qt5-dev

OpenGL-dev

gccglibc-dev

x.org-devbash-dev

Yoctoを使うことで、 recipe/layerからホスト用とターゲット用のパッケージ(rpm,ipk,debが選択可能 )をビルドでき、イメージレシピを使って rootfsイメージにまとめることができる

まじめな発表で使えるスライドはここまで

Yoctoでmyディストロを作ってみた

meta/meta-yocto

meta-linaro

meta-miscellaneous

meta-qt5

image

qt5

Kernel

OpenGL

busyboxglibc

x.org

recipe/layers

gcc

meta-jetson-tk1

jwm

bootconf

meta-lightwm

glmark2

meta-jetson-tk1-distroKernel

Linaroのツールチェインを使うために追加

X.Orgで GPUが使えるBSPレイヤを追加

Qt5を使えるようにしよう

軽量のウインドウマネージャを使いたい

せっかく TegraK1なので、3Dベンチマークも動かしたい

ディストロ専用のカーネルコンフィグで imageを作ろう

jack2

ところが。。。。

meta/meta-yocto

meta-linaro

meta-miscellaneous

meta-qt5

image

qt5

Kernel

OpenGL

busyboxglibc

x.org

recipe/layers

gcc

meta-jetson-tk1

jwm

bootconf

meta-lightwm

glmark2

meta-jetson-tk1-distroKernel

Linaroのツールチェインを使うために追加

X.Orgで GPUが使えるBSPレイヤを追加

Qt5を使えるようにしよう

軽量のウインドウマネージャを使いたい

せっかく TegraK1なので、3Dベンチマークも動かしたい

ディストロ専用のカーネルコンフィグで imageを作ろう

jack2

Gitの特定のハッシュまで戻さないとビルドが通らな

い！！

Qt5おまえもか！！

世の中で Yocto対応 BSP出しているベンダーはどうやってるん

だ？？？

何が問題か？ recipeは特に問題はない

◦ recipeはソースのバージョンに1:1対応する recipeが指定するソースは勝手に変わることはない

◦ layerは通常git管理されているため、 recipeの変更は layerのリビジョンアップになる Layer内の正しい組み合わせはgitのコミット単位でコントロールできる

layerの組み合わせの正解がない！◦ 一般に layer単位でメンテするコミュニティが違う

layer単位でリポジトリを持っている ユーザは自分が使う layerをそれぞれのリポジトリからもってこないといけない コミュニティが使っている layerの組み合わせと違う組み合わせにすると、元々ビルドできていたものができなくなる

複数人開発するためには、 layerの組み合わせを共有しないといけない！！

図で表現するとこんな感じ

meta

meta-linaro

busybox

glibc

x.org

gcc gcc

x.org

busybox

glibc

recipeとソースが 1:1対応しているので、 layerの構成管理で管理できる

ディストロという単位でみると、別々のリポジトリをリンクする方法がない。

世の中のYocto BSPがどうなっているのか調べてみた 某 T●社のGLSDK

◦シェルスクリプトを使って、 git clone & checkout リリース用ならいいけど、複数人の開発でこれはないな。。。

某 R社の BSP◦リリースドキュメント (pdf)に gitコマンドが書いてある

もっとひどい！！

いっそ、全部同じ gitリポジトリに放りこんでしまおうか。。。→参照しているリポジトリの更新を取り込むのが大変なので却下

世の中のYocto BSPがどうなっているのか調べてみた repo

◦ Androidをビルドする人には見慣れたツール◦マニフェストファイル (xml)で、複数の gitリポジトリの組み合わせを表現することができる

<?xml version="1.0" encoding="UTF-8"?> <manifest>

<remote name="yocto" fetch="git://git.yoctoproject.org/" /> <remote name="linaro" fetch="git://git.linaro.org/openembedded/" /> <remote name="qt5" fetch="https://github.com/meta-qt5/" /> <remote name="watatuki" fetch="https://github.com/watatuki/" /> <default revision="master" />

<!-- Yocto Layers --> <project path="poky" name="poky" remote="yocto" revision="b1f23d1254682866236bfaeb843c0d8aa332efc2" /> <project path="meta-linaro" name="meta-linaro.git" remote="linaro" revision="acf4f1f701e07670ec88435897a74f88dbe8ba87" /> <project path="meta-qt5" name="meta-qt5.git" remote="qt5" revision="37693b5357e790665bce4957cb7a8d5d2423390d" /> <project path="meta-jetson-tk1" name="meta-jetson-tk1.git" remote="watatuki" revision="jethro" /> <project path="meta-lightwm" name="meta-lightwm.git" remote="watatuki" revision="master" /> <project path="meta-miscellaneous" name="meta-miscellaneous.git" remote="watatuki" revision="15f549706a316333ba32c90f78df4d70f13cc601" /> <project path="meta-jetson-tk1-distro" name="meta-jetson-tk1-distro.git" remote="watatuki" revision="05b611871a231966d8b8c55b929824895895c926" /> <project path="jetson-tk1-distro" name="jetson-tk1-distro.git" remote="watatuki" />

</manifest>

これだ！ !

図で表現するとこんな感じ (before)

meta

meta-linaro

busybox

glibc

x.org

gcc gcc

x.org

busybox

glibc

recipeとソースが 1:1対応しているので、 layerの構成管理で管理できる

ディストロという単位でみると、別々のリポジトリをリンクする方法がない。

図で表現するとこんな感じ (after)

meta

meta-linaro

busybox

glibc

x.org

gcc gcc

x.org

busybox

glibc

recipeとソースが 1:1対応しているので、 layerの構成管理で管理できる

repoのマニフェストファイルで、異なるリポジトリ間の連携をとることができるようになった

結局何ができるようになったのか？ layerの更新を行いつつ、常にディストロがビルドできる状態を維持できるワークフローを組めるようになった◦レシピを書いて layerのリポジトリにコミット◦ディストロ全体ビルドの確認ができたらマニフェストを更新

レシピの更新

ローカルでのテスト

リポジトリにコミット (push)

OK

NG

レシピ開発

マニフェストの更新

テスト

リポジトリにコミット (push)

OK

NG

インテグレータ

この時点で全員の共通環境が初めて更新される

この時点では構成管理に登録されただけで使われない

まとめ Yoctoは便利で強力な仕組みだが、抜けているところもある

◦ Yocto自身は中途半端にしか構成管理の仕組みを持っていないため、外側でなんとかしないといけない

repoを使うことで Yoctoの抜けているところを補完できる◦ Yoctoと repoをセットで使うといいよ！◦実例はこちら参照

https://github.com/watatuki/jetson-tk1-yocto-distro https://github.com/watatuki/agl-jetson-tk1

でも一人開発なので、意味はあまりないのであった。。。