2013年02月25日

PandaBoard, PandaBoard ESを購入

組込み分野からの離脱を目指しているのに、また新しい組込み評価ボードを買ってしまった。それも2枚も。入手したのは、PandaBoardPandaBoard ESという奴。ESじゃない方がTI OMAP4430、ESの方はOMAP4460(いずれもDual-core ARM Cortex-A9)というCPUを搭載している。どちらも現行のTI OMAPシリーズの中ではハイエンド寄りに位置するCPUだ。この2つのボードはなぜか製造元が違っていて、PandaBoardの方が去年の12/22の記事で紹介したBeagleBoard-xMと同じベンダCurcuitco Electronicsで、PandaBoard ESの方がSVTronicsになっている。

今回はDigiKeyから購入した。公式サイトのpandaboard.orgに複数の販売先リンクが載っていたが、このうちDigiKeyが一番先頭になっていた。DigiKeyのサイトで検索したら、どちらも在庫ありだったが、PandaBoardの方が残り1個なのを見て、片方の在庫がなくなると、しばらく両方一緒に購入できなくなるかもしれないと心配になったので、思い切って二つとも注文してしまった。DigiKeyは海外の電子部品通販サイトの中では有名な所で、以前からその存在は知っていたが、利用したのは今回は初めてだ。日本語のページも用意されていて、注文も日本語を使ってできる(ただし、商品の送付先や請求先情報は英語入力)。注文したのは02/22で、翌日の02/23に出荷の通知メールが来た。そして、今日の昼頃にUPSが商品荷物を配達してくれた。友人から聞いたりググり情報とかでDigiKeyの評判が良いのは知っていたが、ここまで迅速な対応をしてくれるとは。またボードや電子部品を買う機会があったら、ぜひDigiKeyを利用しようという気になった。Amazonもそうだけど、注文した商品が早く届くというのは最大のサービスであり、リピーターを増やすのに一番効果があるんだなぁ。

下が、入手したPandaBoardとPandaBoard ESの製品箱とボード本体の写真。
IMG_3015_1-PandaBoard-PackageBox-20130225.jpg
IMG_3026_1-PandaBoard-PackageItems-20130225.jpg
IMG_3035_1-PandaBoard-EntireTopView-20130225.jpg
IMG_3033_1-PandaBoard-LabelOnBackView-20130225.jpg
IMG_3016_1-PandaBoard_ES-PackageBox-20130225.jpg
IMG_3027_1-PandaBoard_ES-PackageItems-20130225.jpg
IMG_3037_1-PandaBoard_ES-EntireTopView-20130225.jpg
IMG_3034_1-PandaBoard_ES-LabelOnBackView-20130225.jpg
まったく同じ箱に入っているので、貼付ラベルでしか区別がつかない。ボード自体も同サイズですごく似通っているので、裏側の貼付ラベルを確認しないと判別するのが難しい。ボード上に搭載されているコネクタの種類や位置もまったく同じ。それもそのはずで、OMAP4430とOMAP4460は動作クロック周波数(1.0GHz vs 1.2GHz)と3D Encode/Decodeの入出力フォーマット(720p vs 1080p)くらいしか違いがない。CPUが異なるだけで、この2つのボードの回路はまったく同じなのかもしれない。上の写真のとおり、箱にはボード本体とゴム製の足しか入っていなかった。BeagleBoard-xMにはAngstrom Linuxが書き込み済みのSDカードが同梱されていたが、PandaBoardではそれさえも省かれている。もう一つBeagleBoard-xMと比較してPandaBoardには大きな機能上の相違点がある。それは、後者にはTI WiLink 6.0ベースの無線LAN(802.11 b/g/n)とBluetooth(v2.1 + EDR)も搭載されていることだ。Androidや他のモバイルOSでは無線LANはほとんど必須の機能なので、これが有ると無いとでは大きな差だ。BeagleBoard-xMでもUSB-to-WLANアダプターを使えば無線LANを追加できるが、当然ながらUSBポートを一つ塞いでしまう。

BeagleBoardを知っているので、その後継ボードであるPandaBoardの存在も発売時から知っていたが、なぜこの時期にPandaBoardを購入したのかというと、じつは次の2つの目的にこのボードを使いたいと思ったから。

 ・Firefox OSのターゲットボードとして使う。
 ・Android Hackingのターゲットボードとして使う。

最近Firefox OSについてググるのが日課になっているが、Mozilla Developer Networkの下のリンクページがいつもトップの方にヒットしていた。

 Firefox OS ビルドの必要条件 - Mozilla | MDN

本家本元のMozillaの開発者向け情報ページの一つで、このページにFirefox OSの対応ターゲットが掲載されているが、その中にPandaBoardが含まれているのを見つけたのが、このボードをどうしても手に入れたくなったきっかけ。しかもこのボードは「ティア 1 」という積極的にサポートされているグループに属している。いままさに離陸寸前のFirefox OSへの注目度は日に日に上がっていて、必ず今年中にブレークするだろうと私は予想している。こういう風に状況がどんどん進んでいる中で、Firefox OSの研究を始めるならいましかないという想いが日増しに強くなっていた。いまこの時期を逃したら、きっとすごく後悔するだろうと思ったのが、このボードを買った最大の理由。Firefox OS研究のモチベーションが上げたいがために、このPandaBoardを入手したと言っても良いくらいだ。

ちなみに、上で紹介したページにPandaBoard以外のFirefox OSターゲットの情報も載っていて、その中にはAndroidスマホもいくつか含まれている。これらのうち、次の2つは日本国内でも販売された機種なので入手が容易だ。

 Samsung Galaxy S2
 Samsung Galaxy Nexus

近いうちにこれらも必ず入手しようと心に決めている。オークションや中古ショップでこの2つの機種が容易に手に入るのに、なぜわざわざPandaBoardを選択したのかというと、じつは、Firefox OSを他のボードへ移植することに挑戦したいから。Firefox OSのソースをカスタマイズして、他のターゲットへ移植するなら、スマホよりPandaBoardみたいなボードの方が色々とやり易いではないかと思っている。OSのソースをカスタマイズした結果どういう動きをするのか、先にPandaBoardで確認することができる。つまりPandaBoardをリファレンス・ターゲットして使うことができる。いままで色々な組込みOSを移植した経験から、このメリットは非常に大きいことを知っている。単にアプリを開発するだけならスマホで十分だと思うが、私が目論んでいるのは、Firefox OSをできるだけ多くのターゲットハードウェアへ(PandaBoardみたいなボードだけじゃなく、スマホやタブレットにも)移植することだったりする。Firefox OSのスペシャリストになることがこの取り組みの最終目標なので、ソース解読は絶対にやろうと決めていた。こういうことに取り組んでいる人はまだ少ないはずなので、いまのうちからこれをスタートすれば、その過程で習得した技術が、将来Firefox OSがブレークしたときにきっと活きてくるだろう。

もう一つのAndroid HackingのターゲットとしてPandaBoardを使う件については、別の記事に書くことにする。長い記事は読み飛ばす人が多いだろうから、一旦切っりたいというのもある。こちらのついても壮大な目論見を持っていて、じつは、書きたいことがたくさんあったりする。12/09の記事を読んだ人は、「アンチAndroid宣言までしたのに、こいつはなぜいまさらAndroidの研究を再開するのか」と不思議に思うに違いない。アプリ開発ではなくなぜHackingなのかとか、私が始めようとしている事の目的は何なのかとか、その辺のことを別の記事で詳しく書きたいと思っている。

posted by とみやん at 17:33| Comment(0) | TrackBack(0) | Embedded Linux > その他

2013年01月26日

i.MX53 Quick Start BoardでLinuxを動かす (3)

前の2つの記事で、Freescale i.MX53 Quick Start BoardにLinuxを移植した際の作業記録(備忘録)は終わりだ。このシリーズ記事は、ここで終わらせても良かったんだけど、今回の移植作業の感想や今後の計画とかも書いておきたい。前の2つの記事とは性質が異なり、蛇足的な内容なので、明確に区切った方が適切かなぁという気がしたので分けた。

