ラベル Yocto の投稿を表示しています。 すべての投稿を表示
ラベル Yocto の投稿を表示しています。 すべての投稿を表示

2024年11月10日日曜日

「pcDuino3」でYocto Project その10

前回からの続きです。

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


「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/

ファイル・ブラウザ - 1


この「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

ターミナル - 1


今回はそんなに時間はかからないはず!

というわけでbitbake無事終了!!

ターミナル - 2


以下のディレクトリを確認すると…


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


ちゃんと「core-image-sato-pcduino3.wic.gz」というのが出来ていますね!

ファイル・ブラウザ - 2


こちらの記事を参考にSDカードを作成して「pcDuino3」を起動させましょう。

簡単におさらいすると…。

まずは、以下のコマンドで圧縮されている「core-image-sato-pcduino3.wic.gz」を解凍。


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

ターミナル - 3


以下のディレクトリで解凍された「core-image-sato-pcduino3.wic」を確認してください。


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

ファイル・ブラウザ - 3

ここでパソコンにSDカードを挿入して、以下のコマンドでUbuntuに何処に認識されたかを確認します。


$ df

ターミナル - 4

今回の場合「/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

ターミナル - 5

SDカードへアクセスするための権限を付与します。

今回の場合、SDカードは「sdb」と認識されていたので、以下の通り。

b」の部分は環境によって異なる可能性がありますので注意。


$ sudo chmod 666 /dev/sdb

ターミナル - 6

いよいよ以下のコマンでOSイメージの書き込みです。


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

ターミナル - 7


書き込みが終了したら、SDカードを正しくパソコンから取り出し「pcDuino3」に挿入して、電源投入です!

今度は、上手くいくはず!!

冒頭のスプラッシュスクリーンでフリーズすることなく、無事に起動…、いや、でもヤケに地味な画面ですな!

これが佐藤さん?

操作にはマウスが使えますので「pcDuino3」に挿入しましょう。

SATO - 1


デスクトップと思われる画面には、いくつかのアイコンが…。

「Media Player」っていうのは、ちょっと気になる。

SATO - 2


これだけしか無いの?

苦労したのに、淋しいねぇ。

SATO - 3


おっと、右上に何かリンクっぽいものが?

これをクリックすると…。

SATO - 4


おお!ゲームと思しきアプリのアイコンが沢山現れました!!

SATO - 5


ちょっと遊んでみようかな…。

これは、アレだ…パネルをずらしていって、1から15まで並べるヤツ。

「Fiteen」っていうのか~?

SATO - 6


お馴染みのマインスイーパー「Mines」。

SATO - 7


こちらもお馴染み、さめがめ。

…一瞬、何だか分からなかった。

「Samegame」です。

SATO - 8


数独もありました!

これは時間の経つのを忘れちゃう系。

SATO - 9


その他にも、遊び方が分からないものも含めて多くのゲームが入っていました。

すべて単純なものではありますが、デモンストレーションとしては親しみやすいですね。


さて、これで無事に絵の出るディストリビューション「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」にしておけば…って、後の祭りです!!


<終わり>

2024年11月5日火曜日

「pcDuino3」でYocto Project その9

前回からの続きです。

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


「core-image-sato」のビルド(試行錯誤編)

前回までにSSH、Git、そしてNode.jsが使用できる実用的なディストリビューションを作成しました。

しかし、これは「core-image-minimal」という最小限のディストリビューション・タイプにちょっとだけ肉付けをした程度のもの。

ご覧の通り「pcDuino3」にはHDMI端子があるのに、画面に映っているのはテキストだけ…。

pcDuino3


せっかくHDMI端子を持っているなら、当初の目的からは外れるけど、ちょっとグラフィカルな表示をさせてみたい!…という貧乏性的な発想から、何か絵を出せるディストリビューションを作ってみましょう。

今までは「Yocto Project」で用意されている最軽量のディストリビューション・タイプである「core-image-minimal」をベースに改造してきました。

グラフィカルなディストリビューションのためには、それの上位版「core-image-sato」というのをベースにするのが良さそうです。

ウ~ン「~sato」って何でしょうね?

どうやらGTKを使用したシンプルなデスクトップ環境のようです。

別に佐藤さんが作ったわけでもなさそうです。

というわけで、いつも通りUbuntuを起動してターミナルを開いて、以下のコマンドを打って今度は「core-image-minimal」の代わりに「core-image-sato」をbitbakeです。


$ cd poky/

$ source oe-init-build-env


その前に、前回いくつかのパッケージを書き加えた「./conf/」ディレクトリ以下にある「local.conf」の末尾の行「CORE_IMAGE_EXTRA_INSTALL += ~」の行を「#」でコメントアウトしておきましょう。

  • ...
  • # CONF_VERSION is increased each time build/conf/ changes incompatibly and is used to
  • # track the version of this file when it was generated. This can safely be ignored if
  • # this doesn't mean anything to you.
  • CONF_VERSION = "2"

  • #
  • # for pcDuino3
  • #
  • #CORE_IMAGE_EXTRA_INSTALL += "nodejs nodejs-npm openssh git"


今までと変わったことをやる場合は、前回の変更はクリアにしておいた方がいいです。

