「pcDuino3」でYocto Project その６

前回からの続きです。

このテーマを最初からご覧になる場合はこちらからどうぞ。

「meta-sunxi」レイヤーの取得

さて、前回までに述べた通り「Yocto Project」で「pcDuino3」用のLinuxディストリビューションを作成するには「meta-sunxi」というレイヤーが必要であることが分かりました。

前々回「VMware Workstation Player」上にインストールした「Ubuntu」を立ち上げましょう。

ログイン後は、キーボードの「Ctrl」+「Alt」＋「T」を同時に押すなどして、ターミナルを起動させます。

次に、以下のコマンドをターミナルで入力してリターンキーを押すことにより「Yocto Project」の実体である「poky」ディレクトリに移動します。

$ cd poky/

続いて「Yocto Project」の動作に必要な環境変数の設定を設定します。

これは「poky」ディレクトリ以下にある「oe-init-build-env」シェルスクリプトを「source」コマンドで実行することによって行います。

もし、前々回「「pcDuino3」でYocto Project その４」からブッ通しで作業してくれている方の場合、これを行う必要はありません。

しかしながら、一度でもターミナルを閉じてしまったり、ましてやLinuxを再起動してしまった場合などは、再びこの手順を行う必要があります。

なお、前々回にこのコマンドを実行した際は「poky」直下に「build」ディレクトリも作成されたはずですが、これは初回だけです。

すでに「build」ディレクトリが作成されている場合には、これを再生成することはなく、単純に環境変数の設定のみが行われます。

$ source oe-init-build-env

上記のコマンドの実行の結果、強制的に「/home/poky」から、その直下の「/home/poky/build」に移動させられてしまっています。

これだと次の手順で都合が悪いので、一個上の「/home/poky」に戻りましょう。

$ cd ..

続いて、件の「meta-sunxi」レイヤーを取得しましょう。

それが何処にあるかは、前回ご紹介した「OpenEmbedded Layer Index」の「meta-sunxi」レイヤーのページに記述があります。

これによると、リポジトリのURLは「https://github.com/linux-sunxi/meta-sunxi.git」ですね。

https://layers.openembedded.org/layerindex/branch/master/layer/meta-sunxi/

これに従い、以下のコマンドを入力します。

$ git clone https://github.com/linux-sunxi/meta-sunxi.git

上記のコマンドの実行の結果「/home/poky」ディレクトリ以下に「meta-sunxi」が生成されたはずです。

ファイル・ブラウザで確認しておきましょう。

お次は、この「meta-sunxi」のリモートブランチ「origin/ｍickledore」をローカルブラン「pcduino3」としてチェックアウトします。

…って、長嶋茂雄さんの会話みたいになってしまいましたね…。

この意味は、前々回「「pcDuino3」でYocto Project その４」を参照してください。

要するに「meta-sunxi」のバージョンを今回使用する「Yocto Project」の少しだけ古いバージョンである「ｍickledore」の時期のものへ先祖返りさせますよ、ってことで。

これを行うためには、生成されたばかりの「meta-sunxi」ディレクトリの中へ移動する必要があります。

以下のコマンドを入力です。

$ cd meta-sunxi/

そして、以下のコマンドでチェックアウトです。

$ git checkout -t origin/mickledore -b pcduino3

チェックアウトが終わったら、一個上の「/home/poky」に戻りましょう。

$ cd ..

さて、前回も説明しましたとおり、レイヤーはディレクトリの配置だけではダメで、そのディレクトリのパスを「/home/yocto/poky/build/conf/bblayers.conf」ファイルに記述する必要があります。

今回の場合、以下の部分に「meta-sunxi」のパスを記述すれば良さそうなのですが…

…これは、非常にお行儀の悪いやり方だそうです。

では、お上品なやり方とは？

それは、レイヤーを操作するための「bitbake-layers」コマンドを使うことです。

それでは、以下のように「bitbake-layers」コマンドを使用して、レイヤーを追加してみましょう。

