前回からの続きです。
このテーマを最初からご覧になる場合はこちらからどうぞ。
「core-image-sato」のビルド(完結編)
試行錯誤の末、前回までに「core-image-sato」のbitbakeまで漕ぎ付けました。
長いビルド時間をかけて、ようやく絵の出せるディストリビューションを完成させたと思いきや…。
出来上がったイメージをSDカードにコピーし「pcDuino3」に挿入、起動させましたが、以下の画面でフリーズという残酷な結果。
このスプラッシュスクリーンは「core-image-minimal」の時には出ていなかったので、全くダメというわけでもないのでしょうけど…。
何が悪いんだろう？
再びネット検索で調査します。
キーワードは「meta-sunxi」など、問題の有りそうなレイヤーやレシピの名前を使うと良いです。
すると、このページが引っかかりました。
これは、Chelさん（って言うのかな？）のブログで「pcDuino3」と同じくAllWinner製のプロセッサを搭載している「Cubieboard2」というボードで「Yocto Project」を使用した際の記録です。
このように、自分が使おうとしているボードと同じプロセッサの情報でも、案外良いヒントになったりします。
この情報を使わせていただきましょう。
Chelさん、ありがとうございます！
さて、このページの情報によると「core-image-sato」を動かすために更に必要な作業は、以下の通りです。
◯「local.conf」へ必要なパラメータの追記
◯「sunxi-mali_git.bb」の修正
◯「gstreamer1.0-plugins-base_%.bbappend」ファイルの作成
まずは「local.conf」へ必要なパラメータの追記からやってみましょう。
パスは、以下の通り。
/home/yocto/poky/build/conf/local.conf
最終的に、以下のように追記しました。
- ...
- #
- # for pcDuino3
- #
- #CORE_IMAGE_EXTRA_INSTALL += "nodejs nodejs-npm openssh git"
- PACKAGECONFIG:remove_pn-xserver-xorg = "glamor"
- XSERVER:append = " xserver-xorg-extension-glx xf86-video-modesetting xf86-video-fbdev"
- XSERVER:remove = "xf86-input-keyboard xf86-input-mouse"
- IMAGE_FEATURES += "x11"
- DISTRO_FEATURES:append = " opengl x11"
- DISTRO_FEATURES:remove = "wayland"
- MACHINEOVERRIDES .= ":use-mailine-graphics"
- VOLATILE_LOG_DIR = "no"
この内「XSERVER:remove =」の行は、前回の修正。
「MACHINEOVERRIDES .=」の行は、こちらのREADMEを根拠に。
「VOLATILE_LOG_DIR =」の行は、こちらにある通り、「/var/log」以下のログを保存しておきたかったので追記しています。
これ以外は、ほぼChelさんの情報から必要と思われるものを抜粋しています。
追記が終わったら「local.conf」の保存をお忘れなく！
次に「sunxi-mali_git.bb」の修正です…ってこのファイル前回も修正しましたよね？
まだ足りないってか？
パスは、以下の通り。
/home/yocto/poky/meta-sunxi/recipes-graphics/libgles/sunxi-mali_git.bb
ここでは、ファイルの最後の方、一行だけ修正します。
わかりにくいかもしれませんが「RPROVIDES:${PN} +=」の行を「#」でコメントアウトして、その直下に新たに「RPROVIDES:${PN} =」の行を付け加えています。
- ...
- # Packages like xf86-video-fbturbo dlopen() libUMP.so, so we do need to ship the .so files in ${PN}
- PACKAGES =+ "${PN}-test"
- #RPROVIDES:${PN} += "libGLESv2.so libEGL.so libGLESv2.so libGLESv1_CM.so libMali.so"
- RPROVIDES_${PN} = "libGLESv1_CM.so libGLESv2.so libEGL.so"
- #RDEPENDS:${PN}-test = "${PN}"
- FILES:${PN} += "${libdir}/lib*.so"
- FILES:${PN}-dev = "${includedir} ${libdir}/pkgconfig/*"
- FILES:${PN}-test = "${bindir}/sunximali-test"
- ...
変数に「+=」 とした場合、元の変数の中身に加えて、これ以降に表記する要素を加えます。
対して「=」の場合は、元の変数の中身に関係なく、これ以降に表記する要素をそのまま代入します。
つまり、元の表記では余計なものが「RPROVIDES」変数に加えられてしまうのでしょう。
修正が終わったら「sunxi-mali_git.bb」の保存をお忘れなく！
最後に「gstreamer1.0-plugins-base_%.bbappend」ファイルの作成です。
この長ったらしい名前のファイル、以下のディレクトリに作成します。
/home/yocto/poky/meta-sunxi/meta-sunxi/recipes-multimedia/gstreamer/
この「gstreamer1.0-plugins-base_%.bbappend」ファイルの中身は、以下のように表記します。
- RDEPENDS_libgstgl-1.0 += "sunxi-mali"
- RDEPENDS_${PN}-opengl += "sunxi-mali"
これまでの経験からレシピ・ファイルの拡張子は「.bb」であることがお分かりでしょう。
今回の「.bbappend」ファイルというのは、同名のレシピ・ファイル「.bb」の後にbitbakeにより解析され、同名のレシピ・ファイル「.bb」の中で行われた内容を変更したり、補完したりするものです。
例えば、どこかのレイヤーに「hogehoe.bb」というレシピがあって、その中で「HOGEHOGE = "fuga"」とあるとします。
このとき、どこかのレイヤーに「hogehoe.bbappend」というファイルがあって、その中で「HOGEHOGE = "piyo"」とあった場合、最終的に「HOGEHOGE 」変数は「"piyo"」となります。
一方、「hogehoe.bb」というレシピがあったとしても、その中で「HOGEHOGE 」変数の操作が行われていない場合を考えてみましょう。
このケースでは「hogehoe.bbappend」というファイルがあって、その中で「HOGEHOGE = "piyo"」とあった場合は、この内容で「HOGEHOGE 」変数が定義されることになります。
この「.bbappend」ファイルというのは、元のレシピ・ファイルを不用意に変更したり、汚さないようにするために多様されます。
今回の場合「gstreamer1.0-plugins-base_x.xx.x.bb」は、恐れ多くも「Yocto Project」の根幹であり、最上位のレイヤーである「meta」に属するレシピです。
/home/yocto/poky/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_1.22.6.bb
サードパーティとしては、自分の都合でこれを書き換えてもらえるはずもない（ボードやベンダーごとにそんなことやってたら収集が付かなくなる）ので、このような変更方法を採ります。
また「gstreamer1.0-plugins-base_%.bbappend」の「%」は、ワイルドカードです。
レシピ・ファイルは、名前の後にリビジョン番号が付くことがあります。
つまり今回の場合は、全てのリビジョンの「gstreamer1.0-plugins-base」に適応される「.bbappend」ファイルという意味になります。
さて、これで修正作業は完了。
以下のコマンドで「core-image-sato」をbitbakeします！
うぉりゃ、行け～ぃ！！
$ bitbake core-image-sato
今回はそんなに時間はかからないはず！
…
というわけでbitbake無事終了！！
以下のディレクトリを確認すると…
/home/yocto/poky/build/tmp/deploy/images/pcduino3/
ちゃんと「core-image-sato-pcduino3.wic.gz」というのが出来ていますね！
こちらの記事を参考にSDカードを作成して「pcDuino3」を起動させましょう。
簡単におさらいすると…。
まずは、以下のコマンドで圧縮されている「core-image-sato-pcduino3.wic.gz」を解凍。
$gunzip -k -f ./tmp/deploy/images/pcduino3/core-image-sato-pcduino3.wic.gz
以下のディレクトリで解凍された「core-image-sato-pcduino3.wic」を確認してください。
/home/yocto/poky/build/tmp/deploy/images/pcduino3/
ここでパソコンにSDカードを挿入して、以下のコマンドでUbuntuに何処に認識されたかを確認します。
$ df
今回の場合「/dev/sdb1」が「/media/yocto/boot」、「/dev/sdb2」が「/media/yocto/c748ecdf-46b6-4795-82ca-bb519c856946」として認識されていますね。
これは、私の環境の場合ですので、みなさん各自必ず確認してください。
SDカードにOSのイメージを書き込む前に、これらをアンマウントする必要があります。
今回の場合は、そのコマンドは以下の通りです。
$ sudo umount /media/yocto/boot
$ sudo umount /media/yocto/c748ecdf-46b6-4795-82ca-bb519c856946
SDカードへアクセスするための権限を付与します。
今回の場合、SDカードは「sdb」と認識されていたので、以下の通り。
「b」の部分は環境によって異なる可能性がありますので注意。
$ sudo chmod 666 /dev/sdb
いよいよ以下のコマンでOSイメージの書き込みです。
$ oe-run-native bmap-tools-native bmaptool copy ./tmp/deploy/images/pcduino3/core-image-sato-pcduino3.wic /dev/sdb
書き込みが終了したら、SDカードを正しくパソコンから取り出し「pcDuino3」に挿入して、電源投入です！
今度は、上手くいくはず！！
冒頭のスプラッシュスクリーンでフリーズすることなく、無事に起動…、いや、でもヤケに地味な画面ですな！
これが佐藤さん？
操作にはマウスが使えますので「pcDuino3」に挿入しましょう。
デスクトップと思われる画面には、いくつかのアイコンが…。
「Media Player」っていうのは、ちょっと気になる。
これだけしか無いの？
苦労したのに、淋しいねぇ。
おっと、右上に何かリンクっぽいものが？
これをクリックすると…。
おお！ゲームと思しきアプリのアイコンが沢山現れました！！
ちょっと遊んでみようかな…。
これは、アレだ…パネルをずらしていって、1から15まで並べるヤツ。
「Fiteen」っていうのか～？
お馴染みのマインスイーパー「Mines」。
こちらもお馴染み、さめがめ。
…一瞬、何だか分からなかった。
「Samegame」です。
数独もありました！
これは時間の経つのを忘れちゃう系。
その他にも、遊び方が分からないものも含めて多くのゲームが入っていました。
すべて単純なものではありますが、デモンストレーションとしては親しみやすいですね。
さて、これで無事に絵の出るディストリビューション「core-image-sato」を「pcDuino3」上で動かすことができました。
これまで御覧頂いた通り「Yocto Project」でのディストリビューション作成は、相当に難易度が高いです。
マスターしようとしても、特に初期の段階では成長曲線の上がりは鈍いです。
しかしながら、bitbake中に起こるエラーには一定のパターンがあり、過去のエラーの内容と回避方法を覚えておけば、次に同じ問題に遭遇したときに応用が効くため、その後の作業は楽になっていきます。
また、今回のように自分の力だけではどうにもならない場合は、必要な情報をネットで検索するためのコツを掴むことによって、問題解決へと繋げることもできます。
そこに行き着くまでの道のりが長いことが課題と言えます。
しかしながら、NXPにせよ、TIにせよ、Renesasにせよ、STMicroもそうだったかな？
アプリケーションプロセッサのベンダーは、自社のプロセッサを搭載した評価ボードをリリースしており、そのためのレイヤーやレシピを提供しています。
つまり、これらをリファレンスとして利用する製品開発のためには「Yocto Project」を使用することが前提となっているのです。
組み込みエンジニアとして働いていれば、いつ「Yocto Project」を使用しなければならない案件が飛び込んでくるとも限りません。
事前に、今回の「pcDuino」や、メジャーどころの「Raspberry Pi」などで「Yocto Project」に慣れておいて損はないはずです。
Yocto関連の記事は、今回で終了です。
長々とお付き合いくださいまして、ありがとうございました。
今後は「Raspberry Pi5」などで、もっと深いレベルで「Yocto Project」を使用する例などもトライしたいと思います。
…むしろ「pcDuino3」などのマイナーなボードよりも情報量が多いので、最初から「Raspberry Pi5」にしておけば…って、後の祭りです！！
＜終わり＞