トラブル回避のために。

必要ならば、一度ビルドが通ってからまた書き加えましょう。


そして…


$ bitbake core-image-sato


…どやっ!?


ぐはっ!!

なんか、いきなりエラーが出ちゃった。

ターミナル - 1


面倒ですが、エラーをよく調べてみましょう。

これの意味は…「xf86-input-keyboard」は作れないけど「packagegroup-core-x11-xserver.bb」というレシピでこれが必要とされています…!?

  • NOTE: Resolving any missing task queue dependencies
  • ERROR: Nothing RPROVIDES 'xf86-input-keyboard' (but /home/yocto/poky/meta/recipes-graphics/packagegroups/packagegroup-core-x11-xserver.bb RDEPENDS on or otherwise requires it)
  • NOTE: Runtime target 'xf86-input-keyboard' is unbuildable, removing...
  • Missing or unbuildable dependency chain was: ['xf86-input-keyboard']
  • NOTE: Runtime target 'packagegroup-core-x11-xserver' is unbuildable, removing...
  • Missing or unbuildable dependency chain was: ['packagegroup-core-x11-xserver', 'xf86-input-keyboard']
  • NOTE: Runtime target 'packagegroup-core-x11-base' is unbuildable, removing...
  • Missing or unbuildable dependency chain was: ['packagegroup-core-x11-base', 'packagegroup-core-x11-xserver', 'xf86-input-keyboard']
  • ERROR: Required build target 'core-image-sato' has no buildable providers.
  • Missing or unbuildable dependency chain was: ['core-image-sato', 'packagegroup-core-x11-base', 'packagegroup-core-x11-xserver', 'xf86-input-keyboard']


なんのこっちゃ?

ちょっと「xf86-input-keyboard」というものについて調べる必要がありそうですね。

これは、X.Org Server(ウィンドウ・システム)で使用されるキーボードのドライバーだそうです。

さらに、こちらのページの一番上の投稿によると、この「xf86-input-keyboard」や「xf86-input-mouse」は非推奨であり、これらの機能は「xf86-input-evdev」などに置き換えられているとのこと。

このページは「Yocto Project」向けのものではありませんが、同じLinuxの情報ですから軽視はできません。


ひょっとして「xf86-input-keyboard」って、もう使われていないのでは?

それなのに呼び出しているので、これが原因では?


そういった推理から現在の「Yocto Project」のレイヤーから「xf86-input-keyboard」が定義されているレシピを探しましょう。

まずは「meta-sunxi」レイヤーを疑います。

以下のコマンドを入力。


$ cd ../meta-sunxi/

