2011/06/26

[q5]SmartQ5へAndroid2.3.4を載せようとしているが、うまくいかん。

はい、うまくいかんシリーズです。
SmartQ5にAndroid2.3.4を載せようとしているところ。
ビルドなんかは通るのだが、動かん。

どこかというと、init中。
kernelも起動し、initも動いてinit.rcを読んで動こうとしているのだが、ファイルがいろいろと見つからない。
いろいろとというよりも、/以外見えてないんじゃなかろうか?というところ。
SDブート式にすれば今までの要領でやれそうなんだけど、ここはせっかくなのでiNANDに書き込みたい。

そもそも、iNANDってどういう風に見えてるんだろう?
SDインターフェースでアクセスするようなので、

mmc0: host does not support reading read-only switch. assuming write-enable.
mmc0: new high speed SD card at address d555
mmcblk0: mmc0:d555 ST01G 1003264KiB
 mmcblk0: p1 p2 p3

これかな。

まあ、今週も忙しくて見る暇はないだろうから、来週だな。
あーー、今も雨が降っているので、今週は憂鬱な週になりそうだ。。。

[q5]SmartQ5を復旧させる

SmartQ5のソースが入手できることがわかったので、repoで取ってきた。
ビルドできるのはだいたい確認できたので、そのままAndroid2.3.4を突っ込んでみようと考えた。

そこまではよかったのだが、ビルドの確認が「だいたい」すぎた。。
最後に「OK」みたいなのが出たから安心していたが、kernelのビルドができていなかった。
しかし私は安心しきっていたので、そのままSmartQ5にインストールさせてしまった。

そして・・・起動しなくなった・・・。

さて、復旧させますか。



SmartQ5 debug serial port

まずはこちらを見て、デバッグ用のシリアルポートを確保。
別件で購入していたレベルコンバータ兼USBシリアルを接続。

そうすると、Qiというブートローダが起動していることが確認できた。
まったく死んでしまったわけではないようだ。
よしよし。



そういえば、SmartQ5掲示板にファームウェアアップデートに失敗したときのことが書かれていた。

  1. PanasonicのSDフォーマッタでフォーマット。といいつつ私はHPのフォーマッタを使ったが。
  2. SD Card Update Toolで何か知らんが書き込む。
  3. そのSDカードをSmartQ5に入れ、AC電源を挿し、+と-の間にあるボタンを押したままリセット。
  4. かなり待たないといかんが、待ってるといつものファームウェアアップデート画面が出てくる。

2は、やらなくていいかも。
わからないのでやってみたけどね。



2011/06/25

AccessoryChatの使い方

こんにちは。

最近、USB Accessory機能が追加されましたが、Arduinoとか持ってないので他の実現手段を探していました。
一番手軽そうなのが、Accessory Chatアプリを動かす方法だったので、紹介します。
ただ、自作の環境でしか試せていないので、他でも使えるかどうか分かりません。


AccessoryChat

◆どういうもの?
USB Accessory機能のテスト用アプリ。
通信相手は、Linuxで動くPC。
なので、Linuxが動くPCが必要になります。
VMwareでやれるかどうかは、わかりません。

◆環境
Android Platform(2.3.4)の開発環境一式がたぶん必要です。
どこからかダウンロードしてください。

◆ビルド
Androidアプリと、Linuxアプリの2つがあります。

$ cd frameworks/base/libs/usb/tests/AccessoryChat
$ mm
$ cd accessorychat
$ mm

最初のmmでAndroidアプリが、次のmmでLinuxアプリがビルドされます。
Androidアプリは、out/target/product/(各自の環境)/data/app/AccessoryChat.apk。
Linuxアプリは、out/host/linux-x86/bin/accessorychat。

◆使い方
Android端末の方にはアプリをインストールしておきます。
Linux側でaccessorychatを起動させておき、Android側にUSB Bを挿したUSBケーブルをPCに挿します。
そうすると、うまくいけばAndroid側が自動的にAccessoryChatを起動させようとします。

接続がきちんとできれば、Android側から送信した文字列がLinux側に表示されるし、Linux側が入力した文字がAndroid側に表示されます。

◆解説
ポイントは、accessorychatアプリ。
この人が、Android Accessory Protocolをkernelとやりとりしています。
README.txtによると、Android側で動かすこともできるらしいです(hostサポート時)。

動きについては、今までの記事を参考にしてください。

[felica]PUSH端末

今週、Googleプレイスのフィールドテストがあったようだ。
http://www.itmedia.co.jp/news/articles/1106/24/news017.html


かざすとレビューができる、くらいしか書かれていないので、実際に何が行われているかわからない。
が、twitterで「R/Wが電池かいな?」ということが書かれていた。

そうならば、これはPUSH端末だ。
例えば、こんなの。
http://www.usc-sbc.com/navi/index.htm

R/Wかと言われると、PUSH専用なので「違う」ということになる。
が、PUSHする機能はInitiatorコマンドなので、R/W機能と言えなくもないか。
まあ、私も仕事でしかものを見たことがないんだけどね。

[nfc]ISO-DEPとは?

コメントをいただいたので、久しぶりにNFCの資料を眺めている。
Nexus SとPN532でDEPできるか?というもの。

Nexus Sといえば、Android 2.3.4。
Android 2.3.4といえば、IsoDep
IsoDepはISO 14443-4。
NFC Forum的にはISO-DEPもNFC-DEP、すなわちISO 18092のDEPもある。
手近に資料があるので、NFC Forumのドキュメントから見ていこう。


-- NFC Forum --

ISO-DEPは、Type 4AかType 4Bタグを使用する。
Type 1は、NFC-A。でもCRC_B。
Type 2も、NFC-A。こっちはCRC_A。
Type-3は、NFC-F。あれ、Listen Modeはoptionalなんだ。。。
Type-4Aは、NFC-Aで、Listen Modeはoptional。
Type-4Bは、NFC-Bで、Listen Modeはoptional。

今までR/W周りをやってきてわかったのは、R/Wコマンド1発でいろいろとパケットをやりとりしていること。
それと、パケットの中身もうまいこと作ってくれていること。
CRCやDIDなんかは、上位層は気にしなくてよかったからな。
なので、RFパケットのところはあまり深く見なくても済む。


-- ISO 14443-4 --

ネットで、ISO 14443-4ドキュメントが出てきた。
いいんだろうか。。。
詳細な説明は見ない。それは前述した通りだ。
ただ、用語は把握しておいた方がよい。
DEP、という言葉は使われていないのだ。
「Half-duplex block transmission」とか「chaining mechanism」とか。
そういった言葉がデータ交換周りで使われている。

これを基礎知識として、PN533のドキュメントを読んでみよう。


-- PN533 --

ここでは「ISO/IEC14443-4 chaining mechanism」と「DEP chaining mechanism」という言葉が出てきている。
chainingというのは、大きいデータを複数パケットに分割するやり方、みたいなものだと把握している。
なので、これは送信した後の話だ。
送信するパケット自体の話は、そのシーケンスを見るとよい。

ISO14443-4 chaining mechanismのシーケンス例として、PN533(Initiator)とISO 14443-4 PICC間のものが描かれている。
PICCはProximity IC Cardのことだが、おそらくTargetと同じ意味だろう。
InitiatorがInListPassiveTargetでポーリングすると、相手からSEL_REQの応答SEL_RESとして「ISO14443-4 compliant」が返ってくるとなっている。