「bitbake-layers」コマンドに、レイヤーの追加を指示する「add-layer」オプションを加え、そのパスを指定します。

ですが…

$ bitbake-layers add-layer ../poky/meta-sunxi/

エラーメッセージが出て失敗しましたね…。

内容は…

「sunxi」レイヤーは「meta-python」レイヤーに依存するが、このレイヤーはアンタの設定では有効ではない！

…とか何とか。

うむ、どうやら依存関係の問題で「meta-sunxi」の前に他のレイヤーを追加しておく必要があるみたいですね。

これは「bitbake-layers」コマンドがレイヤーの依存関係を検証した結果、出力されたエラーメッセージです。

もし、レイヤーを追加するために直接「/home/yocto/poky/build/conf/bblayers.conf」ファイルを書き換えていたら、このエラーには気が付かずに、後々ドツボにハマっていたかもしれませんね。

そういう意味で、ちゃんと「bitbake-layers」コマンドを使用して、レイヤーを追加するのが正しい…というか、間違いのない作法ということなのでしょう。

では「meta-sunxi」が依存するレイヤーとは？

答えは、先程も開いた「OpenEmbedded Layer Index」の「meta-sunxi」レイヤーのページにあります。

右側の「Dependencies」という欄に注目。

これによると「meta-sunxi」レイヤーは、以下の4つの別のレイヤーに依存しているとのことです。

●openembedded-core

●meta-oe

●meta-python

●meta-arm

というわけで、これらのレイヤーから先に導入しましょう。

依存レイヤーの導入

上記に挙げた「meta-sunxi」が依存するレイヤーを順番に導入していきましょう。

まずは「openembedded-core」レイヤーです。

このレイヤーの導入については、特にやることはありません。

何故ならば「Yocto Project」、すなわち「poky」ディレクトリを生成した時点で既に導入されているからです。

その場所は「/home/poky/meta」ディレクトリです。

「OpenEmbedded」は「Yocto Project」の基となったフレームワークであることは前述のとおりです。

つまり「openembedded-core」レイヤーとは、その上に被せる全てのレイヤーの基底となるレイヤーであると考えてください。

したがって、最初から導入されているんですね。

次に「meta-oe」レイヤーです。

このレイヤーの「OpenEmbedded Layer Index」のページを見てみましょう。

「meta-sunxi」レイヤーのページの右側の依存レイヤーのリストからから「meta-oe」をクリックします。

開かれた「meta-oe」レイヤーのページで、レポジトリのURLがわかります。

「git://git.openembedded.org/meta-openembedded」ですね。

これに従い、ターミナルで以下のコマンドを実行することでダウンロードを行います。

$ git clone https://github.com/linux-sunxi/meta-sunxi.git

ファイル・ブラウザで「meta-openembedded」が生成されているのを確認しましょう。

「meta-oe」っていう名前じゃない理由は、後で述べます。

「meta-sunxi」の時と同様「meta-openembedded」のリモートブランチ「origin/ｍickledore」をローカルブラン「pcduino3」としてチェックアウトします。

以下のコマンドで、生成されたばかりの「meta-openembedded」ディレクトリの中へ移動します。

$ cd meta-openembedded/

以下のコマンドでチェックアウトです。

$ git checkout -t origin/mickledore -b pcduino3

チェックアウトが終わったら、一個上の「/home/poky」に戻りましょう。

$ cd ..

次に「meta-python」レイヤーです。

このレイヤーの「OpenEmbedded Layer Index」のページを見てみましょう。

「meta-sunxi」レイヤーのページの右側の依存レイヤーのリストからから「meta-python」をクリックします。

開かれた「meta-python」レイヤーのページで、レポジトリのURLがわかります。

「git://git.openembedded.org/meta-openembedded」ですね…って、コレさっきの「meta-oe」の時と一緒じゃん！？

これはどういうことか？

