TOPPERS/ASP - Arduino UNO R4版 その６

前回からの続きです。

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

プロジェクトの作成

前々回までの作業で、開発環境をインストールし、Arduino UNO R4版TOPPERS/ASPのソースコードをダウンロードし、それに雛形プロジェクトから抜き出したソースコードを補填し、それをCygwinターミナルでビルドするまでを行いました。

そこで、今回は「e2 studio」上でTOPPERS/ASPのビルドが行えるようにプロジェクトを作成しましょう。

まずは「e2 studio」を立ち上げて下さい。

そして、画面左上のメニューから「ファイル」→「新規」→「プロジェクト」の順にクリックしていきましょう。

以下のダイアログが表示されたら、リストボックスの中の「c/c++」ディレクトリのアイコンをクリックしてください。

すると「c/c++」ディレクトリの以下の項目が展開されます。

今度は「Makefile Project with Existing Code」の項目をクリックして選択し、ダイアログ下部の「次へ」ボタンをクリックします。

ダイアログが以下の表示に切り替わったら必要事項を入力します。

ここでは、以下の通り。

プロジェクト名：＜任意のプロジェクト名（ここでは「asp_1.9.2」）＞

既存のコードの場所：C:\cygwin64\home\＜ユーザ名＞\asp_1.9.2

インデクサー設定に対するtoolchain：＜なし＞

入力が終わったら「終了」ボタンをクリックします。

その後は元の画面に戻ります。

もし「e2studio」が「FSP Configuration」モードになっている場合は「C/C++」モードに切り替えましょう。

この切り替えは、画面右上の「C/C++」ボタンで行います。

クリックしてみましょう。

左側の「プロジェクト・エクスプローラー」というタブの中には、元からあった「Hinagata」プロジェクトのディレクトリと、先程入力したプロジェクト名（つまりは「asp_1.9.2」）のディレクトリが追加され、表示されているはずです。

次に、画面上部のメニューから「ウィンドウ」→「ビューの表示」→「ビルドターゲット」の順にクリックしていきましょう。

これにより、画面下右側のウィンドウに「ビルドターゲット」タブが追加されたはずです。

以降の作業は、このページ（TOPPERS/ASPのビルドからデバッグまで～サンプルプロジェクトのデバッグ）の「プロジェクトのクリーンとビルド」の項目を参考に続行してください。

この「e2 studio」は、Eclipseベースなので、上記のページと同じ方法で作業を続行できます、

但し、文中の「Makeターゲット」タブは、先程表示させた「ビルドターゲット」タブに置き換えてお読みください。

名称は違いますが、これらのタブは同じ働きをするものです。

「e2 studio」の画面右側に以下のようなアイコンが表示されて、これらをダブルクリックすることによりビルドができるまでを確認してください。

「realclean」や「all」など、アイコンをダブルクリックすることにより、その操作に応じたメッセージが画面下部の「コンソール」タブ内に表示されるはずです。

次回はいよいよ実機へプログラムを転送して、実行／デバッグを行っていきます！

＜続く＞

「pcDuino3」でYocto Project その７

前回からの続きです。

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

「local.conf」の更新

いよいよ「pcDuino3」のLinuxディストリビューションをビルドしたいと思うのですが、最後の…というより最も重要な作業が残っています。

それは「local.conf」というファイルを「pcDuino3」のための内容に更新することです。

その「local.conf」が何処にあるかというと、以下のパスに生成されているはずです。

/home/yocto/poky/build/conf

このファイルは「Yocto Project」を導入した後に初めて「$ source oe-init-build-env」を実行した際に生成された「build」ディレクトリに含まれています。

内容は、以下の通り…といってもゴチャゴチャしていて難しそうです。

今はあまり深入りせずに「pcDuino3」のディストリビューションを作るための要点だけに集中しましょう。

まずは、以下の箇所をご覧ください。

「local.conf」の16行から始まる「Machine Selection」という部分からです。

最後の行にご注目。

なにやら「MACHINE」という変数に「qemux86-64」という文字列を代入していますね。