では、SEL_RESを見てみよう。
NFC Forumのドキュメントを見ると、SEL_RESのbit7, 6で判断できるようだ(bit8~1)。
・00 : Type2 Tag
・01 : Type 4A Tag
・10 : NFC-DEP
・11 : Type 4A TagとNFC-DEP
つまり、bit6=1であればISO-DEPが可能ということになる。
このSEL_RESは、ISO18092のものを拡張してある。こちらはbit7をチェックするだけになっている。

シーケンスの続きでは、InListPassiveTargetのあとはInDataExchangeになっている。
では、とInDataExchangeの詳細を読むと、ああ、説明が全部書いてあった。
SetParametersも一緒にやってやらんといかんかも。


そんなわけで、R/Wから見たISO-DEPは、
  • PN533ではInDataExchangeでDEP Initiator側になれるはず
  • Initiatorになるなら、InListPassiveTargetでSEL_RESを見るとよい
  • TgInitAsTargetでDEP Target側にもなれるはず
というところでしょうかね。

2011/06/19

[nfc]ISO 18092

ISO 18092は、通称「NFCIP-1」と呼ばれている。
あるいは逆かもしれないが、その日本語版がJIS X 5211。
PDFはJISのホームページから見ることができる。

FeliCaはISO 18092で国際規格になっている、といわれるが、FeliCaというよりもNFC ForumでいうところのNFC-Fの部分が規格化されているといった方が正しいと思う。
ISO 18092を製品化しました、の例がFeliCaという見方かな。
ソフト的にいうなら、ISO 18092を基底クラスに持った派生クラスがFeliCa、と。

ただ、ISO 18092には106kbpsの規格も書かれている。
そう、NFC ForumでいうところのNFC-Aだ。
いわゆる「Type-A」で、その製品例がMifare。

よくわからないのが、なぜType-AはISO 18092にもISO 14443にも現れたのか、だ。
http://www.atmarkit.co.jp/frfid/special/5minic/04.html
こちらを読むと、ISO 14443ではだめだったFeliCaが、Philipsと組んでNFCとして提案、と書かれている。
Philipsといえば、もちろんType-A。
だから、Type-AとFeliCaの無線部分が規格になったということか。


残ったのは、Secure Element。
メモリ部分だ。
この部分がおのおの異なって製品になると考えてもよさそうだ。
Mifareは、SWPで外部と通信するようにしているみたいだ。
FeliCaは非公開だが、とりあえず別チップにはなっている(少なくとも今販売されているのはそうだろう)。

SWPになると何がいいかというと、SWPに対応したチップが使えるということだ。
また、SWPというプロトコルでやりとりすればいいので、NFC部分がメーカー依存にならずに済むという安心感のようなものがある。
まあ、逆も然りで、SWPでアクセスできてしまうのでセキュリティ的な危険は増すのかも。
残念ながら、私はSWPをよく知らないのだ。。。

ちょっと検索してみたが、USIMとかUSATとか、避けてきた単語が・・・。
そんなわけで、このまま避け続けたいと思います。


ふっ、と、AES対応はSWP対応の前準備ではないか?と思った。
FeliCaのSecureElementを守るためには、3DESでは足りないと判断したのかもしれない。

[qt]Qt Creatorでどこら辺ができるか(2011/06)

数年前の私は、Qt Designerを使いたがらない方だった。
理由は、デザインをコードで書くよりも遅くなるはずだからだ。
私が扱ってきたソフトでは、ユーザが画面をリサイズさせることはなく、画面の配置は常に一定でよい。
そうなると、わざわざリサイズに対応していたり、自動的に画面部品の位置を調整してくれるような機能はもったいない。
ディスクを圧迫するし、なにより画面の表示が遅くなる、と。

しかし、時代は流れた。
Qtで画面を表示するような実行環境であれば、その程度のパワーはあまり問題にならなさそうだ。
それよりも、画面レイアウトを別の人にお願いできる方がありがたい。

そんなわけで、Qt Creatorのデザイナでどこら辺ができるのか見てみた。
今のQt Creatorが、というよりも、今の私が、という意味合いが大きい。
まだよくわかっていないので、認識が違うかもしれん。


WS000000.JPG

画像がでかいが、まあいいや。。。

部品(Widget)を置いたり、並べたりは、当然ながらできる。
WidgetのまとまりをLayoutで管理できるのだが、これは置いた後でも設定できる。
どちらかというと、置いた後でやった方がやりやすい。
先にLayoutを配置してその中にWidgetを突っ込んでいくのは、けっこう大変だった。

ボタンのシグナルと規定のスロットを接続することもできる。
これは「シグナル/スロット エディタ」でやれた。
シグナルを新たなスロットに接続することもできる。
これは「スロットへ移動」でやるようだ。

新しいシグナルの作成が、はっきりしない。
「シグナル/スロットを変更」ではスロットとシグナルが出てきて、追加ができる。
できるのだが、引数がよくわからん。
私が持っている本「入門Qt4プログラミング」では、引数にconstとか&とかを使っているのだが、このダイアログではスペースや&が入力できないのだ。


今の私のレベルでは、ここまでだ。
全然使いこなせてないなぁ。

まあ、慌てずにやっていこう。

[qt]デバッグ開始するとエラーになったが、解決できた

一難去ってまた一難。
今度はデバッグ開始するとSegmentation Faultで落ちてしまう。
デバッグ版の開始ではなく、デバッグ開始。
つまり、ブレークポイントとかで止まってほしいの時の開始ですな。

今回よかったのは、デバッグモードでの起動だったので、落ちた箇所がわかることだ。
落ちたのは、c:\WINDOWS\system32\guard32.dll。
これで検索すると、いくつか見つかった。
「別の名前にリネームしろ」というのが解決方法だった。
どうやら、FirewallソフトにCOMODO Firewallを使っている人に見られる現象のようだ。

そんなんでいいのか?と思いつつやってみると、確かに問題なくなった。
始めるまでが大変ですなぁ。

[qt]ビルドできるようになった

QtSDKでビルドできるようになった。
ただ。。。何をしたのが直接よかったのかがわからない。

環境変数PATHに、自分でも気付いていないものが関係しているものが含まれているかもしれないので、動作に影響がなさそうな範囲で削除。
TortoiseGitやTortoiseSVNなんかは残したが、doxygenやgraphvizなどは消した。

そこで試しておけばよかったのだが、もう1つやってしまった。
レジストリクリーナーだ。
フリーのレジストリクリーナーがインストールされていたので、それを実行。
私のところでは、Wise Registry Cleaner4が入っていた。
1つずつ見ていくのも面倒なので、自動クリーンをやった。

そしたら、ビルドできるようになった。
Qt Creatorでもコマンドプロンプトでもどっちでもだ。
他には操作してないと思うけどな。。。

気になったのでPATHを戻してみたが、ビルドできる。
ということは、レジストリクリーナーが効いたってことなのか。
今までレジストリクリーナーで顕著な効果が出たことがなかったので「絶対にこれだ」と断言できない。
ビルドできない場合はお試しください、というくらいで。

[qt]まだビルドできない