まずは、Freescaleが配布するLinux BSPを使ってIMX53QSBへLinuxを移植した感想になるが、結局のところBSP=LTIBなので、移植作業の感想イコールLTIBの使用感ということで書くしかない。はっきりて言って、私はこのLTIBというビルドツールをものすごく使い難いと感じた。i.MX CommunityでもLTIBの評判はあまり良くないみたいだ。大体いまどき組込みLinuxでrpm形式のパッケージ管理はないだろう。OpenEmbeddedYocto Projectもdeb形式パッケージを採用しており、業界的にはdebベースのパッケージ管理とビルドフレームワークの方が主流派だ。じつは、Freescaleが配布するi.MXシリーズ用Linux BSPは、i.MX51シリーズまではOpenEmbedded準拠の形式だったらしい。i.MX53シリーズからi.MXシリーズ共通のLinux BSP用ビルドツールとしてLTIBが導入されたみたいだが、なぜFreescaleはこんな使い難いツールを採用したのか理解に苦しむ。i.MX51シリーズまでの形式を維持して、i.MX53シリーズでもOpenEmbedded準拠のBSPを配布してくれた方がよっぽど良かったじゃないかという気がしてならない。i.MX Communityや他の組込みLinux系の情報交換サイトを検索すると、同じ意見が散見される。私家版のOpenEmbedded形式i.MX用Linux BSPを作ろうとしている人もいるようで、私も時間さえあれば同じことをやりたいくらいだ。FreescaleはTIと並ぶ組込みCPUのメジャーメーカーであり、i.MXシリーズは多くの組込み機器で採用されている(特にここ数年、車載機器でのi.MXシリーズの採用例が急増しているらしい)。この点を考えると、業界のトレンドに逆行するような形式のLinux BSPを配布することは悪影響が大きいんじゃないかと心配してしまう。最新のi.MXファミリCPUであるi.MX6シリーズの量産が2012年12月から始まっているが、残念ながら、i.MX6シリーズ用Linux BSPでもLTIBが使われているらしい。もしFreescale社の方がこの記事を読んでいたら、i.MXシリーズ用Linux BSPをOpenEmbedded形式に変更することをぜひ検討してください。切にお願いします。

話は変わって、今後の計画についてだが、じつは、本業の仕事でIMX53QSBへQtを移植するための作業をいまやっている真っ最中だったりする。最終的なターゲットハードウェアは同じi.MX535を搭載したカスタムボードなんだけど、IMX53QSBへQtが移植できたら、そのQtの実行ファイル一式をカスタムボードのシステム環境へコピーすればそのまま動くはずだ。という訳で、IMX53QSBへQtを移植する作業の経過を今後記事に書いていこうと思っている。BeagleBoard-xMの記事に、すでにこちらのボードにQtを移植済みだと書いた。そのとおりなんだけど、本業の仕事が忙しくて両方のボードのQt移植の記事を書く時間がしばらく取れそうもない。当面はIMX53QSBの方を優先して、こちらのボードへQtを移植する作業過程を備忘録として書いていきたい。BB-xMへのQtの移植方法については、IMX53QSBの方の作業が一段落したところで書くつもりでいる。

BB-xMのTI DM3730、そしてIMX53QSBのFreescale i.MX535。期せずして、TIとFreescaleという2つのメジャーメーカーのARM CPUを搭載したボードが手に入ったので、LinuxやQt以外の移植にもトライしたい気持ちがふつふつと湧いている。何を考えているかというと、じつは、この2つのボードへFirefox OSを移植できないものかと目論んでいる。Androidに対抗するモバイルOSのダークホース的な存在して、Firefox OSに対する注目度は日に日に大きくなっている。最近ほぼ毎日「Firefox OS」というキーワードでググっているが、日に日にヒット数が増えていることからもこれが判る。Firefox OSはAndroidなんか比べものにならないくらいキビキビと動作し、低性能なハードウェアでもかなりレスポンスが良いらしい。やたらとCPUバワーを食うAndroidの所為で、日本国内で販売されているスマホやタブレットはいまや高価格帯の製品ばかりになってしまっている。日本人の平均収入は低下する一方なのに、スマホやタブレットの製品価格は上がる一方だ。Firefox OSが本格的に普及すれば低価格なスマホやタブレットがかなり市場に出てくるんじゃないだろうか。低収入で生活を維持している人が増えている時代なので、こういう低価格なスマホやタブレットの需要も相当あるはずだ。すでにKDDIは、Firefox OSを搭載した低価格帯のスマホの製造と販売について検討に入っているという情報もある。Androidに対抗するモバイルOSとして、Firefox OSは今年必ずブレークするだろう。私もいまこそFirefox OSに賭ける時だという気持ちが大きくなる一方だ。私はアンチAndroid派であることを宣言しているので、当然ながらFirefox OSに大きな期待を抱いており、できるものなら、いますぐFirefox OSのエバンジェリストになりたいとさえ思っている。上の計画をどういう形で具現化するか色々と考えを巡らしているが、計画の内容が固まったら、このブログで記事として発表したい。
タグ:i.MX Feeescale
posted by とみやん at 17:49| Comment(0) | TrackBack(0) | Embedded Linux > その他

2013年01月25日

i.MX53 Quick Start BoardでLinuxを動かす (2)

前記事に続いて、i.MX53 Quick Start BoardでFreescale配布するLinux BSPを動かした際の記録(備忘録)を書いていく。

今回の作業で参照したドキュメントは以下のとおり。

 ltib_build_host_setup.pdf : LTIB Build Host Setup
 i.MX53_START_Linux_BSP_UserGuide.pdf : i.MX53 START Linux User's Guild
 i.MX53_START_Linux_BSP_Release_Note.pdf : i.MX53 START 11.09.01 Linux Release Notes


●LinuxのブートSDを作成する

前記事までで、LTIBを使って、Linux BSPから以下の3つが作成できた。

 U-Boot(ブートローダー)イメージ
 カーネルイメージ
 rootファイルシステム(rootのユーザーランド・ファイル群)

すべてLTIBディレクトリ直下のrootfsというディレクトリの中に作成される。これらをmicroSDメディアへ書き込んで、IMX53QSBでブート可能な形式のSDを作成すれば、今回の作業の最終目的はほぼ達成できたことになる。上のBSP User's Guideドキュメントの「7. Using a Linux Host to Set Up an SD/MMC Card」という節にその手順が記載されている。

まずは、4GBのmicroSDとUSBカードーリーダを用意した。そして、U-BootイメージをSDへ書き込むために、下のコマンドを実行した。
 $ cd <LTIB directory>
$ cd rootfs
$ sudo dd if=u-boot.bin of=/dev/sdb bs=512
$ sync

ddコマンドを使っているということは、上のコマンドはSDのブートセクタにu-boot.binを書き込んでいるんだな。ちなみに、すでにu-boot.binを書き込み済みのSDに再度同じファイルを書き込む場合は、次のコマンドを使わないとならないようだ(上のコマンドだと、既存のパーティションテーブルが消えてしまうのだろう)。
 $ sudo dd if=u-boot.bin of=/dev/sdb bs=512 seek=2
$ sync

続いて、カーネルイメージをSDへ書き込むために、下のコマンドを実行した。
 $ sudo dd if=uImage of=/dev/sdb bs=512 seek=2048
$ sync

最後に、rootファイルシステム(rootfs)をこのSDへ書き込むが、その前にパーティションを作成する必要がある。次のコマンドでfdiskを起動して、
 $ sudo fdisk /dev/sdb

下のように、開始セクタ=8192〜終了セクタ=最終セクタの領域を持つパーティションを作成した。
 Command (m for help): p

Disk /dev/sdb: 4004 MB, 4004511744 bytes
124 heads, 62 sectors/track, 1017 cylinders
Units = cylinders of 7688 * 512 = 3936256 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x2e0e4e51

Device Boot Start End Blocks Id System

Command (m for help): u
Changing display/entry units to sectors

Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 1
First sector (62-7821311, default 62): 8192
Last sector, +sectors or +size{K,M,G} (8192-7821311, default 7821311):
Using default value 7821311

Command (m for help): p

Disk /dev/sdb: 4004 MB, 4004511744 bytes
124 heads, 62 sectors/track, 1017 cylinders, total 7821312 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x2e0e4e51

Device Boot Start End Blocks Id System
/dev/sdb1 8192 7821311 3906560 83 Linux
Partition 1 does not end on cylinder boundary.

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.

さらに、fdiskで作成したパーティションを初期化するために、下のコマンドを実行した。
 $ sudo mkfs.ext3 /dev/sdb1

rootfs用パーティションの作成と初期化が終わったら、一旦SDを取り外して、再度挿入し直した。Ubuntuではリムーバブルメディア上の初期化済みのパーティションは自動的にマウントされる。挿入したSDのパーティションのマウントポイントは、次のコマンドで確認できる。
 $ df -h