1. #
2. # Machine Selection
3. #
4. # You need to select a specific machine to target the build with. There are a selection
5. # of emulated machines available which can boot and run in the QEMU emulator:
6. #
7. #MACHINE ?= "qemuarm"
8. #MACHINE ?= "qemuarm64"
9. #MACHINE ?= "qemumips"
10. #MACHINE ?= "qemumips64"
11. #MACHINE ?= "qemuppc"
12. #MACHINE ?= "qemux86"
13. #MACHINE ?= "qemux86-64"
14. #
15. # There are also the following hardware board target machines included for
16. # demonstration purposes:
17. #
18. #MACHINE ?= "beaglebone-yocto"
19. #MACHINE ?= "genericx86"
20. #MACHINE ?= "genericx86-64"
21. #MACHINE ?= "edgerouter"
22. #
23. # This sets the default machine to be qemux86-64 if no other machine is selected:
24. MACHINE ??= "qemux86-64"

これは、「QEMU」というオープンソースのエミュレータ（今使っている「VMware」みたいなものですね！）で動作するのインテルx86-64アーキテクチャ用のLinuxディストリビューションを選択する、という意味です。

つまり「Yocto Project」は、デフォルトの状態で「bitbake」すると「QEMU」用のディストリビューションが作成されるということになります。

このことから、この「local.conf」というファイルは、作ろうとしているLinuxディストリビューションの各種設定を記述するファイルであると推測できます。

というわけなので「local.conf」を「pcDuino3」で動くようなLinuxディストリビューションを作成できるように修正していけばよいのです。

まずは手始めに、今「qemux86-64」となっている「MACHINE」変数を変更する必要があります。

ところで、この「qemux86-64」という文字列の根拠は何でしょうか？

実は、これは同名の設定ファイルを意味しています。

前回のレイヤーの話で触れた「meta～」というディレクトリ。

これらの中には「conf」というディレクトリと、その下に「machine」というディレクトリを持つものがあります。

例えば「meta」というディレクトリの中には「conf」というディレクトリがあって、さらにその下に「machine」というディレクトリが存在します。

この中には、多くの設定ファイル「～.conf」が置かれており、デフォルトで「MACHINE」変数に設定されている「qemux86-64.conf」も存在しています。

/home/yocto/poky/meta/conf/machine

興味のある方は、この設定ファイルの中を覗いてみてください。

つまり「pcDuino3」用の設定ファイルを見つけて、そのファイル名を「local.conf」の中で「MACHINE」変数に代入すればよさそうです。

いままでの作業で、この設定ファイルが存在してそうなレイヤー、もしくは「mata～」ディレクトリといえば…「meta-sunxi」あたりが臭そうですね。

というわけで「meta-sunxi」ディレクトリを開いてみると…あった！

「meta～/conf/machine」のパターンです！

/home/yocto/poky/meta-sunxi/conf/machine

この中に「pcDuino3」用の設定ファイルがあれば楽なんだけど…。

あーありました！！

その名もズバリ「pcduino3.conf」！

/home/yocto/poky/meta-sunxi/conf/machine

では、この「pcduino3.conf」を「MACHINE」変数に代入するよう「local.conf」を修正しましょう。

「local.conf」の37行から、以下のように修正して保存してください。

1. #
2. # This sets the default machine to be qemux86-64 if no other machine is selected:
3. MACHINE ??= "pcduino3"
4. #MACHINE ??= "qemux86-64" コメントアウト

「pcDuino3」用ディストリビューションのビルド

それでは、早速「pcDuino3」用のLinuxディストリビューションをビルドしましょう！

「/home/yocto/poky/build」に移動して以下のコマンドを入力します。

エラーが出る場合は、ホームから「$ cd poky/」でpokyディレクトリへ移動して「$ source oe-init-build-env」で環境変数を設定するのをお忘れなく！

$ bitbake core-image-minimal

以前にも味わったので嫌な思い出があるかもしれません。

そう…これは終了までに物凄い時間がかかるのです。

というわけで、今日は寝ちゃいましょう…。

....

zzzz

....

起床！

警告は出ているものの無事終了のようです。

以下のディレクトリを開いてください。

色々できてると思います。

/home/yocto/poky/build/tmp/deploy/images/pcduino3

「pcDuino3」起動用SDカードの作成

