2007年12月26日水曜日

USBアナライザとD02HW

「NetBSDでD02HWをつかう」では比較的(というかほぼ全部)試行錯誤でデバイスの設定に必要な条件を推測してデバイスドライバへのパッチを作成した。ハードウェアを触るときによく感じることは「見えないものはわからない」ということだ。当たり前のことだが、電気信号は眼にはみえないので、推測するしかなくそれはいつまでも推測のままで推移してしまう。電圧を測るのにテスターが必要で、時間ドメインの波形をみるのにオシロスコープが必要なように、扱う事象を見るための専用の「アナライザ」が必要になることは多い。実はとある目的のためにUSBバスアナライザが手元にあったので、D02HWのデバイスドライバ作成作業を検証してみることにした。

手元にあるのはellisysUSB Explorer 200だ。これは、USB2.0のHighSpeed(480Mbps)に対応したアナライザで、Windowsソフトウェアと組み合わせることでだいたいすべてのUSBイベントを表示してくれる、という便利な逸品である。ソフトウェアは誰でもダウンロードできるようになっていて、USBバスのキャプチャファイルを入手したときに誰でも表示できるのがうれしい(ちなみにキャプチャファイルの拡張子はUFOだ)。
写真でわかるように、アナライザを解析ソフトが入っているPCにつなげて、デバイスとデバイスをつなげるホストの間にはさむようにアナライザを配置する。これで、デバイスとホスト間のデータをインターセプトするという仕組みになっている。
まず、Windowsで動かしてみたときにUSBバスにどんなトランザクションが発生しているかを見てみた。
NetBSDでEmobile D02HWを使う(3)」にあるUSBのインターフェイスとエンドポイントの情報を見ながら、どのエンドポイントとホストがどんな通信をしているかを眺めてみる。アナライザは、

たとえばこんな情報が表示されて、トランザクションのタイプと中身のデコード結果をだしてくれるので、それとUSB2.0の仕様書(このへんにある)を眺めながら追っていく。赤裸々にどんなトランザクションをやりとりしているかを見ていてわかったことは以下の3つ。

  • NetBSDにつくったパッチは正しい。
  • ATコマンドいろいろ
  • D02HWは実はさらに別のインターフェイスをもっている。
最初のは、結局あのシーケンスを送らないとデバイスは言うことをきいてくれないみたいだ、ということを追認できたということだ。ちゃんとUSB2.0の仕様書を読み込むと、あのメッセージは
  • デバイスへのスタンダードのリクエスト(SET_FEATURE)でHost→Device
  • リクエストタイプはDEVICE_REMOTE_WAKEUP
  • wIndexの0x2はendpoint2を意味する
ということだった。アナライザでの結果をみるとendpoint2はモデムの主通信用のパイプなので、これで意味がわかってすっきりした。
2つめのATコマンドいろいろはたぶんWindowsとかのモデム定義ファイルをみればわかる情報なので大した追加情報ではない。問題は3つめで、確かに「NetBSDでEmobile D02HWを使う(3)」では、モデムとして認識されるようになると3つのインターフェイスディスクリプタが見えている。ひとつはモデムでひとつはUSBストレージデバイスだ、ということもわかっていたが、実はなぜもうひとつみえるのか、は謎のまま残っていた。まだ実際にコードを書いて叩いてみたわけではないのだが、USBのBUSトランザクションを見る限り、

INTERFACE descriptor 1:
bLength=9 bDescriptorType=interface(4) bInterfaceNumber=1 bAlternateSetting=0
bNumEndpoints=2 bInterfaceClass=255 bInterfaceSubClass=255
bInterfaceProtocol=255 iInterface=3(Data Interface)

ENDPOINT descriptor:
bLength=7 bDescriptorType=endpoint(5) bEndpointAddress=5-in
bmAttributes=bulk wMaxPacketSize=64 bInterval=0

ENDPOINT descriptor:
bLength=7 bDescriptorType=endpoint(5) bEndpointAddress=5-out
bmAttributes=bulk wMaxPacketSize=64 bInterval=0

のendpoint5はもう一本のモデム制御用のパイプらしい。まだ憶測だが、endpoint2でデータ通信しながらでもモデムが管理しているHSDPA由来の制御情報などを並列してとれるのではないかと予想している。これを扱うデバイスドライバかくのはどうしたもんか、と悩みがふえてしまった(しばらくはきっとやらないけどね)。

(12/28追記:実験してみたらモデムモードに入った後は3本ともシリアルらしい。2本目をはやすハックをしてみた、あとで詳しく書く予定)
(12/30追記:やっぱり3本目はusb mass strageだとおもうなあ。コードかいてみるか。。)
(1/4追記:usb mass strageでした。)

というわけで、アナライザを使うとみたいことも見えるけど、まったく気が付いていなかったようなことも見えてしまう、ってことで。今回はおしまい。

2 件のコメント:

shigeya さんのコメント...

これ、Windowsのデバドラのトランザクションとは一致しているってことですか?

yuo さんのコメント...

大枠としては一致しています。不明なベンダスペシフィックなリクエストも4種類ほど観測されているんですが、なにしているかは不明。実際に発行してみないとわからないですね。