2013年4月18日木曜日

Firefox OS on PandaBoard ES (3)

前回、USB miniコネクタのケーブルがないため先に進まなかったが、買ってきたので再トライ。

PandaBoardのOTG USBのコネクタにケーブルを接続して、PCに接続。するとホストOSであるWindows8でPandaBoardが認識されることが確認できた。確認はデバイスマネージャにデバイスが追加されることで確認したが、デバイス名にはGoogleという文字が。。。まあ、Android端末として起動しているからということか。。

VMware上のUbuntuからもlsusbを実行すると。。。

Bus 001 Device 012: ID 18d1:d002 Google Inc.

と出てくるのが確認できる。

次はこのページのREADMEのステップ2と3を実行する。ステップ1はビルドのシェルを実行した時点で完了しているのでスキップしていいとのこと。

USBを挿入せずに、PandaBoardをUSB OTG経由でPCに接続、そして電源投入。するとLEDが一つだけ点灯する。その後Ubuntuからlsusbを実行すると。。。

Bus 001 Device 031: ID 0451:d010 Texas Instruments, Inc.

と出てくるので、やはりGoogleとでるのはAndroidが起動していたからという事で落ち着いた。

早速、ステップ2のコマンド

> device/ti/panda/usbboot device/ti/panda/bootloader.bin

を実行すると。。。


using built-in 2ndstage.bin
reading ASIC ID
CHIP: 4440
IDEN: 0000000000000000000000000000000000000000
MPKH: 0000000000000000000000000000000000000000000000000000000000000000
CRC0: 229e85ba
CRC1: 00000000
sending 2ndstage to target... f0030002
waiting for 2ndstage response...

と出力されたまま、停止。。。。PandaBoardもさっきまで光っていたLEDも消えており、どうも失敗しているようにみえる。。。

再度、このページを確認すると以下の既知の問題についての説明があった。
USB ブートを使用した際の "waiting for OMAP4XXX..."
もし、このメッセージが表示されたら、全てのケーブルを PandaBoard から外してください。PandaBoard に接続するのは USB のみです。電源は接続しません。この状態で、sudo で usbboot を実行してください。
という訳で、PandaBoardにはUSBのみ接続して、今回はsudoを付加して


> sudo device/ti/panda/usbboot device/ti/panda/bootloader.bin



実行すると。。。。何も変わらない。。。時間がかかるだけなのか?時間がないので今日はこれでおしまい。


2013年4月17日水曜日

Firefox OS on PandaBoard ES (2)

前回、PandaBoard用のAndroidをLinaroのイメージを利用して作ったが、ハングするという問題があるが、USB通信させるために必要な設定が可能であるかを確認してみた。
その結果、必要な設定はAndroid側に必要なのではなく、開発PC側に必要だという事に気が付いた。。。^^;

そもそもこのページには
Under GNU/linux systems (and specifically under Ubuntu systems), regular users can't directly access USB devices by default. The system needs to be configured to allow such access.
と書いてあるわけで、そのシステム(=GNU/linux)は設定される必要がある、ときちんと書いてあるのだが、読み飛ばしていたため、勝手な解釈をしてしまっていた訳だ。真夜中のクラブ活動的なところがあるとはいえ、もう少し落ち着てやらねば。。。

気を取り直して、Ubuntu側で以下のコマンドを実行し、指定通りの内容のファイルを作成する。

> /etc/udev/rules.d
> gedit 51-android.rules

ただし、Mozillaの説明では
B2G に対しては、安全に使用するために、ファイルモードを "0666" に設定します。
と書いてあるので、ファイルを作成後、以下のコマンドを実行する。

> sudo chmod 0666 51-android.rules

