連載
» 2011年12月12日 12時05分 UPDATE

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

KGDBを使ってAndroid搭載の組み込みボードをリモートデバッグする。【後編】第1弾の今回は、リモートデバッグする上で欠かせない通信インフラの検討を行い、ホストPC上でカーネルの再構築をする方法を解説。

[中垣内勇祐、森崇、中谷洋一(永和システムマネジメント),@IT MONOist]

はじめに

 前回は少し横道にそれて、「KGDB(Kernel Gnu DeBugger)」の仕組みについて解説しましたが、今回はLinuxマシン上からリモートでAndroidを搭載した組み込みボードをデバッグできるようにしていきたいと思います。

 ただし、本連載で使用しているボードは、あくまでもデモ用のものですので、デバッグに必要となる環境一式が用意されているわけではありません。つまり、必要なものは全て自分で調達していかなければならないわけです。

 特に、本ボードをデバッグする上で大きな難点があります。通常、KGDBでのデバッグをする場合は、ターゲットボードとホストPCとの間の通信にはシリアルケーブルを使います。しかし、このボードにはシリアルケーブルの端子は1つしかありません。シリアルケーブルはコンソールで利用するので、このケーブルを使ってしまうとコンソールが使えなくなってしまいます。

 このような問題をはじめ、本ボードをリモートデバッグするためには、さまざまな問題に立ち向かわなければなりません。今回から3回にわたり、それら内容について詳しく見ていきたいと思います。

  • 第1回:通信インフラを検討し、KGDBを組み込んだカーネルを再構築する
  • 第2回:USBデバイスドライバを作成する
  • 第3回:ターゲットボードのカーネルを変更し、グラフィカルなデバッガでデバッグする

 第1回目となる今回は、リモートデバッグする上で欠かせない通信インフラの検討を行い、ホストPC上でカーネルの再構築をする方法を解説します。

通信インフラを検討する

 ターゲットボードをリモートデバッグする上で、以下の2つの通信インフラについて検討を進める必要があります。

  1. KGDBを組み込んだカーネルイメージをターゲットボードに転送するための通信インフラ
  2. ターゲットボードとホストPC間の通信データを転送するための通信インフラ
通信インフラを検討する

 これら通信インフラを検討する上で、ターゲットボード側で使用できる通信用のインタフェースを整理しておきましょう。通信インタフェースは以下のように全部で3種類ありますので、これらの通信インフラを用途に応じて取捨選択していきます。

  1. シリアルインタフェース
  2. LAN
  3. USB(注1)
ターゲットボード側で使用できる通信用のインタフェース
※注1:USBのインタフェースとしては、ホストとデバイスがありますが、ホストの方は使用できません。理由は、PC側にUSBデバイスのインタフェースがないためです。


カーネルイメージ転送の通信インフラを検討する

 ホストPCからターゲットボードにカーネルイメージを転送するには、本ボードのブートローダー(U-Boot)を使用する必要があります。U-Bootには、ファイルデータ転送用のコマンドが標準で用意されており、主に以下のものがあります。

  1. LAN経由(NFSプロトコル)
  2. LAN経由(TFTPプロトコル)
  3. シリアル経由

 ただ、今回使用しているU-BootにはUSBプロトコルでのデータ転送機能もあります。この機能は、いわゆるUSBデバイスとしての機能であり、Android USBガジェットを勉強する上で大変参考になると思いますので、この方法を採用することにしました。

 本ボードに組み込まれているソースには、U-Bootのソースコード(ut6410-uboot-v2.0-20101004.tgz)が同梱されていますので、U-Boot USBデバイスの仕様を確認できます。後は、そのUSBデバイス仕様に準拠したホスト側(Linux)のUSBデバイスドライバがあれば、カーネルイメージを転送できるようになるわけです。

 よって、大変回り道となりますが、Linux USBデバイスドライバを作成してから転送するようにしたいと思います。その内容の詳細は次回以降でさせていただきます。

リモートデバッグの通信インフラを検討する

 ホストPCとターゲットボードとのKGDBデータ転送用の通信インフラについて検討を進めます。KGDBはオープンソースとして公開されており、世界中で使われていますので、まずはいろいろとググって(調査して)みました。すると、以下のWebサイト(http://bootloader.wikidot.com/android:kgdb)に行き着きました。


 このWebサイトを参考にすると、現状KGDBの通信手段として以下の3つがあるようです。どれも本ボードに搭載されているのでまずは一安心です。

  1. シリアル通信
  2. USB通信
  3. イーサーネット通信

 それでは1つずつ検討していきましょう。

1.シリアル通信 
シリアル通信はKGDBでは広く普及しており、本ボードに組み込まれているAndroidカーネルソースにもそのドライバが標準で組み込まれています。ただ、前述の通り、シリアル通信路はコンソールで使いますので、残念ですが使用できません。

2.USB通信 
USB通信は非常に魅力的ですね。上記Webサイトで紹介されている通り、通常シリアルやイーサーネットがAndroid端末にあることはほとんどありません。ですが、USB端子はホストPCとの通信路として標準で搭載されていますので優位性があるといえます。とはいえ、今回のデバッグ対象はUSBモジュールであり、この通信路を使うとUSBガジェットドライバのデバッグができませんので、大変魅力的ではありますが……断念せざるを得ません。

3.イーサーネット通信 
最後に残ったイーサーネットですが、本ボードにはLAN端子があり、そのドライバソース(KGDB over Ethernet)もネット上で出回っていますので、本ボードのカーネルソースに組み込めるはずです。

 以上の理由から、今回はLAN端子を使ってリモートデバッグしていくことにします。

       1|2 次のページへ

Copyright© 2017 ITmedia, Inc. All Rights Reserved.