デスクトップPCのPATHからmingw, cygwinっぽいパスを外した状態でQtSDKを新規インストールし直した。
やり方はノートPCと同じ。
インストールして、同じようにExamplesを動かしたが・・・・やはり同じエラーが出る。

しかし、今回はMakefileはrmではなくdelを使うようになっていた。
やはり何かしらの情報を使っていたのだろう。
それはいいのだが、他に何があるのだろうか?

まずはウイルス対策ソフトを削除してやってみた。
デスクトップPCはavast!6を、ノートPCはAviraを使っている。
しかし変わらず。。

procmonで見てみると、実行するためのbatファイルをDocuments and Settings以下のTempに作成するのだが、そのスレッドがファイルを作ってExitThreadした直後にmingw32-makeがProcessExitして、エラーを出している。
エラー番号は255で、QtCreatorも同じことを言ってた。
mingw32-makeが死んだ後は、svchost.exeがあれこれ見に行っているが、これはなんとなく関係なさそうだ。

なんでbatファイル生成後に死んでいるのかがよくわからない。
うーむ、週末は何もしないといってはみたものの、この状況は気持ち悪いなぁ。

[qt]別のPCではすんなりビルドできた

ビルドできないので、アンインストールして寝よう。
と思ったが、ノートPCもあるのでそっちにインストールしてみた。

こっちではQtの2009.05版が入っていた。
念のために起動させると、動いた。

環境としては、だめだったデスクトップPCとあまり変わらない。
ただ、あまり開発では使っていないので、インストールされているものは少ない。
cygwinやmsysなんかは入っているけどね。

インストールは同じようにやろうと思ったが、少しだけ変えた。
MaemoやSymbian環境もインストールされるので、そのチェックを外したのだ。
変更はそれくらい。
古いQtはまだアンインストールしていない。

同じようにやってみると・・・すんなりビルドできてしまった。。。。
何が違うんだ??
古いQtと一緒にインストールしたMinGwが生きているからか?
そう思ってアンインストールしたが、ちゃんとmakeできている。
なんだ??

Makefileを見てみると・・・違う。
rmじゃなくてdelを使うようになってる。
Makefileは、proファイルを見てqmakeが作ることになっている。
ということは、qmakeが何かしらだまされているってことか。

明日はそこら辺を見ることにしよう。

[qt]Windowsのmingw版でmakeがエラーになる

QtのWindows版をインストールした。
今の最新版は、Version 1.1.1である。
http://qt.nokia.com/downloads

オンラインでインストールするのはあまり好きではないので、Direct downloadからダウンロード。
1.5GBもある。。。
インストールは、デフォルト設定で行った。
C:\QTSDKというところにインストールされるが、まあ気にすまい。

Qt Creatorを起動させ、とりあえずサンプルを動かしてみようとした。
サンプルの「Qt C++のサンプルを参照する」で「Main Window > Menus」を選ぶ。
なんか出てくるので、OKとする。
そうすると開発画面になるので、左下のトンカチをクリック。

Interrupt/Exception caught (code = 0xc0000005, addr = 0x41f96e)
燃え上がっていたQt熱が下がってしまった・・・。



クリーンをしても、同じ。
Qt Creatorでやるからかもしれないと思い、コマンドプロンプトでもやったが、同じ。
うーむ。

検索をする。
http://qt-devnotes.blogspot.com/2010/07/mingw32-makeexe-interruptexception.html
http://qt-devnotes.blogspot.com/2010/01/cqt200905mingwbinmingw32-makeexe.html
http://bugreports.qt.nokia.com/browse/QTSDK-32

一番わかりやすいのは、3つめのリンク先だ。
「複数のmingwライブラリが入ってるから」ということをいっている。
いや、そうなのかもしれないけど、じゃあ影響されないように何とかしなさいよ、と思う。

仕方ないので、mingw32-makeのデバッグをすることにした。


C:\QtSDK\Examples\4.7\mainwindows\menus-build-desktop>mingw32-make -f Makefile.Debug -d
(中略)
g++ -c -g -frtti -fexceptions -mthreads -Wall -DUNICODE -DQT_LARGEFILE_SUPPORT -DQT_DLL -DQT_GUI_LIB -DQT_CORE_LIB -DQT_HAVE_MMX -DQT_HAVE_3DNOW -DQT_HAVE_SSE -DQT_HAVE_MMXEXT -DQT_HAVE_SSE2 -DQT_THREAD_SUPPORT -DQT_NEEDS_QMAIN -I'../../../../Desktop/Qt/4.7.3/mingw/include/QtCore' -I'../../../../Desktop/Qt/4.7.3/mingw/include/QtGui' -I'../../../../Desktop/Qt/4.7.3/mingw/include' -I'../../../../Desktop/Qt/4.7.3/mingw/include/ActiveQt' -I'debug' -I'../menus' -I'.' -I'../../../../Desktop/Qt/4.7.3/mingw/mkspecs/win32-g++' -o debug/mainwindow.o ../menus/mainwindow.cpp
Unhandled exception filter called from program mingw32-make
ExceptionCode = c0000005
ExceptionFlags = 0
ExceptionAddress = 41f96e
Access violation: write operation at address 0

g++を実行したことで捕捉できない例外が発生した、ということか。
ちょっとg++は面倒なので、もう1つ失敗したクリーンの方を見てみる。

C:\QtSDK\Examples\4.7\mainwindows\menus-build-desktop>mingw32-make -f Makefile.Debug clean -d
(中略)

rm debug/moc_mainwindow.cpp
Unhandled exception filter called from program mingw32-make
ExceptionCode = c0000005
ExceptionFlags = 0
ExceptionAddress = 41f96e
Access violation: write operation at address 0



rmで?

C:\QtSDK\Examples\4.7\mainwindows\menus-build-desktop>which rm
/usr/bin/rm

なんでwhichが使えるかというと、cygwinが入っていてパスを通しているから。
そして/usr/bin/rm というのは、cygwin側のパスだ。

C:\QtSDK\Examples\4.7\mainwindows\menus-build-desktop>which g++
/cygdrive/c/QtSDK/mingw/bin/g++

/cygdriveというのは、cygwinから見た「マイコンピュータ」みたいな位置づけ。
だから/cygdrive/cはCドライブのルートディレクトリだ。

私の推測は、cygwin側のコマンドが呼び出されるとmingw側のライブラリと不整合が起きてしまう、というもの。
rmはcygwin側だからありえそうだと思った。
しかしg++もだめってのがねぇ。。。
試しにcygwinのパスを外してみたが、現象が変わらない。

腹が立ったので、MSYSインストールした。
現在の最新版は、mingw-get-inst-20110530.exe
C++とMSYSにチェックを入れてインストール。
インストール後に、MinGw Shellを起動し、カレントディレクトリを移動。

/c/QtSDK/Examples/4.7/mainwindows/menus-build-desktop
$ mingw32-make -f Makefile.Debug

通った。
しかし、Qt CreatorもQtコマンドラインもやはりmakeでエラーになる。
なんじゃこりゃ?
そもそも、QtSDK以下にはrmがないぞ。
デフォルトでインストールしたのがまずいのか??
まったくもう。。。

2011/06/18

Qt for Android

Androidやる前は何をやってたかなー、と思い出すと、私はQtをやりだそうとしていたところだった。
ちょっと手を付けただけで終わっていた。。。

そんなわけで、しばらくQtをやろう。