$ grep -r "xf86-input-keyboard" ./*


この結果「./conf/machine/include/sunxi.inc」というレシピの参照ファイル(.inc)に「xf86-input-keyboard」という文字列が見つかりました。

ターミナル - 2


このファイルを開いてみましょう。


/home/yocto/poky/meta-sunxi/conf/machine/include/sunxi.inc

ファイル・ブラウザ - 1

ファイルを見ると冒頭に「XSERVER = 」で始まる行が見つかります。

ここでは「XSERVER」という変数に「xf86-input-keyboard」を代入していることが分かります。

前述のページの投稿では「xf86-input-keyboard」や「xf86-input-mouse」は非推奨であり、これらの機能は「xf86-input-evdev」などに置き換えられ…とありましたね。

なのに、この行では「xf86-input-evdev」に加え、これに置き換えられたはずの「xf86-input-keyboard」や、さらには「xf86-input-mouse」まで加えられています。

  1. SOC_FAMILY ??= ""
  2. include conf/machine/include/soc-family.inc
  3. MACHINEOVERRIDES =. "sunxi:"
  4. # Sub-architecture support
  5. MACHINE_SOCARCH_SUFFIX ?= ""
  6. MACHINE_SOCARCH_SUFFIX_sun4i = "-sun4i"

  7. PREFERRED_PROVIDER_virtual/xserver = "xserver-xorg"
  8. XSERVER = "xserver-xorg \
  9.            xf86-input-evdev \
  10.            xf86-input-mouse \
  11.            xf86-input-keyboard"

  12. PREFERRED_PROVIDER_virtual/kernel ?= "linux-mainline"
  13. PREFERRED_VERSION_linux-mainline ?= "6.1.%"
  14. PREFERRED_PROVIDER_u-boot ?= "u-boot"
  15. PREFERRED_PROVIDER_virtual/bootloader ?= "u-boot"
  16. ...


これは臭いな~。

ならば、もう要らないと噂の「xf86-input-keyboard」と「xf86-input-mouse」を「XSERVER」変数から削除したいところですね。

これを行うには「local.conf」に記述を行うのが得策です。

(因みにこのファイルを直接修正しても結果は同じですが、お行儀の良い方法としてはコッチです。)

「local.conf」では「Yocto Project」で使用される様々なパラメータを変数単位で追加したり、変更したり、削除したりすることができます。

というわけなので「local.conf」の末尾に以下の記述を追加しましょう。

変数からアイテムを削除するには…


[変数名]:remove = "[削除するアイテム]"


…です。

つまり「XSERVER:remove = "xf86-input-keyboard xf86-input-mouse"」と追記すれば良さそうです。

  • ...
  • # CONF_VERSION is increased each time build/conf/ changes incompatibly and is used to
  • # track the version of this file when it was generated. This can safely be ignored if
  • # this doesn't mean anything to you.
  • CONF_VERSION = "2"
  • #
  • # for pcDuino3
  • #
  • #CORE_IMAGE_EXTRA_INSTALL += "nodejs nodejs-npm openssh git"

  • XSERVER:remove = "xf86-input-keyboard xf86-input-mouse"


これを保存して、再び「core-image-sato」のbitbakeにトライ!


$ cd build/

$ bitbake core-image-sato


あかん、また違ったエラーが出ちまったい…。

ウーン、この修正は上手く通ったようですが…。

ターミナル - 3

今回のエラーメッセージは、こんな感じ。

sunxi-mali_git.bb」というレシピのConfigure中でコケている模様。

  • ERROR: sunxi-mali-git-r0 do_configure: ExecutionError('/home/yocto/poky/build/tmp/work/cortexa7t2hf-neon-poky-linux-gnueabi/sunxi-mali/git-r0/temp/run.do_configure.5903', 2, None, None)
  • ERROR: Logfile of failure stored in: /home/yocto/poky/build/tmp/work/cortexa7t2hf-neon-poky-linux-gnueabi/sunxi-mali/git-r0/temp/log.do_configure.5903
  • Log data follows:
  • | DEBUG: Executing python function extend_recipe_sysroot
  • | NOTE: Direct dependencies are ['/home/yocto/poky/meta-sunxi/recipes-graphics/libump/libump_git.bb:do_populate_sysroot', '/home/yocto/poky/meta-sunxi/recipes-graphics/xorg-xserver/libdri2_git.bb:do_populate_sysroot', '/home/yocto/poky/meta/recipes-core/glibc/glibc_2.37.bb:do_populate_sysroot', '/home/yocto/poky/meta/recipes-devtools/gcc/gcc-cross_12.3.bb:do_populate_sysroot', '/home/yocto/poky/meta/recipes-devtools/gcc/gcc-runtime_12.3.bb:do_populate_sysroot', '/home/yocto/poky/meta/recipes-devtools/quilt/quilt-native_0.67.bb:do_populate_sysroot', '/home/yocto/poky/meta/recipes-graphics/drm/libdrm_2.4.115.bb:do_populate_sysroot', '/home/yocto/poky/meta/recipes-graphics/xorg-lib/libx11_1.8.7.bb:do_populate_sysroot', '/home/yocto/poky/meta/recipes-graphics/xorg-lib/libxau_1.0.11.bb:do_populate_sysroot', '/home/yocto/poky/meta/recipes-graphics/xorg-lib/libxdmcp_1.1.4.bb:do_populate_sysroot', '/home/yocto/poky/meta/recipes-graphics/xorg-proto/xorgproto_2022.2.bb:do_populate_sysroot', 'virtual:native:/home/yocto/poky/meta/recipes-devtools/patch/patch_2.7.6.bb:do_populate_sysroot', 'virtual:native:/home/yocto/poky/meta/recipes-devtools/patchelf/patchelf_0.17.2.bb:do_populate_sysroot', 'virtual:native:/home/yocto/poky/meta/recipes-devtools/pseudo/pseudo_git.bb:do_populate_sysroot']
  • | NOTE: Installed into sysroot: []
  • | NOTE: Skipping as already exists in sysroot: ['libump', 'libdri2', 'glibc', 'gcc-cross-arm', 'gcc-runtime', 'quilt-native', 'libdrm', 'libx11', 'libxau', 'libxdmcp', 'xorgproto', 'patch-native', 'patchelf-native', 'pseudo-native', 'libtool-native', 'libpciaccess', 'libpthread-stubs', 'xtrans', 'util-macros', 'libxcb', 'attr-native', 'gnu-config-native', 'xz-native', 'binutils-cross-arm', 'zstd-native', 'libmpc-native', 'texinfo-dummy-native', 'linux-libc-headers', 'zlib-native', 'gmp-native', 'mpfr-native', 'flex-native', 'libxext', 'libxfixes', 'libgcc', 'xcb-proto', 'gettext-minimal-native', 'm4-native']
  • | DEBUG: Python function extend_recipe_sysroot finished
  • | DEBUG: Executing shell function do_configure
  • | rm -f config.mk
  • | make config.mk
  • | make[1]: Entering directory '/home/yocto/poky/build/tmp/work/cortexa7t2hf-neon-poky-linux-gnueabi/sunxi-mali/git-r0/git'
  • | make -f Makefile.config
  • | make[2]: Entering directory '/home/yocto/poky/build/tmp/work/cortexa7t2hf-neon-poky-linux-gnueabi/sunxi-mali/git-r0/git'
  • | ABI="armhf" (Provided)
  • | VERSION="r3p0" (Provided)
  • | EGL_TYPE="x11" (Detected)
  • | make[2]: Leaving directory '/home/yocto/poky/build/tmp/work/cortexa7t2hf-neon-poky-linux-gnueabi/sunxi-mali/git-r0/git'
  • | Makefile.config:87: *** No Mali libs exist for r3p0, armhf, x11. Stop.
  • | make[1]: *** [Makefile:12: config.mk] Error 2
  • | make[1]: Leaving directory '/home/yocto/poky/build/tmp/work/cortexa7t2hf-neon-poky-linux-gnueabi/sunxi-mali/git-r0/git'
  • | make: *** [Makefile:9: config] Error 2
  • | WARNING: exit code 2 from a shell command.
  • ERROR: Task (/home/yocto/poky/meta-sunxi/recipes-graphics/libgles/sunxi-mali_git.bb:do_configure) failed with exit code '1'
  • NOTE: Tasks Summary: Attempted 3390 tasks of which 3385 didn't need to be rerun and 1 failed.

  • Summary: 1 task failed:
  •   /home/yocto/poky/meta-sunxi/recipes-graphics/libgles/sunxi-mali_git.bb:do_configure


なにやらライブラリが足りない!とか言っているようですね。

ソースやらライブラリが足りないというエラーの場合は、それらをGitからダウンロードするのに失敗しているケースが大半です。

エラーを起こした「sunxi-mali_git.bb」というレシピを調べてみましょう。

因みに「sunxi-mali」とは「pcDuino3」に搭載されているプロセッサ「Allwinner A20」用のグラフィック・モジュールです。

今回の絵を出すディストリビューションを作るミッションにおいては主役ですね。


/home/yocto/poky/meta-sunxi/recipes-graphics/libgles/sunxi-mali_git.bb

ファイル・ブラウザ - 2


ここでは「SRC_URI = 」から始まる行に注目します。

この「SRC_URI 」は、ソースやライブラリのダウンロード先を示す変数のようです。

  • DESCRIPTION = "libGLES for the A10/A13 Allwinner processor with Mali 400 (X11)"

  • LICENSE = "Proprietary"
  • LIC_FILES_CHKSUM = "file://README;md5=1b81a178e80ee888ee4571772699ab2c"

  • COMPATIBLE_MACHINE = "(sun4i|sun5i|sun7i|sun8i)"

  • # These libraries shouldn't get installed in world builds unless something
  • # explicitly depends upon them.
  • EXCLUDE_FROM_WORLD = "1"
  • PROVIDES = "virtual/libgles1 virtual/libgles2 virtual/egl"

  • # There's only hardfp version available
  • python __anonymous() {
  •     tunes = d.getVar("TUNE_FEATURES", True)
  •     if not tunes:
  •         return
  •     if "callconvention-hard" not in tunes:
  •         pkgn = d.getVar("PN", True)
  •         pkgv = d.getVar("PV", True)
  •         raise bb.parse.SkipPackage("%s-%s ONLY supports hardfp mode for now" % (pkgn, pkgv))
  • }

  • SRCREV = "d343311efc8db166d8371b28494f0f27b6a58724"
  • SRC_URI = "git://github.com/linux-sunxi/sunxi-mali.git;protocol=https;branch=master \
  •            file://0001-Add-EGLSyncKHR-EGLTimeKHR-and-GLChar-definition.patch \
  •            file://0002-Add-missing-GLchar-definition.patch \
  •            file://0003-Fix-sed-to-replace-by-the-correct-var.patch \
  •            file://0001-fix-test-build.patch \
  •            "

  • S = "${WORKDIR}/git"

  • DEPENDS = "libdrm xorgproto libump patchelf-native"
  • ...


もし「SRC_URI 」の内容が正しければ、今回のエラーは起こらないはずなんですけどねぇ。

この変数の先頭のアイテム「git://github.com/linux-sunxi/sunxi-mali.git;protocol=https;branch=master」をWebで見てみましょう。


https://github.com/linux-sunxi/sunxi-mali/tree/master/lib


ライブラリが足らないということなので、この中の「lib」のディレクトリを覗いてみましょう。

すると、ここには「mali @ 1c5063f」とかいうディレクトリが含まれていて、それがどうやらサブモジュール扱いになっているようです。

Github - 1


サブモジュールというのは、リポジトリの中で他のリポジトリにリンクするモジュールを意味します。

その証拠、この「mali @ 1c5063f」ディレクトリをクリックすると「sunxi-mali-proprietary」という別のリポジトリに飛ばされます。

これこそが足りないと騒ぎになっているライブラリのソースでは?

Github - 2


試しにダウンロードされた現物を見てみましょう。

「Yocto Peoject」ではbitbake中にダウンロードし、展開されたソースは(デフォルトでは)「/home/yocto/poky/build/tmp/work/」以下のディレクトリに置かれることになっています。

そこで「sunxi-mali」のリポジトリ通りにダウンロード・展開されているかを確認します。

サブモジュール「mali @ 1c5063f」が正しく存在するか?を調べるために以下のディレクトリにアクセスすると…やっぱり何もないじゃん!?


/home/yocto/poky/build/tmp/work/cortexa7t2hf-neon-poky-linux-gnueabi/sunxi-mali/git-r0/git/lib/mali

ファイル・ブラウザ - 3


サブモジュール「mali @ 1c5063f」がここに展開されていない…つまりは、正しくダウンロードできていないことが分かりました。

もう一度、以下の「sunxi-mali_git.bb」を見てみましょう。


/home/yocto/poky/meta-sunxi/recipes-graphics/libgles/sunxi-mali_git.bb


「SRC_URI 」の先頭アイテムとして…


git://github.com/linux-sunxi/sunxi-mali.git;protocol=https;branch=master


…が記述されていましたが、コレがダメなんでしょう。

  • DESCRIPTION = "libGLES for the A10/A13 Allwinner processor with Mali 400 (X11)"

  • LICENSE = "Proprietary"
  • LIC_FILES_CHKSUM = "file://README;md5=1b81a178e80ee888ee4571772699ab2c"

  • COMPATIBLE_MACHINE = "(sun4i|sun5i|sun7i|sun8i)"

  • # These libraries shouldn't get installed in world builds unless something
  • # explicitly depends upon them.
  • EXCLUDE_FROM_WORLD = "1"
  • PROVIDES = "virtual/libgles1 virtual/libgles2 virtual/egl"

  • # There's only hardfp version available
  • python __anonymous() {
  •     tunes = d.getVar("TUNE_FEATURES", True)
  •     if not tunes:
  •         return
  •     if "callconvention-hard" not in tunes:
  •         pkgn = d.getVar("PN", True)
  •         pkgv = d.getVar("PV", True)
  •         raise bb.parse.SkipPackage("%s-%s ONLY supports hardfp mode for now" % (pkgn, pkgv))
  • }

  • SRCREV = "d343311efc8db166d8371b28494f0f27b6a58724"
  • SRC_URI = "git://github.com/linux-sunxi/sunxi-mali.git;protocol=https;branch=master \
  •            file://0001-Add-EGLSyncKHR-EGLTimeKHR-and-GLChar-definition.patch \
  •            file://0002-Add-missing-GLchar-definition.patch \
  •            file://0003-Fix-sed-to-replace-by-the-correct-var.patch \
  •            file://0001-fix-test-build.patch \
  •            "

  • S = "${WORKDIR}/git"

  • DEPENDS = "libdrm xorgproto libump patchelf-native"
  • ...


「git://~」と記述した場合は、サブモジュールまではダウンロードしてくれないようです。

サブモジュールまでゲットしたい場合は「gitsm://~」と書くのが正解のようです。

つまり…


gitsm://github.com/linux-sunxi/sunxi-mali.git;protocol=https;branch=master


…が正解?

したがって「sunxi-mali_git.bb」を以下のように修正してみましょう。

「SRC_URI = 」から始まる行です。

  • DESCRIPTION = "libGLES for the A10/A13 Allwinner processor with Mali 400 (X11)"

  • LICENSE = "Proprietary"
  • LIC_FILES_CHKSUM = "file://README;md5=1b81a178e80ee888ee4571772699ab2c"

  • COMPATIBLE_MACHINE = "(sun4i|sun5i|sun7i|sun8i)"

  • # These libraries shouldn't get installed in world builds unless something
  • # explicitly depends upon them.
  • EXCLUDE_FROM_WORLD = "1"
  • PROVIDES = "virtual/libgles1 virtual/libgles2 virtual/egl"

  • # There's only hardfp version available
  • python __anonymous() {
  •     tunes = d.getVar("TUNE_FEATURES", True)
  •     if not tunes:
  •         return
  •     if "callconvention-hard" not in tunes:
  •         pkgn = d.getVar("PN", True)
  •         pkgv = d.getVar("PV", True)
  •         raise bb.parse.SkipPackage("%s-%s ONLY supports hardfp mode for now" % (pkgn, pkgv))
  • }

  • SRCREV = "d343311efc8db166d8371b28494f0f27b6a58724"
  • SRC_URI = "gitsm://github.com/linux-sunxi/sunxi-mali.git;protocol=https;branch=master \
  •            file://0001-Add-EGLSyncKHR-EGLTimeKHR-and-GLChar-definition.patch \
  •            file://0002-Add-missing-GLchar-definition.patch \
  •            file://0003-Fix-sed-to-replace-by-the-correct-var.patch \
  •            file://0001-fix-test-build.patch \
  •            "

  • S = "${WORKDIR}/git"

  • DEPENDS = "libdrm xorgproto libump patchelf-native"
  • ...


では修正した「sunxi-mali_git.bb」を保存して、再度bitbakeです。

但し「core-image-sato」全体ではなくて、今回は時短のために「sunxi-mali」単体でbitbakeしてみましょう。

このように、レシピを単体でbitbakeすることもできます。


$ bitbake sunxi-mali

ターミナル - 4

今回は大丈夫かな?

ターミナル - 5

以下表示になれば、とりあえず「sunxi-mali」に関しては正しくbitbakeできています。

ターミナル - 6

さきほどの「sunxi-mali」のサブモジュール、今回は正しく生成できているでしょうか?

まあ、できているのでbitbakeが通ったんですけどね。

一応確認です。

再度、以下のディレクトリを確認しましょう。

今回はちゃんとできています!

Webで見た「sunxi-mali-proprietary」というサブモジュールがそのまま展開されています。


/home/yocto/poky/build/tmp/work/cortexa7t2hf-neon-poky-linux-gnueabi/sunxi-mali/git-r0/git/lib/mali

ファイル・ブラウザ - 4

ヨシ!

なんだ、今までの苦労って全部「meta-sunxi」のバグじゃん!?

思われる気持ちも分かります。

しかし、この程度の障害はオープンソース・ソフトウェアでは付きものです。

メンテナーさんを責めてはいけません。

善意でやってくださっているのだから。

さて、満を持して「core-image-sato」をbitbakeです!


$ bitbake core-image-sato

ターミナル - 7


すでに以前の経験からお分かりだと思いますが、終わるまでに凄い時間が掛かります。

就寝前にbitbakeを仕掛けるのが良いでしょう。

というわけで、今日の作業は終了です。

明日の朝起きれば「core-image-sato」のbitbakeが無事に終了して「pcDuino3」が美麗なグラフィックを表示するだろうと楽しみに眠りに就く私。

しかし、これは新たなる苦悩の序章であるとは知る由もなかった…。


…てなわけで、長くなっちゃうので一回切ります。

今回わざわざ試行錯誤の過程を書いたのは「Yocto Project」でのディストリビューション開発の苦悩と現実を理解いただくためです。

そう、意外に難しいんですよ!「Yocto Project」って。


<続く>

2024年3月3日日曜日

「pcDuino3」でYocto Project その8

前回からの続きです。

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


実用的なディストリビューションの作成

前回までで「pcDuino3」で動くディストリビューションを作成することができるようになりました。

「pcDuino3」


しかし、このディストリビューションは「Yocto Project」で最初から用意されているディストリビューション・タイプの中でも「core-image-minimal」という最小限のもの。

クックック…、ヤツは我らYoctoディストリビューションの中でも最弱…。

そのままでは、実用性がありません。

そこで今回は、この「core-image-minimal」をベースに代表的なJavaScriptの実行環境の一つ「Node.js」を使えるように改造したいと思います。

「Node.js」で何か凝ったものを開発しようと思えば、JavaScriptのパッケージ管理ツールの「NPM」も必要です。

また、ソースコードを管理するためには「Git」コマンドも使いたいものですよね。

さらには「core-image-minimal」にはロクなGUIを積んでいませんので「pcDuino3」側でコーディング作業を行うのは困難です。

ですので、パソコン側から「pcDuino3」を操作したいので「OpenSSH」というプロトコルも載せちゃいましょう。

この「OpenSSH」を「pcDuino3」に積んでおけば、パソコン側で「VisualStudio Code」などのリッチなIDE(統合開発環境)を使って「Node.js」による開発を行えるようになりますよ。

というわけで、現在の「core-image-minimal」に加えるパッケージは、以下の4つとなります。


◯nodejs

◯nodejs-npm

◯openssh

◯git


問題は、これらをどうやってディストリビューションに組み込むか、ということですが…。

それには、前回「pcDuino3」用のディストリビューションを作るために、ほんのチョットだけ修正した「local.conf」ファイルを編集することによって行います。

「local.conf」ファイルの開き方は、前回の記事を参考にしてください。

以下のように「local.conf」の末尾に呪文を追記しましょう。

  1. #
  2. # Memory Resident Bitbake
  3. #
  4. # Bitbake's server component can stay in memory after the UI for the current command
  5. # has completed. This means subsequent commands can run faster since there is no need
  6. # for bitbake to reload cache files and so on. Number is in seconds, after which the
  7. # server will shut down.
  8. #
  9. #BB_SERVER_TIMEOUT = "60"
  10. # CONF_VERSION is increased each time build/conf/ changes incompatibly and is used to
  11. # track the version of this file when it was generated. This can safely be ignored if
  12. # this doesn't mean anything to you.
  13. CONF_VERSION = "2"
  14. # ↓以下を追記↓
  15. #
  16. # for pcDuino3
  17. #
  18. CORE_IMAGE_EXTRA_INSTALL += "nodejs nodejs-npm openssh git"


この呪文の意味、なんとなく分かりますよね?

CORE_IMAGE_EXTRA_INSTALL」という変数にインストールしたいソフトウェアのパッケージをスペース区切りで記述して代入しています。

このように「Yocto Project」においては、作成するディストリビューションにソフトウェアやパッケージをインストールしたい場合「local.conf」などの設定ファイルに任意の変数へ追加代入することによって行います。

注意しなければならないのは、今回は「CORE_IMAGE_EXTRA_INSTALL」という変数に代入しましたが、ソフトウェアや機能によっては、別の変数を使用しなければならない場合があることです。

このような変数には、他にも「IMAGE FEATURES」や「DISTRO_FEATURES」などがありますので、インストールしたいソフトウェアや機能のドキュメントなどを事前に調査しておくことが必要です。

しかしながら、殆どの場合は「CORE_IMAGE_EXTRA_INSTALL」で大丈夫でしょう。

さて「local.conf」の追記が完了したら、こちらの記事を参考に再度「core-image-minimal」を「bitbake」コマンドでビルドしましょう。

今回も完了までに結構な時間がかかりますので、コマンドの実行は就寝前がオススメです。


スワップの設定

朝起きて「bitbake」コマンドが無事終了していた方は幸いです。

しかし、私の場合はダメでしたぁ~。

ターミナルは以下のようなエラー表示。。。

最悪の寝覚めだ…。

この「ld tarminated with signal 9 [killed]」というエラーメッセージ、実は一番目にする機会が多いものです。

ターミナル - 1


これの主な原因は、メモリ不足です。

ログを見ていると「nodejs」のコンパイル中にエラーが発生しています。

「nodejs」は、巨大なソフトウェアです。

「Yocto Project」がソフトウェアのソースコードをダウンロードして、それをビルドしてディストリビューションにインストールする作業を繰り返していることは、以前の記事でもご説明した通り。

それらのソフトウェアの中には、このようなコンパイルのためホスト側のパソコンに膨大なメモリを要求するソフトウェアもあります。

コンパイルを試みたものの、その過程でメモリが食い尽くされて、Linuxカーネルがたまらず「Signal 9」を発生させてプロセスを中断したことが、今回の顛末です。

では、どうするか?

ホストのパソコンにメモリを増設すれば良いのですが、お金がかかるからヤダ。

となれば、ハードディスクの余りの容量を仮想のメモリをして使用するための「スワップ」というLinuxの機能を使いましょう。

まずは、今のLinuxのスワップの状況を調べてみましょう。

ターミナルから以下のコマンドを入力します。


$ free -m

ターミナル - 2


単位はM(メガ)ですので、現在、このLinuxには「4095MB - 4GB」程度のスワップ領域が有効になっていることが分かります。

本来のメモリ16GBに加えて、スワップも4GBですよ!?

そんなにあっても足らない?

「Node.js」恐ろしい子…。

では、この容量を増やしてやりましょう。

まずは、現在のスワップ機能をオフにする必要があります。

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


$ sudo swapoff /swapfile

ターミナル - 3

次にスワップ領域を拡張しましょう。

どの程度に拡張するかが問題です、

多いほど良さそうな感じがしますが、一般に多すぎても意味がないという説もあります。

今回は、本来のメモリと同じ容量である16GBに拡張します。

足りなくて再度ビルドに失敗するようであれば、またトライすれば良いし…。

(やたら時間がかかるので、失敗すると凹むけど!)

以下のコマンドでスワップ領域の予約を行います。


$ sudo fallocate -l 16G /swapfile

ターミナル - 4

スワップ領域の実態は、ルートディレクトリに配置されている「swapfile」というファイルです。

以下のコマンドでパーミッションを設定しておきます。


$ sudo chmod 600 /swapfile

ターミナル - 4


次に、実際のスワップ領域の作成です。

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


$ sudo mkswap /swapfile

ターミナル - 5


スワップ領域が作成できましたので、これを有効化しましょう。

以下のコマンドです。


$ sudo swapon /swapfile

ターミナル - 6


コレで良し!!

念のため、確認だけはしておきましょうか。

うん、ちゃんと16GBに拡張できていますね!


$ free -m

ターミナル - 7


この状態で、こちらの記事を参考に再度「$ bitbake core-image-minimal」に挑戦です。

今度は、絶対に上手くいきますよ!


「OpenSSH」の検証

無事に「core-image-minimal」がビルドできたら、こちらの記事を参考にSDカードを作成して「pcDuino3」を起動させたいところなんですが…。

その前に「pcDuino3」のネットワーク環境を考える必要があります。

「pcDuino3」にはWiFiが無くて、有線LANポートが一つしかありません。

そして、ここに繋ぐネットワークはインターネットに接続できて、且つ、開発用のパソコンとも接続できなければなりません。

今どきのお宅は、WiFiしかなくて有線LANのネットワークなんて少数派なんじゃないですかね?

ウチもそうです。

そうすると「pcDuino3」は家のネットワークに参入できません。

ですので、私は、以下のようなWiFiー有線LANブリッヂを買ってきました。

WiFiー有線LANブリッヂ


Amazonさんで¥3,000程度ですね。

これは、名の如く有線LANポートしかない機器をWiFiネットワークに接続させるためのブリッヂです。

組み込み用途などで使用頻度の高い安価なLinuxボードでは、WiFiが非搭載の場合が多いです。

そのような機器のソフトウェアの開発の際に、こういったブリッヂは非常に有意義ですので、一台持っておいても絶対に損はありませんよ。

ちなみに、電源はUSBのバス供給です。

これを「pcDuino3」に接続して、新しいディストリビューションのSDカードでLinuxを起動します。

Linuxの起動


起動が完了したら「root」でログインします。

パスワードは入力の必要がありません。

「pcDuino3」のターミナル - 1


ログインできたら、まずは「pcDuino3」のIPアドレスを調べておきましょう。

このIPアドレスが分かれば、以後の作業はすべて「OpenSSH」を使って開発用のパソコンでリモートに行うため、非常に効率が良くなりますよ。

以下のコマンドでIPアドレスを調べます。

私が試した時は「pcDuino3」は「192.168.179.12」というIPアドレスが割り振られたことが確認できますね。


# ip a

「pcDuino3」のターミナル - 2


以降の作業は、開発用のパソコンで今まで作業していた「VMware Workstation Player」上の「Ubuntu」Linuxではなく、Windowsで行うことにします。

まずは、現在の開発用のパソコンのIPアドレスも調べてみましょう。

Windowsのコマンドプロンプトを開いて以下のコマンドでIPアドレスを調べます。

私のパソコンは「192.168.179.15」というIPアドレスが割り振られたことが確認できます。


> ipconfig

Windowsのコマンドプロンプト


パソコンが「192.168.179.15」。

「pcDuino3」が「192.168.179.12」ですから、これらは同じクラスですので、お互いに通信できます。

それが確認できたところで、ターミナルソフトウェア「TeraTerm」を起動します。

インストールしていない方は、こちらの記事を参考にしてください。

以下のダイアログが表示されたら「ホスト」の欄に「pcDuino3」のIPアドレスである(今回の場合は)「192.168.179.12」を入力して「OK」ボタンをクリックします。

「新しい接続」ダイアログ


次は以下のようなダイアログが現れます。

「ユーザ名」のテキストボックスに「root」と入力し、下方の「OK」ボタンをクリックです。

「SSH認証」ダイアログ


すると「TeraTerm」の表示が以下の様になり、ターミナルで「pcDuino3」のLinuxへログインできたことになります。

ここまでできれば、新しく作成したLinuxディストリビューションに追加した「OpenSSH」が正しく動作していることが確認できます。

「TeraTerm」ターミナル - 1


一応「pcDuino3」の時計の時刻合わせだけは行っておきましょう。

時計があまり大きく狂っていると、以降の作業においてSSH認証のエラーが出る可能性があります。

とはいえ「pcDuino3」の電源を一度でも落としてしまうと、また狂ってしまうんですけどね…。

以下のコマンドで現在設定されている時刻を確認します。


# date

「TeraTerm」ターミナル - 2


設定する時刻が「2024年2月25日 1時15分」だったら以下のコマンドです。


# date 022501152024

「TeraTerm」ターミナル - 3


「Node.js」の検証

「OpenSSH」の次は「Node.js」の動きも確認しておきましょう。

「Node.js」の起動は、以下のコマンドを入力することによって行います。

バージョン情報など、何か表示されましたね?

プロンプトが「#」から「>」になっているのに注目です。


# node

「TeraTerm」ターミナル - 4


これだけでも、新しく作成したLinuxディストリビューションに追加した「Node.js」が正しく動作していることが確認できますが、それだけだと面白くないので、簡単なプログラムを実行させてみましょう。

「>」というプロンプトに以下のプログラムを入力し、エンターキーを入力します。

お約束の例のヤツです。


> console.log("Hello World!");

「TeraTerm」ターミナル - 5


「Ctrl」+「c」を押すと「Node.js」が終了し、プロンプトが「>」から「#」に戻ります。

「TeraTerm」ターミナル - 6


以上で「Node.js」の検証は終了です。


「NPM」の検証

「Node.js」を使って開発を進めていく上では、様々なパッケージやツールを別途ダウンロードする必要が出てきます。

そのためのパッケージ管理ツールが「NPM」であり、こちらも新しいディストリビューションに追加しました。

こちらも検証しておきましょう。

まず以下のコマンドで「sample」というディレクトリを作成し、その中へ移動します。


# mkdir sample

# cd sample/

「TeraTerm」ターミナル - 7


おそらく「Node.js」を使うなら、いずれ必ず使うであろう「ejs」というテンプレート・エンジンを「NPM」を使ってダウンロードしてみましょう。

以下のコマンドを実行するとダウンロードできるはずです。


# npm install ejs

「TeraTerm」ターミナル - 8


「sample」ディレクトリの中に以下のようなディレクトリやファイルが確認できたら「NPM」の検証も完了です。


# ls -l

「TeraTerm」ターミナル - 9


以下のコマンドで、元のディレクトリに戻りましょう。


# cd ..

「TeraTerm」ターミナル - 10


「Git」の検証

最後に「Git」の検証を行います。

何でも良いのですが、リポジトリからソースコードをクローンします。

ここでは、私のリポジトリから「openocd_nora」というソースコードをクローンしてみます。

ちょっと長いけど、以下のコマンドです。

クローンが始まったでしょうか?


# git clone https://github.com/RyutaroMorita/openocd_nora.git

「TeraTerm」ターミナル - 11


正しくクローンできたでしょうか?


# ls -l

「TeraTerm」ターミナル - 12


以上で「core-image-minimal」に新たに追加したすべてのソフトウェアが正しく動作していることが確認できました!


「pcDuino3」用のLinuxディストリビューションも、ここまでくれば、かなり実用的なものになったはずです。

次回は、今まで慣れ親しんだ最小限のディストリビューション「core-image-minimal」を離れ、よりリッチでGUIの表示を持つ「core-image-sato」というディストリビューションのビルドを行いたいと思います。

え、単に「bitbake core-image-sato」ってやるだけでしょ…って?

いやいや、これが結構大変だったんですよ~。


<続く>

Simplicity Studioを使ってみた! その3

前回からの続き です。 このテーマを最初からご覧になる場合は こちら からどうぞ。 「Simplicity Studio」でプログラミング インストールしたSilicon Labs社のマイコン用の統合開発環境「 Simplicity Studio 」で、テストプログラムを動かして...