Ubuntuでは/media以下にリムーバブルメディアのパーティションがマウントされる。SDのパーティションのマウントポイントを確認した後、下のコマンドを実行して、rootfs全体をそのパーティションへコピーした(/media/SD-Volume-ID_FS_UUIDがマウントポイントと仮定)。
 $ cd rootfs
$ sudo cp -rpa [A-z]* /media/SD-Volume-ID_FS_UUID
$ sync

これで、ブートSDは完成だ。

●Linuxシステムの起動テスト

ブートSDができたので、さっそくこのSDで起動するか試してみた。上で作成したSDをIMX53QSBのmicroSDスロットに挿入し、VGAポートにモニタを接続して、ワクワクしながら、ボードの電源を投入(ACアダプタを接続)してみた。
IMG_2781_1-IMX53QSB_LinuxBSP_L2.6.35_11.09.01_Booting_VGA-20130123.jpg
「おっ、Linuxペンギン・ロゴが出たぞ。よし、やったぁ」と思ったのもつかの間、それ以上のブートシーケンスがまったく表示されない。「なぜ???」。

もしかすると、ブートシーケンスはシリアル側に出力されるのかも。それならばと、IMX53QSBのシリアルポートとMacをストレート・シリアルケーブルで接続した状態で、ボードの電源を再投入してみた。すると、下のようにブートシーケンスの表示が始まった。
IMX53QSB_LinuxBSP_L2.6.35_11.09.01_ZTerm-Scrnshot09-855x782
そして、最終的に、下のようにLinuxのログインプロンプトが表示された。「おー、やったぜ。セルフおめでとう。パチパチ」。
IMX53QSB_LinuxBSP_L2.6.35_11.09.01_ZTerm-Scrnshot10-855x782
しかし、せっかくボード上にVGAポートが在るのに、こちら側にブートシーケンスが出力されないのは納得いかん。この程度の問題なら、ちょっと調べれは解決できそう予感もするし・・・。

さーてと、気を引き締めながら、ここでシリアルへ出力されている上のブートシーケンスを良く観察した。うーん、最初の方はU-Bootの出力みたいだ。「Hit any key to stop autoboot: 」の箇所で3秒のカウントダウンが表示されるのが気になったので、このメッセージが出力された瞬間に任意のキーをタイプしてみた。すると、ブートシーケンスが停止して、下のようなU-Bootのコマンドプロンプトが表示された。そして、さらに「printenv」というコマンドを入力してみた(山勘で「help」と入力したら、U-Bootのコマンド一覧が表示されたので、このコマンドの存在を知った)
IMX53QSB_LinuxBSP_U-Boot_Output_ZTerm-ScrnShot22-855x782
うーん、やっぱりこのU-Bootの環境変数に上の問題を解決するヒントがありそうだなぁ。この後の経過は端折ってしまうが、i.MX Communityというサイトでいくつかのキーワードを組み合わせて検索したら、この問題の解決方法が見つかった。下のコマンドでU-Bootの環境変数を追加・変更すれば、VGA側にもブートシーケンスが出力されということが判った。
 > setenv vga 'video=mxcdi1fb:GBR24,VGA-XGA di1_primary vga'
> setenv bootargs_base 'setenv bootargs console=ttymxc0,115200 console=tty0 ${vga}'
> saveenv
> reset

下の写真が、VGAポートに接続したモニタにブートシーケンスが表示されている様子。
IMG_2791_1-IMX53QSB_LinuxBSP_L2.6.35_11.09.01_Booting_VGA-20130123.jpg
IMG_2788_1-IMX53QSB_LinuxBSP_L2.6.35_11.09.01_Booting_VGA-20130123.jpg
また、ドーターボードのHDMIポートへブートシーケンスを出力するには、下のコマンドを実行すれば良いことも判った。
 > setenv hdmi 'video=mxcdi0fb:RGB24,1024x768M@60 di0_primary hdmi'
> setenv bootargs_base 'setenv bootargs console=ttymxc0,115200 console=tty0 ${hdmi}'
> saveenv
> reset

上の二組のコマンドを実行すると、U-Bootの環境変数は最終的に下のような値になる。
 bootdelay=3
baudrate=115200
loadaddr=0x70800000
netdev=eth0
ethprime=FEC0
uboot=u-boot.bin
kernel=uImage
nfsroot=/opt/eldk/arm
vga=video=mxcdi1fb:GBR24,VGA-XGA di1_primary vga
hdmi=video=mxcdi0fb:RGB24,1024x768M@60 di0_primary hdmi
bootargs_base=setenv bootargs console=ttymxc0,115200 console=tty0 ${hdmi}
bootags_nfs=setenv bootargs ${bootargs} root=/dev/nfs ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp
bootcmd_net=run bootagrgs_base bootargs_nfs; tftpboot ${loadaddr} ${kernel}; boom
bootags_mmc=setenv bootaggs ${bootargs} ip=dhcp root=/dev/mmcblk0p1 rootwait rw
bootcmd_mmc=run bootargs_base bootargs_mmc; mmc dev 0; mmc read ${loadaddr} 0x800 0x1800; bootm
bootcmd=run bootcmd_mmc
stdin=serial
stdout=serial
stderr=serial
ethact=FEC0

この状態で、VGAポートにブートシーケンスを出力したければ、次のコマンドを、
 > setenv bootargs_base 'setenv bootargs console=ttymxc0,115200 console=tty0 ${vga}'
> saveenv
> reset

HDMIポートにブートシーケンスを出力したければ、次のコマンドを実行すれば良い。
 > setenv bootargs_base 'setenv bootargs console=ttymxc0,115200 console=tty0 ${hdmi}'
> saveenv
> reset

ちなみに、U-Bootの環境変数の説明はBSP Release Notesにちゃんとに書かれてある。上の問題を解決した後でこのことに気がついた。「やっばり、マニュァルやドキュメントには先にひと通り目を通しておかないとダメだよなぁ」という教訓を味わった事例になってしまった。

●未解決の問題

ブートシーケンスの出力先をVGAやHDMIポートに変更する件についてはこれで解決できたが、じつは、未解決の問題点がいくつかある。以下がそれ。
 
 (1) 「cp: write error: No space left on device」というメッセージが出力される。
 (2) 「mount: mounting usbfs on /proc/bus/usb failed: No such file or directory」というメッセージが出力される。
 (3) シェルのログインプロンプトが表示されない。

いずれの問題も上に掲載したVGAのブートシーケンスの写真で確認できる。シリアル出力ではOKなのに、VGA/HDMI出力ではこれらの問題が起きるのが不思議だ。じつは、本記事を書いている時点で、残念ながら、(2)と(3)の問題はまだ解決できていない。これらの問題の解決方法はそのうち見つかるだろうと思っているので、いまは放っておくことにした。組込みLinuxをやっていると、こういう事は良くあるので、まぁ、焦らないが吉というこで・・・。

取りあえず、上の(1)の問題の解決方法だけは判った。/etc/rc.d/rc.conf内の下の項目の値を「8192k」に変更すれば良いみたいだ。変更前の値は「512k」になっている。
 TMPFS_SIZE = 8192k

この問題の解決方法もi.MX Communityで検索して見つけた。

未解決の問題点が残ってしまったが、これでIMX53QSBへのLinux移植は一応お終いということで。
タグ:Freescale i.MX
posted by とみやん at 14:05| Comment(0) | TrackBack(0) | Embedded Linux > その他

2013年01月24日

i.MX53 Quick Start BoardでLinuxを動かす (1)

本業の仕事の関係で、i.MX53 Quick Start Board(部品番号:MCIMX53-START-R)というボードを入手した。Freescaleのi.MX535というCortex-A8 ARMコアCPUを搭載した組込み向け評価ボード。

i.MX53QSB_EntireView_from_IMX53QSBRM.jpg

私の所に来たときは、このボード専用の別売部品であるHDMI Interface Card for MX535/08(部品番号:MCIMXHDMICARD)というドーターボードが取りつけられた状態だった。

上の写真はFreescaleのサイトから入手したもの。現在はまだ借用品だが、いまの仕事が終わったら、これをそのまま譲ってもらえることになっている。ボードの実物写真は後日別の記事に掲載するつもり。