Androidでもいいやん、と思われそうだが、そこはちょっと理由がありまして。
私は基本的に、アプリを作るのが好きではない。
でも、やはりアプリを作らないとドライバとかミドルだけではやっていけず。。。

どうせアプリを書かないといけないなら、JavaよりもC++だな、と。
Javaはだめだ、とかではなく、Javaに慣れていないから、というところ。
スキル不足だ。

まあ、まずはQtでアプリを作れるようになってから考えましょうかね。
たしかAndroidでQtを動かすようなものがあったな、と思い出した。
検索すると、Qtの研究チームが報告してた。日本語版の記事もある。
necessitas、というらしい。
開発環境がnecessitasで、動作環境がministroということかな。


で、これがすごいのは、Qtがやってるのではなく個人がやっているということだ。
うーむ。
負けてられん、といいたいが、そのレベルにはない。。。
ないが、あきらめてもいかんので、まずはQtの勉強から始めよう。

2011/06/13

FeliCa Liteのカード鍵生成標準アルゴリズムの資料があった

以前、「FeliCa Liteの片側認証はこうなのか?」という記事を書いた。
あのときの私は、何もわかっていなかった。

AES暗号化のこともあったので、SONYの技術資料ページへ飛ぶと、FeliCa Liteのセキュリティ関係資料があった。
まったく見逃していた。

前回の私は、こんなことを書いていた。

> やるとするなら、認証ソフトも自分で作って、ランダムチャレンジブロックへの書き込み値を一定にして、
> 同じMAC値が返ってくるカード鍵値を求める、というくらいだろうか。
> カード鍵さえわかれば、ランダムチャレンジブロックは毎回変化するのでどうでもいい。
> 自分で認証ソフトを作り、繰り返すだけでいいのだ!

このときの私は「同じ種別のカードを作るときは、おなじカード鍵になってるはずだよな」と思っていた。
ほら、鍵だから、カードごとに違うはずはなかろう、と。

しかし、FeliCa Liteの資料には、こう書いてあった。

カード鍵を設定する際は、すべてのカードに同じカード鍵を設定するのではなく、
カードごとに異なるカード鍵を設定してください。

なんと!
ちゃんと対策が考えてあったのだ。
これを「さすが」というのは、セキュアな世界の人々にとってはレベルが低いことなのかもしれない。

でもまあ、自分なりに考えていった結果が間違っていなかったことが確認できて、私は嬉しい。
それをふさぐ手段があったことも、もちろん嬉しい。
こういう目に会うと、片側認証をちゃんと実装してみたくなるのよねー。
技術に敬意を表するというか。

しかし、トリプルDESはなかなか壁が高い。
ブラウザも暗号化があるだろうから、そういうとこのライブラリを借りるのかなぁ。
暗号化には暗いので、よくわからん。

2011/06/12

AES対応FeliCaチップ

AES暗号化に対応したFeliCaチップが発表された。

それまでは何だったかというと、3DES。トリプルDES。
安全性としてはAESの方が高いが、いかんせんFeliCaの方が早かった。
当時は3DESが最高だったのだ、という記事をどこかで読んだ覚えがある。

暗号化しているのはどこか?というのも気になる。
リンク先には比較表があるが、これによると「R/Wとの認証方式」「通信路の暗号化」「搭載コマンド」に違いがある。
しかしFeliCaの技術情報を見ても、そこら辺のことが書かれていない。
まあ、ソフトの人が気にしても仕方ないことであるが。。。

FeliCa Liteは簡易セキュリティを持つという。
違いが表になっていた
では、見たいところだけまとめよう。

新FeliCa Standard 現FeliCa Standard FeliCa Lite
R/Wとの認証方式

・トリプルDESによる相互認証
・AES128bitによる相互認証

トリプルDESによる相互認証 トリプルDESによる簡易認証
通信路の暗号化 ・DES暗号方式
・AES暗号方式
DES暗号方式 なし
搭載コマンド ・DES暗号化対象コマンド
・AES暗号化対象コマンド
・非暗号コマンド

・DES暗号化対象コマンド
・非暗号コマンド

非暗号コマンド



FeliCa Liteのシステム構成例を見てわかるように、「通信路の暗号化」の通信路は無線通信を指している。
Liteは無しで、Standardは暗号化をしている。

とはいえ、ポーリングみたいにStandardでもLiteでも使えるコマンドがある。
これが「搭載コマンド」の「非暗号コマンド」だろう。
こういう通信は、暗号化しているとLiteでは認識できないので、暗号化していないはずだ。
そんなわけで「通信路の暗号化」は、常に暗号化しているわけではなく、暗号化対象コマンドが使われたときのみ暗号化されると考えている。
それに、ISO 18092は暗号化について触れてないしね。

規格ついでに、JIS X6319を見てみよう。
これには暗号化対象が書かれている。
「Write to Secure File」「Read from Secure File」のコマンドとレスポンス、「Authentication2」のレスポンスが暗号化対象となっている。
詳細は、みなさんで確認しておくれ。



そんなわけで、何でもかんでも暗号化しているわけではなく、相互認証している間だけが暗号化されているのだろう。
それに、FeliCa Liteを使う分には影響がない。
モバイルFeliCaチップもまだAES対応版が出ていない。
これは普及のための前準備、というところなのかな。

Accessory Modeのまとめ

何となく、アクセサリモードのまとめ文書を作った。
Google Documentってあまり使ったことがないんだけど、見えるかな?

ポイントは、通信はバルク転送です、というところかな。

気になったのは、最初からアクセサリモードだった場合の動作。
このシーケンスだとURIなんかは取得するタイミングがないはずだが、いいんだろうか?
accessorychat.cを見てもそうなっている。
ここの2番でやっているリクエストコード52の処理は、通信確立後の方がいいのでは?という気がしている。

でもまあ、Android側が既にアクセサリモードになっているってことは、覆すことができないからいいのか。
思っていたのは、52で受けとった文字列を使って起動するアプリが選択できるようにしてもいいのではないか、ということだ。
でも、インテントを受けとるのはopenAccessory()する前だ。
アプリとしては「呼ばれたけど私は起動したくない」という処理ならできるだろう。


うちで動くAndroid端末は、BeagleBoardとSmartQ5しかない。
(SmartQ5は長いこと火を入れてないから、ちょっと心配だ。)
ちょっと遊ぶときにしか使ってないので、アクセサリモードで使うデバイスって考えつかないのだ。
USBホストとして動く必要があるから、ちょろっとしたセンサを付けてももったいない気がする。
うーむ。

現在のBeagleBoard構成

忘れそうなので、現在のBeagleBoard構成を書いておこう。

BeagleBoard_C4.png

Android : 2.3.4
Linux : 2.6.32.9(rowboatベース)


これにUSBシリアル変換ケーブルをつなげたり、PaSoRiとかRC-S620/Sをつなげることもある。
まあ、おおよそ動いている。

Androidは、ほぼ素の2.3.4だ。
TI版のを使うと、モニタがDVI-Dならもっと高速な描画を楽しむことができる。
しかし残念ながら、うちには余ったDVI-Dモニタがないので、DisplayLinkをつなげている。
持ち運びには便利なのだが、描画は速くない。

2011/06/11

Android Accessory Protocolを使ってIDmを送ってみた

WinUSBは忘れて、Linuxで何か作ってみることにした。