さて、今回はこのできあがったLinuxディストリビューションのイメージファイルを「bmaptool」というコマンドでSDカードに書き込みたいと思います。

イメージファイルを書き込んだSDカードを「pcDuino3」に挿入して、Linuxを起動させようという目論見です。

この「bmaptool」で使用するイメージは「WIC」形式（「～.wic」）のファイルでなければいけません。

「core-image-minimal-pcduino3.wic.gz」っていう、それっぽいファイルがありますね。

/home/yocto/poky/build/tmp/deploy/images/pcduino3

このファイルは圧縮されているようですので、解凍しましょう。

以下のコマンドです。

元の「～.wic.gz」ファイルを残す場合は「-k（--keep）」、このファイルはリンクされており、それを強制的に解凍するので「-f（--force）」オプションを付けましょう。

$ gunzip -k -f ./tmp/deploy/images/pcduino3/core-image-minimal-pcduino3.wic.gz

すると「/home/yocto/poky/build/tmp/deploy/image/pcduino3」に「core-image-minimal-pcduino3.wic」というファイル名で「WIC」形式のイメージファイルが解凍されました！

/home/yocto/poky/build/tmp/deploy/images/pcduino3

イメージファイルは準備OK。

あとは、これをSDカードに書き込むためのツール「bmaptool」の調達が必要です。

これは、Linuxディストリビューションと同じく「bitbake」コマンドを使用してビルドします。

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

とかく待たされる印象が強い「bitbake」コマンドですが、今度はすぐに終わりますのでご安心を。

$ bitbake bmap-tools-native

次に、マイクロSDカードを用意します。

加えて、これをお使いのパソコンに接続するためのアダプタが必要になります。

私は、こんなのを買ってきました。

USBのコネクタ部分にマイクロSDカードを差し込むようなタイプですが、これって、下手をするとパソコン側のUSBの口にマイクロSDカードが取り残されそうで怖いんだよなぁ…。

マイクロSDカードを挿入したアダプタをパソコンに接続します。

すると、以下のようなダイアログが表示されますので「仮想マシンに接続」を選択して「OK」ボタンをクリックします。

以下のような表示も出るかもしれませんが、これも「OK」ボタンをクリックして閉じちゃってください。

Ubuntu上のファイル・ブラウザの左側に、認識されたマイクロSDカードが表示されましたでしょうか？

以下の例では「16 GB Volume」と表示され、認識されていることが分かります。

この「16 GB Volume」の表示の部分にマウスカーソルをしばらく乗せておくと、マウントされたディレクトリのパスが表示されます。

続いてターミナルに戻り、以下のコマンドを実行します。

これにより、先程のディレクトリのパスの行に「/dev/sdb1」と表示されているので、このマイクロSDカードは「/dev/sdb」という仮想ファイルとしてシステムに認識されたことが分かります。

他のデバイスの接続状況によっては「sdb」ではない可能性もありますので、この部分はよく確認してから作業を行ってください。

$ df

上記のコマンドの結果、現在マイクロSDカードは「/media/yocto/DDEB-8DCA」というディレクトリとしてマウントされていることが分かります。

この「DDEB-8DCA」の部分は識別子であり、マイクロSDカードによって異なりますので、こちらも要確認です。

とにかく、マウントされているとLinuxディストリビューションのイメージファイルを書き込めないので、以下のコマンドでアンマウントします。

前述の識別子が「DDEB-8DCA」の場合は、以下のコマンドです。

$ umount /media/yocto/DDEB-8DCA

では、いよいよLinuxディストリビューションのイメージファイルを書き込みましょう。

まずは「/dev/sdb」のパーミッションを設定します。

以下のコマンドを実行してください。

（パスワードを問われた場合は、入力します。）

$ sudo chmod 666 /dev/sdb

イメージの書き込みは以下のコマンドで行います。

おっと、コマンドが見つからないとかなんとか？

$ oe-run-native bmap-tools-native bmaptool copy ./tmp/deploy/images/pcduino3/core-image-minimal-pcduino3.wic /dev/sdb

エラーメッセージのアドバイス通り、以下のコマンドを実行します。

