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

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

遅ればせながら…

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

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

＜続く＞

「MSX DEVCON」アムステルダム報告会

「MSX DEVCON」アムステルダム報告会　概要

12月26日、「MSX DEVCON」アムステルダム報告会に参加してきました。

今回のイベントは、西　和彦さんによりオランダ、アムステルダムで12月9日に開かれた「DEVCON」の報告会です。

会場は、東京国立博物館・平成館大講堂で13:00より行われました。

以下のように、事前にX（旧Twitter）で参加人数を調査され、300人ほどの会場を用意されたとのことですが…

お知らせ

12月26日に1300時から1600時に
東京上野で
msx devconオランダ報告会をすることになりました

会場設営のため出席希望の方だけいいねをお願いします

最新のmsx0とmsx3についてお話しさせて頂きます

無料です
msx0の即売もします pic.twitter.com/gvTRzpwlnj

— 西　和彦　Kazuhiko Nishi (@nishikazuhiko) December 1, 2023

実際に会場に集ったのは、多くて100人を少し超える程度。

しかしこれは、決して日本での「MSX3」への関心が低くなったわけではないでしょう。

まず、この年末の多忙な時期というタイミング、それに加え、ネット配信や録画で自宅で参加したいというニーズが高かったものと考えられます。

それでも、アムステルダムでのイベントの報告をいち早く日本のファンに届けたいという西さんの思いは伝わってきます。

「MSX3」は、あくまでも「Made in Japan」の精神にブレはありません。

おそらく、後日、会場の模様は録画でも配信されるでしょうから、あえてこのブログで報告会の内容を細々と記述する必要はないでしょう。

ここでは、個人的な感想を勝手に述べさせていただきたいと思います。

「MSX3」は高価なHDMIセレクタ？

すでに公開されている「MSX3」のプロトタイプの姿は以下の通りです。

次世代MSXプロジェクトの本命「MSX3」のプロトタイプが公開！　2006年に発売された「1chipMSX」が有償アップグレードでUSB 2.0対… https://t.co/b1q8AFifQ5 #MSX3 #MSX0 #西和彦 pic.twitter.com/md7LYehniC

— GAME Watch (@game_watch) December 17, 2023

今回の報告会において、初めて「MSX3」の具体的な姿、そして目指す方向性が見えてきました。

まず「MSX3」は、どのカテゴリーの製品なのかということです。

今、私たちが普段使用している情報機器は、パソコンとスマートフォンの二つです。

40年前に発売されたMSXは、一般的にはパソコンというカテゴリに属する製品でした。

したがって、その後継としての「MSX3」もまたパソコンであると考える方が自然ではあります。

では、現在広く使われているWindowsやMacOSと競合するものを目指すのか？

答えはノーです。

パソコンよりも遥かに気軽でウェアラブルなスマートフォンの立ち位置ではどうでしょう。

「MSX3」は、iOSやAndroidと競合するものを目指すのか？

こちらも、答えはノーです。

いずれの方向も、既に双璧がシェアを争う構図が確定しており、今後数年に渡って大きな変化はないでしょう。

MSXが、今からこれらの分野の3番手を狙うのは現実的ではありません。

では、どうするか？

そもそも、40年前に発売されたMSXが単なる「パソコン」であったのかどうかを疑う必要があります。

当時、人々が直に使い得る情報機器は、非常に高価なオフィスコンピュータくらいなものでした。

（PC88や、ましてやPC98は、非常に高価でした。）

それより規模は小さいものの、安価で、一般の人が購入できる価格でコンピュータを提供したことが、MSXの偉業と言えるでしょう。

それが、日本のその後のモノづくり、技術者の育成にどれだけの貢献をしたかを含めて。

このように、MSXとは「パソコン」とういう概念に囚われず「安価に入手できる、本来手にできなかったモノ」と定義すれば、「MSX3」は必ずしも第3のパソコンでなくても良いのです。

では現在、個人ではなかなか手にできない情報機器とは何でしょうか？

それは、富岳などに代表されるスーパーコンピュータです。

西さんの思い描く近未来とは、誰もがスーパーコンピュータ…つまり「MSX3」を使って、ユーザが個人でメタバースを運営したり、AIを育てたり、気象予報が可能となる世界でしょう。

更には、日本のモノづくりへの貢献です。

国立研究開発法人、産業技術総合研究所のスーパーコンピュータ、AI橋渡しクラウド（AI Bridging Cloud Infrastructure、ABCI) は、多くの企業によって、数カ月先まで予約が埋まっている状態だと聞きます。

スーパーコンピュータを使いたくても使えない状況。

「MSX3」には、このような状況を打開し、スピーディーに企業や個人が大規模なシステムの開発を推進できる起点になる可能性すら感じさせます。

重要なことは、MSXは、それらが可能な砂場（サンドボックス）を安く提供するまではやります、と。

しかし、その砂場でどういう遊びをするのかは、ユーザに委ねられている点です。

したがって「MSX3」は、ユーザが何も手を加えなければ、高価なHDMIセレクタに過ぎないと、西さんは仰られました。