私から見た感じでは、Android Accessory Protocolというのは、接続部分が主だ。
ホスト側は、接続されたUSB機器がAccessoryモードでなかったら切り替えるためのコマンドを送って切り替えさせる。
切り換わってベンダIDとプロダクトIDが特定の値になったら、あとはバルク転送を勝手にやってくれ、というイメージ。

アプリ側はインテントが飛んでくるので、それを受けてopenAccessory()しにいく。
うまくいけば、ディスクリプタを取得してストリームを開き、ホスト側とはストリーム経由で通信する。
ストリームで通信すると、ホスト側とはバルク転送が行われていることになる。

まあ、AccessoryChatがそういうアプリだったためかもしれないが、そう間違ってもいないだろう。
接続処理を書くのは面倒だが、そこはaccessorychatの処理をまるまる使えばいい。
そう、Linuxならね。


そんなわけで、以前作っていたLinuxで動くFeliCaライブラリ(PaSoRi or RC-S620/S)を動かし、取得したIDmをAccessoryChatに返すアプリを作ってみた。
まあ、うまくいきましたよ。
だってやってるのは、LinuxホストでIDmを取得して、それを文字列に置きかえて、バルク転送するだけだから。。。IDm取得を追加しただけで、accessorychatの元機能には変更なし。
簡単でしたわ。

Android側も変更して、直接FeliCaコマンドをバルク転送して、受け取ったデータをPaSoRiに転送するようにすることもできる。
そういうしくみを作れば、ホストになれないAndroidでもホストっぽく動くことができるだろう。

WinUSBはしばらくやめておく

WinUSBでAccessoryChatをまねしてみよう、とやっていたのだが、だんだん嫌になってきた。

BOOLとかULONGとか、VCで使っているものが自前typedefしたものなので、標準系でなるべくやりたい人からすると、非常にめんどくさい。
BOOL→boolは、!!してごまかしたけど、ULONGとかになってくると嫌になってきた。
サイズを返したかったのでsize_tに置き換えようとしたけど、それだけでwarningが出てくる。

いや、warningが出るのはいいんだけど「結局WindowsのVC++専用だよなあ」と思うと、やる気がなくなってきた。
そんなにWindows系は嫌いではないつもりなんだけどねぇ。
なんでだろう?

たぶん、仕事でもないのにULONGとかUCHARなんかが強制されるのが嫌だったのだろう。
自前で書けばそんなこともないんだけど、API使うときしかWindowsの定義使わないしね。
やることとやりたいことが決まっていて実現手段は問わない、となっているからだ。
それなら、コーディングと実行が簡単な環境でやるよなー、と。
今のところ、Linuxが一番やりやすい。
Windowsで同じことをせないかんなら、そのときは移植するだけだ。

そんなわけで、1週間もやってないけどWinUSBはやめる。

2011/06/06

WinUSBを試す

唐突だが、WinUSBを試してみた。
まあ、予想は付くだろうが・・・accessorychatみたいなものをWindowsで実現させてみようというわけだ。
まずは手始めに、WinUSBがどんなものかを試したというところ。

雑誌Interfaceの2010年2月号に資料があるので、ほぼそれを見ながらやっただけだ。
やったというか、サンプルを動かしただけ。
相手はBeagleBoardなので、ベンダIDとプロダクトIDだけ対応させた。
まあ、接続はできたけど、そこから先は失敗している。

WinUSBのいいところは、作業がアプリだけになるというところ。
アプリというか、ミドルというか、ドライバよりも上位層でよいというか。
あまりめんどうなことはしたくないので、ちょうどよさそうだ。

もう1ついいところは、無料入手の開発環境だけでやれるというところ。
Windowsでは、これが一番気になっていたのだ。
もちろん、お金を取るのが悪いわけではない。
ないんだけど、ちょろっと作るだけの人にとってはね・・・。

Linuxでいいやん、という気もするが、それはそれで面白くない。
どうせやるなら、いろんなプラットフォームで動いた方が楽しい。
といっても、Macの環境は持ってないので、LinuxかWindowsになってしまうのだが。

2011/06/05

AccessoryChatが動くとこうなる

IME_ACTION_DONEを認識しないのはあきらめたので、Enterキーで送信されるようになった。

AndroidChat側から文字入力してEnterすると、accessorychat側にその文字が表示される。
accessorychat側から文字入力してEnterすると、AccessoryChat側にその文字が表示される。

シンプルだ。
これを使って遊ぶことにしよう。

AccessoryChatから送信されないのは、IME_ACTION_DONEが出ないため


AccessoryChatアプリには、EditTextが1つある。
ここに文字を打ち込んでEnterを押すと、onEditorAction()が呼ばれる。
呼ばれると、ストリームにwrite()しておしまい。
accessorychatはバルク転送を監視し、何か来たら標準出力に吐き出す。

のだが・・・何も出てこない。
そもそも、logcatにこれがでるのがいかん。

D/AccessoryChat( 1176): onEditorAction 0 event: KeyEvent{action=0 code=66 repeat=0 meta=0 scancode=28 mFlags=8}

送信の条件として、アクションIDがEditorInfo.IME_ACTION_DONEってなってるけど、うちは0で来ている。
0はIME_ACTION_UNSPECIFIEDだから、よくない。

よくないのだが、どこをどうやっても出ないのだ。。。
  • keycharsの見直し(なぜかうちは__USB_Keyboard.kcm.binを読もうとするので、そうした)
  • imeOptions不可
思いついたのはこれくらいだ。
もうだめなので、IME_ACTION_DONEチェックをなくした。
敗北だ。。。

remoteに新しいbranchをpush。ついでに削除。

未だにgitがよくわかっていないので、調べ調べやっている。
今回は、ローカルで作ったbranchをremoteにあげる方法。
作ったのは「rowboat-gingerbread-2.6.32」という名前。

$ git push origin rowboat-gingerbread-2.6.32

これでいいみたい。

cloneしたときにbranchがたくさんあったけど私にはいらないので、削除。

$ git branch -a
  rowboat-eclair-2.6.32
* rowboat-gingerbread-2.6.32
  remotes/origin/HEAD -> origin/master
  remotes/origin/master
  remotes/origin/rowboat-am1808-2.6.32
  remotes/origin/rowboat-am389x-2.6.32
  remotes/origin/rowboat-eclair
  remotes/origin/rowboat-eclair-2.6.32
  remotes/origin/rowboat-gingerbread-2.6.32
  remotes/origin/rowboat-kernel-2.6.35
  remotes/origin/rowboat-kernel-2.6.37
  remotes/origin/rowboat-ti81xx-2.6.37

$ git push origin :rowboat-am1808-2.6.32

こんな感じで。
コロンがポイントだと思う。忘れそうって意味で。

ベンダIDがようやく切り替わった

どこがどうなるとベンダIDが切り換わるのか分からなかったが、android_usb_platform_data構造体にデータを詰める際、num_productsを指定してなかったためのようだ。
グローバル変数なので、設定しないと0になってしまうのだな。

さて、accessorychatのログは・・・

Found possible android device - attempting to switch to accessory mode
device supports protocol version 1
Found android device in accessory mode

わーい。

lsusbは・・・

Bus 001 Device 024: ID 18d1:2d01 Google Inc.

わーい。
というわけで、無事にkernelは動いたようだ。

