Downloaded 66 times
![Unity 2018-2019を見据えたDeNAのUnity開発のこれから [DeNA TechCon 2019]](https://cdn.slidesharecdn.com/ss_thumbnails/techcon2019harutootake-190218063853-thumbnail.jpg?width=640&height=640&fit=bounds)
YoctoをつかったDistroの作り方とハマり方
- 1.
- 2. 名前: wata2ki(watatuki) ◦ 元はハードウェアで画像処理をやっていましたが、現在は組 み込み屋をやっています ◦ 最近はJetson-TK1/TX1向けのアンオフィシャルYocto BSP を作り、そのうえでディスクトップ環境や別ボード向けのディス トロを動かして遊んでいます ◦ GitHub https://github.com/watatuki
- 3.
- 4. L.F.(Linux Foundation)のプロジェクトで、正式名称は YoctoProject ◦ https://www.yoctoproject.org/ Linuxのディストリビューションを作るのに必要なツー ル・データを提供 ◦ 最終的にはpokyという名前のリファレンスディストロとして提 供される ◦ OpenEmbedded(http://www.openembedded.org/)コミュニティ 由来のプロジェクトで、ツールも共同開発している GentooLinuxがクロスビルドになったようなもの
- 5. 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に関しては、少なくともビルドが通ることが確認されている (はず。。。)
- 6. Yoctoでは、自分の作りたいディストロをlayerを組み合 わせて構築する 自分の作りたいディストロ meta (oe-corelayer) meta-yocto (yocto layer) meta-jetson (BSP layer) meta-mydistro (my layer) 標準Layer meta-windowmng (layer) BSP Layer ターゲットボード用のカーネルや、ファーム ウェア等 さらに追加したいコンポーネントが入っ たLayerを積み上げる
- 7. 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) 優先度5 glibc(recipe) mesa(recipe) 自分の作りたいディストロ
- 8. 1つのレシピ(.bb)で1つのソフトコンポーネント ◦ gitリポジトリやtarのアーカイブ１個につき1レシピが基本 ◦特定のバージョン/リビジョンを指定する ◦ レシピに追加で当てたいパッチファイルを書くことで、ビルド時に パッチをあてることも可能 ◦ configureオプションを指定することが可能 結構チェックが厳しいので、レシピを作るのは慣れるまでは苦労しま す｡｡｡｡ 既存のレシピに追記することも可能(.bbappend) ◦ 既存のレシピ(たとえばmesa)のconfigureオプションを変えたい時な どに使う 例えば、pokyのmesaレシピはvmrgfx用のドライバが有効になっていない ので、有効にするオプションを追加
- 9. クロスビルド用でないレシピ ◦ imageレシピ 最終的なrootfsイメージの構成を指定するレシピ 「ベースのX11が使えるimageにqtをインストールしたイメージを作る」 といった、最終的に自分の作りたい物を記述する クロスSDKやターゲットSDKも同じように作ることが可能 ◦ バイナリインストール用レシピ SOCベンダ提供のレシピによくあるタイプ OpenGLドライバがバイナリ提供なので、バイナリをダウンロードしてく れる
- 10.
- 12.
- 13.
- 14. recipeは特に問題はない ◦ recipeはソースのバージョンに1:1対応する recipeが指定するソースは勝手に変わることはない ◦ layerは通常git管理されているため、recipeの変更はlayerのリビジョンアップに なる Layer内の正しい組み合わせはgitのコミット単位でコントロールできる layerの組み合わせの正解がない！ ◦ 一般にlayer単位でメンテするコミュニティが違う layer単位でリポジトリを持っている ユーザは自分が使うlayerをそれぞれのリポジトリからもってこないといけない コミュニティが使っているlayerの組み合わせと違う組み合わせにすると、元々ビルド できていたものができなくなる 複数人開発するためには、layerの組み合わせを共有しないといけな い！！
- 15.
- 16. 某T●社のGLSDK ◦ シェルスクリプトを使って、gitclone & checkout リリース用ならいいけど、複数人の開発でこれはないな。。。 某R社のBSP ◦ リリースドキュメント(pdf)にgitコマンドが書いてある もっとひどい！！ いっそ、全部同じgitリポジトリに放りこんでしまおうか。。。 →参照しているリポジトリの更新を取り込むのが大変なので却下
- 17. 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> これだ！!
- 18.
- 19.
- 20. layerの更新を行いつつ、常にディストロがビルドできる状 態を維持できるワークフローを組めるようになった ◦ レシピを書いてlayerのリポジトリにコミット ◦ディストロ全体ビルドの確認ができたらマニフェストを更新 レシピの更新 ローカルでのテスト リポジトリにコミット (push) OK NG レシピ開発 マニフェストの更新 テスト リポジトリにコミット (push) OK NG インテグレータ この時点で全員の共通環 境が初めて更新される この時点では構成管理に登録 されただけで使われない
- 21. Yoctoは便利で強力な仕組みだが、抜けているところもある ◦ Yocto自身は中途半端にしか構成管理の仕組みを持っていないため、 外側でなんとかしないといけない repoを使うことでYoctoの抜けているところを補完できる ◦ Yoctoとrepoをセットで使うといいよ！ ◦ 実例はこちら参照 https://github.com/watatuki/jetson-tk1-yocto-distro https://github.com/watatuki/agl-jetson-tk1 でも一人開発なので、意味はあまりないのであった。。。