用意されていないものは、自分で作る。

この精神性もまた、MSXの伝統と言えるでしょう。

「MSX3」を簡単にまとめると…

◯インターネット接続

◯HDMI接続の映像出力

◯32bitと64bitのCPU

◯メタバースに対応し得るビデオとオーディオ

◯すべての人にスーパーコンピュータを

◯IoTへの新たなるアプローチ

これらは、既にプロトタイプに実装されているといいます。

より具体的な中身については、今後発表されるSDK（Software Development Kit）を精査する必要があります。

待ち遠しいですね！

「MSX3」と「MSX turbo」の関係は？

「すべての人にスーパーコンピュータを」

このベクトルは、本来、3つある新しいMSXの内の一つ「MSX turbo」が担う分野だったはずです。

私も「MSX3」とは全く別のラインで、スーパーコンピュータ「MSX turbo」が登場するものと思っていましたが、どうやら違ったようです。

「MSX3」は、そのCPUボードを最大16枚スタックすることができるそうです。

すなわち、ユーザのニーズ、必要な処理速度に合わせてCPUボードを増設することによって、メニコアのシステムに育てて行くことが可能とのこと。

つまり「MSX turbo」とは「MSX3」の延長であると解釈するのが正解のようです。

「お前のMSX、何段？」

「今は8段だけど、次のボーナスで12段にするぜ！」

…なんて会話が、ヘビーユーザの間で交わされるのでしょうか？

「MSX3」のOSはLinuxベースであり、その上に「TAOX」というレイヤーを被せます。

「TAOX」自体は、OSというよりもPosixに依存するフレームワークのようで、ロボット・アプリケーションの分野で普及する「ROS」に近いイメージでしょうか。

おそらく、この「TAOX」が、CSP（Communicating sequential processes）すなわち、並行処理を担うレイヤーになるでしょう。

「TAOX」は、以前から開発されているものですが、一般的に情報は少なく、こちらについても詳細はSDK待ちということになるでしょう。

以前のDEVCONでは、プログラミング言語として「Occam」を使用すると説明がありましたが、今回は触れられていません。

流石に古すぎたか？

個人的には、CSPの思想を受け継ぐのであれば、今であれば「Go lang」が使えると面白いと思います。

ゲームは重要！

ゲームに関しては、西さん独特のシニカルな言い回しで仰いました。

「わたしゃゲームは嫌いだ。でも、MSXにとってゲームは非常に重要だ。」

同時に、現在「kibidango」でのクラウドファンディングで募集中のMSX0各機種が、非常に苦戦しているとのことでした。

確かにキツそうです。

（購入予定はなかったけど、急遽応援します。）

この原因について、西さんは「ゲームを置き去りにしてしまった。ゲームは今までMSXが生き残ってきた重要な要素であり、今後はそれを無視できない。」と仰っています。

西さんのことですから、今後、この分野でも大きな動きを起こすでしょう。

また、この日も「株式会社D4エンタープライズ」の鈴木代表も登壇されましたが、ゲームの供給という点でプレッシャーは大きいでしょう。

そもそも「MSX3」は「メタバースに対応し得るビデオとオーディオ」を搭載できます。

8K対応の「ORIN GPU」で「Open GL」に対応するとのことで、旧作ばかりではなく、新しい、そして、かなり高度なゲームを開発できる土壌はあるはず。

有力なサードパーティの参入に期待したいところですが、それには何より、まずユーザサイドで盛り上がる必要がありますね。

メーカーに、活発な市場と思わせなければなりません。

西さん、ここまでのMSX3に開発経緯を記した「反省記２」の執筆も進めているそうです。

前作の「反省記」も、モノづくりに関わる人間の一人として、着眼点やその発想の方法に大きな感銘を受けた内容でした。

こちらも楽しみです。

さて、まだまだ目が離せないMSX界隈の状況。

今後も注目していきたいと思います。

皆様、良いお年を！

「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」に組み込むか？をやっていきたいと思います。

＜続く＞

TOPPERS/ASP - Arduino UNO R4版 その４

前回からの続きです。

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

Cygwinターミナルでのビルド

雛形プロジェクトができましたので、ここで生成されたソースコードの一部を「TOPPERS/ASP Arduino UNO R4版」のソースコードを補完しましょう。

その前に「Cygwin」のインストールをお願いします。

このページ（TOPPERS/ASPのビルドからデバッグまで～Cygwinの導入）を参考にしてください。

次に「TOPPERS/ASP Arduino UNO R4版」のソースコードをゲットしちゃいましょう。

今、インストールしたばかりの「Cygwin」を起動させてください。

起動したターミナルで、以下のコマンドを使ってソースコードのクローンを行います。

$ git clone https://github.com/RyutaroMorita/asp_arduino_uno_r4_gcc.git

上記のコマンドの結果、以下のパスに「asp_arduino_uno_r4_gcc」というディレクトリが生成されたはずです。

エクスプローラを開いて、確認してみてください。

C:\cygwin64\home\＜ユーザ名＞