$ bitbake bmap-tools-native -caddto_recipe_sysroot

これで良いのか？

再度、イメージの書き込みにトライ！

最小限の「core-image-minimal」というタイプのディストリビューションなので、それほどの時間は掛かりません。

以下の表示が出れば、イメージの書き込み完了です。

$ oe-run-native bmap-tools-native bmaptool copy ./tmp/deploy/images/pcduino3/core-image-minimal-pcduino3.wic /dev/sdb

イメージの書き込みが完了したマイクロSDカードを安全に引き抜きましょう。

ファイル・ブラウザのイジェクトボタンをクリックするか、もちろんターミナルから「umount」コマンドを実行しても構いません。

「pcDuino3」用ディストリビューションの起動

それでは、イメージの書き込みが完了したマイクロSDカードを「pcDuino3」に挿入し、Linuxを起動させてみましょう。

「pcDuino3」には、HDMI接続のディスプレイとUSBキーボードを接続しておきます。

「pcDuino3」のマイクロUSBから給電させると、なにかディスプレイに表示されましたよ！

Linuxは順調に起動しているようです。

ログインは「root」とでも入力しときましょう。

パスワードの設定はありませんので入力不要です。

早速、今回の主目的…新しいカーネルで動いているのかどうかを確かめます。

以下のコマンドを入力と…。

# uname -a

OK、カーネル・バージョンは「6.1.9」と出ました！！

デフォルトでインストールされていたカーネルが「3.4.79」だったので、大きな進歩です。

さて「Yocto Project」を使用して、無事Linuxディストリビューションを作成できたわけですが「core-image-minimal」という最小限の構成です。

SSHすら載ってません。

次回以降、より実用的なディストリビューションを構築していきましょう。

SSHは必須、Gitや「Node.js」も欲しいですよね。

当初の目的からは逸れますが、せっかくHDMIがあるのだから、ちゃんとしたGUIも表示させてみたいかも。

＜続く＞

TOPPERS/ASP - Arduino UNO R4版 その５

前回からの続きです。

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

デバッガ⇔ターゲット・ケーブルの作成

今回は、デバッガとしてRenesas純正の「E2 emulator Lite」を使用しますが、これを「Arduino UNO R4」に接続するためのケーブルが必要になります。

「E2 emulator Lite」と「Arduino UNO R4」を接続した例は、以下のようになります。

「E2 emulator Lite」を購入するとフラットケーブルが同梱されています。

しかし、これは2.54mピッチの20ピン用で、1.27mmピッチの10ピンヘッダの「Arduino UNO R4」のデバッグ端子には、どう頑張っても接続できません。

ですので、面倒でもケーブルの作成が必要です。

早速、部材集めです！

電子部品の購入は、やっぱりボクらの強い見方、秋月電子通商さんをオススメします！

お持ちでない方は、デバッガの「E2 emulator Lite」も一緒に導入できちゃうので、大変便利です。

さて、ケーブルに必要な部品は以下の通りです。

●２×１０（２０Ｐ）両端コネクタ付ＩＤＣリボンケーブル　×　１本

●２×５（１０Ｐ）両端コネクタ付ＩＤＣリボンケーブル　×　１本

●ピッチ変換基板　２×５⇔１×１０　×　２枚

●ピンヘッダ　１．２７ｍｍ　２×５（１０Ｐ）　×　２個

●ブレッドボード・ジャンパーワイヤ（オス－オス）　×　１セット

この他、ワイヤーが必要ですが、適当に余っている物をご使用ください。

余りがない場合は、こちらのような「AWG24」くらいの太さの頑丈なものを推奨します。

これらの部品を使用した完成イメージは、以下の通り。

さて、これから配線をしていくのですが、各信号線の詳細を確認しておきましょう。

今回「E2 emulator Lite」と「Arduino UNO R4」を接続するのは、SWD（Serial Wire Debug）という方式です。

ARM系のマイコンと、それに対応するデバッガであれば、各社ほぼ共通の接続方式であり、信号線が少ないのが特徴です。

殆どの場合、以下の信号線をマイコンとデバッガのそれぞれに接続するだけで動作します。