さて、これで接続できるだろうとリトライするも何も変化なし。lsusbでもTI関係の出力は出ないし、そもそもホストOSであるWindowsでも認識されていない。。。配線が間違っているのかと確認してみると、あれ?PandaBoardの基板にもう一つUSBと書かれたコネクタがあるぞ。。。嫌な予感がして、PandaBoard本家のサイトで確認すると、やはり新たに見つけたUSBコネクタがUSB OTG対応のコネクタということが判明。しかし、このコネクタはmini USBなので、手元に使えるケーブルがないので、今日はどうすることもできない。

という訳で、次はmini USBコネクタのケーブルを買ってからトライだ。

※ ハングの問題はまだ原因究明出来ていないが、PandaBoardに接続したマウスを頻繁に操作しているとハングしないので、もしかするとスクリーンセーバー起動後に復旧出来なくなっているのか?

2013年4月15日月曜日

Firefox OS on PandaBoard ES (1)

昨年度はPandaBoard ESを別の目的で使用していたが、ここでは報告することができない内容だったのだが、今回は公開しても問題ない内容なので、手順を記録する意味で記す。

PandaBoard ESで動作させるのは、FirefoxOS。

◆開発環境
 Ubuntu 12.04 on VMware Player on Windows8 Professional
 Linuxの必要条件はここに書かれているので、それらを満たすようにする。

◆SDカードの初期化

とりあえずここの情報をもとにSDカードを初期化。

> sudo ./omap3-mkcard.sh /dev/sdb

./omap3-mkcard.sh: 37: ./omap3-mkcard.sh: kpartx: not found
というエラーが出るので、apt-getでインストール。


> sudo apt-get install kpartx
これで再度シェルを実行するとSDカードのパーティションが正常に分割された。
パーティションは次の二つに分割されればOK。
  1. W95FAT32(LBA)タイプでBootable74MB
  2. Linuxタイプの8.0GB
◆AndroidのSDカード作成

Firefox OSの動作環境を作るためには一度AndroidのIceCream Sandwichを起動できるSDカードを準備しないといけないらしい。
ICSをビルドするのはしんどいので、ここの情報をもとにイメージをダウンロードして、SDカードの構築を行う。
まずここのページから 、boot.tar.bz2、system.tar.bz2、userdata.tar.bz2の3ファイルをダウンロードする。
次のコマンドでLinaroイメージツールをインストールする。
> sudo add-apt-repository ppa:linaro-maintainers/tools
> sudo apt-get update
> sudo apt-get install linaro-image-tools
> sudo apt-get install bzr
> bzr branch lp:linaro-image-tools

次のコマンドを実行した結果がtrueならば、

> gsettings get org.gnome.desktop.media-handling automount
以下のコマンドを実行する(自動マウントの無効化)。
> gsettings set org.gnome.desktop.media-handling automount false

次のコマンドを実行した結果がtrueならば、

> gsettings get org.gnome.desktop.media-handling automount-open
以下のコマンドを実行する(自動オープンの無効化)。
> gsettings set org.gnome.desktop.media-handling automount-open false

※Linaroのページでは自動マウント、自動オープンの無効化はdconfを使っていたのだが、エラーが出て正しく動作しないので、上記コマンドを代用した。

次にダウンロードしたファイルがあるフォルダに移動し、以下のコマンドを実行(赤字のドライブ名は環境によって違うので、各自の環境に合わせて変更すること)。
> sudo linaro-android-media-create --mmc /dev/sdb --dev panda --boot boot.tar.bz2 --system system.tar.bz2 --userdata userdata.tar.bz2

※ここで、なぜか/dev/sdb1がresource busyと怒られてエラーだらけとなっていたが、VMware PlayerからSDカードリーダーを切断し、再接続したらエラーは回避された。

この手順の後で確かにSDカードに色々書き込まれていることが確認できる。

次に以下のコマンドでグラフィックスライブラリをインストールするらしい。

> wget http://people.linaro.org/~vishalbhoj/install-binaries-4.0.4.sh
> chmod a+x install-binaries-4.0.4.sh
> ./install-binaries-4.0.4.sh

なお3番目のコマンドはライセンス規約を読まされて最後にI ACCEPTと入力しないと失敗するので注意。