このボードの仕様は以下のとおり。

 プロセッサ      i.MX535(MCIMX535DVV1B)
 DRAMメモリ     8GB DDR3 SDRAM
 ストレージ:     5 in 1 SD/MMC/SDIO Card Connector
            microSD Card Connector
            7-pin SATA Data Connector
 実装コネクタ     Video Output: 15-Pin D-Sub VGA Connector
             30-Pin LVDS Connector
            Ethernet: RJ-45 Connector for 10/100 Base-T
            USB: Dedicated HS USB 2.0 Standard-A Host Connector
             Shared HS USB 2.0 Standard - Host and Micro-B Device Connectors
            Audio; 3.5mm Stereo Head Phone output
             3.5mm Mono-Microphone input and Mono Head Phone (right channel) output
            Debug: 9-Pin D-Sub Debug UART Connector
             20-Pin Standard ARM JTAG Connector
 拡張ヘッダ      120-Pin Header (Populated) to Support 1 of the following:
            Optional HDMI Output Daughter Card (orderable)
            Optional WVGA and WQVGA LCD Display Daughter Cards (orderable)
            Camera Daughter Card (custom)
            SDIO Based WiFi Daughter card (custom)
 インターフェース部品 Power, Reset, 2 User-Defined Buttons
            8 Status LEDs – External Power, PMIC ON, Fault Condition, and more
 電源         5V mm Barrel Connector


さっそくこのIMX53QSBにLinuxを移植したので、その経過を紹介していこう。ただし、BeagleBoardと比べると、このボードはマイナーなので、持っている人はかなり少ないじゃないかと思う。同じボードを持っている人にしか役に立たない情報になるので、本記事は自分のための備忘録として書いていく。

IMX53QSB用のLinux BSPはFreescale社のサイトで配布されているので、今回はそれを入手して使った。ちなみに、Android BSPも同サイトで配布されているが、このボードでAndroidを動かすつもりはない。私自身Androidにまったく興味を持っていないし、IMX53QSBへのLinux移植は本業の仕事向けの支援作業として取り組んでおり、この仕事でもAndroidを使っていないからだ。

最初に、Freescale社のサイトから以下のファイルを入手した。

 (A) Linux 2.6.35 Source Code Files and documentation 11.09L2.6.35_11.09.01_ER_source_bundle.tar.gz
 (B) Patch based on L2.6.35_11_09_ER_SOURCELinux_201112_20patch_bundle.tar.gz


Freescale社のサイトからソフトウェアやツール類をダウンロードするには、先にユーザー・アカウントを作成しておく必要がある(一般公開の製品資料などは、アカウントなしでもダウンロード可能)。

(A)のファイルを解凍して、その中のL2.6.35_11.09.01_ER_docs.tar.gzに含まれている以下の3つのドキュメントにざっと目を通した。

 ltib_build_host_setup.pdf : LTIB Build Host Setup
 i.MX53_START_Linux_BSP_UserGuide.pdf : i.MX53 START Linux User's Guide
 i.MX53_START_Linux_BSP_Release_Note.pdf : i.MX53 START 11.09.01 Linux Release Notes


●LTIB(=BSP)をインストールする

まずはBSPのビルドフレームワークツールであるLTIB(Linux Target Image Builder)をインストールせよと書いてあったので、上のLTIBの設定手順が記載されたドキュメントを読みながら、それのとおりにやってみた。

このドキュメントには、LTIBが対応しているディストリビューションはUbuntu Destop 9.04だけだと書かれているが、下調べで得た情報で、Ubuntu 10.04でも動くことが判っていたので、Ubuntu Desktop 10.04(32ビット版)をインストールしたVMware仮想マシンを用意して、その上にBSPのビルド環境を構築した。本当はUbuntu 12.04を使いたかったんだけど、このLTIBというツールがUbuntu 10.04までしか対応していないという情報がたくさん見つかったので、今回はUbuntu 12.04を使うことは断念した(LTIBはスクリプト・ベースのツールなので、スクリプトにパッチを当てればUbuntu 12.04でも動くという情報も在ったが、パッチを当てても確実に動く保証はないみたいだ。本来の目的であるBSPビルドの前段階の作業に時間を取られたくなかったこともあり、今回はUbuntu 12.04の使用はすっぱりと諦めた。いつか時間があるときに、Ubuntu 12.04上にLTIB環境を構築することに挑戦しようと思っている)。

LTIBの動作に必要なパッケージをインストールするために、最初に、以下のシェルスクリプトを実行しろとドキュメントに書かれてあった。
 #!/bin/bash

# Install packages needed by LTIB
sudo aptitude -y install gettext libgtk2.0-dev rpm bison m4 libfreetype6-dev
sudo aptitude -y install libdbus-glib-1-dev liborbit2-dev intltool
sudo aptitude -y install ccache ncurses-dev zlib1g zlib1g-dev gcc g++ libtool
sudo aptitude -y install uuid-dev liblzo2-dev
sudo aptitude -y install tcl dpkg

# Packages required for 64-bit Ubuntu
# Do "uname -a" and see if the word "x86_64" shows up.
if uname -a|grep -sq 'x86_64'; then
sudo aptitude -y install ia32-libs libc6-dev-i386 lib32z1
fi

# The following recommended for Linux development.
# They are not required by LTIB.
sudo aptitude -y install gparted emacs22-nox openssh-server
sudo aptitude -y install nfs-common nfs-kernel-server lintian
sudo aptitude -y install git-core git-doc git-email git-gui gitk
sudo aptitude -y install diffstat indent tofrodos fakeroot doxygen uboot-mkimage
sudo aptitude -y install sendmail mailutils meld atftpd sharutils
sudo aptitude -y install manpages-dev manpages-posix manpages-posix-dev linux-doc
sudo aptitude -y install vnc4server xvnc4viewer