種明かしのために「/home/poky/meta-openembedded」ディレクトリをファイル・ブラウザで開いてみてください。

すると、その中に「meta-oe」ディレクトリと「meta-python」ディレクトリが配置されていることが分かります。

これはつまり「meta-openembedded」という、いかにもレイヤーっぽい名前のディレクトリの直下に「meta-oe」、「meta-python」とその他複数のレイヤーが格納されているという状態です。

したがって「meta-python」は既に取得済みであることが分かります。

このような一つのレポジトリに複数のレイヤーが含まれる例は、大規模なカテゴリの場合に、ママ目にすることがありますので、ご用心を。

それでは、ここいらで「meta-oe」と「meta-python」の両レイヤーを「/home/yocto/poky/build/conf/bblayers.conf」ファイルに追加してしまいましょう。

お作法として「bitbake-layers」コマンドに、レイヤーの追加を指示する「add-layer」オプションを加え、そのパスを入力することによって行うのでしたね？

まずは「meta-oe」レイヤーから。

$ bitbake-layers add-layer ../poky/meta-openembedded/meta-oe/

続いて「meta-python」レイヤー。

$ bitbake-layers add-layer ../poky/meta-openembedded/meta-python/

さて、次は「meta-arm」レイヤーです。

このレイヤーの「OpenEmbedded Layer Index」のページを見てみましょう。

「meta-sunxi」レイヤーのページの右側の依存レイヤーのリストからから「meta-arm」をクリックします。

開かれた「meta-arm」レイヤーのページで、レポジトリのURLがわかります。

「git://git.yoctoproject.org/meta-arm」ですね。

これに従い、ターミナルで以下のコマンドを実行することでダウンロードを行います。

$ git clone git://git.yoctoproject.org/meta-arm

ファイル・ブラウザで「meta-arm」が生成されているのを確認しましょう。

続いて「meta-arm」のリモートブランチ「origin/ｍickledore」をローカルブラン「pcduino3」としてチェックアウトします。

以下のコマンドで、生成されたばかりの「meta-arm」ディレクトリの中へ移動します。

$ cd meta-arm/

以下のコマンドでチェックアウトです。

$ git checkout -t origin/mickledore -b pcduino3

チェックアウトが終わったら、一個上の「/home/poky」に戻りましょう。

$ cd ..

次は「meta-arm」レイヤーを「bitbake-layers」コマンドを使って「/home/yocto/poky/build/conf/bblayers.conf」ファイルに追加しましょう。

ここで、一つご注意を。

「OpenEmbedded Layer Index」の「meta-arm」のページを今一度御覧ください。

右側の「Dependencies」という欄によると「meta-arm」レイヤーは、以下の3つの別のレイヤーに依存しているとのことです。

●openembedded-core

●meta-python

●meta-arm-toolchain

このうち「openembedded-core」と「meta-python」に関しては、既に導入済みです。

問題は「meta-arm-toolchain」というレイヤーです。

これをどうやって入手するか？

「meta-arm-toolchain」の表示をクリックしてください。

移動した「meta-arm-toolchain」のページでは、レポジトリのURLが「git://git.yoctoproject.org/meta-arm」となっています。

これは、先程「git clone」とチェックアウトを行った「meta-arm」レイヤーと同一です。

つまりこれは「meta-openembedded」の時と同じような、一つのレポジトリに複数のレイヤーが格納されているタイプなのではないだろうか？…と推測できます。

確認のために「/home/poky/meta-arm」ディレクトリをファイル・ブラウザで開いてみてください。

すると、案の定その中に「meta-arm」ディレクトリと「meta-arm-toolchain」ディレクトリが配置されていることが分かります。

すなわち「meta-arm-toolchain」レイヤーは既に取得済みということが分かります。

では「/home/yocto/poky/build/conf/bblayers.conf」ファイルに「bitbake-layers」コマンドを使って、これらのレイヤーを追加しましょう。

