どうやって私はRC-S620/Sを壊したか

RC-S620/Sが動かなくなったので、スイッチサイエンス社に注文していた。
その品が、今日届いた。

もしかすると、RC-S620/SからPCにつなぐまでの経路が壊れたのかも、と期待したのだが、だめだった。
差し替えると動く。
あちゃー。
やってしまった。。。。

---

さて、私は何をして壊してしまったのだろうか？

原因は、逆接続だと思う。
付属のコネクタがピン折れしてしまったので、変換基板を購入していたのだ。
あまり考えずに接続していたのだが、落とし穴があった。

それは、変換基板に書いてある１～６ピンと、RC-S620/Sの１～６ピンが逆になっていることだ。
それに気付かず、動かんなー、動かんなーとしばらくやっていたのだよ。
ちょっとだけだったらよかったかもしれないけど、逆と思っていなかったので長いことやってたんだよなぁ。

なんかもう、甘く見ていた、ということに尽きる。
RC-S620/Sが温かいなとは思ったのだが、チンチンになってなかったので安心していたのだ。

配線を確認してから通電しなさい、という基本を怠ったことに対する手痛い教訓だ。

libstagefrighthwは誰がビルドさせようとしているのか？

libstagefrighthw.soがビルドされてしまうのを止めたい。
solaさんのところからgit cloneしたものでは、ビルドされなかった。
なにかが、何かが違うようだ。

build/ 以下をgrepすると、build/core/user_tags.mkのGRANDFATHERED_USER_MODULESに含まれていた。
でも他のもたくさんあるので、libstagefrighthwだけ除外することはできない。
なにか抑制する手段があるということか。

GRANDFATHERED_USER_MODULESは、base_rules.mkで使われている。
長いけど引用。