この「asp_arduino_uno_r4_gcc」というディレクトリの名前を「asp_1.9.2」と改名してください。

（深い意味はないです…説明がしやすいだけ。）

改名した「asp_1.9.2」ディレクトリの中身は、こんな風になっていると思います。

この「asp_1.9.2」ディレクトリの下層、以下のパスを表示してみてください。

C:\cygwin64\home\＜ユーザ名＞\asp_1.9.2\target\arduino_uno_r4_gcc

ここには、TOPPERS/ASPカーネルのターゲットボード、すなわち、今回の場合は「Arduino UNO R4」依存のソースコードが格納されています。

このターゲットディレクトリのエクスプローラ、開いておいてくださいね。

さて、前回作成した雛形プロジェクトのディレクトリを別のエクスプローラで開きます。

記事のとおりに作業していただいた場合は、以下のパスに生成されています。

C:\Users\＜ユーザ名＞\e2_studio\workspace\Hinagata

この中の以下の4つのディレクトリを予め開いておいたターゲットディレクトリのエクスプローラにコピーしてください。

●ra

●ra_cfg

●ra_gen

●src

コピーが終わった時点で、ターゲットディレクトリのエクスプローラは、こんな感じの表示になりましたか？

この作業でコピーした雛形プロジェクトのディレクトリの中に入っているソースコードを補完することによって、不完全だった「TOPPERS/ASP Arduino UNO R4版」のソースコードは、完璧なものになりました。

試しに「Cygwin」ターミナルを使ってTOPPERS/ASPのビルドを通してみましょう。

「Cygwin」ターミナルを開いて、以下のコマンドでTOPPERS/ASPソースツリーの場所まで移動しましょう。

$ cd asp_1.9.2/

次にその直下の「OBJ」ディレクトリに移動します。

$ cd OBJ/

コンフィギュレーターのパーミッションを実行可能に設定します。

$ chmod 755 ../cfg/cfg/cfg.exe

ここまで、大丈夫ですか？

そうしたら「OBJ」ディレクトリの中にあるコンフィグファイル（sample1.cfg）の情報を元に、OSに必要な定義を記したソースコード（「kernel_cfg.c」と「kernel_cfg.h」）を生成します。

これは、以下のコマンドで実行します。

$ make depend

以下のような表示にならずエラーが出力される場合は、残念ながらこれまでの作業に誤りがあります。

お手数ですが、最初からご確認を！

ここまで上手くいったら、ホンチャンのビルド。

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

$ make all

以下のように無事にビルドが通ったでしょうか？

さて、ターミナルでのビルドが通ったら、次はIDE（統合開発環境）の「e2studio」を使ってデバッグできるようにしたいと思います…が。

その前に、デバッガの「E2 emulator Lite」とターゲットの「Arduino UNO R4」とを接続するためのケーブルを作らなければなりません。

というわけで、次回は半田付け作業です。

＜続く＞

TOPPERS/ASP - PIC32MX版 目次

絶滅危惧の「MIPS」アーキテクチャのマイコン「PIC32MX」。

今後、たとえ「ARM」アーキテクチャに移行してしまっても、PICはPICらしく。

DIPパッケージをラインナップするなど、あくまでもホビーユーザーに寄り添ったマイコンであり続けて欲しいでものですね。

以下、TOPPERS/ASP PIC32MX版に関する記事の目次です。

■TOPPERS/ASP - PIC32MX版 その１

TOPPERS/ASP - PIC32MX版 概要

必要なもの

ダウンロード／GitHub

■TOPPERS/ASP - PIC32MX版 その２

開発環境の構築（MPLAB X IDE編）

■TOPPERS/ASP - PIC32MX版 その３

開発環境の構築（XC32コンパイラ編）

■TOPPERS/ASP - PIC32MX版 その４

開発環境の構築（Eclipse編）

■TOPPERS/ASP - PIC32MX版 その５

MPLAB Harmonyとは？

MPLAB Harmonyのインストール

MPLAB HarmonyのIDEへの登録

■TOPPERS/ASP - PIC32MX版 その６

雛形プロジェクトの作成

■TOPPERS/ASP - PIC32MX版 その７

Harmony Frameworkのコピー

雛形プロジェクトで生成したソースコードのコピー

コマンドラインでのビルド

■TOPPERS/ASP - PIC32MX版 その８

プロジェクトの作成（Eclipse編）

プロジェクトの作成（MPLAB X IDE編）

■TOPPERS/ASP - PIC32MX版 その９

シリアル通信用の配線の引き出し

プログラムの転送とデバッグ

■TOPPERS/ASP - PIC32MX版 その１０

サンプルプロジェクトの説明

PIC32MX版カーネルについて

ライセンスについて

なお、Qiitaにも上記の記事を1ページにまとめたダイジェスト版を投稿しました。

こっちの方が読み易いです。

よろしければ参考にしてください。

TOPPERS/ASP - PIC32MX版 - Qiita

「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」で動くようにする作業をやっていきましょう。

＜続く＞