まずは「meta-arm-toolchain」からです。

「meta-arm」が「meta-arm-toolchain」に依存しているので「meta-arm-toolchain」の方が先です。

$ bitbake-layers add-layer ../poky/meta-arm/meta-arm-toolchain/

次に「meta-arm」です。

$ bitbake-layers add-layer ../poky/meta-arm/meta-arm/

これで「meta-sunxi」が依存するすべてのレイヤーの導入が完了したはずですね。

「meta-sunxi」レイヤーの導入

紆余曲折ありましたが、いよいよ当初の目的である「mets-sunxi」レイヤーを導入します。

ディレクトリは既に取得済みで、チェックアウトも終えています。

満を持して「/home/yocto/poky/build/conf/bblayers.conf」ファイルに「bitbake-layers」コマンドを使って「meta-sunxi」レイヤーを追加しましょう。

以下のコマンドを実行します。

$ bitbake-layers add-layer ../poky/meta-sunxi/

ヨシっ！

今度はエラーが出力されることなく導入に成功したみたいですね。

それでは最終確認。

今まで散々「bitbake-layers」コマンドで「/home/yocto/poky/build/conf/bblayers.conf」ファイルにレイヤーを追加してきましたが、正しく出来ているでしょうか？

「/home/yocto/poky/build/conf/bblayers.conf」ファイルを開いて確認してみましょう。

以下のように今までの作業が反映されているでしょうか？

これで「BBLAYERS」という変数に必要なレイヤーのパスが代入されるようになりました。

いよいよ「pcDuino3」用のLinuxディストリビューションをビルドしましょう…と思いますが、まだまだ若干の作業が必要です。

さて、長くなってしまうので、一度区切りましょう。

遅ればせながら…

皆様、明けましておめでとうございます。

本年が皆様によって素晴らしい年になりますように。

＜続く＞

「pcDuino3」でYocto Project その５

前回からの続きです。

このテーマを最初からご覧になる場合はこちらからどうぞ。

「Yocto Project」におけるレシピとは？

「Yocto Project」を使う上で、絶対に避けて通れないのが「レシピ」という概念です。

レシピって聞いて、皆さん何を思い浮かべるでしょうか？

そう、お料理のレシピですよね。

はい、これでもう「Yocto Project」のレシピは理解できたも同然です！

例えば、今晩の夕食はカレーライスにしようと思います。

まず「ご飯」のレシピを想像してみましょう。

「ご飯」を炊くためには、まず、お米が必要です。

お米は、何処で買いましょう？

どうやって、どのくらい研ぎましょうか？

炊飯器にどのくらいの水を入れましょうか？

どのくらいの時間蒸らしましょうか？

…などなど、細かく書くと意外と複雑ですよね。

次に「カレールー」のレシピです。

これは「ご飯」よりも、もっと複雑です。

何処産のターメリックをどれくらい使いましょうか？

何処産のカルダモンをどれくらい使いましょうか？

何処産のシナモンをどれくらい使いましょうか？

何処産のコリアンダーをどれくらい使いましょうか？

辛さは？

…こりゃキリがないですね。

他にも「野菜」や「お肉」の調理方法が書いてあるレシピが、カレーライスを作るためには必要です。

これを「Yocto Project」でLinuxディストリビューションを作る場合に置き換えてみます。

まず「Linuxカーネル」のレシピがあります。

「Linuxカーネル」をビルドするには、ソースコードが必要です。

ソースコードは、どこからダウンロードしましょう？

どのアーキテクチャでビルドしましょうか？

どういったオプションでビルドしましょうか？

どのようなモジュールを追加しましょうか？

…などなど「ご飯」の時と似てますよね。

他にも「ブートローダー」や「BusyBox」など、Linuxが動作するために必要な部材のレシピが存在します。

前回「git clone」して生成された「poky」というディレクトリの中には、これらのレシピがたくさん入っています。

