KGDBを使って、Android組み込みボードをリモートデバッグしよう！【後編】〜USBガジェットドライバをデバッグする（2）〜：実践しながら学ぶ Android USBガジェットの仕組み（4）（2/3 ページ）

KGDBを使ってAndroid搭載の組み込みボードをリモートデバッグする。【後編】第2弾の今回は、再構築したカーネルイメージをターゲットボードにUSB転送するために必要となる“USBデバイスドライバの作成方法”について解説する。

[中垣内勇祐、森崇、中谷洋一（永和システムマネジメント），＠IT MONOist]

　それでは、先ほど持ち越していた「USBコアがUSBデバイスドライバに何を望んでいるのか」を少しずつ紐解いていきましょう。

　USBコアには、エニュメレーションという大変重要な役割を担う機能があります。USBデバイスがホストPCに接続されたときに、USBコアは自動的にUSBデバイスと情報をやりとりし、接続されたデバイスを扱えるUSBデバイスドライバを検索してから、USBデバイスを使用可能な状態にします。

　USBデバイスドライバを検索する際は、登録されているドライバに対し、接続されたデバイスを扱えるかどうかを問い合わせます。そのため、ドライバ側では自分が担当するものであるかどうかをUSBコアに応える必要があります（要件：（3））。

　ドライバ側で「それは自分のもの！」と応えた場合、USBコアはそのドライバに対してUSBデバイスの登録を依頼し、USBデバイスドライバ側では自分が扱うデバイス情報を登録する必要があります（要件：（4））。そして、このタイミングでユーザーに対してデバイスファイルを作成し、使用できるようにしてあげます（図5）。

図5　USB接続時にデバイスファイルを作成する

　最後に、USBコアはUSBデバイスの切断を検出すると、USBドライバに対してUSBデバイスの登録解除を依頼します。よって、USBデバイスドライバ側では、登録していたデバイス情報を解除する必要があります（要件：（5））。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

USBデバイスの仕様は？

　デバイスをUSB接続すると、USBコアは各USBデバイスドライバに対して「これはあなたのもの？」と問い合わせを行います。そのため、USBデバイスドライバとしては、自分が担当するデバイスの仕様を把握しておく必要があります。

　通常、デバイスの仕様を調べるにはマニュアルを紐解いていけばよいわけですが、残念なことにそのあたりの仕様が詳細に書かれているものは見当たりませんでした。ただ、幸いなことに、本ボードに組み込まれている「U-Boot」のソースはあるので、ソースを読み解けば仕様が見えてきます。

　ちなみに、ブートローダーはシングルタスクであるため、処理の流れを捉えやすい（読み解きやすい）と思います。興味のある方はぜひソースを読解してみてください。コントローラの操作方法がよく分かると思います（注3）。

　余談はさておき、USBデバイスとしての仕様は以下の通りでした。

図6　USBデバイス情報

※注3：これは、今後、Androidのソースを読み解くときにとても強力な手掛かりとなるでしょう。

　この内容から、USBデバイスのインタフェースが“1つ”定義されていることが分かります。ここでいうインタフェースとは“USBの機能”を表します。代表的な例でいうと、マウスやキーボードなどです。これらUSB機能を実現するには、USBデバイスとの通信が必要となりますので、その通信情報を「エンドポイント」として定義します。エンドポイントには、データ転送方向と転送方式などが定義されています。

　本デバイスの場合は、転送方向は「IN／OUT」（注4）両方向が定義されており、今回の場合は、ホストからデバイス方向なので「OUT」だけを使用します。また、転送方式には大量のデータを欠損なく転送するのに適したバルク転送であるため、今回の要件を満たしています。

※注4：IN／OUTは、ホストから見た方向であり、ホストからデバイスへデータ転送する場合は「OUT」、デバイスからホストへデータ転送する場合は「IN」となります。