ifneq ($(filter $(LOCAL_MODULE_TAGS),user),)
  ifeq ($(filter $(GRANDFATHERED_USER_MODULES),$(LOCAL_MODULE)),)
    $(warning *** Module name: $(LOCAL_MODULE))
    $(warning *** Makefile location: $(LOCAL_PATH))
    $(warning * )
    $(warning * Each module must use a LOCAL_MODULE_TAGS in its)
    $(warning * Android.mk. Possible tags declared by a module:)
    $(warning * )
    $(warning *     optional, debug, eng, tests, samples)
    $(warning * )
    $(warning * If the module is expected to be in all builds)
    $(warning * of a product, then it should use the)
    $(warning * "optional" tag: )
    $(warning * )
    $(warning *    Add "LOCAL_MODULE_TAGS := optional" in the)
    $(warning *    Android.mk for the affected module, and add)
    $(warning *    the LOCAL_MODULE value for that component)
    $(warning *    into the PRODUCT_PACKAGES section of product)
    $(warning *    makefile(s) where it's necessary, if)
    $(warning *    appropriate.)
    $(warning * )
    $(warning * If the component should be in EVERY build of ALL)
    $(warning * products, then add its LOCAL_MODULE value to the)
    $(warning * PRODUCT_PACKAGES section of)
    $(warning * build/target/product/core.mk)
    $(warning * )
    $(error user tag detected on new module - user tags are only supported on legacy modules)
  endif
endif

これは、Android.mkにLOCAL_MODULE_TAGSを指定してないときに出てくるメッセージだ。
ここにあったんだ。

LOCAL_MODULE_TAGSが"user"以外で、GRANDFATHERED_USER_MODULESの中にビルドしたいモジュール名があると出てくるようだ。

---

(2011/09/17)
最後のコンマを見逃していた。

 ifneq ($(filter $(LOCAL_MODULE_TAGS),user),)

なので、 「LOCAL_MODULE_TAGS」から「user」と一致する文字列を抜き出し、それが空文字列ではなかったらtrue、ということになる。
つまり、LOCAL_MODULE_TAGSにuserが含まれていた場合はtrue、か。

  ifeq ($(filter $(GRANDFATHERED_USER_MODULES),$(LOCAL_MODULE)),)

これも同じだ。
GRANDFATHERED_USER_MODULESの中からLOCAL_MODULEと一致する文字列を抜き出し、それが空文字だったらtrue、ということになる。
つまり、GRANDFATHERED_USER_MODULESにLOCAL_MODULEが含まれていなかった場合はtrue、か。

全然違ったわ・・・すまん。

試していないが、デフォルトではLOCAL_MODULE_TAGSはuserで、システムとしてビルドさせようと思っているモジュール名はGRANDFATHERED_USER_MODULESにあらかじめ書いてあるってことではないだろうかね。

---

けど、user以外で指定していれば出てこないメッセージなので、これより前にフィルタリングするしくみがあるのだろう。
ってことは、GRANDFATHERED_USER_MODULESは単なるリストで、あまり意味がないということか。

device/以下も見てみたが、crespoにしかない。
うーん、ということは、やはり自動的にビルドしているのか。。。
しかし、solaさん環境でlibstagefrighthwのAndroid.mkでエラーを出すようにしても、ビルドがうまくいく。
つまり、ビルドしようとすらしてないのだ。
ということは、その上に答えがあるはず。

１つ上のhardware/ti/omap3にもAndroid.mkがある。

ifeq ($(TARGET_BOARD_PLATFORM),omap3)
  include $(all-subdir-makefiles)
endif

ほほう。
私は自分のところで、指定している。

　　TARGET_BOARD_PLATFORM := omap3

solaさんのところには、ない。
これか～。

FeliCa Plug来る

FeliCa PlugのRC-S802が来た。

小さい！！
小指の第1関節くらいまでぐらいだ。

まだ何に使うかは決めてないけど、あせらずにやろう。

OMXMaster::addPlugin()は通らないはずだ

エラーが出る箇所は分かったので、ログを追加してみた。
プラグインのコンポーネント名がわかれば、そこから追えると考えたのだ。
しかし、いきなりエラーのようで、名前すら得ることができない。

そこでちょっと考え直した。
そもそも、

F/OMXMaster(  744): frameworks/base/media/libstagefright/omx/OMXMaster.cpp:90 err != OMX_ErrorNoMore

このログが出ることがおかしいのではないか。
だって、プラグインなんてわざわざ追加した覚えはない。
それなのにこのルートを通るという事自体がおかしいのだ。

呼び出しているのは、OMXMaster::addVendorPlugin()。
もう見るからに、ベンダーのHW向けプラグインを追加してやるぜ、という意志が伝わってくる。
ここで、dlopen()して、あれば呼ばれるようだ。
対象となるファイル名は、libstagefrighthw.so。

/system/libを見ると、確かにある。
あるんだけど、どこのファイルなんだ？
そう思って、out/..../obj/SHARED_LIBRARIESから探しだし、中にあったPファイルを開く。
Pファイルを見ると、依存関係がわかる。

そして出てきたのが、hardware/ti/omap3/libstagefrighthw/だった。
はあ、そんなのがあるんですな・・・。
しかし、これらはBeagleBoardで動くのか？
よくわからん・・・。

わからんなりに、system/lib/libstagefrighthw.soを削除すると、mediaserverは落ちなくなった。
これでよしとするかどうかは、もう少し調査が必要だ。

logcatに出てくるSIGSEGVからソースファイルを割り出す

KMC Staff Blog:Androidのデバッグダンプからソース上の問題発生箇所を調べる方法

実践してみよう。

まず、スタックトレースから。

I/DEBUG   (  741):          #00  pc 00015ca4  /system/lib/libc.so
I/DEBUG   (  741):          #01  pc 0000143a  /system/lib/liblog.so
I/DEBUG   (  741):          #02  pc 0000bb7e  /system/lib/libstagefright_omx.so
I/DEBUG   (  741):          #03  pc 0000bbe2  /system/lib/libstagefright_omx.so
I/DEBUG   (  741):          #04  pc 0000be5c  /system/lib/libstagefright_omx.so
I/DEBUG   (  741):          #05  pc 0000a446  /system/lib/libstagefright_omx.so
I/DEBUG   (  741):          #06  pc 000167b8  /system/lib/libmediaplayerservice.so
I/DEBUG   (  741):          #07  pc 00059aba  /system/lib/libstagefright.so
I/DEBUG   (  741):          #08  pc 0004a3ee  /system/lib/libstagefright.so
I/DEBUG   (  741):          #09  pc 00018cfc  /system/lib/libmediaplayerservice.so
I/DEBUG   (  741):          #10  pc 00014be4  /system/lib/libmediaplayerservice.so
I/DEBUG   (  741):          #11  pc 00015570  /system/lib/libmediaplayerservice.so


libcとかliblogとか見ても仕方ないので、その次のlibstagefright_omx.soに着目。
アドレスは0x0000bb7e。

シンボルつきのオブジェクトは、out/target/product/xxxx/symbols以下にあるとのこと。
この情報が重要だ。
リンク先ではobjdumpを使用しているけど、私はソースファイルの場所が知りたいのでaddr2lineを使う。

$ addr2line -e symbols/system/lib/libstagefright_omx.so 0x0000bb7e
/home/...../frameworks/base/media/libstagefright/omx/OMXMaster.cpp:90

のように、ソースファイルの行数が出てくる。
そこを見ると、こんなのがあった。

    CHECK_EQ(err, OMX_ErrorNoMore);

なんかそれっぽいログがその直前に出ていたな。。。

F/OMXMaster(  744): frameworks/base/media/libstagefright/omx/OMXMaster.cpp:90 err != OMX_ErrorNoMore

ああ、これこれ。
CHECK_EQをたどっていくと、__builtin_trapで途切れてしまった。
たぶん、linuxかgccのトラップ処理かなにかで、assert()ぽい動きをするのだろう。

そんなわけで、addr2lineを使わなくてもログでわかったんだけど、このログがSEGVに直結していることが確認できてよかった。
logcatの「F/」で始まるログはFATALのFで、そのままSIGSEGVで落ちてしまうと考えて良さそうだ。

straceはinit.rcでは動かせない

mediaserverにまつわるプロセスで落ちているのはわかっている。
ならば、straceで見てみるといいんじゃないの？と思った。

init.rcに記述して実行すると・・・

I/DEBUG   (  726): ptrace attach failed: Operation not permitted

だめなんだ。。。
straceコマンドは、ptraceシステムコールで実現されているので、こういうログになるようだ。
違うかもしれんが、こういうことなのだろうか。

ということを調べていると、いい情報が！

Androidのデバッグダンプからソース上の問題発生箇所を調べる方法

おお、やりたいのはこういうことかも。
というわけで、次で実践してみます。

NFC ForumのWhite Paperが日本語だけ違う内容

何となく、NFC ForumのWhite Paper欄を見ていた。
正確に言えば、NFC Forumのメンバーになった企業が提供しているWhite Paperだ。
お、日本語のがある、と思って読んでみたけど、なんか変。


パート１

Turning the NFC promise into profitable, everyday applications

将NFC的承诺转变成盈利的日常应用

システムオンチップ(SoC)統合への移行

中国語は読めないけど、日常って書いてあるから英語のと同じだと思う。
日本語のは・・・これはパート３の内容だ。
リンク先が違うぞ～


パート２

Using the right NFC tag type for the right NFC application

选择适当的NFC标签类型

NFCにおける将来的な展望を有効な日常アプリケーションへ


あー、これは日本語のがパート１の内容なのだな。
しかし中国語版って、表が表になってないぞ。いいのか？

パート３

Moving to System on Chip (SoC) integration

片上系统（SoC）集成

正しいNFCアプリケーションへの正しいNFCタグタイプの使用

まあ、もういわなくてもいいな。



それよりなにより、Type 3 Tagの内容が正しいのかどうか疑わしい。
「正しいNFCアプリ・・・」のPDFだ。
表しか見比べてないけど、UIDとRead speedが空欄なのだ。
Securityの16bit or 32bitデジタル電子署名ってのも、何を指しているのかわからん。
Type3のメモリは1MBもある、といっておきながら、表では1KBだし。

そもそも、Type 3 TagってFeliCaカードとかFeliCa Liteカードのように複数あるだろう。
Type4だって、Ultralightみたいな小さいのから大きいものまで複数ある。
表を見ると、Type1ってのを絶賛しているけど、なんか変だよな・・・。

というところで、ようやく気づいた。
Type1は、この資料を作ったInnovation社のTopazというカードなのだ。
なーんだ、宣伝かよ。
NFC Forumにそういうタイプの資料が載ると思ってなかったので、てっきり技術資料と思い込んでしまった。

skiaってなんだろう？

フォントのことを調べていた。
昨日、BeagleBoardで日本語を表示させたときに、なんかいつものじゃなかったからだ。
まあ、たぶんフォントのコピー忘れだろう。
そういえばDroidSansJapaneseって、まだあるんだよな？

いつの間にやら、時代はMTLc3m.ttfとかMTLmr3m.ttfになっていた。。。
さらに調べてみると、DroidSansJapaneseよりも優先度が高い、とか。
なんだ、優先度って？

ソースを検索してみると、こういうのがあった。
順番は、確かに上になってる。
これはskiaというexternalにあるライブラリのようだ。
そもそも、skiaってなんだ？

skiaはテキスト描画のような2Dグラフィックライブラリらしい。
名前が牛丼やさんっぽいが、だまされてはいけない。
Wikipediaによると、もとはSkia Inc.が開発していたもののようだ。
ここによると、2005年にGoogleが買収したか吸収したかってことらしい。
openskiaってのも別にあるようだが、アップデート履歴を見るとこちらは終わっているようだ。
Chromeなんかでも使われていて、skiaいいぜ、といっている(意訳)。

そんなわけで、残念ながらskiaの語源はわからなかった。

[bb]まだMedia Serverが落ちるし、わからない

めでたくALSAモジュールを読み込んでくれるようになったが、次はこうなった。


I/DEBUG   (  749): pid: 752, tid: 811  >>> /system/bin/mediaserver <<<
I/DEBUG   (  749): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr deadbaad


デッド・バアアッド、だ。
悪くて死んだ？でいいのかな。
いわゆる Segmentation FaultとかBus Errorとかだろう。

SIGV_MAPPERと合わせて、「malloc中にSegmentation Fault」ということらしい。
たぶんdanglingポインタじゃないの？というところまで言ってくれるところがありがたい。
残念なのは、スタックトレースを見てもさっぱりわからないことだ。

mediaserverは、init.rcで実行させている。

service media /system/bin/mediaserver
    user media
    group system audio camera graphics inet net_bt net_bt_admin net_raw
    ioprio rt 4
ソースはframeworks/base/media/mediaserverにある。。。のだが、中身は少ない。
各行にログを埋め込んでみたが、最後の「IPCThreadState::self()->joinThreadPool()」まで実行している。
ここから先はメッセージループになっていて、抜けないんじゃないかな？

というわけで、ちょろっと見れば済むものでもなさそうだ。
腰を少し据えてかかりますかね。

[bb]ALSAモジュールがない

カメラを動かそうとしたが、動かない。
たぶん、media serverが動いていないからだろう。
その原因は、たぶんこれじゃなかろうか。

E/ALSALib (  729): external/alsa-lib/src/control/control.c:902:(snd_ctl_open_noupdate) Invalid CTL AndroidOut
W/AudioHardwareALSA(  729): Unable to attach mixer to device AndroidOut: No such file or directory
E/ALSALib (  729): external/alsa-lib/src/control/control.c:902:(snd_ctl_open_noupdate) Invalid CTL AndroidIn
W/AudioHardwareALSA(  729): Unable to attach mixer to device AndroidIn: No such file or directory
E/AudioHardwareALSA(  729): ALSA Module not found!!!
AndroidOutがないとか、AndroidInがないとか。
カメラと関係ないかもしれないが、気になっていたのでやっつけてしまおう。
なんで関係あると思ったかというと、以前、カメラのシャッター音ファイルがないだけでアプリが落ちていたからだ。
あれ、ということは以前まで動いていたってことか。
それなら関係ないかも。。。まあいいや。


AndroidOutとAndroidInが何かというと、hardware/alsa_sound/ALSAMixer.cppに出てくる。

    initMixer (&mMixer[SND_PCM_STREAM_PLAYBACK], "AndroidOut");
    initMixer (&mMixer[SND_PCM_STREAM_CAPTURE], "AndroidIn");

コンストラクタでの初期値だ。
PLAYBACKが再生で、CAPTUREが録音になるのかな。

たぶん、だが、これはこういうデバイス名になるんじゃなかろうか。

# ls -l /dev/snd/pcm*
crwxrwxrwx root     audio    116,  24 2000-01-01 00:00 pcmC0D0c
crwxrwxrwx root     audio    116,  16 2000-01-01 00:00 pcmC0D0p
cがcaptureで、pがplayback。

しかしエラーと先に判断したのは、hardwareではなくALSALibの方だ。
snd_config_search_definition()の結果がエラーだと、出るログ。
関数名からすると、asound.confファイルから項目を探し出しそうな気がする。
でも、探すのに成功した時はログを出さないよな。
そう考えると、ここはひとまず置いておいてもいいんじゃなかろうか。
先にたどるべきは、ALSAモジュールがない、というエラーのほうか。
原因がやはりAndroidOut/Inなら、そのとき調べ直そう。

これは、hardware/alsa_sound/AudioHardwareALSA.cppのコンストラクタで出している。
hw_get_module()の失敗、つまり、ファイルがないってことだ。

hw_get_module()は全体でよく使われている。
/system/lib/hw/alsa.XXXX.so、というファイルを探しにいく、と過去の自分は調べている。
XXXXに当てはまるのは、
・ro.hardware
・ro.product.board
・ro.board.platform
・ro.arch
らしいが、これは調査が古いので、今は分からん。
でもまあ、そんなに違いはなかろう。
では、/system/lib/hwを見ると・・・おや、gralloc.default.soくらいしかありませんな・・・・。
hardware/alsa_soundがあれば勝手にビルドされていると思い込んでいたのがよくなかったな・・・。
LOCAL_MODULE_TAGSがoptionalなので、自動的にはやってくれないのだろう。

PRODUCT_PACKAGES += \
    acoustics.default    \
    alsa.default

よしよし、できたライブラリをSDカードにコピーすると、エラーが出なくなった。
AndroidOut/Inは出るけど、まあいいんじゃないか？

しかし・・・まだmedia serverが立ち上がらない件は続く。