料理のレシピは、紙のメモ等かもしれませんが、そこはLinuxなので「Yocto Project」のレシピはテキストファイル形式で存在しています。

拡張子は「.bb」です。

以下の通り「poky」ディレクトリの下層、たとえば「~/poky/meta/recipes-kernel/」ディレクトリの中には、たくさんのソフトウェアごとのディレクトリがあって…

その中に、それぞれの「.bb」ファイルが存在するのを確認できますね。

興味のある方は、レシピがどういう風に書かれているか、見てみるのも良いかもしれません。

（但し、訳が分かんなくてもヘコタレナイこと！）

「bitbake」コマンドとは？

さて、カレーライスの場合は、私たち自身がレシピを読みながら料理をしなければなりません。

では、Linuxディストリビューションの場合は？

それを行うのが、ビストロ「Yocto Project」の料理長「bitbake」コマンドさんだったのです。

前回、以下のようなコマンドを打ちましたよね？

終わるまでに5時間くらい掛かった例のヤツ。

$ bitbake core-image-minimal

これは、料理長「bitbake」さんに「core-image-minimal」というお料理を注文したことになります。

「bitbake」さん、料理長なのにお客さんの注文取ったり、色々大変なので「グズグズすんな」とか「トロトロしてんじゃねー」とか「ぁくしろよ！」とか言っちゃダメ。

でもって「core-image-minimal」の注文を受けた「bitbake」料理長、厨房に戻ると「core-image-minimal」に必要な食材を買い出しに行きます。

…え、今からかいっ！？

まあ、そういったツッコミは、例え話なんでご勘弁を。

たくさんのレシピに書かれている部材をすべて買い揃えた「bitbake」料理長、厨房に戻って、これまたレシピ通りに各食材を調理していきます。

こうして「bitbake」料理長の大車輪の活躍で出来上がったのが「core-image-minimal」というお料理、すなわち、Linuxディストリビューションとなります。

「Yocto Project」におけるレイヤーとは？

コスプレする人のことじゃないです。

「Yocto Project」には、レシピの他、もう一つ重要な概念「レイヤー」というものがあります。

前回ビルドした「core-image-minimal」は、いわばプレーンなカレーライス、学食の300円のカレーみたいなもんで、なんのヒネリもないシンプルなものです。

（今思うと、アレはアレで美味しかったなぁ。）

これをグレードアップして、カツカレーライスにしたいと思います。

しかし、カツカレーライスを作るためには、ベースのプレーンなカレーライスのレシピに加えて、上に乗せるカツのレシピも必要になります。

カツも一から作るとなれば、結構大変です。

お肉は何処で買えば良いのか？

油の量や温度はどうするのか？

...などなど。

カレーライスとは別の料理として、複数のレシピが必要になりそうです。

これを「Yocto Project」風に言えば、カレーライスの上に、カツのレシピが含まれた、カツの「レイヤーを加える」必要があるわけです。

おまけに、このカツカレーライスに福神漬をトッピングしちゃった日にゃ、ダイコンやらレンコンやら、それらの味付けやらで、複数のレシピが含まれた福神漬の「レイヤーを加える」ことになります。

すなわち、レイヤーとは、ある要素を一纏めにしたレシピの集合体と言えます。

前回作った「core-image-minimal」が、プレーンなカレーライス。

今後、この記事で作ろうとする「pcDuino3」向けの「core-image-minimal」が、カツカレーライス。

このように例えるなら「pcDuino3」向けのLinuxディストリビューションは、前回作った「core-image-minimal」に「レイヤーを加える」ことによって作成することになります。

レイヤーは原則として「meta-xxx」というディレクトリ名が付けられます。

このディレクトリの中に、関連するレシピ、すなわち「.bb」ファイルがたくさん配置されています。

（「.bb」ファイル以外のものもありますが、それは今は気にしないで。）

ディレクトリを配置しただけではダメです。

レイヤーの場所を教えてあげないと「bitbake」料理長、その中のレシピが見れなくて困っちゃう。