信号名	詳細
VCC	電源
SWDIO	SWD通信用データ
GND	グランド
SWCLK	SWD通信用クロック
RESET	リセット

本当にこれらの信号線のピンが存在するのか？一応コネクタのピン配置を確認しておきましょう。

まずは「E2 emulator Lite」から。

以下の図の（b）のコネクタを使用します。

そして「E2 emulator Lite」のマニュアルによると、このコネクタのピン配置は以下の通りとなります。

上記の各種信号線が、ちゃんと存在していることが確認できます。

上記の内「RES」は「RESET」と同義です。

また、上記の内「UCON」という信号は、ターゲット側（つまり「Arduino UNO R4」）でGNDにおちているか否かで、接続の有無を検出する信号であるため、配線が必要です。

次に「Arduino UNO R4」です。

「Arduino UNO R4」の回路図の「SWD CONNECTOR」において、こちらにも各種信号線が存在していますね。

基本的には、同じ名前の信号がそれぞれ接触するようなケーブルの配線をすれば良いのですが、今回はひと工夫加えました。

「Arduino UNO R4」の回路図をもう一度ご覧ください。

「P502_SCI1_RXD」と「P501_SCI1_TXD」という信号も「SWD CONNECTOR」に配線されていますね？

これらの信号はシリアル通信の信号です。

TOPPERS/ASPを動作させる際に、デバッグのためにシリアル通信を使用しますが、そのための信号をここから取れそうです。

それを踏まえた上で、作成するケーブルの具体的な配線は以下の通りとしました。

シリアル通信の信号線「RXD」、「TXD」、「GND」の引き出し線は「ブレッドボード・ジャンパーワイヤ（オス－オス）」の片方のハウジング部分を切って使用しています。

ちょっと勿体ないけど…。

裏から見ると、こんな感じ。

注意しなければいけないのは「E2 emulator Lite」側のピッチ変換基板において、ピンヘッダが10ピンなのに対して、これに刺すリボンケーブルが20ピンであることです。

再度「E2 emulator Lite」のマニュアルのピン配置の表をご覧ください。

これによると、11ピン以降は何も信号線が配線されていないことが分かります。

つまり、後半の10ピンは未使用です。

ですので「E2 emulator Lite」側のピッチ変換基板の10ピンのピンヘッダに、20ピンのリボンケーブルを刺す場合、以下のように1から10ピンまでを通電させるようにします。

この作業は慎重に行ってください。

もしズレて刺したまま通電してしまうと、最悪の場合は「E2 emulator Lite」が壊れてしまうことがあります。

ですので、この部分はテスターなどを使用して配線を確認後、正しかったらグルーガンなどで固定してしまうと良いかもしれませんね。

鋭い方はお気付きかもしれませんが、単純にデバッガとターゲットを接続するだけなら、２×１０（２０Ｐ）両端コネクタ付ＩＤＣリボンケーブルが一本あれば、電気的には事足りるんです。

しかし、その場合は「Arduino UNO R4」のJDIGITALピンヘッダと幅が広い20ピンのリボンケーブルのピンソケットが干渉し、ピンソケットを物理的に削ったりしない限り刺さりません。

また、せっかくSWDピンヘッダに配線されているシリアル通信の信号線を無駄にしたくなかったため、それらを引き出すためにも、あえて今回のケーブル作成という手間をかけました。

引き出したシリアル通信ポートはデバッグ用途専用に使用することにして、正規のArduinoインターフェースの方に配線されているシリアル通信ポートはアプリケーション目的に使用しましょう。

さて、苦手な半田付けも無事終了。

組み込みエンジニアは、ハードウェアに触れる機会も多いため半田付けが得意な人もいるかもしれませんが、そういう人を本当に尊敬します。

私は、いくら努力してもダメ…。

（写真でバレる。キタナイでしょ？）

次回は、作成したケーブルでデバッガとターゲットを接続し、実際にTOPPERS/ASPを動かしていきましょう！

…と、その前に「e2 studio」でTOPPERS/ASP用のプロジェクトを作らなきゃだわ。

＜続く＞

「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ディストリビューションをビルドしましょう…と思いますが、まだまだ若干の作業が必要です。

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

遅ればせながら…

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

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

＜続く＞