最後に自動マウント、自動オープンを有効にする。

> gsettings set org.gnome.desktop.media-handling automount true
> gsettings set org.gnome.desktop.media-handling automount-open true

以上の手順で作成されたSDカードをPandaBoard ESに挿入して起動すると、Androidが起動して、マウスで操作できることは確認できた。PCとserial接続してminicomでアクセスすることもできた。
しかし、なぜか時間が経つと、Androidが固まり、マウスもminicomも反応しなくなる問題が発生。。。


◆Firefox OSのダウンロード&ビルド

並行して、ここの情報をもとにFirefox OSのプロジェクトのダウンロードとビルドを行う。ちなみに、ダウンロードは6時間くらいかかったような気がする。
また、ビルドも途中で以下のエラー出力を筆頭にして大量のエラーが発生するが、ここの情報を見る限りはNSPRのインストールができていないことが原因の様子。

external/negatus/src/Buffer.h:8:21: error: prtypes.h: No such file or directory

NSPRはここのページに書いてある通りNetspace Portable Runtimeだそうです。以下のコマンドでインストールできることも書いてある。

> sudo apt-get install libnspr4-dev

再度ビルドすると、一時間はかからずに完了する。
この後の手順はPandaBoard ESとPCがUSB接続できてからとなるはずなので、反応しなくなる問題を解決しないといけない。。。

※2013/04/17 ラベルをつけ忘れていたので、追加。

2013年4月14日日曜日

Windows8

やはりMacBookAirでは色々とリソース不足なので、Windows8 PCを購入。ノートパソコンではなく、デスクトップ。

今後は、Windows+Ubuntu on VMwareで色々試したりしようかと思っている。
MacBookAirは今でリモートデスクトップでWindowsマシンを制御するのに利用する予定。

2013年1月17日木曜日

what's transferable objects?

元ネタはこちら
workers with transferable objectとは何か?を調べて見つけたページ。
2011年の投稿なので結構前からある技術の様だ。

transferable object以前


chrome 13でweb workerとmain process間でデータのやり取りを行うのにstructured cloningと呼ばれる(HTML5の仕様に記載されているらしい)方法が使われていた。これはJavaScriptの複雑なオブジェクトをシリアライズする方法でJSONよりも使える範囲は広くImageObjectやRegExpとかでもOK。だが、オブジェクトは新規にクローンを作って伝達する仕組みになっているので、メモリコピーが発生している分遅く、H/Wスペックは不明だが、32MBのArrayBufferをweb workerに転送するのに数百ミリ秒かかるらしい。

でtransferable objectとは?

そんなstructured cloningの課題を解決する方法として開発されchromeに採用されたのがtransferable object。メモリコピーがボトルネックだった訳なので、当然の様にzero-copyであり、C/C++の世界の参照渡しを想像してもらえばよい。しかし、完全に同じと言う訳ではなく、オブジェクトを送信してしまうと、そのオブジェクトは送信元のコンテキストから送信先のコンテキストに移動してしまい、送信元のコンテキストからクリアされ、利用する事が出来なくなる。うーん、使い方を気をつけないと行けない制約だ。

で、transferable objectを使う為のAPIは専用になっており、以下のAPIがchrome/v8には用意されている。

worker.webkitPostMessage(arrayBuffer, [arrayBuffer]);
window.webkitPostMessage(arrayBuffer, targetOrigin, [arrayBuffer]);

どの程度早くなるのか?

で最終的にどの程度早くなったのかを計測した結果が書かれている。それによると、32MBのArrayBufferを転送するのが302msecから6.6msecまで短縮されており、効果としては絶大なものがある。しかし、32MBものデータを転送するのか?とか考える人もいるだろうと思うのだが、WebGLのテクスチャー転送などで使えると書いてある(ちょっとした自動車のモデルを高精度に描画しようとすると、数MBは楽勝なので、確かに考えられるレベルではあると思う)。