それをやっているのが以下のパスの「bblayers.conf」ファイルです。

/home/yocto/poky/build/conf/bblayers.conf

この「bblayers.conf」ファイル、中身はこんな感じのテキストです。

これを見ると、なにやら「BBLAYERS」という変数に、パスのリストを代入しているように見えます。

この代入により「meta」と「meta-poky」と「meta-yocto-bsp」の3つレイヤーが登録されていることになります。

わずか3つ！

すなわち、前回作った「core-image-minimal」は、非常に少ないレイヤーで構成されていたことが分かります。

そりゃ学食の300円カレーだもの…。

「meta-sunxi」レイヤー

さて「pcDuino3」用のLinuxディストリビューションを作るために必要なレイヤーを手に入れなければなりません。

ところで「pcDuino3」のような名の通ったボードでLinuxを動かすために、白紙の状態から独自のレシピを書いてレイヤーを作ることは、まず無いと思います。

そういったものは、大概はコミュニティの方々が既に開発して、公開している上にメンテナンスまでやってくれています。

本当にありがたいですよね。

お仕事で独自のLinuxボードを作って、それにLinuxを動かす場合でも、使用したCPUのベンダーが必要なレシピやレイヤーを提供していることがほとんどで、最小限のカスタマイズで移植可能です。

では「pcDuino3」に必要なレイヤーがどこにあるか？

結論から言うと、まず以下の「meta-sunxi」レイヤーのページを御覧ください。

このページは「Yocto Project」の元となった、組み込み機器用のLinuxディストリビューションを作るためのソフトウェアフレームワーク「OpenEmbedded」がサポートする、公式の各種レイヤー情報ページです。

そして、このページの「Machines」タブをクリックしてください。

https://layers.openembedded.org/layerindex/branch/master/layer/meta-sunxi/

このページを下の方へスクロールしますと…。

「pcduino3」という表記がありますね。

どうやら、このレイヤーを使えば良いらしいことが分かります。

因みに「sunxi」って何？って思いますよね。

これは「pcDuino3」に搭載されている、中国Allwinner Technology社のCPUシリーズの型番に由来します。

「pcDuino3」に搭載されているものは「A20（sun7i）」です。