これを機にgitoriousのブランチを切り直そうと思ったが・・・うまくいかん。
また別の機会に。
accessorychat側の出力を見ると、まったく分かってないわけでもなさそうだ。

Found possible android device - attempting to switch to accessory mode
device supports protocol version 1
Found possible android device - attempting to switch to accessory mode
failed to read protocol version

「1」は、ちゃんと通信した結果みたい。

このルートを通るのは、ベンダIDが0x18d1 or 0x22b8で、プロダクトIDが0x2d00でも0x2d01でもない場合。
その後、コマンド52で文字列を送り、コマンド53を送信して終わり。

D/UsbService(  858): entering USB accessory mode: UsbAccessory[mManufacturer=Google, Inc., mModel=AccessoryChat, mDescription=Accessory Chat, mVersion=1.0, mUri=http://www.android.com, mSerial=1234567890]

送ってる文字列と同じものがlogcatにも出ているので、そこもよさそうだ。


# cat /sys/devices/virtual/usb_composite/accessory/uevent
FUNCTION=accessory
ENABLED=1


USBケーブルを外すとENABLEDが0になるから、kernelもわかってるんだ。
単にプロダクトIDが切り替わってないだけってことか。。。

accessorychatを起動させずにUSB接続しても、AccessoryChat起動要求がこない。
んで、adbを起動させてもベンダIDは0x0018のままだ。
0x0015になることを期待したのだが。。。
ということは、そもそもベンダIDを切り替える部分が動いていないということなのか?

/sys/class/switch/usb_XXXにはkernelで対応

/sys/class/switch/usb_connected/state
/sys/class/switch/usb_configuration/state

これらがない件については、 kernel側で対応致しました。
solaさんのこちらを見ながら、まねしたというところ。

このkernelで起動すると、なかなか順調。
USBをPCに挿すと、Android側が認識して「AccessoryChatを起動する?」みたいな問い合わせをしてくれる。
記念に、USBを挿してからのログを載せておこう。

--------- beginning of /dev/log/system
W/Vold    (  799): Ignoring unknown switch 'usb_connected'
W/Vold    (  799): Ignoring unknown switch 'usb_connected'
android_usb gadget: high speed config #1: android
adb_function_set_alt: maxsize = 512
W/Vold    (  799): Ignoring unknown switch 'usb_connected'
D/Vold    (  799): USB connected
acc_open
acc_release
--------- beginning of /dev/log/main
D/UsbService(  858): entering USB accessory mode: UsbAccessory[mManufacturer=Google, Inc., mModel=AccessoryChat, mDescription=Accessory Chat, mVersion=1.0, mUri=http://www.android.com, mSerial=1234567890]
I/ActivityManager(  858): Starting: Intent { flg=0x10000000 cmp=com.android.systemui/.usb.UsbConfirmActivity (has extras) } from pid 858
adb_release
adb_open
W/Vold    (  799): Ignoring unknown switch 'usb_connected'
D/Vold    (  799): USB disconnected
W/Vold    (  799): Ignoring unknown switch 'usb_connected'
W/Vold    (  799): Ignoring unknown switch 'usb_connected'
android_usb gadget: high speed config #1: android
adb_function_set_alt: maxsize = 512
W/Vold    (  799): Ignoring unknown switch 'usb_connected'
D/Vold    (  799): USB connected
I/ActivityManager(  858): Displayed com.android.systemui/.usb.UsbConfirmActivity: +472ms
musb_g_ep0_irq 668: SetupEnd came in a wrong ep0stage idleI/ActivityManager(  858): Starting: Intent { act=android.hardware.usb.action.USB_ACCESSORY_ATTACHED flg=0x10000000 cmp=com.android.accessorychat/.AccessoryChat (has extras) } from pid 922
D/AccessoryChat( 1181): intent:
acc_open
Intent { act=android.hardware.usb.action.USB_ACCESSORY_ATTACHED flg=0x10000000 cmp=com.android.accessorychat/.AccessoryChat (has extras) }
D/AccessoryChat( 1181): openAccessory: UsbAccessory[mManufacturer=Google, Inc., mModel=AccessoryChat, mDescription=Accessory Chat, mVersion=1.0, mUri=http://www.android.com, mSerial=1234567890]
D/AccessoryChat( 1181): openAccessory succeeded
I/ActivityManager(  858): Displayed com.android.accessorychat/.AccessoryChat: +465ms


よしよし、と思ったが・・・。
PC側のaccessorychatが認識していない。
lsusbで見ても、まだプロダクトIDが変わってない。
うーん・・・。

getAccessoryList()でnullが返ってきている

logcatを見ると、
D/AccessoryChat( 1165): intent: Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10200000 cmp=com.android.accessorychat/.AccessoryChat }
D/AccessoryChat( 1165): mAccessory is null


UsbAccessory[] accessories = mUsbManager.getAccessoryList();

これがnullだからだめなんだ。
しかし"RemoteException in getAccessoryList"というログはない。
そもそも、UsbAccessory関係のログがほとんどないので、元から動いていないようだ。

W/UsbDeviceSettingsManager(  851): settings file not found
I/UsbService(  851): This kernel does not have USB configuration switch support

この2つがあやしい。

settings fileは、これだろう。
/data/system/usb_device_manager.xml
確かに、こんなものはコピーした覚えがない。
自動生成かとも思ったが、今はできてない。
まあ、いいや。

configuration switch supportの方は、以下のどちらかが存在しないからだ。
/sys/class/switch/usb_connected/state
/sys/class/switch/usb_configuration/state

うん、/sys/class/switch以下が空っぽだ。
というわけで、まずはここを解決する必要がある。

AccessoryChatとaccessorychat

f_accessoryを動かすとして、どうやって確認したらいいのか困っていた。
しかしそこは見抜かれていたようで、サンプルがあった。

frameworks/base/libs/usb/test/AccessoryChat/README.txt
Androidアプリとして「AccessoryChat」を、Linux用として「accessorychat」を用意してあるらしい。

よくわからんが、ビルドすればわかるんじゃなかろうか。
あら、Linux向けのビルドってどうやるんだろう?
こういうときに「mmm」を使うのか?

と、まったく何も考えずにmmmとすると・・・なんかあれこれビルドを始めた・・・。
Tests関係のものがすべてビルドされているみたい。
あちゃー。

でも、helpには
- mmm:     Builds all of the modules in the supplied directories.

ってあるではないか。
frameworks/base/libs/usb/test/AccessoryChatでmmmしてるのに、なんでCtsAppSecurityTestsみたいなものまでビルドされているんだ?

よくわからんが、ここはいつものmmでいいや。
Androidアプリはdata/app/AccessoryChat.apk、コマンドはout/host/linux-x86/bin/accessorychatにできる。

Linuxでaccessorychatを動かすと、待ち状態になる。
そこにBeagleBoardを挿すと、認識して、失敗した。

Found possible android device - attempting to switch to accessory mode
failed to read protocol version

Android側でAccessoryChatを起動すると、すぐに落ちた。


I/dalvikvm( 1118): Could not find method com.android.future.usb.UsbManager.openAccessory, referenced from method com.android.accessorychat.AccessoryChat.openAccessory

すまん。。。
気を取り直してもう一度AccessoryChatを起動。
今度はちゃんと起動した。
出てきたのは、EditTextがあるだけの画面。
これに文字を入れるのだろう。
BeagleBoardをPCに接続すると・・・やっぱりaccessorychatはfailedだ。

ここは、やはりkernelでしょうな。。。
lsusbで見ると、
Bus 001 Device 008: ID 18d1:9018 Google Inc.
ってことで、AccessoryのプロダクトIDではない。
うーむ。

2011/06/04

rowboat-kernel + 2.3.4でadbが動いた

ようやく、BeagleBoard C4で、rowboat-kernel + android2.3.4でadbが使えるようになった。

TI提供の環境(お、韻を踏んでる)で、どのbranchを使っているかわからんかった。
調べる方法があるのかな?
私は、commit logを見ていって探していった。
なんか、まぬけだ。

今回から、ALSAをなくした。
今まで、使ってもいないのにALSA関係でけっこう面倒だったのだ。
なんでこだわっていたのかよくわからない。。。

でも、カメラはUSBカメラ、しかもBayerのやつでOpenCVライブラリありの構成だ。
使ってないのだけど、使うかもしれないし。

f_accessoryを入れ込んだけど、動いているかどうかわからん。
今は、adbが動いている。
adb devices、とすると見えてるし。
これにいろいろやると、AAPできるようになるのかしら。

さあ、やってみよう。

TI-kernelで自分ビルド環境が立ち上がったが、固まった

タイトルどおりだ。

前回、BatteryService側を変更して、強制的にフル充電状態を作り出した。
そうすると、いままでandroid起動アニメーションから抜けられなかったものが、とうとうHOME画面まで到達した。
もちろん表示されたのは、DisplayLink側だ。



したのだが、真っ暗になってしまった。
kernelがpanicも出さずに固まったようだ。
最後にログが出ている。


/SurfaceFlinger( 845): About to give-up screen, flinger = 0x94670
PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.01 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
Suspending console(s) (use no_console_suspend to debug)


これはどうも、電力管理のような気がする。
うん、Androidのバックライト消灯時間を長くすると、同じ時間では落ちない。
困ったことに、復旧はしてくれないが、まあいいや。

仮想バッテリードライバがなかった

my-kernel(TI提供)、my-androidで起動しないので、logcatを見た。

I/SystemServer(  870): Battery Service
W/dalvikvm(  870): No implementation found for native Lcom/android/server/BatteryService;.native_update ()V
W/dalvikvm(  870): threadid=9: thread exiting with uncaught exception (group=0x40015560)
I/Process (  870): Sending signal. PID: 870 SIG: 9
E/AndroidRuntime(  870): *** FATAL EXCEPTION IN SYSTEM PROCESS: android.server.ServerThread
E/AndroidRuntime(  870): java.lang.UnsatisfiedLinkError: native_update
E/AndroidRuntime(  870):     at com.android.server.BatteryService.native_update(Native Method)

そういえば、BeagleBoardにはバッテリーがないから、仮想バッテリードライバがあるといいよ、という記述を読んだ記憶がある。
使っていたkernelは、それが入っていたのだろうが、TI環境ではAndroidからバッテリーチェックをはずしているのだろう。
うんうん、きっとそうだ。

こちらを見ながら変更。
http://d.hatena.ne.jp/bs-android/20090603/1244043649

・・・変わらん。
と思ってlogcatを見直すと、これがあった。

W/dalvikvm(  830): No implementation found for native Lcom/android/server/BatteryService;.native_update ()V


なんでこれが出るかというと、これだ。

E/BatteryService(  866): Could not open /sys/class/power_supply

JNI登録の前でエラーがあるため、できてないのだ。
これはkernelのせいで、おそらく私がオプションを外したのだろう。
CONFIG_POWER_SUPPLYか。

では、有効にして置きかえると・・・・
あ、起動した!!
TIカーネルで自ビルドAndroidが起動できましたわ。
やっt・・・・・

あれ、モニタが消えた。。。(つづく)

SurfaceFlingerが落ちるとmediaserverが落ちる

今、手元で実現できる構成は、こうなっている。
  1. TI-kernel, TI-android : 起動する(DVI)
  2. my-kernel, my-android : 起動する(DisplayLink)
  3. TI-kernel, my-android : 起動しない
  4. my-kernel, TI-android : 起動しない
4は、mediaserverが再起動を繰り返しているためだ。

# ps
media     828   1     16908  4772  ffffffff afd0b6fc S /system/bin/mediaserver

init: untracked pid 828 exited


しかしlogcatを見ると、どうもframebufferまわりらしい。
SurfaceFlingerがエラーを出したら、mediaserverが落ちるんだ、という認識がなかった。

I/SurfaceFlinger(  876): SurfaceFlinger is starting
I/SurfaceFlinger(  876): SurfaceFlinger's main thread ready to run. Initializing graphics H/W...
E/FramebufferNativeWindow(  876): couldn't open framebuffer HAL (No such device)



つまりTI-android環境は、SGXを動かさないと起動しないようなのだ。
mediaserver=ALSA、だと思っていたので、こっちを気にしていたのだ。

Unable to attach mixer to device AndroidPlayback: No such file or directory
Unable to attach mixer to device AndroidCapture: No such file or directory

しかしこいつは、TI環境でも出ていて、ちゃんと起動して動いている。
なので、関係ないようだ。


でもなあ・・・ソースを見ると、単にfb0をオープンしているだけっぽいんだが。
ものはあるし、崩れてはいるがdroid氏もDisplayLinkに出ている(何の画面だ?)。
そしてinit.rcでSGXを起動しないようにしていると、TI-kernelでも同じ現象なのだ。

# ls -l /dev/graphics/fb0

crw-rw---- root graphics 29, 0 2000-01-01 00:00 fb0

つまり、fb0以外のものも使っているということか。
SGXありとなしで/devを比較すると、違いはこれだ。

crw-rw-rw- root     root     250,   0 1970-01-01 00:00 pvrsrvkm

これがないので、SurfaceFlingerが落ちているのだな。

omapfbを無効にしても起動した

前回のコメントで、TI環境のkernelでomapfbを無効にすると起動しない、と書いたが、なぜか今は起動している。
なんでだ??
という気はするものの、おそらくどこか設定がおかしかったのだろう。
すまなかった。。。。

だからといって、DisplayLinkにちゃんと出るわけでもないんだけどね。
・・・と思ったら、前回fb1に出力するようにしたままだった。
そこを戻すと表示されたが、またno vmaが出るようになった。
もちろん、起動アニメーションから抜けられない。

わかったのは、no vmaエラーが出るのはAndroid側でDisplayLink側に表示することがトリガとなっている、ということだ。
まあ、Android側に非はないので、そこはkernelとかで吸収すべきだろう。
因果関係がわかったのは収穫としてよかろう。

kernel optionはDocumentation/kernel-parameters.txtにある

はい、タイトルどおりです。

カーネルのオプションはいろいろありそうだけど、どこに一覧があるのだろう?と思っていた。
Documentation/kernel-parameters.txt にあるとのこと。

テキストファイルで、2800行くらいある。
全部は載せられないので、今回使っているTI-2.6.32での部類だけ載せておこう。


    ACPI    ACPI support is enabled.
    AGP    AGP (Accelerated Graphics Port) is enabled.
    ALSA    ALSA sound support is enabled.
    APIC    APIC support is enabled.
    APM    Advanced Power Management support is enabled.
    AVR32    AVR32 architecture is enabled.
    AX25    Appropriate AX.25 support is enabled.
    BLACKFIN Blackfin architecture is enabled.
    DRM    Direct Rendering Management support is enabled.
    EDD    BIOS Enhanced Disk Drive Services (EDD) is enabled
    EFI    EFI Partitioning (GPT) is enabled
    EIDE    EIDE/ATAPI support is enabled.
    FB    The frame buffer device is enabled.
    GCOV    GCOV profiling is enabled.
    HW    Appropriate hardware is enabled.
    IA-64    IA-64 architecture is enabled.
    IMA     Integrity measurement architecture is enabled.
    IOSCHED    More than one I/O scheduler is enabled.
    IP_PNP    IP DHCP, BOOTP, or RARP is enabled.
    ISAPNP    ISA PnP code is enabled.
    ISDN    Appropriate ISDN support is enabled.
    JOY    Appropriate joystick support is enabled.
    KVM    Kernel Virtual Machine support is enabled.
    LIBATA  Libata driver is enabled
    LP    Printer support is enabled.
    LOOP    Loopback device support is enabled.
    M68k    M68k architecture is enabled.
            These options have more detailed description inside of
            Documentation/m68k/kernel-options.txt.
    MCA    MCA bus support is enabled.
    MDA    MDA console support is enabled.
    MOUSE    Appropriate mouse support is enabled.
    MSI    Message Signaled Interrupts (PCI).
    MTD    MTD (Memory Technology Device) support is enabled.
    NET    Appropriate network support is enabled.
    NUMA    NUMA support is enabled.
    GENERIC_TIME The generic timeofday code is enabled.
    NFS    Appropriate NFS support is enabled.
    OSS    OSS sound support is enabled.
    PV_OPS    A paravirtualized kernel is enabled.
    PARIDE    The ParIDE (parallel port IDE) subsystem is enabled.
    PARISC    The PA-RISC architecture is enabled.
    PCI    PCI bus support is enabled.
    PCIE    PCI Express support is enabled.
    PCMCIA    The PCMCIA subsystem is enabled.
    PNP    Plug & Play support is enabled.
    PPC    PowerPC architecture is enabled.
    PPT    Parallel port support is enabled.
    PS2    Appropriate PS/2 support is enabled.
    RAM    RAM disk support is enabled.
    S390    S390 architecture is enabled.
    SCSI    Appropriate SCSI support is enabled.
            A lot of drivers has their options described inside of
            Documentation/scsi/.
    SECURITY Different security models are enabled.
    SELINUX SELinux support is enabled.
    SERIAL    Serial support is enabled.
    SH    SuperH architecture is enabled.
    SMP    The kernel is an SMP kernel.
    SPARC    Sparc architecture is enabled.
    SWSUSP    Software suspend (hibernation) is enabled.
    SUSPEND    System suspend states are enabled.
    FTRACE    Function tracing enabled.
    TS    Appropriate touchscreen support is enabled.
    UMS    USB Mass Storage support is enabled.
    USB    USB support is enabled.
    USBHID    USB Human Interface Device support is enabled.
    V4L    Video For Linux support is enabled.
    VGA    The VGA console has been enabled.
    VT    Virtual terminal support is enabled.
    WDT    Watchdog support is enabled.
    XT    IBM PC/XT MFM hard disk support is enabled.
    X86-32    X86-32, aka i386 architecture is enabled.
    X86-64    X86-64 architecture is enabled.
            More X86-64 boot options can be found in
            Documentation/x86/x86_64/boot-options.txt .
    X86    Either 32bit or 64bit x86 (same as X86-32+X86-64)

    BUGS=    Relates to possible processor bugs on the said processor.
    KNL    Is a kernel start-up parameter.
    BOOT    Is a boot loader parameter.

2011/06/03

TIのGingerbreadはちゃんと動く

当たり前の報告かもしれないが、TIさんのGingerbreadは、うちのBeagleBoard C4で見事に動いた。
自分でビルドしたものでなく、pre-build版だ。
そりゃ動くよなぁ。

では自分ビルドkernelが動くか、というのを試したいところだが、ぐっと我慢してログを眺めよう。
ログが逃げるわけではないが、今日は動かす前に調べたい気分なのだ。


まず気になったのは、kernel option。

わし:
console=ttyS2,115200n8 noinitrd init=/init root=/dev/mmcblk0p3 rootfstype=ext4 rw rootwait nohz=off


TI:
console=ttyS2,115200n8 androidboot.console=ttyS2 mem=256M root=/dev/mmcblk0p2 rw rootfstype=ext3 rootdelay=1 init=/init ip=off mpurate=720 omap_vout.vid1_static_vrfb_alloc=y


私のは、おそらくどこかのを真似たのだと思う。ファイルシステムが違う以外は、そんなに特徴がない。
TIさんのを見ていこう。
  • androidboot.console。これは、どうやってか忘れたが、initで使えるパラメータになってたと思う。
  • mem。システムに、メモリ量を教える。 256MBあるよ、と教えているのだろう。

    わし:
    Memory: 128MB 128MB = 256MB total
    Memory: 254592KB available (3988K code, 780K data, 160K init, 0K highmem)
    TI:
    Memory: 256MB = 256MB total
    Memory: 249856KB available (4532K code, 825K data, 172K init, 0K highmem)

    どちらも256MBとは思ってくれているようだが、よくわからん。
それ以外のものは、どうでもいいような気がする。



omapdss DPI: Could not find exact pixel clock. Requested 23500 kHz, got 24000 kHz

omapdssは動いていないようだから、気にすまい。


それ以外は、よくわからんなぁ。
というのも、pre-built版はDVI-D出力になり、うちにはDVI-Dモニタは1つしかなく、必然的に今使っているモニタに出力させざるを得ない、となる。
dmesgとかとればよかったんだろうけど、やっぱりねぇ。。。


まあ、明日はkernel optionだけ合わせて試してみよう。

no vmaは出なくなったが、netdが再起動する

omap2のフレームバッファを削ると、no vmaが出なくなっていた。
うーん、あのときはなぜkernel panicが出たんだ。。。。

解せないが、眠たいので。

でもその次には、mediaserverとnetdの再起動が発生している。
うーん。。。

2011/06/01

no vma、今日は解決できず

no virtual memory allocate、とかか?
とにかく、今日は解決できなかった。

まず、fb1を見ていた部分をfb0に戻してみた。
関係なし。

DisplayLinkを抜いてみた。
関係なし。

dmesgを見た。
あやしそうなところを列挙しておこう。

<3>omapdss DPI error: display already enabled
<4>omap_vout omap_vout: 'dvi' Display already enabled
<3>omapdss DPI error: display already enabled
<4>omap_vout omap_vout: 'dvi' Display already enabled
<6>omap_vout omap_vout: Buffer Size = 3686400
<6>omap_vout omap_vout: : registered and initialized video device 0
<6>omap_vout omap_vout: Buffer Size = 3686400
<6>omap_vout omap_vout: : registered and initialized video device 1

どうだ?

そうそう、こちらのパッチも当ててみたけど、やはりだめでした。
https://groups.google.com/forum/?hl=ja#!topic/android-kernel/XTqkkBxRmjI