KGDBを使ってAndroid搭載の組み込みボードをリモートデバッグする。【後編】第2弾の今回は、再構築したカーネルイメージをターゲットボードにUSB転送するために必要となる“USBデバイスドライバの作成方法”について解説する。
前回は、ターゲットボードをリモートデバッグするために、通信インフラの検討を行いました。
ターゲットボードをリモートデバッグできるようにするには、ボード上のカーネルを、「KGDB(Kernel Gnu DeBugger)」を組み込んだものに変更する必要があります。
そのための手順(図1)は、以下の通りであり、今回は「USBデバイスドライバを作成する」について解説します。
ターゲットボードにカーネルイメージをUSBで転送するには、ホストPC側に専用のUSBデバイスドライバが必要となります。
これから、USBデバイスドライバを作成していくに当たり、LinuxカーネルのUSBアーキテクチャを紐解(ひもと)いてみたいと思います。
Linuxは汎用OSであるため、USBのデータ転送に必要となる全ての処理を実装する必要はありません。LinuxカーネルのUSBアーキテクチャは図2に示すように、3層構造になっているため、ユーザー層に一番近い「USBデバイスドライバ」層の機能だけを実装すればよいことになります。
「USBコア」層は、USBの重要な機能である「エニュメレーション機能」(注1)や、USB通信に関する機能を提供しており、USBの複雑なプロトコル操作を吸収してくれています。また、USBデバイスと実際に通信するUSBホストコントローラのハードウェア操作は「USBホストコントローラドライバ」層が担当してくれますので、USBデバイスドライバはホストコントローラのハードウェア仕様を意識する必要はありません。
Linuxの場合、USBデバイスドライバの機能実装は非常に容易です。ただ、LinuxのUSBドライバの実装方法(ソースコード)をいきなり説明してしまうと、「この構造体は何のために必要なの?」「この関数は何をするものなの?」など、戸惑ってしまうことが多いと思います。少なくとも筆者はそのような経験を何度もしたことがありましたので、ここではユーザー視点に立って、できるだけ分かりやすく説明していきたいと思います。
図3は、USBデバイスドライバとして実現すべき要件をまとめたものです。
まず、ユーザーがUSBデバイスドライバに対して行う操作としては、自作ドライバをLinuxに登録/解除することです(要件:(1))。さらに、今回の要件としては、ターゲットボードにカーネルイメージをデータ転送することです(要件:(2))。
まぁ、ここまでは単純な話ですよね。それでは、さらに“もう一歩”話を進めていきましょう。
自作ドライバを登録/解除するといっても、どうやったらよいのでしょうか? それには、「insmod/rmmod」というLinuxに標準で組み込まれているコマンドを利用します。よって、自作ドライバを登録する際は、コマンドの引数にドライバモジュールを渡すだけで済みます。では、そのドライバモジュールには、どんな情報や処理を実装すればよいのでしょうか? この点については、「USBコアがUSBデバイスドライバに何を望んでいるのか」を把握しないと何とも分からないことですので、後ほど詳しく説明したいと思います。
ホストPC(Linux)上にあるカーネルイメージを、ターゲットボードに転送するためには、Linux上にある何らかの「データ転送用のインタフェース」を利用する必要があります。さらに、その転送途中でデータが失われてしまわないような「データ転送方式」を考える必要があります。
まず、データ転送用のインタフェースとして、Linuxでは「デバイスファイル」というものがあります。Linuxは何でもファイルで管理しており、デバイスに対する操作もファイルに対して行います(注2)。USBデバイスもその例外ではなく、USBデバイスファイルを作って、そのファイルをオープンし、カーネルイメージをデータとして書き込むことでターゲットボードに転送できます(図4)。
次に、データ転送方式ですが、これはUSBの転送方式を紐解くと、データの欠損なく通信してくれるものとして、「USBバルク転送方式」がありますのでこれを利用します。
では、「そのデバイスファイルをどうやって作ればよいのでしょうか?」、また、そのデバイスファイルの書き込み処理である「USBバルク転送方式をどうやって実現すればよいのでしょうか?」……といったことを、さらに考えなければなりませんが、この点はもう少し後に紹介します。
Copyright © ITmedia, Inc. All Rights Reserved.