他にも、このシリーズには「A10 (sun4i）」や「A13 (sun5i）」などが存在します。

つまり「sunxi」の「x」は、型番の番号のアスタリスクになっているわけです。

スンシィー、寸志！？…なんか中国語っぽい意味かと思ったけど違ったみたい。

さて、今回は作業無くウンチクだけで終了。

次回から、実際にこのレイヤーをどのように「Yocto Project」に組み込むか？をやっていきたいと思います。

＜続く＞

「pcDuino3」でYocto Project その４

前回からの続きです。

このテーマを最初からご覧になる場合はこちらからどうぞ。

「Yocto Project」の構築

前回「VMware Workstation Player」上にインストールした「Ubuntu」を立ち上げましょう。

ターミナルを起動します。

キーボードの「Ctrl」+「Alt」＋「T」を同時に押すと楽です。

Linuxを扱うと、どうしてもターミナル（コマンドライン）での作業が多くなります。

アレルギーのある方は、今のうちに慣れておきましょう。

さて「Yocto Project」を動作させるには、いくつかのプログラムを予めインストールしておくことが前提となります。

それがまた、エラい数です。

早速、これらをインストールしましょう！

下のコマンドをコピーして「Ubuntu」のターミナルにペーストしてリターンキーを押しましょう。

（頭の「$ 」以降をコピーしてください。）

Winodowsから「VMware Workstation Player」上の「Ubuntu」へコピー・アンド・ペーストできますし、逆もまた可です。

• $ sudo apt install gawk wget git diffstat unzip texinfo gcc build-essential chrpath socat cpio python3 python3-pip python3-pexpect xz-utils debianutils iputils-ping python3-git python3-jinja2 libegl1-mesa libsdl1.2-dev python3-subunit mesa-common-dev zstd liblz4-tool file locales

ね！エラい数でしょ？

こんなのイチイチ打ってられるかっ！

パスワードの入力が求められます。

「yocto」でしたね。

「sudo」は、以降のコマンドを管理者権限で実行させるコマンドで「apt install」というのが、以降に続くプログラムをダウンロード、インストールするコマンドです。

以下の画面では、作業を続行して良いかどうかを問われています。

ここは、リターンキーを押します。

作業中…。

意外と速く進みます。

ダウンロードとインストールが終わると、以下の表示になります。

次に、UTF-8ロケールの設定を行います。

要は文字コードの設定なのですが「Yocto Project」はUTF-8じゃないとトラブるようです。

以下のコマンドを入力してリターンキーを押します。

$ sudo locale-gen en_US.UTF-8

いよいよ「Yocto Project」をダウンロード／インストールします。

以下のコマンドを入力してリターンキーを押します。

$ git clone git://git.yoctoproject.org/poky

地味に時間がかかる感じ？

終了した模様。

以下のコマンドで、現在のホームディレクトリに「poky」というディレクトリが生成されたことが確認できます。

これが「Yocto Project」の実体です。

$ ls -l

では、その中に突入！

ターミナルに「$ cd poky/」と入力してリターンキーを…と、その前に豆知識。

例えば、今回のようにターミナルでディレクトリを打ち込む機会って今後も結構あると思います。

今回の場合「cd po…」まで打ってから「Tab」キーを押してください。

そうすると、勝手に残りの「…ky/」が補完されます。

これは「タブ補完」と呼ばれているもので、現在のディレクトリ直下の存在するディレクトリやファイルの候補を自動的に補完してくれる機能です。

（存在しない場合は、何も起こりません。）

つまり、目的のディレクトリやファイルの頭から2～3文字だけ入力して「Tab」キーを押すことで名前が補完されるので、長いパスをタイピングする必要がなくなります。

これなら、ターミナルでのキー入力の回数が大幅に減って、大変楽になります。

実は私、若かりし頃Linuxを触りだしてから、かなり長いことこの機能を知りませんでした。

そして立派なターミナル・アレルギーになってしまいました。

でも、これを知ってからターミナルが大好き…にはなってませんがね。

まあ、…普通？

さて、話を戻して。

ターミナルに「$ cd poky/」と入力してリターンキーです。

$ cd poky/

ここで思案のしどころ…。

一口に「Yocto Project」と言っても、ソフトウェアなので古いのやら新しいのやら、色々とバージョンがあります。

このページに一覧表があります。

どれを選びましょう？

ソフトウェアというものは、新しいほど良いという訳ではありません。

とはいえ、古すぎては「pcDuino3」に新しいディストーションを！…という、今回の趣旨に反します。

「Yocto Project」は、経験上、サポートが終わったばかりの状態が一番安定している気がします。

（最近は違うのかも？）

というわけで、今回は「Mickledore」というのを選びます。

「Mickledore」＝ミクルドア…、イギリスにある山の名前みたいですね。

以下のコマンドを入力してリターンキーを押します。

$ git checkout -t origin/mickledore -b pcduino3

このコマンドは、説明が必要かもしれません。

通常「git clone」コマンドでダウンロードされるソースコードやドキュメント類は、公開されている最新のものとなります。

しかしながら、今回は少し古い「Mickledore」を使用したいのです。

そのためには、ダウンロードされたソースコードやドキュメント類をその「時期」のものに先祖返りさせる必要があります。

この「時期」を指すのがリモートブランチと言って、上記のコマンドでは「origin/ｍickledore」の部分にあたります。

そして「origin/ｍickledore」のスナップショットをダウンロードしたソースコードやドキュメント類に反映させます。

これを「checkout」と呼びます。

リモートブランチ「origin/ｍickledore」は、管理者によって今後も変更されるかもしれません。

一方「checkout」したスナップショットは、今後、私達が変更するかもしれません。

この時点で「origin/ｍickledore」は分岐したことになります。

文字通りブランチ「枝」別れという訳です。

本家の「origin/ｍickledore」は、リモートブランチとして今後も「Yocto Project」のGitサーバで管理されます。

スナップショットは「pcduino3」という新たな名前のローカルブランチとして私達の開発用PCの中で管理していきます。

…とまあ、分かりにくい説明で申し訳ありません。

要は、ダウンロードした最新の「Yocto Project」を少し古いバージョンに戻したよ！ってコトで。

次に「Yocto Project」の動作に必要な環境変数の設定と「build」ディレクトリを作成します。

以下のコマンドを入力してリターンキーを押します。

環境変数が設定され、さらに「build」ディレクトリが作成されて、そこに移動した様子が分かります。

$ source oe-init-build-env

「Ubuntu」のエクスプローラーで見ても「poky」ディレクトリ以下に「build」ディレクトリが出来ていますね。

さてさて、早速「Yocto Project」の試運転と行きましょうか。

そこで、ちょっと相談があるんですが…。

今、このページを読んでくれて、実際に試そうと思っている方！

今何時ですか？

…というのも、次のコマンドは終了までにとても長い時間がかかります。

試運転ですから、最小限の軽いLinuxディストリビューションを作ろうと思っています。

まずは、いきなり「pcDuino３」用ではなく、デフォルト設定の「x86-64」アーキテクチャ用、すなわち普通のPC向けのディストリビューションです。

それでも、開発用PCのスペックと、ネットの環境によっては5時間以上は覚悟です。

「Yocto Project」のビルドツールである「bitbake」は、相当に処理が重いため、その間はPCをほぼ専有されてしまいます。

ですので、次のコマンドは就寝前に実行することをオススメします。

朝起きれば、きっとディストリビューションのビルドが成功しているはずですよ。

普段の行いが良ければ。

…というわけで、布団の入る前に、以下のコマンドを入力してリターンキーを押します。

$ bitbake core-image-minimal

なにやら、始まりましたよ～。

これは、ディストリビューションに含まれる様々なソフトウェアのソースコードをダウンロードしてはビルドする...ということを延々と繰り返しているようです。

そして、就寝！！

…

…

起床！！

眠い目を擦りながらも、すかさず開発用PCの画面を確認。

よし！どうやらディストリビューションのビルドに成功したみたいです。

エラーが出た時って、真っ赤なエラーメッセージがビッシリ出力されるので一目で分かります。

ビルドの成果物は、以下のパスに生成されています。

階層、深すぎですね…。

/home/yocto/poky/build/tmp/deploy/images/qemux86-64

タイムスタンプを見てみると、ディストリビューションのイメージファイルの生成時間が「4:50」くらい。

「bitbake」コマンドを打ったのが昨晩「0:00」くらいだったので、やっぱり5時間コースですね。

仕事でLinuxを扱っていた頃、今回のように会社で帰宅時に「bitbake」コマンドを打って、夜通しビルドを行うことがよくありました。

それで、翌朝出社して画面を見ると、大量のエラーが出てビルド失敗。

その日の出鼻を挫かれた感じで、一日中スッキリしない気分…なんてことは、組み込みLinuxエンジニアあるあるです。

エラーの原因は、色々あります。

単純にパラメータの入力ミスとかなら分かるのですが、ネットワークの切断だったり「Ubuntu」のフリーズだったり、はたまたソースコードのダウンロード元のサーバが落ちていたりなどなど、納得いかない理由であることもしばしば…。

どうやら、今回構築した「Yocto Project」は、正常に動作してくれたようです。

さて、今回はここまで。

今回は試運転だったので「pcDuino3」では動かないディストリビューションを作りました。

次回以降は、これを「pcDuino3」で動くようにする作業をやっていきましょう。

＜続く＞