このシェルスクリプトは一回だけしか実行しないはずで、そんなものをわざわざ作成するのは面倒だと思ったので、上の各行を一つずとコピペしながら、LTIBの必須パッケージのインストールを行った。このシェルスクリプトではたくさんパッケージをインストールしているが、私は前半の(「# Install packages needed by LTIB」で始まる)5行分のパッケージしかインストールしなかった。LTIBのドキュメントを良く読むと、LTIBによるビルドとシステムイメージからブートSDを作成するだけなら、他のパッケージは不要なんじゃないかという気がしたからだ。また、このシェルスクリプトの「if〜fi」で挟まれた行はホスト環境が64ビット版であるかどうかを判定して実行されるので、64ビット版Ubuntuの場合はこれらのパッケージもインストールする必要がある。

続いて、/etc/sudoersの最後に以下の設定項目を追加した。
 $ sudo visudo

USER ALL=NOPASSWD:/usr/bin/rpm,/opt/freescale/ltib/usr/bin/rpm

上の設定項目の「USER」部分には、LTIBを使用するユーザー名にした。LTIBのドキュメントには、これを「%admin」にしろと書かれていたが、それだと、adminグループに所属するすべてのユーザーが上記のディレクトリにアクセスできてしまう。これはセキュリティ的に怖いので、アクセス権を与えるのはLTIBを使うユーザーだけに限定することにした(特定のコマンド限定とはいえroot権限の実行権をを与えることは、セキュリティ的に大いに問題があると思う。どうもこのLTIBというツールは好きになれない)。

さらに、以下のコマンドを実行して、LTIB本体のインストールを行った。
 $ tar zxf L2.6.35_11.09.01_ER_source.tar.gz
$ cd L2.6.35_11.09.01_ER_source
$ ./install

上のinstallは会話形式で、Freescaleのソフトウェア使用ライセンスに同意するかどうかの質問に続いて、LTIBのインストール先ディレクトリを尋ねるプロンプトが表示されるだけの短いシェルスクリプト。

LTIBのインストールが終了した後、インストール先のLTIBのファイル構成をざっと調べてみたが、どうもターゲット用のカーネルやパッケージはすべてLTIBと一体になっていて、このツールを使わないとBSP自体のビルドができないようになっているようだ。LTIBでは、ターゲット用のパッケージはすべてrpm形式で管理されており、パッケージを追加する場合は、これに合わせる必要があるみたいだ(deb全盛の時代に、rpmベースのパッケージ管理はないだろうという気がして仕方ないんだけど・・・)。

●ターゲット構成情報を設定する

ここまででLTIBのインストールは終了したので、続いて、LTIBが持っているターゲット構成情報の設定を行った。
 $ cd <LTIB directory>
$ ./ltib -m config

上の「./ltib -m config」というコマンドは、LTIBをインストールした直後に必ず一度実行しなければならないようだ。LTIBのインストール直後にこのコマンドを実行すると、「Installing host support packages.」というメッセージが表示され、しばらく待たされた後(初めて「./ltib」コマンドを実行したときに、全パッケージファイルを/opt/freescale/pkgsディレクトリへ移動する処理を行なっているようだ)、下のような画面が開く。
IMX53QSB_LinuxBSP_LTIB_ConfigMenuScreen-Scrnshot01-640x410.png
これはターゲットプラットホームのカテゴリを選択する画面のようだ。Freescale社はPowerPCやColdFireコアのCPUも製造しているが、LTIBはこれらのCPUにも対応していようなので、ターゲットプラットホームのカテゴリ選択画面が最初に表示されるのは、多分この理由によるのだろう。上の画面の「Platform choice (Freescale iMX reference boards) --->」というのがターゲットプラットホームのカテゴリを選択するメニューだが、このメニューの選択可能項目はこれしか存在しない。つまりこのメニューはすでに適切に設定済みの状態なので、特に変更する必要はない。そのまま画面の下側の「」を実行した。すると、前画面での設定内容を保存するかどうかの質問画面に続いて(この画面では当然「」を選択した)、下のような新しい画面が表示される。
IMX53QSB_LinuxBSP_LTIB_ConfigMenuScreen-Scrnshot03-640x410.png
この画面では、以下のメニュー項目を変更した。
 --- Choose the platform type
Selection (imx25_3stack) ---> (X) imx5x
--- Choose the packages profile
Selection (use packages in preconfig (Min profile)) --->〔変更なし〕

さらに、下の画面が表示されるので、
IMX53QSB_LinuxBSP_LTIB_ConfigMenuScreen-Scrnshot13-640x410.png
IMX53QSB_LinuxBSP_LTIB_ConfigMenuScreen-Scrnshot18-640x410.png
この画面では、下のメニュー項目を変更した。
 --- Choose your bootloader for U-Boot
bootloader (u-boot) --->〔変更なし〕
--- Choose your board for u-boot
board (mx51_bbg) ---> (X) mx53_loco

BSP User's Guideに上の手順の説明が書かれていたので、すべてそれに従った。最後の画面の「Exit」を実行すると、LTIBの構成設定画面は終了する。以上で、LTIBのターゲット構成情報の設定は完了のようだ。

BSP User's Guideには、ここで下のコマンドを実行せよと書いてある。
 $ ./ltib

このコマンドを実行すると、BSPのビルドが始まり、最終的にカーネルを含むシステムイメージを生成してくれるらしい。しかし、私は、最新のパッチを適用済みの状態で最初のビルドをやりたかったので、上のコマンドを実行せずに、ここでFreescaleから配布されている最新のパッチをBSPへ適用することにした。上述の(B)のファイルにIMX53QSB用Linux BSPの最新パッチが格納されている。

●最新版パッチをBSPに適用する

まずは、パッチが格納されているファイルを展開した(ホームディレクトリに、Linux_20201112_20patch_boundle.tar.gzを展開した)。
 $ cd ~
$ tar zxf Linux_20201112_20patch_boundle.tar.gz
$ tar zxf L2.6.35_MX53_201112_Patches.tar.gz

上の圧縮ファイル(Linux_20201112_20patch_boundle.tar.gz)には以下のファイルが格納されている。

 (C) L2.6.35_MX53_201112_Patches.tar.gz ⇒ パッケージ別のパッチが格納された圧縮ファイル
 (D) MX53_LINUX_BSP_201112_Patch_release.pdf ⇒ 本パッチの説明ドキュメント


(C)のファイルを展開すると、以下の7つのファイルが生成される。

 ./L2.6.35_MX53_201112_Patches/linux-2.6.5.3-imx_11.09.01_201112.tar.gz
 ./L2.6.35_MX53_201112_Patches/u-boot-v2009.08-imx_11.09.01_201112.tar.gz
 ./L2.6.35_MX53_201112_Patches/imx-lib-11.09.01_201112.tar.gz
 ./L2.6.35_MX53_201112_Patches/imx-test-11.09.01_201112.tar.gz
 ./L2.6.35_MX53_201112_Patches/firmware-imx-11.09.01_201112.tar.gz
 ./L2.6.35_MX53_201112_Patches/amd-gpu-bin-mx51-11.09.01_201112.tar.gz
 ./L2.6.35_MX53_201112_Patches/amd-gpu-x11-bin-mx51-11.09.01_201112.tar.gz


ファイル名から判るとおり、パッチはパッケージ別に分かれており、上の各ファイルがそれらに相当する。

以降、下の手順を実行して、上の各パッチをBSPへ適用した。
Kernel

$ cd <LTIB directory>
$ ./ltib -m prep -p kernel
$ cd rpm/BUILD/linux-2.6.35.3
$ tar -xzvf ~/L2.6.35_MX53_201112_Patches/linux-2.6.35.3-imx_11.09.01_201112.tar.gz
$ sh linux-2.6.35.3-imx_11.09.01_201112/patch.sh


U-Boot

$ cd ../../..
$ ./ltib -m prep -p u-boot
$ cd rpm/BUILD/u-boot-2009.08
$ tar -xzvf ~/L2.6.35_MX53_201112_Patches/u-boot-v2009.08-imx_11.09.01_201112.tar.gz
$ sh u-boot-v2009.08-imx_11.09.01_201112/patch.sh

imx-lib

$ cd ../../..
$ ./ltib -m prep -p imx-lib
$ cd rpm/BUILD/imx-lib-11.09.01
$ tar -xzvf ~/L2.6.35_MX53_201112_Patches/imx-lib-11.09.01_201112.tar.gz
$ sh imx-lib-11.09.01_201112/patch.sh

imx-test

$ cd ../../..
$ ./ltib -m prep -p imx-test
$ cd rpm/BUILD/imx-test-11.09.01
$ tar -xzvf ~/L2.6.35_MX53_201112_Patches/imx-test-11.09.01_201112.tar.gz
$ sh imx-test-11.09.01_201112/patch.sh

Firmware

$ cd ../../..
$ ./ltib -m prep -p firmware
$ cd rpm/BUILD/firmware-imx-11.09.01
$ tar -xzvf ~/L2.6.35_MX53_201112_Patches/firmware-imx-11.09.01_201112.tar.gz
$ sh firmware-imx-11.09.01_201112/patch.sh

amd-gpu for FB solution

$ cd ../../..
$ tar -xzvf ~/L2.6.35_MX53_201112_Patches/amd-gpu-bin-mx51-11.09.01_201112.tar.gz
$ ./ltib -m prep -p amd-gpu-bin
$ cd rpm/BUILD/amd-gpu-bin-mx51-11.09.01
$ rm -rf *
$ cp -rf ../../../amd-gpu-bin-mx51-11.09.01_201112/* .

amd-gpu for X-Window

$ cd ../../..
$ tar -xzvf ~/L2.6.35_MX53_201112_Patches/amd-gpu-x11-bin-mx51-11.09.01_201112.tar.gz
$ ./ltib -m prep -p amd-gpu-x11-bin
$ cd rpm/BUILD/amd-gpu-x11-bin-mx51-11.09.01
$ rm -rf *
$ cp -rf ../../../amd-gpu-x11-bin-mx51-11.09.01_201112/* .

上の「./ltib -m prep -p <PACKAGE>」というコマンドは、どうやら「rpmbuild -bp <PACKAGE>」を呼び出しているようだ。

話が少しそれるが、7年位前に私が初めて組込みLinuxの仕事をやったときに、rpmベースのビルドフレームワークツールを使ったことがある。この仕事のときに、ターゲットシステムを構築する全作業のかなりの割合を、rpmパッケージを作成してビルドツールの環境へ追加することに費やしたので、一応rpmパッケージの作成方法については理解している(ずいぶん昔のことなので、記憶を思い起こす必要があるが・・・)。Linuxカーネルの移植が終わったら、それに続いて、IMX53QSBへのQtの移植にも挑戦するつもりだが、Qtが依存するパッケージをLTIBのフレームワーク環境へ追加する必要があるので、多分この仕事のときにやったのと同じような作業をやらざるをえなくなるんじゃないかと予想している。

●システムイメージを生成する

これで、IMX53QSB用BSPはすべての最新のパッチが適用済みの状態になった。以上でシステムイメージをビルド生成する条件は整ったことになるが、ここで改めてBSPのドキュメントに読むと、タッチスクリーンを使用しない場合は、そのドライバをカーネルから削除するように勧めている注意書きの存在に気がついた。IMX53QSB用にタッチパネルLCDを入手する予定は当面ないので、このアドバイスに従って、最初のビルドを行う前に、タッチスクリーン・ドライバの削除もやってしまうことにした。

LTIBにはmenuconfing(Linuxカーネル・ソースに含まれている標準的なコンフィグレーション設定ツール)の機能も含まれており、LTIBからmenuconfingを起動して、カーネルのコンフィグレーション設定を変更できるようになっている。menuconfingを開くには、次のコマンドを実行して、LTIBの画面を開く。
 $ cd <LTIB directory>
$ ./ltib -m config

すると、下のような画面が表示される。
IMX53QSB_LinuxBSP_LTIB_ConfigMenuScreen-Scrnshot32-640x410.png
この画面内の「Configure the kernel」というメニュー項目を有効状態して、一旦LTIBの画面を終了した。そして、以下のコマンドを実行した。
 $ ./ltib

そうすると、下の画面のようなカーネルのコンフィグレーション設定画面が表示されたので、
IMX53QSB_LinuxBSP_LTIB_ConfigMenuScreen-Scrnshot35-640x410.png
IMX53QSB_LinuxBSP_LTIB_ConfigMenuScreen-Scrnshot36-640x410.png
この画面から下のようにメニューを移動して、タッチスクリーン・ドライバを無効状態に変えた。
       Device Driver  --->

Input device support --->

[ ] Touchscreens --->

menuconfigの画面を抜けると、LTIBによるBSPのビルドが開始されてしまった(オプションなしの「./tlib」だと、常にビルドが実行されるみたいだ)。全行程に約11分かかったが(Intel Core i7 1.8GHz HyperThreading 4コア、メモリ2GB、ストレージ SSDという構成のVMware仮想マシンの場合)、特にエラーが起きることもなくビルドは問題なく終了した。ビルドが完了すると、LTIBディレクトリの直下にrootfsというディレクトリが作成され、生成されたシステムイメージ一式はこの中に格納されるようだ。

長くなったので、本記事は一旦ここまでで切ろう。続きは次の記事に書くが、上で作成したシステムイメージを使って実際にIMX53QSBでLinuxを動かすところまでが、その内容になる予定。
タグ:Freescale i.MX
posted by とみやん at 07:40| Comment(0) | TrackBack(0) | Embedded Linux > その他

2012年12月29日

BeagleBoard-xMでAngstrom Linuxを動かす

前記事で紹介したBeagleBoard-xMはQt移植・開発のために買ったボードなので、さっそくこのボードでQtを動作させるまでの手順を記事に書きたいところだが、その前にLinuxカーネルを移植することを先にやならいといけない。QtやwxWidgetsなどのUIフレームワークやGStreamerやFFmpegなどのミドルウェアもすべてLinux上で動作するので、Linuxカーネルの移植はBeagleBoard-xMのようなボードで組込みシステムを構築する際の必須条件だ。さすがにこれについての説明を省略する訳にはいかないので、先にBeagleBoard-xMへLinuxカーネルを移植する方法について記事を書く(Linuxカーネル移植についての説明はスキップしても良いかなぁいう気もしたんだけど、元組込みプログラマのプライドがどうしてもそれを許さなかった)

BeagleBoard-xMの開発元であるBeagleBoard.orgプロジェクト紹介ページに掲載されているとおり、多くの組込みLinuxディストリビューションやモバイルOSがこのボードへ移植されているが、この中でもっとも多く使われているのはやはりUbuntuだと思うが、それと同じかあるいは二番目位に使われているのがÅngström Distributionだ。これはOpenZaurus(Sharp Zaurus向けのオープンソースOSを開発するプロジェクト)から派生したプロジェクトで、PDA、ハンドヘルドデバイスなどの機器に特化した組込みLinuxディストリビューションを開発することを目的としている。日本ではAngstromについて知っている人は少ないかもしれないが、対応デバイスやボードの種類も多く、海外では結構使われているメジャーな組込みLinuxディストリビューションの一つだ。私がAngstromについて知ったのは、Archosというフランスの家電メーカーのAndroidタブレットを入手したのがきっかけで、これはBeagleBoardについて調べ始めるより前にあたる。ArchosのタブレットにAngstromが移植されていることを知って、「へぇー、こういうものがあるのかぁ。ちょっと動かしてみたいなぁ」と思ったことを記憶している(手持ちのAndroidタブレットを処分中だが、Angstrom移植のためにArchos製タブレットだけは残すつもり)。BeagleBoard-xMを入手したことにより最近またAngstromに調べているが、結構面白そうなディストリビューションなので、Qt移植・開発のベースOSとして使うだけじゃなく、いずれは本格的に研究するテーマに加えたいと思っている。

●オンラインビルダーを使ってAngstromのシステムイメージを作成する

Linuxカーネルの移植と言うと、難易度の高い作業のように聞こえかもしれないが(BSPが用意されていない段階から始めると、実際に難易度の高い作業なんだけど)、Angstromの場合、 Linuxカーネルや追加パッケージをオンラインでビルドできるサイトが用意されているので、このサイトを利用すれば目的は簡単に達成できてしまう。

まず最初に、WebブラウザでAngstromのこちらのサイトにアクセスしよう。すると、下のようなページが開く。これがAngstromのオンラインビルダー・ページだ。
Angstrom_Online_Builder_Page-Scrnshot01-1138x1084
このページの使い方は全然難しくない。初めに、画面の最上段にある"Select the machine you want to build your rootfs image for:"というプルダウンメニューから「beagleboard」という項目を選択する。これが、ビルド対象となるターゲットボードの種類に相当する。今回のターゲットボードはBeagleBoard-xMだが、BeagleBoardとBeagleBoard-xMのカーネルやパッケージはほとんど共通化されているので、ターゲットボードの種類は「beagleboard」で問題ない。
Angstrom_Online_Builder_Page-Scrnshot04-1009x1098
二段目の"Choose your image name."というエディットボックスには、ページを開いた時点でランダムに生成された文字列が自動的に入るようになっている。この文字列がビルド後に生成されるファイル名に相当するので、自動生成された名前をそのまま使うか、あるいは任意の名前を入力する。

その下の"Choose the complexity of the options below."というプルダウンメニューはrootfsイメージのバージョンやBase Systemの種類などを変更するために用意されており、このメニューから「advanced」という項目を選択すると、これらの項目を設定することができるようになっている。これらについて特にこだわりを持っていければ、取りあえず、ここは「simple」のままで良いだろう。

さらに、その下の"User environment selection:"というプルダウンメニューは、その名のとおり、UI環境の種類を選択するためのもの。取りあえず、カーネルの動作確認だけが目的なら、このメニューは「Console only」を選択すれば良い。メニューの説明に書かれているとおり、他にX11やOPIE(Open Palmtop Integrated Environment:PDAなどのLCD搭載機器向けのオープンソースのQt EmbeddedベースGUI)も用意されている。

上のスクリーンショットの選択状態だとカーネルとBase Systemだけが含まれた最小限のシンプルなコンソールベース・システムが出来上がるが、最下段の"Additional packages selection:"に存在するカテゴリ内の項目を選択すれば、色々な種類のパッケージをあらかじめシステムに組み込むことが可能だ。Angstromにはopkgというパッケージマネージャが含まれていて、これを使うと、Ubuntuのaptみたいにオンラインでパッケージを追加することもできる。そのため、オンラインビルダーで作成するシステムはできるだけシンプルな構成にしておいて、必要に応じて、後からパッケージを追加していくという方法もある。コンソールだけではあまりにも味気ないと思ったので、今回は、"Platform specific packages:"というカテゴリから「Beagleboard validation GNOME image」という項目を追加してみた。
Angstrom_Online_Builder_Page-Scrnshot06-1009x1998
オンラインビルダーのすべての項目の設定が済んだら、この画面の一番下に存在する「Build me!」というボタンを押す。そうすると、下のような画面にページが切り換わり、システムイメージのビルドが始まる。
Angstrom_Online_Builder_Page-Scrnshot07-1009x969
そして、ビルドのすべての工程が終了すると、下のような画面になる。
Angstrom_Online_Builder_Page-Scrnshot09-1009-1113
カーネルとBase Systemのみのコンソールベース・システムだと5分程度でビルドが終了するが、今回は追加パッケージがあるので20分位かかった。追加パッケージの数が多ければ、当然その分ビルドに時間がかかる。上のビルド終了画面の一番下に表示されている「*.tar.gz」というファイルに、最終的に生成されたシステムのイメージが格納されている。このファイル名のリンクをクリックすれば、当該ファイルをダウンロードすることができる。

●AngstromのブートSDを作成する

ここまででAngstrom Linuxのシステムイメージが作成できたので、続いて、このシステムイメージからBeagleBoard-xM用のブートSDを作成する手順を説明しよう。以降では、Angstromのオンラインビルダー・ページで作成したファイルの名前がangstrom-image-beagleboard.tar.gzであると仮定して説明する。

まずは、容量4GB以上のMicroSDを用意してこれを初期化するが、BeagleBoard-xM用ブートSDのフォーマットには一定のルールがある。最初のパーティションがFAT32で、二番目以降のパッーティションはext3でなければならないというのがそれだ。fdiskコマンドを使って手動でSDカード上にパーティションを作成することも可能だが、ここではスクリプトを使おう。下のサイトからmkcard.txtというファイルを入手する。

 Beagleboard demo files

上の準備が済んだら、SDを挿入したUSBカードリーダーをPCに接続し、Terminalを開いて、以下のコマンドを実行しよう。
 $ sudo umount /dev/sdb1
$ chmod +x mkcard.txt
$ sudo ./mkcard.txt /dev/sdb
$ sync

※最初のumountコマンドは、すでにパーティションが存在するSDカードを挿入した場合に必要となる。バーティションが存在しないSDではこれは不要。
/dev/sdb, /dev/sdb1がUSBカードリーダーとSD上の既存バーティションのデバイスファイルだが、PCのディスク構成によってこれは変わることがある。

初期化が済んだら、一旦SDカードを取り外して再度PCに挿入する。Ubuntuの場合、挿入されたSDのパーティションを認識して自動的にマウントするようになっているので、上記の手順で初期化したSDのパーティションは以下のマウントポイントにマウントされるはずだ。

 FAT32 → /media/boot
 ext3  → /media/Angstrom

SDのパーティションがマウントされているかどうかは、次のコマンドにより確認できる。
 $ df -h

続いて、マウント済みのSDへAngstromのシステムイメージを書き込む訳だが、これは以下のコマンドで行う。
 $ sudo tar -xvz -C /media/Angstrom -f angstrom-image-beagleboard.tar.gz
$ sync
$ cd /media/Angstrom
$ cd boot
$ sudo cp MLO /media/boot
$ sudo cp u-boot.bin /media/boot
$ sudo cp uImage /media/boot
$ sync

※FAT32パーティションへコピーしているMLO, u-boot. uImageの3つがブートに必要なファイルで、これらのファイルのうちMLOは一番最初に書き込まなればならない。

ここまでの手順によって一応ブートSDは出来上がりだが、BeagleBoard(とBeagleBoard-xM)Rev Cに限って追加でやらないといけない作業がある。SD上のFAT32パーティションへuEnv.txtというファイルを追加することがそれ。エディタを使って、以下のような内容を含んだuEnv.txtというファイルを作成して、SDのFAT32パーティションへコピーする。
 $ sudo vi uEnv.txt

dvimode="hd720 omapfb.vram=0:8M,1:4M,2:4M"
vram=16M
optargs="consoleblank=0"
console="tty0 console=ttyO2,115200n8"

$ sudo cp uEnv.txt /media/boot
$ sync

uEnv.txtの書き込みが済んだら、SDのパーティションをすべてアンマウントした上で、PCから取り外す。
 $ cd
$ sudo umount /media/boot
$ sudo umount /media/Angstrom

以上で、BeagleBoard-xM用のブートSDは完成だ。

●Angstromの動作確認と環境設定

Angstrom LinuxのブートSDが作成できたので、さっそくこのSDでBeagleBoard-xMが起動・動作することを確認してみよう。

BeagleBoard-xMのMicroSDスロットにブートSDを挿入し、USBキーボード、USBマウス、LANケーブルを接続する。さらに、HDMIケーブル(または、HDMI−DVI-D変換ケーブル)でモニタを接続した上で、ACアダプターにより電源を投入すると、Angstrom Linuxのブートシーケンスが始まる。

最初の起動時はブートシーケンスが終了するのに20〜30分位かかる。ブート中にカーネルとGnomeモジュールの構成設定処理が自動的に実行されるからだ。すべてのブートシーケンスが終了するまで気長に待つと、いきなり画面が暗転し、この状態が1分位続いた後、Auto Login画面が現れ、最後に下のスクリーンショットのようなGnomeのデスクトップ画面が表示される。
BB_xM-Angstrom_Gnome_Desktop-Scrnshot01-1280x720
めでたくシステムが起動したら、しばらく感慨に浸ろう。移植を試みたOSが初めて起動した瞬間こそ組込み開発の醍醐味なので、この瞬間をじっくりと味わないともったいない(なんてことを言っているようじゃ、組込み分野からの離脱はほど遠い。OSが動き始めた瞬間なんかに大した意味はなく、アプリを含めたシステム全体が仕様どおりかつ高パフォーマンスで動くことの方がずっと重要な課題。組込みプログラマはもっとアプリ側へ関心を向けるべきなんだ)。これでAngstrom Linuxの移植は完了した訳だが、このブートSDのシステム環境を継続して使うつもりなら、起動後にネットワークとタイムゾーンの設定をやっておいた方が良い。

内蔵Ethernetのデバイス名はusb0で認識され、デフォルトのネットワーク構成は、DHCPによりIPアドレスなどの情報を自動的に取得するように設定されている。DHCPからIPアドレスが正常に取得できているかどうかは、「Applications > Accessories > Terminal」メニューでターミナル画面を開いて、次のコマンドを実行すると確認できる。
 # ifconfig

ネットワーク構成をスタティックIPに変更する場合は、/etc/network/interfacesを以下のように編集する。
 #iface usb0 inet dhcp
iface usb0 inet static
address 192.168.1.100
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
gateway 192.168.1.1

さらに、DNSサーバーのIPアドレスを/etc/resolv.confに追加する(ファイルが存在しない場合は、新しく作成すること)。
 nameserver 192.168.1.10

タイムゾーンの設定は、以下のコマンドを実行すれば良い。
 # cd /etc
# mv localtime localtime.orig
# ln -s /usr/share/zoneinfo/Asia/Tokyo localtime

いずれも変更を行ったら、ターミナル画面からrebootコマンドを実行するか、あるいは、「System > Shut Down...」メニューの画面で「Restart」ボタンを押してシステムを再起動する。設定内容は、再起動後にシステムに反映される。

以上で基本的なシステム設定は終わりだが、最後に、インストール済みパッケージの更新をやっておいた方が良いだろう。前述のとおり、Angstrom Linuxにはopkgというパッケージマネージャーが存在し、デフォルトでこれがインストールされている。このopkgはUbuntuのaptと同じような機能を持っており、オンラインでパッケージの追加、削除、検索ができるので非常に便利なものだ。後々必ずopkgコマンドを使うことになるので、一度は以下のコマンドを実行しておくべきだ。
 # opkg update
# opkg upgrade

上の2つのコマンドは、それぞれパッケージ管理情報の更新と既存パッケージのアップデートを行なっている。ただし、これらのコマンドはすでにインターネット回線に接続されていることを前提としているので、先に上記のネットワーク構成の設定を終わらせておく必要がある。

結構長くなってしまったが、この記事は以上で終わりだ。Linuxベースの組込みシステムを構築する場合、カーネルの移植が最初の大きなハードルとなることが多いが、Angstromでは、オンラインビルダーを利用すればこのハードルがかなり低くなる。すでにAngstromが移植済みの対応ボードに限定されるが、Linuxカーネルは手っ取り早くを動かしてしまって、本来の目的であるミドルウェア移植やアプリケーション開発などにすぐに着手できるメリットは大きいじゅないだろうか。プロの組込みLinuxエンジニアから見ると、あまりにも手抜きのカーネル移植方法だと思われるかもしれないが(私自身自分でそう思えてならないが・・・)、Linuxベースの組込みシステムを開発する場合、カーネルの移植自体が最終目的になるケースは少ない。ほとんどの組込みプロジェクトでは、アプリを含めたシステム全体をいかに少ない工数で開発するかということが本当の課題であるはずだ。実際にやってみた感想になるが、Angstromのオンラインビルダーのようなお手軽な手段が用意されているなら、こういうものを利用してカーネルの移植はさっさと終わらせてしまうのも、いまどきのカジュアルなやり方として有りかもしれないと思えた。

別の記事で紹介するつもりだが、この後さらにBeagleBoard-xMへのQtの移植も試みたが、その際にopkgコマンドで簡単にパッケージを追加できることがすごく役に立った。カスタムボードの場合は当然オンラインビルダーを使えないので、AngstromのビルドフレームワークであるOpenEmbeddedのツール群を使ってLinuxカーネルを移植しなければならないが、一旦カーネルの移植が終われば、対応ボードと同じように、opkgコマンドを使ってオンラインでパッケージを追加インストールすることができるんじゃないかと想像している(ただし、CPUコアが既存の対応ボードと同じであることが条件となるはず)。本当にこれが可能なのか、いつか他のボードへAngstrom Linuxを移植することにトライしてみたいと思っている。
タグ:BeagleBoard
posted by とみやん at 12:09| Comment(0) | TrackBack(0) | Embedded Linux > その他

2012年12月22日

BeagleBoard-xMを購入

BeagleBoard-xMというARMコアCPUを搭載した組込み評価ボードを購入した。CPUはTI DM3730というシングルコアCortex-A8を内蔵したSoCで、DSP(TMS320DM64x+ )と3D Graphic Accelarator(PowerVR SGX)も搭載している。最近のAndroidスマホやタブレットに搭載されているCPUと比較すると性能は数段劣るが、組込みCPUとしてはなかなか強力な奴だ。

いつもならこういうボードは海外の通販サイトから個人輸入するんだけど、今回は急いでいたので、TechShare Storeという国内の販売代理店から購入した。このボードが届いたのは11/08なんだが、本業の仕事で忙しい状況が続いていたので、いままで紹介記事を書きそびれていた。

BeagleBoard-xMの製品パッケージを開けてみると、下の写真のとおり、簡易そのものだった。ボードがぴったり収まる紙製の箱に、ボード本体、動作確認用MicroSD、SDアダプタの3点しか入っていない(説明書やCDメディアの類は一切なし)。
IMG_2751_1-BeagleBoard_xM-PackageBox-Photo37-20121215.jpg
IMG_2716_1-BeagleBoard_xM-PackagePrint-Photo02-20121215.jpg
IMG_2745_1-BeagleBoard_xM-PackageItems-Photo31-20121215.jpg
元々はTI在籍エンジニアの小規模チームによって開発された教育用ボードという性質を持つ製品なので、販売対象は趣味レペルの電子工作愛好家や学生とかを想定しているのかもしれない。プロの組込みエンジニアも結構購入していると思うが、大多数は想定どおりの人達がこのボードを購入しているのだろう。

下の写真が、BeagleBoard-xM上に実装されているコネクタ群。
IMG_2729_1-BeagleBoard_xM-BoardSideView1-Photo15-20121215.jpg
IMG_2728_1-BeagleBoard_xM-BoardSideView2-Photo14-20121215.jpg
IMG_2727_1-BeagleBoard_xM-BoardSideView3-Photo13-20121215.jpg
ボードの各サイドには以下のコネクタやプラグが存在する。

 USB 2.0 HS Hosts x 4
 10/100 Ethernet
 RS-232 Serial
 DC 5V Power
 USB 2.0 HS OTG
 MicroSD Slot(ボード裏面に実装)
 Stereo Audio In
 Stereo Audio Out
 S-Video (TV Out)
 DVI-D(HDMIコネクタを使用)

さらに、ボード上に実装されているピンヘッダには以下のインターフェースの入出力もある。

 LCD
 Camara
 I2C, I2S, SPI, MMC/SD
 JTAG

実際にBeagleBoard-xMを使っている様子が、下の写真。
IMG_2762_1-BeagleBoard_xM-Using_with_Cables-Photo02-20121224.jpg
IMG_2763_1-BeagleBoard_xM-Using_with_KMM-Photo03-20121224.jpg
ボード本体以外に、以下のような機材を用意する必要がある。

 ACアダプタ(定格電圧 DC 5V、最大電流 2A程度)
 HDMI−DVI-D、またはHDMIケーブル
 LANケーブル
 RS-232 シリアルケーブル(メス−オス ストレート)
 MicroSDカード(容量4GB以上)
 MicroSDアダプタ
 モニタ(DVI-D、またはHDMI入力端子付き)
 USB キーボード
 USB マウス

また、当然ながらPCも必要になる。Linuxカーネルイメージを書き込んだブート用MicroSDを作成するので、Ubuntuなどをインストール済みのLinuxマシンがベストだ。

下の写真が、ボードに同梱されていた動作確認用MicroSDから起動した際のブート画面。
IMG_2758_1-BB_xM-AngstromLinux_Booting-Photo02-20121223.jpg
IMG_2760_1-BB_xM-AngstromLinux_Booting-Photo04-20121223.jpg
カーネルのブートシーケンス終了後に「Angstrom」というロゴが表示されていることから、このカーネルはÅngströmというLinuxディストリビューションからビルドしたもののようだ。

さらに、ブートシーケンス完了後に起動されるGUI環境の画面が、下のスクリーンショット。
BeagleBoard_xM-Gnome_Desktop-Scrnshot02-1280x720
BeagleBoard_xM-Gnome_Desktop-Scrnshot05-1280x720
このデスクトップ画面はGnomeみたいだ。MidoriというWebブラウザまで搭載されていて、PC用Linuxディストリビューションと遜色ない環境が提供されている。

組込み分野から離脱することを目指して新事業開拓をやっているのに、なぜいま頃こんなボードを買ったのかというと、Qt移植・開発用の手頃なボードが欲しくなったからだ。本業の仕事で使っているターゲットボードの詳細情報をブログ記事に書くわけにはいかないので、このボードをターゲットとして、これからQtの記事を書いていこうと思っている。

ちなみに、TI OMAP3530を搭載したBeagleBoardというボードも存在していて、今回購入したBeagleBoard-xMはこのボードの後継機種にあたる。OMAP3530とDM3730の違いは動作クロックくらいで、この2つのCPUの差はほとんどないみたいだ。搭載RAMの容量は差があるが(BeagleBoardが256MBなのに対して、BeagleBoard-xMは512MB)、この2つのボードの性能差はそれ程大きいものではない。

発売開始はBeagleBoardが2008年7月で、BeagleBoard-xMは2010年9月だが、これらは丁度Android 1.0〜1.6の登場時期と重なっている。そのため、この2つのボードはAndroidの評価用ターゲットとして盛んに使われたという歴史的な経緯がある。「BeagleBoard Android」というキーワードでググると、たくさんのページがヒットすることからもそれが分かる。この経緯により、Android用BSPも存在するが(CPUベンダーであるTIから配布されている)、私はこのBeagleBoard-xMでAndroidを動かすつもりはまったくない。シングルコアCortex-A8のCPUでAndroidを動かしても、実用にはほど遠い性能しか出ないことが分かりきっているからだ。Androidを動かすことを試みたとしても、結局「ふーん、動いているなぁ」という程度の小さな感動で終ってしまい、それ以上の発展も面白さも感じないだろう。時間の無駄とまでは言わないが、このボードでAndroidを動かした情報はすでにたくさん存在するので、いまさら私が同じような記事を書く必要性は低いような気がする。ドキュメント付きでBSPが配布されているなら、そのドキュメントに記載されている説明のとおりにやっていけば良いわけで、BSPが用意されているケースでのAndroidの移植はそれほど難易度の高い作業ではない。多少のTipsはあると思うが、このボードが販売されてから2年以上の月日が経っているので、そういうTips情報はすでに出尽くしているはずだ。

元々Qtの移植・開発用として買ったものなので、それ以外の用途にBeagleBoard-xMを使うつもりはあまりない。このボードは当面Qtに特化して使っていくが、ググってみると、MaemoやMeeGoのビルドや動作情報も存在するようだ。この2つのモバイルOSのUIはQtベースで、Androidなんかとは比べものにならないくらいサクサクと動くらしいので、これらの移植にはいずれトライして、その顛末を記事に書こうと目論んでいる。

タグ:BeagleBoard
posted by とみやん at 18:30| Comment(0) | TrackBack(0) | Embedded Linux > その他