2010年12月02日
ET2010でライブデバッグしてます。
2010年12月1から12月3日まで横浜パシフィコで開催されているET2010に出展しています。
ブース番号は A-13 です。
ブースの左端で、ノートパソコンの画面を大画面テレビに映して、Andorid対応のPARTNER-JetによるKZM-A9-Dualボードのデバッグの実演をしています。(下の写真の手前の部分。）
主なトピックは
(1) NDKのサンプルのSanAngelsのデバッグ。
(2) カーネル内の関数にブレークポイント。
(3) ユーザーモードの最初のプロセスであるinitのデバッグ。
(4) Linux動作中に物理アドレスでI/Oポートのアドレスを指定してPARTNER-Jetから読み書き。
(1) NDKのサンプルのSanAngelsのデバッグ
以前のABCなどで見せているものと同じものです。
NDKのプログラムのJavaの部分は通常のEclipse JDTの使用方法でデバッグできますが、NDKのネイティブメソッドの部分は追いかけることができません。そこでネイティブメソッドの部分はPARTNER-Jetでブレークポイントをかけて追いかけます。ソースコードがあれば、NDKのダイナミックリンクライブラリの部分だけでなく、OpenGLのシステムライブラリやDalvikVMの中まで追いかけていくことができます。
(2) カーネル内の関数にブレークポイント
(1)はユーザー空間のダイナミックリンクライブラリがデバッグ対象でしたが、カーネル空間もデバッグすることができます。forkシステムコールやexecveシステムコールの実体であるdo_forkやdo_execveにブレークポイントをかけてみます。
Androidのメニューを操作すると、新しいJavaアプリを起動するときにforkシステムコールは呼ばれていますが、execveシステムコールは呼ばれていないことが確認できます。
シリアルコンソールのshellからlsコマンドを実行するとdo_exeveでブレークするのでexecveシステムコールが呼ばれたことがわかります。また、その時の第一引数のfilenameが"/system/bin/ls" なので、それが確かにlsコマンドによるexexveであったことが確認できます。
(3) ユーザーモードの最初のプロセスであるinitのデバッグ
ユーザープロセスはgdbでもデバッグすることができますが、一番最初に実行されるユーザープロセスのinitの最初の部分からデバッグしようとすると、かなりトリッキーなことしなければできません。
PARTNER-Jetでは簡単にinitプロセスのmain関数でブレークさせることができます。
(4) Linux動作中に物理アドレスでI/Oポートのアドレスを指定してPARTNER-Jetから読み書き
EMMA-Moible EV/2 もそうですが、最近のSoC(System on Chip)はGPIOを正しく設定したかどうかがカーネルの移植のひとつのポイントになります。（少なくとも私がKZM-A9-DualにLinuxカーネルを移植したときにはうまく動かないときの原因の多くはGPIO関連の設定の漏れや誤りでした。）
チップの仕様書に書いてあるI/Oポートのアドレスは物理アドレスです。Linuxカーネルが動作し始めると全てのメモリアクセスは仮想アドレスになります。
PARTNER-Jetを使うと物理アドレスでI/Oポートのアドレスを指定して読み書きすることができます。
簡単な例ですが、ボード上のpushボタンの状態をPARTNER-Jetを使ってI/Oポートの値を確認してみました。
