なぜGIOChannelを使うのか

GTK+でGUIアプリケーションを書くと、プログラムは基本的にイベントドリブンになります。つまり、メインループの中でイベントが起きるのを黙って待って、何か起きたらコールバックの中で処理します。こうしたフレームワークではファイルやソケットの読み書きでブロックされる(待ちが発生する) のは嬉しくありません。ブロックされている間は基本的に他の処理ができず、たとえば処理中のアニメーションが止まったりします。GIOchannelを使えば、ブロックされない状態になってから処理を開始することができます。

なお、今回はあまり関係ありませんが、テキストのエンコーディングを適当にUTF-8に変換してくれる機能もあります。

GIOChannelの使い方

• g_io_channel_unix_newで生成 (unix系のシステムを想定しています……)
• NONBLOCKに設定する (設定しないとG_IO_STATUS_AGAINが返るかわりにブロックされます)
• g_io_add_watchでイベントソースをデフォルトメインループに追加
  (頻繁に掛け外しをする場合は、g_io_create_watchで作ったイベントソースを自分で扱った方がいいかも知れません)
• コールバック
  • どんなイベントが起きたのか、GIOConditionを見て判断する
  • GIOChannelを読み書きしてG_IO_STATUS_NORMALやG_IO_STATUS_AGAINが返ってきたらTRUEを返す
    G_IO_STATUS_EOFやG_IO_STATUS_ERRORが返ってきたらFALSEを返してイベントソースを外す

読み込みサンプル

標準入力から読み込んでg_messageでメッセージを表示するサンプルです:

#include <glib.h>
static gboolean read_callback(GIOChannel *io, GIOCondition cond, gpointer user_data) {
  GMainLoop *loop = user_data;
  gboolean continue_to_watch = FALSE;
  if (cond & G_IO_IN) {
    GError *e = NULL;
    char *text;
    switch (g_io_channel_read_line(io, &text, NULL, NULL, &e)) {
    case G_IO_STATUS_NORMAL:
      g_message("%s: read line: %s", __func__, text);
      g_free(text);
      continue_to_watch = TRUE;
      break;
    case G_IO_STATUS_AGAIN:
      g_message("%s: AGAIN", __func__);
      continue_to_watch = TRUE;
      break;
    case G_IO_STATUS_ERROR:
      g_message("%s: error: %s", __func__, e->message);
      g_error_free(e);
      break;
    case G_IO_STATUS_EOF:
      g_message("%s: EOF", __func__);
      break;
    default:
      break;
    }
  }
  if (! continue_to_watch) {
    g_main_loop_quit(loop);
    g_main_loop_unref(loop);
  }
  return continue_to_watch;
}

static void sample_loop(int fd, GIOCondition cond, GIOFunc callback) {
  GMainLoop *loop = g_main_loop_new(NULL, FALSE);
  GIOChannel *io = g_io_channel_unix_new(fd);
  guint tag = g_io_add_watch(io, cond, callback, g_main_loop_ref(loop));
  g_io_channel_set_flags(io, G_IO_FLAG_NONBLOCK, NULL);
  g_io_channel_set_close_on_unref(io, TRUE);
  g_io_channel_set_encoding(io, NULL, NULL);
  g_main_loop_run(loop);
  g_io_channel_unref(io);
  g_main_loop_unref(loop);
}

int main(int argc, char *argv[]) {
  sample_loop(0, G_IO_IN, read_callback);
  return 0;
}

G_IO_INは読み込み可能を示すフラグです (読み込み専用のfdについてはこのフラグしか立たないようです――man poll参照)。ただし、読み込み可能と言っても、読んでみたらすぐにG_IO_STATUS_EOFが返ってくることもあります。EOFが返ってきたらもうチャンネルに用はないのでFALSEを返してイベントソースを外します。

書き込みサンプル

標準出力 (のバッファ) が書き込み可能になるのを待って書き込みまくるサンプルです。なおsample_loop関数は前節の関数をそのままコピーして使ってください。実行すると大量のメッセージが出力されますから、

./sample | read i

などとして、パイプが適当に閉じられるようにして実行してください:

#include <glib.h>
static gboolean write_callback(GIOChannel *io, GIOCondition cond, gpointer user_data) {
  GMainLoop *loop = user_data;
  gboolean continue_to_watch = FALSE;
  if (cond & (G_IO_ERR | G_IO_HUP))
    g_message("%s: channel is closed", __func__);
  else if (cond & G_IO_OUT) {
    GError *e = NULL;
    char *text = "BABEL\n";
    int len;
    switch (g_io_channel_write_chars(io, text, -1, &len, &e)) {
    case G_IO_STATUS_NORMAL:
      g_message("%s: wrote %d chars", __func__, len);
      continue_to_watch = TRUE;
      break;
    case G_IO_STATUS_AGAIN:
      g_message("%s: wrote %d chars, AGAIN", __func__, len);
      continue_to_watch = TRUE;
      break;
    case G_IO_STATUS_ERROR:
      g_message("%s: error: %s", __func__, e->message);
      g_error_free(e);
      break;
    case G_IO_STATUS_EOF:
      g_message("%s: EOF", __func__);
      break;
    default:
      break;
    }
  }
  if (! continue_to_watch) {
    g_main_loop_quit(loop);
    g_main_loop_unref(loop);
  }
  return continue_to_watch;
}

int main(int argc, char *argv[]) {
  sample_loop(1, G_IO_OUT | G_IO_ERR | G_IO_HUP, write_callback);
  return 0;
}

チャンネルが閉じられるとコンディションにG_IO_ERRのビットが立ちます。同時にG_IO_OUTビットが立つこともありますが、それは単にバッファに空きがあるというだけで、書き込んでも誰も見てくれないので無視するようにしました。

またg_io_channel_write_charsでは、本来は書き込まれたバイト数もチェックしなければならないのですが、長いデータを書き込まなければ途中で切れることはないようなので、今回はチェックしていません。

読み書き用の場合

ソケットは読み書き両用なので、必要なら読み書き両用のコールバックを書くことができます。そのときは上記のread_callback関数とwrite_callback関数を適当に結合させればいいでしょう。なお、ソケットの相手側が閉じられていても (コンディションにG_IO_ERRビットが立っていても)、バッファに読み込み可能なデータが残っていることがあります。プロトコルによりますが、必要ならG_IO_INビットをチェックしてG_IO_STATUS_EOFが返ってくるまで読み出してやることもできます。

おわり

GIOChannelを使えば、GLibのメインイベントループの中で、ブロックされることなく入出力を処理することができます。イベントドリブンなアプリケーションを書くために是非とも使い方を把握しておきたいものです。

Happy hacking!

※一応、使っているのはMSP430F247であると断わっておきます。

MSP430には二つのタイマが入っていて、PWMを自動で (CPUが割り込みの中で操作しなくても) やってくれます。今回は普通にタイマでPWMをする方法を紹介し、さらに頑張って普通はPWMに使えないポートでも半自動でPWMをやってみたいと思います。

タイマの概要 (コンペアモード)

タイマにはタイマレジスタとキャプチャ・コンペアブロック0から2 (もしくは0から7) があり、大体以下のように動作します:

• タイマレジスタ
  • 値が0になるときに割り込みを発生させる (オーバーフロー割り込み)
  • タイマAでは16ビット幅で固定、タイマBでは16/12/10/8ビット幅で可変
  • 三つのタイマモード
    • ビット幅全てを使ってカウントアップ (連続モード)
    • コンペアレジスタ0の値までカウントアップ (アップモード)
    • コンペアレジスタ0の値までカウントアップ、さらに0までカウントダウン (アップダウンモード)
• キャプチャ・コンペアブロック
  • キャプチャ・コンペアレジスタ (コンペアレジスタと略します) と出力ビットがある
  • コンペアレジスタの値がタイマレジスタの値と等しくなるとき割り込み (コンペア割り込み)
  • 同時に出力ビットをセット・リセットする
• キャプチャ・コンペアブロック (0以外)
  • タイマレジスタの値がコンペアレジスタ0の値と等しくなるときに (すなわちコンペア割り込み0のタイミングで)、出力ビットをセット・リセット・トグルする (出力モードによる)

キャプチャ・コンペアブロック (0以外) には、出力ビットの変化するタイミングが

• 自分のコンペア割り込み
• ブロック0のコンペア割り込み

の二つあることに気づかれましたか。変化のタイミングが二つあるので、各ブロックごとに異なったデューティー比のPWM出力ができるわけです。つまり、普通のPWMとしての使い方は次のようです:

• アップモード
• コンペアレジスタ0: 変調周波数を決める
• コンペアレジスタ0以外: デューティー比を決め、適当な出力モードでPWM出力

キャプチャ・コンペアブロック0でもPWM

上記のような特性から、ブロック0ではPWM出力はできません (パルス幅が0固定のPWMと言えなくもないのですが)。かといって、連続モードに設定して、割り込みが発生するたびにコンペアレジスタを設定しながらGPIOを叩くのもやや無駄な話です。そういうのは各ブロックで別々の割り込み周期を使いたい場合にすることです。もうちょっとCPUがサボりながらPWM出力をする方法があります。ハードウェアに足りない機能だけ、ソフトウェアで実現するべきです。

PWMのキモはこの特徴です:

コンペア割り込みのタイミングで出力ビットをセット・リセット・反転

これでデューティー比が決まるわけです。この特徴は全てのキャプチャ・コンペアブロックに存在します。活用しましょう。ただし、キャプチャ・コンペアブロック0で活用するには、連続モードにしなければいけません。代償として変調周波数は自由に設定できなくなります。

一方、キャプチャ・コンペアブロック0には、この機能がありません:

ブロック0のコンペア割り込みタイミングで出力ビットをセット・リセットする

当然ですね。この部分をオーバーフロー割り込みのタイミングでソフトウェアで処理すれば、キャプチャ・コンペアブロック0でもPWMができます。つまりオーバーフロー割り込みで、出力ビットを0または1に設定すればいいのです。

なお、出力ビットは、通常の出力モードでは値を設定できません。手動設定のモードに切り替えてから設定し、また通常のモードに戻すことになります。なかなか普通じゃない感があります。

そして自由な変調周波数

先に、「代償として変調周波数は自由に設定できなくなります」と書きましたが、自由にする方法が無いわけではありません。というのは、タイマAのタイマレジスタはビット幅が16ビット固定で、連続モードに設定すると周期がかなり長くなってしまうのです。通常の1MHzのクロックだとおよそ16Hz、8MHzのクロックを使ってもおよそ128Hzです。省電力な低速クロックではさらに遅くなりますし、そもそも16HzなんてPWMでLEDを光らせるには遅すぎます。

解決方法は簡単で、周期を短くしたければ、オーバーフロー割り込みの中でタイマレジスタの値を適当に大きくすればいいのです。例えば、0xff00を代入すれば、カウンタは8ビット幅になったも同然。こうして自由な変調周波数を手に入れることができます。コンペアレジスタの値も対応する値にしておきましょう。

まとめ

まとめると次のようにタイマを設定することになります:

• 初期設定
  • 連続モード
  • コンペアレジスタ0にデューティー比を設定 (必要なら、(0×10000 – 周期 + デューティー比) の値にする)
  • 出力モードはトグル
• オーバーフロー割り込み
  • 出力モードを手動に設定し、出力ビットを0 (ないし1) に初期化
  • 出力モードをトグルに設定し直す
  • 必要ならタイマレジスタの値を (0×10000 – 周期) の値に設定し直す

ちなみに、タイマのクロックがCPUのクロックと同期していない場合についてデータシートには色々と注意書きがありますが、今回のような使い方では特に気にするべきことはないようです。

おしまい

実は事の発端はタイマBの出力0にLEDをつなげてしまったことだったりします。プリント基板を作る前にチップの仕様をよく確認しないと、ソフトにしわ寄せがくるようですね (寄せることができるともいう)。
ともあれ、Happy hacking!

異なるビット

二つのビット列のうち、ビットの異なる位置を抽出することは簡単です。基本です:

d = a ^ b;

ビットを数える

あとはここから立っているビットを数えるわけですが、普通に考えると

• ビット列の幅の分だけループさせる
• プロセッサのビットサーチ命令を使う

という方法を使うと思います。前者は当然遅いので嫌ですね。後者はインラインアセンブラを使ってプロセッサ依存にしないといけませんし、ビットマスクを作ってビットを消しながら数えなくてはならず、いかにも面倒です (←根拠もなくシフト命令は遅いと思っているヤツ)。

そこで私が使う方法は次のようなものです:

d &= d - 1; // 立っている最下位ビットを消す

全ビットが消えるまでループすればハミング距離が分かります:

d = a ^ b;
i = 0
while (d) {
  d &= d - 1;
  i++;
}

おしまい

このコードを何に使うのかというと、BCH(15,5)符号などをパターンマッチングで誤り訂正しようということだったりします。15ビットもあるのに内容は5ビット(32パターン)しかないので、ハミング距離が一番小さい符号語が訂正結果ということにした方が簡単なのではないかというわけです。別にガロア体がよく分からんとかそういう理由ではないんですよ。
Happy hacking!

電源回路の基本の基本

よく使用される電源回路はDC/DCコンバータという回路です。
この回路を使うことで、例えばリチウムイオンバッテリの電圧である+3.7Vから内部回路の動作に必要な各種電圧を生成するわけです。
DC/DCコンバータの実際の動作としては電力変換を行うのですが、残念ながら100%変換されるわけじゃありません。
性能としては変換時の「効率」が重要になります。ちなみに変換できなかった電力は…熱に変換されますw
では、実際の回路を見てみます。

DM355EVMの電源回路

実際に自分たちが使用しているCPUであるDM355に関する例を紹介してみます。
まずはDM355の評価ボードであるDM355EVMを見てみます。
DM355EVMの回路図は http://c6000.spectrumdigital.com/evmdm355/reve/files/EVMDM355_Schematics_RevE.pdf からDLできます。
P.25-26がDM355の電源回路部分になります。使用しているチップは TPS54310 ですね。
このチップのデータシート http://focus.tij.co.jp/jp/lit/ds/symlink/tps54310.pdf をちょっと見てみます。
まずはP.1にある「効率 対 負荷電流」のグラフを見てみます。
内部回路、この場合はDM355に対して、出力電圧+3.3Vで1Aの電流が流れた場合(つまりDM355に3.3Wの電力を供給した場合)に約93%ぐらいの効率であることが読み取れます。なかなか優秀ですね。
でも、DM355は省電力モードのあるCPUです。
例えば、省電力モードになって+3.3Vで1mAの負荷電流となった(つまりDM355に3.3mWの電力だけを供給することでよくなった)場合に、効率はどうなるか…もう少しデータシートを読み漁ってみましょう。
P.10に特性グラフが出てきました。図12に注目してください。
何と、負荷電流が200mAぐらいのところを境にして、急激に効率が65%程度まで低下しているじゃないですか！
この回路では省電力モード時に約35%の電力が電源チップで熱となって消費されてしまいます。
というか、このEVMでは残念ながら省電力モードの評価や実験はできないですねw

Leopard Boardの電源回路

DM355が載っているボードとして、最近一部で話題のLeopard Boardがあります。
このボードはカメラ付きで$99と評価ボードとしては破格の価格のボードです。
早速、回路図を見てみましょう。回路図は http://www.leopardboard.org/uploads/DM355_LEOPARD_BOARD.pdf からDLできます。
P.13が電源回路になります。Leopard BoardではDM355EVMとは違って、電源統合チップ TPS65053 が使用されていますね。どうりで安いわけですね(ぉ
さてさて、どんな性能でしょうか…データシート http://focus.tij.co.jp/jp/lit/ds/symlink/tps65053.pdf を見てみましょう。
データシートのP.1には大体そのチップのFEATUREが書いてありますが、いきなり “Up To 95% Efficiency” と書いてありますね。期待できそうです。
問題は省電力モードになったとき、つまり低負荷時の効率です。
P.7のFigure1, Figure2に注目です。
どちらも効率と負荷電流の関係を表していますが、Figure1のほうが負荷電流が0.001A=1mAのときでも効率が90%程度を維持しています。
違いは何かというと、Figure1が”PWM/PFM Mode”なのに対して、Figure2が”PWM Mode”オンリーなことです。
このモードをどう切り替えるか、それもデータシートに書いてあります。
P.5に TPS65053 の各ピン毎の機能が “TERMINAL FUNCTIONS” にまとめられていますが、その中のMODEピンが該当します。

Select between Power Save Mode and forced PWM Mode for DCDC1 and DCDC2.
In Power Save Mode, PFM is used at light loads, PWM for higher loads.
If PIN is set to high level, forced PWM Mode is selected.
If Pin has low level, then the device operates in Power Save Mode.

つまり、通常時はMODEピンをHighにしておいて、DM355が省電力モードになるときにはLowにしてあげるとバッテリが効率良く使えますね。
電源回路はこうじゃないといけないです。

電源回路のポイントとまとめ

バッテリ動作するようなモバイル機器の電源回路は、とにかく高効率であることが重要です。
しかも、ON/OFFできるだけじゃなく、電源回路自体がパワーセーブモードを持つものじゃないと長生きできません。
今回はDM355の省電力モードと絡めて電源回路を紹介しましたが、Linuxが動作しているようなCPUが実際に省電力モードになるまでの動作に興味をもたれる方もいると思いますので、次回はその辺の具体例を紹介する予定です。

背景色を正しく設定する

ウィジェットのある部分についてexposeイベント (ひらたく言えば描画イベント) が発生すると、当該部分が背景色で塗り潰されてからexposeハンドラが呼ばれます。ここを別な色で塗り直すのは当然無駄なわけで、ウィジェットの生涯を通じて最も描画面積の大きい色を背景色として設定しておけば、描画処理は軽くなるでしょう。

クリッピングする

ウィジェットの重なりが変更されたり、GtkLabelなどの自分のGdkWindowを持たないウィジェットの内容が変更されたりすると、
下になっているウィジェットの重なっている部分が再描画されます。
exposeハンドラでは、GdkGCを設定して、ウィジェットの必要な部分だけを書き換えるようにしましょう。

GdkRegionを使う方法

この方法が推奨されているようです:

static gboolean
my_widget_expose_event_handler (GtkWidget *widget, GdkEventExpose *event) {
  GdkGC *gc = widget->style->fg_gc[GTK_WIDGET_STATE(widget)];
  gdk_gc_set_clip_region(gc, event->region);
  /* 描画処理 */
  gdk_gc_set_clip_region(gc, NULL);
  /* 他の処理 */
}

GdkRectangleを使う方法

static gboolean
my_widget_expose_event_handler (GtkWidget *widget, GdkEventExpose *event) {
  GdkGC *gc = widget->style->fg_gc[GTK_WIDGET_STATE(widget)];
   gdk_gc_set_clip_rectangle(gc, &event->area);
  /* 描画処理 */
  gdk_gc_set_clip_rectangle(gc, NULL);
  /* 他の処理 */
}

ウィジェット全体を再描画するのはやめよう

クリッピングとも関係のある話ですが、手抜きをしてgtk_widget_queue_redraw_areaを使うのは避けるべきです。gtk_widget_queue_redraw_area を多用している場合は設計を見直した方がいいかも知れません。
特に画像を重ねて描画している場合、効率よく再描画するために重なりを管理する処理を書くことになりがちです。それはGTK+が既に持っている機能なので自分で作るべきではありません。

バグのあるウィジェットは使わない

バグのあるウィジェットとはGtkFixedのことですが、子ウィジェットを動かすとGtkFixed全体が再描画されるというバグがあります。

具体的なことはgtk_fixed_moveとgtk_layout_moveの実装を比較すると分かりますし、直すことも難しくありません。しかしGtkFixedは設計も古く (よく言えば単純で)、あんまりメンテナンスされていないようなので使わない方がいいでしょう。

おしまい

ぶっちゃけGTK+は独学なのであまり偉そうなことは言えません。むしろ教えてください。
Happy hacking!

Beagle Boardの記事が好評だったので、そのままなにかBeagleネタで行こうかとおもったのですが、本日、開発マシンが突然死したので、哀しみの開発マシン移行記を今回は書いてみます。

事の発端

土曜日の午前中、結構集中してコーディングをしていました。マシン自体は、快調に動いており、問題なく作業を進めました。ふと、喉が渇いて、お茶を汲んで、トイレに行ってきました。かえってきたら、sshでログインしているターミナルがすべて反応しません。

あれっとおもって、マシンを見ると、CPUファンが回っていません。あれ、電源落ちた？と思い、近づきます。明らかに焦げ臭いにおいが漂ってきました。危険な感じがヒシヒシと伝わってきます。とりあえず、保存してない分のソースは藻屑と消えました、合掌。。。って、この時点でテンション-10です。

とりあえず、原因をさぐるために、マザーボードに顔を近づけます。どうも、臭いのもとはCPU周辺で、かつ、ヒートシンクは触れないくらい熱くなっています。CPUが焦げて再起不能になった感たっぷりです。

ちょっと余談ですが、自作PC系でオーバークロックとかを趣味にされている方を中心に、なんというかこの臭いを感じた瞬間のテンションの下がりかたは、経験のある人はわかるとおもうのですが、完全に脱力系です。

さて、そうなると、とりあえず、電源ボタン、というか、マザーに直刺ししているスイッチを押しても当然のように反応がありません。これはやばいな、ということで、とりあえず、電源ケーブルを抜きます。ここで、おもむろにヒートシンクを掴むとやけど確実に火傷します。とりあえず、はやる気持ちを抑え、心を落ち着けて、深呼吸しながら冷えるのを待ちます。何故かこの時間の間に自分で自分を無駄に責めます。エアフローダメすぎとか、いや、ていうか根本的にオーバークロックしてる時点で、とかぐるぐるしながら待ちます。

さて、こっからが問題なのですが、結局のところ、起動しない原因がCPUかどうかを確定するのは結構厄介です。わざわざほかのマシンに挿してみるのも面倒ですし、それでなんかショートとかしてて、その検証用マザーを壊した日には泣くに泣けません。

というわけで、とりあえず、もう一度だけ、電源をつないでみて、CPUを刺し直して、起動をためしてみました。やっぱりダメです。ここで、結論をだします。諦めてマシンを新調することにしました。

新旧マシン構成の変化点

事の発端が、むやみと長くなりました。さっきクラッシュして、マシン組み直したばかりなので、まだショックから抜け切れていないせいか、まだ妙にハイテンションです。そのせいもあり、どこかのだれかに共感してほしくて長く書いてしまいました。

さて、本題にもどって、新しいマシンにするなら、どういう構成にするかを決めて、必要なものを買い出しです。うちの会社はアキバのPCパーツ系ショップエリアから徒歩３分くらいなので、買い出しには困りません。この会社の位置は素晴らしいです。

結局、開発マシンで壊れている部分を考えると、CPUは間違いなさそう、マザーはどうだろう、微妙だな、という具合です。一番、やすく済ませるなら、とりあえずCPUだけ買ってきて変えてみるのも手なのですが、これを期に、ウチのほかのサーバ用マシンと構成をあわせるのもついでにやってしまおうということで、思い切ってAMDなPhenomからIntel C2Qに変更することにしました。そうすると、もれなくマザーも買い換えです。

なので、購入したのは以下の部品です。

• Intel Core2Quad Q9550
• Intel DQ45CB

なんで、DQ45CBかは、はてなさんのサーバが公開された時も紹介されていましたが、キーワードは消費電力とIntel AMTです。このへんの話題はまた来週のエントリを書く際にご紹介したいとおもいます。

もともとのCPUとマザーボードは、以下のような構成です。

• Phenom 9950BE 3.0GHz (x15に倍率変更)
• GIGABYTE GA-MA78GPM-DS2H

まあ、ご覧の通り、OCしてるし、VCoreもちょっと盛ってるので、壊れたのはまさに自業自得です。

それ以外のメモリ、HDD、電源などのパーツはすべて流用です。

Gentooの移行

マシンは昼飯ついでに買ってきて、さくさくっとくみ上げます。ざっと配線などをチェックして電源を入れます。うん、うまく動きました。とりあえず、予想通り、CPUかマザーが壊れているので正解だったようです。電源とかだったら、涙目になるところでした。

とりあえず、BIOSとAMTまわりをざーっと設定します。さて、あとは、OSの移行です。もともと、開発マシンはGentooがインストールされていたので、その環境を再現しましょう。

基本的に、すでに動いていたHDDを挿すので、そのまま起動するはず、と一瞬おもったんですが、よく考えたらCPU変えたけど、大丈夫かいな、とおもいつつ、起動します。まずは、不安的中、カーネルがIOMMUまわりで刺さります。

わーん、となげきつつ、しょうがないのでまずはカーネルを入れ替えるところをやります。とりあえず、USB-HDDから起動できるようにしたGentoo MinimalインストールCDイメージがあったので、そのHDDをつないで、そこから起動します。

起動できなかったHDDを適当なところにマウントします。まあ、インストール時と同じ、/mnt/gentooがわかりやすい気がします。

# mount /dev/sda1 /mnt/gentoo
# mount /dev/sda2 /mnt/gentoo/var
# mount -t proc none /mnt/gentoo/proc
# mount -o bind /dev /mnt/gentoo/dev

おもむろに、chrootします。うまくいったので、深く考えなかったんですが、ここで実行できるバイナリだったので、よかったです。chrootできないと結構悲惨でしたね。

# chroot /mnt/gentoo /bin/bash
# env-update

さて、カーネルが刺さるので、コンフィグを見直します。とりあえず、同じ構成でうごいているマシンがあるので、その.configをもってきます。バージョンが2.6.30.2->2.6.30.4だったので、

# make oldconfig

します。さて、ここで問題発生。いつになっても、oldconfigがおわりません。そんな時間のかかる処理だったっけ、とあまりよく考えず、3分くらい待ちました。やっぱり終わりません。ここまできて、ようやくtopとかvmstatを眺めます。cc1が100%のまま、ずーっと張り付いています。ここで激しく嫌な予感。もしかして、gccがPhenom向けにコンパイルされててうまく動いてない感じなのか、と気づきます。そういえば、gccのオプションを/etc/make.confで-march=nativeとかにしています。やばげ。

さて、どうにかしないといけません。とりあえず、作戦を変更して、カーネルだけほかのマシンからもってきて、grubを書き換えて起動します。nicとかがudevのせいで、eth1に変わったりしてちょっと変ですが、とりあえず、うまく起動しました。これで、gccもうごくといいなー、とまったく根拠のない希望をもちつつ、make oldconfigと叩きます。はい、やっぱりダメです。

うーん、これはなんとかして、このマシン上でも動くgccを用意するしかありません。これも、結局、他のマシンのgcc, glibcをもってくることにしました。しかし、どのファイルをもってくればいいのか、特定するのはめんどくさいです。

解決策は、Gentooならquickpkgをつかって、バイナリパッケージをtbz2で作成してくれます。

# quickpkg gcc glibc

そうすると、/usr/portage/packages以下にファイルができあがります。これを開発マシンにコピーします。そして、はじめは、淡い希望をもって、emerge経由でインストールできないもんかと試します。

# emerge -avk =sys-devel/gcc-4.3.3-r2

残念。やっぱりcc1が暴走して、永遠に終わりません。となると、バイナリパッケージって所詮、ただのtarで固められたアーカイブなので、思い切って上書きで展開します。なにかおこったら、諦めて最初から構築しなおしの覚悟を決めます。

# tar jxpvf gcc-4.3.3-r2.tbz2 -C /
# tar jxpvf glibc-2.9_p20081201-r2.tbz2 -C /

さて、とりあえず、gcc -vとかためして、入れ替わったか確認します。うん、上書きされたようです。そして、再度、make oldconfigします。やった、うまくいきました。

ここまでいけば、あとは、カーネル再構築して、バイナリを最適化されているものに入れ替えです。Gentooつかってると、emerge -eDN worldとかちょっとわくわくしますよね。とか書いて、そんなわけねーよと思われていたら、悲しいですが。

そして、現在、emerge worldの最中です。問題無く、コンパイルされているようです。あとは、待つのみ。

最後に

これで、なんとか開発マシンがもとの状態にもどるところまでたどり着きました。

今回の教訓。

CPUとか変更するなら、事前にもうちょっといろいろ考えろよ、自分、っていうところにつきますね。まあ、なんとかなったからいいか、とおもって、毎回、こういう行き当たりばったりなことをしている気がします。直そう。

まあ、とりあえず、こういうときにいろいろ手が考えられるところとかも含め、いろいろGentooは楽しいです。みんなUbuntuとか言わずに、Gentooにしようよ、と社内で布教中なのですが、だれも言うことを聞いてくれません。悲しいです。ていうか、Ubuntuを使っていると、このケースならトラブルなく移行できた気がしますね。負けました。

さて、次回のエントリは、Intel AMTで快適リモート操作〜IPMIなんてなくても頑張れる子 DQ45CB〜をご紹介したいと思います。

では、長々と書きましたが、ここまで読んでくれた方、大変ありがとうございました。

最後に新旧開発マシンはこんな感じ。

]]> http://tech.cerevo.com/blog/archives/190/feed 1 http://tech.cerevo.com/blog/archives/177 http://tech.cerevo.com/blog/archives/177#comments Sun, 09 Aug 2009 23:30:42 +0000 hnakagawa http://tech.cerevo.com/blog/?p=177 はじめまして、Cerevoの中河です。
ソフトウェア担当で主にLinuxカーネル/ドライバ回りを担当しています。
今回はUBIFSとういうLinuxで使用できるファイルシステムについて書きたいと思います。

UBIFSって？

UBIFSとはNANDフラッシュメモリ向けに開発されたファイルシステムです。
フラッシュメモリと言うと、一般的にはUSBメモリやSSDが連想されるかもしれませんが、それらのデバイスはハードディスクと同じような扱いが出きるようハードウェア的な仕組みが入っている為、ここでは該当しません。
UBIFSが対象としているのは、あくまでもCPUのNANDフラッシュメモリ・コントローラに直接接続されたNANDフラッシュメモリです。

何故UBIFS？

フラッシュメモリ上では、JFFS2というファイルシステムが広く使用されてきました。
しかし、JFFS2にはフラッシュメモリの容量に比例して、マウント時間やメモリ使用量が大きくなってしまうという設計上の問題があり、昨今の大容量NANDフラッシュメモリには対応できなくなってきました。
そういった問題を解決するために設計・開発されたのがUBIFSです。

JFFS2と比較すると、UBIFSには以下のような特徴があります。
- 高速マウント
JFFS2の様にマウント時にパーティション全体をスキャンする必要が無く、高速にマウントできる。
- 省メモリ
JFFS2はファイルシステムのインデックスをメモリ上に置いていたため、容量に比例して大量のメモリを消費していましたが、UBIFSではインデックスをフラッシュメモリ上に置いているため、メモリ消費量が少ない。
- Write-Backサポート
Write-Backをサポートしているため高速に書き込み処理が出来る。
- UBI
JFFS2はMTDと呼ばれるフラッシュメモリ・デバイスドライバを抽象化したサブシステム上で動作しますが、UBIFSはMTD上にさらにUBIという、ウェアレベリング※1と論理ボリュームを実現するレイヤをのせ、その上で動作します。

UBIFSを使用してみる

- まずホスト環境で、UBIツールをクロスビルドします。
$ git clone git://git.infradead.org/mtd-utils.git
$ cd mtd-utils/
$ CROSS=arm-uclinuxeabi- make

- ビルドしたflash_eraseallとubimkvolコマンドをターゲットにコピーしてください。
$ cp arm-uclinuxeabi/flash_eraseall [ターゲットのroot]/usr/bin
$ cp arm-uclinuxeabi/ubi-utils/ubimkvol [ターゲットのroot]/usr/bin

- 続いてターゲット環境上でUBIFSで使用するmtdパーティションを初期化します。
$ flash_eraseall /dev/mtd1

- 以下のブートパラメータを追加します。
ubi.mtd=1

- 最後にUBI論理ボリュームを作成 & マウントします。
$ ubimkvol /dev/ubi0 -n 0 -N ubifs -m
$ mount -t ubifs ubi0_0 /mnt

まとめ

駆け足でしたが、UBIFSを紹介してみました。
UBIFSは製品レベルで十分使用できるものと考えていますので、大容量NANDフラッシュメモリを使用する場合は、是非UBIFSの採用を検討してみてください。
またそのうち、UBIFSやUBIの内部構造もご紹介できればと思います。

参考
UBIFS – http://www.linux-mtd.infradead.org/doc/ubifs.html
UBI – http://www.linux-mtd.infradead.org/doc/ubi.html

※1 http://ja.wikipedia.org/wiki/%E3%82%A6%E3%82%A7%E3%82%A2%E3%83%AC%E3%83%99%E3%83%AA%E3%83%B3%E3%82%B0

なぜパワーをマネージメントするのか？

ノートパソコンや携帯、デジカメなどのモバイル機器には電源としてバッテリが実装されています。
バッテリの容量というのは大小色々ありますが、有限です。
その限られた電力で出来るだけ長時間動作させたい、というのが目的になります。
(もっと大容量、もっと小型のバッテリが使えるようになると話は変わるのかも知れませんが)

良く使われるパワーマネージメント方法

出来るだけ電力消費を抑えるのが目的になるので、実際には機器内部のハードウェア・デバイスを色々と制御することになります。
いくつかの手法がありますが、世の中の常でプロコンがあります。

ソフトウェアスタンバイ

まずはデバイスの省電力機能を使うことが上げられます。
最近のデバイスはレジスタにアクセスすることで省電力モードになるものがあります。
「ソフトウェアスタンバイ」なんて言葉でこの機能が説明されている場合が多いです。
この手法はお手軽で通常の状態に復帰するのも早いですが、一方でそれほど消費電力が下がらないということがあります。

ハードウェアスタンバイ

次にデバイスのピンの電圧を変化させることで省電力状態にする手法があります。
これは上の例とは異なり、外部からターゲットとなるデバイスのピンに対してHigh or Lowをハード的に出力する手法になります。
「ハードウェアスタンバイ」なんて言葉で説明されている場合が多いです。
この手法はHigh or Lowを出力する仕組みが別途必要になるのでお手軽ではないのですが、大体の場合は消費電力が大幅に低下します。

電源制御

最後はターゲットとなるデバイスの電源をOFFにしてしまう手法です。
これは分かりやすいですね。消費電力は0になります。
ただし、電源ラインをON/OFFできるスイッチ(古くはリレー、最近はFETなんかで構成できます)とそのスイッチを制御する仕組みが別途必要になるのでハードウェア的には一番複雑になります。
しかも電源をOFFにしてしまうので、通常状態に復帰させるためには電源をONにして初期設定をし直さないといけません。
・・・でも、でも、「消費電力ゼロ」は魅力的なわけです。また、起動に1分かかるPCとは違って、起動して初期設定完了まで1～2秒程度、なんてのが一般的なので、意外に使えちゃったりするわけです。ケータイのカメラなんかは良い例ですね。

まとめ

概要は以上なのですが、実際には機器内部には多くのデバイスがあって、動作仕様によって今回の3つの手法を織り交ぜて使います。
パワーマネージメントはハードとソフトが協調して動かないといけないので、ちゃんと設計しないといけない雰囲気は伝わったかと思います。
次回は少し具体的な例を紹介しようと思います。

というわけで第一弾はいきなり日曜大工系で「コンクリート壁への重量物取り付け」。具体的にはライティングレールなど(※配線には要電気工事2種資格)。

用意するのは電気ドリルとコンクリート用ドリル刃、コンクリートアンカープラグ、タッピングビス。コンクリート壁に通常のタッピングビスを打ってもすぐに抜け落ちてきてしまいますので、ドリルで下穴をあけてからアンカーを指し込み、タッピングビスを打ち込むことでコンクリート内でアンカーが広がり、固定されます。

ポイントはコンクリート専用ドリル刃というのが売っていますので、これを使うこと。柔らかいところであれば鉄鋼用の刃でも太刀打ちできますが、刃がすぐにダメになってしまいます。また、アンカープラグの長さよりも少し長いビスを使うこともポイント。プラグを貫通してプラグが大きく広がることで、がっちりと固定されます。

秋葉原で1本単位で購入するなら、西川電子部品のネジ部がおすすめです。
http://nishikawa.or.tv/map/index.htm

西川電子部品では1本単位のビスに値段が書いていませんが、店員さんに聞けばちゃんと教えてくれます。ちなみに鉛製オールプラグ（サンコーテクノ製）と、それに適合するM3のタッピングビスはそれぞれ10円でした。

gtrkrcの書き方

gtkrcをちょっと書いてみようとして、ググったけどまともな解説がなくて挫折したという方、
けっこういるのではないでしょうか?
実は、書くときに必要な知識はGTK+のドキュメントに書いてあります。
http://library.gnome.org/devel/gtk/stable/gtk-Resource-Files.html

しかし他のドキュメントを参照しないと分からない部分もありますし、
そういう部分に限ってドキュメントのポインタが示されていなかったりするのも事実です。

そこで、gtkrcを書こうとしたけどよく分からなかったという人や
自分のプログラムでどう利用したらいいか分からないという人向けに、
gtkrcの書き方・使い方をまとめてみたいと思います。

スタイル

GTK+では、色やフォントの設定はスタイル (GtkStyle) としてまとめられています。
gtkrcでは次のような記述でスタイルを定義します。

style "hoge" {
   fg  [NORMAL] = "#fff"
   font_name = "M+1P+IPAG 12"
   xthickness = 2
   GtkWidget::focus-line-width = 3
}

色

fg bg text base bg_aaの部分の5種類の部分について、
NORMAL ACTIVE PRELIGHT SELECTED INSENSITIVEの各状態の色を指定します:

fg[NORMAL] = "#fff"

普段はNORMALの色、カーソルが当たったときはPRELIGHTの色などと使い分けることが想定されているようですが、
実際のところ、これらの色を実際にどこに配置するかはウィジェット次第です。
例えばGtkNotebookはちょっとそれ違わない?って感じの配色をしますね。
極端な話、GtkDrawingやGtkLayoutを使う場合は、5×5=25色のパレットだと思ってしまってもいいかもしれません。
お行儀よくはありませんが。

フォント

font_name = "M+1P+IPAG 12"

などと指定します。fontconfigが面倒を見てくれます。

厚み

xthicknessとythicknessはボタンの厚みやボックスのマージンなんかに使われる、
と思います。ほとんどいじったことはありません。

各クラス固有のスタイルプロパティ

普通のプロパティとは別にスタイルプロパティというものが各クラスに定義されており、
gtkrcで設定することができます。

たとえばGtkWidgetにはfocus-line-widthというスタイルプロパティがあり、

GtkWidget::focus-line-width = 3 

などと指定すると、
フォーカスの当たっているウィジェットに破線で描かれる枠が太くなります。

プログラムからの利用

ウィジェットはスタイルを持っており、公開されていますから、普通にポインタでアクセスできます。
例えばNORMAL状態の前景色のGdkGCは

widget->style->fg_gc[GTK_STATE_NORMAL]

としてアクセスできます。
プログラムの中でGdkGCやPangoを操作するのは面倒ですし 、
デザイン変更のたびにリコンパイルするのも大変ですから、
積極的に利用したいものです。

バインディング

バインディングはキーにアクションシグナルを結びつけます:

binding "fuga" {
  bind "Return" { "move-current" (next) }
  bind "Left" { "cancel" () }
}

解説を探してもEmacsキーバインディングにする方法しか書いてないことがほとんどで、
たとえば「どんな名前のキーがあるのか」ということはよく分からないという
ちょっと厄介な部分です。

バインディングも、スタイルと同様、一式を定義してからウィジエットに結びつけるという形をとります。

キーの名前

使うキーの名前は gdk/gdkkeysyms.h に書かれています。
たとえばGDK_Rightと書かれていたら、gtkrcには”Right”と書きます。
どのキーなのかは、おおむね見れば分かります。それで深く考えたことはありませんが、
どうしても気になるときは、GdkEventKeyをダンプするプログラムでも書いたら分かるんじゃないんでしょうか。

アクションシグナル

アクションシグナルの定義は、スタイルプロパティ同様、各クラス (と親クラス) のドキュメントに書かれています。
引数は、基本的に文字列か数か (上記の”move-current”に対するnextのような) シンボルです。
シンボルに関しては、アクションシグナルの定義をみると型が宣言されているので、それを見ればなんとなく分かります。

たとえばGtkMenuShellの”move-current”シグナルは引数にGtkMenuDirectionTypeを取るのですが、
その型は次のように宣言されています:

typedef enum
{
  GTK_MENU_DIR_PARENT,
  GTK_MENU_DIR_CHILD,
  GTK_MENU_DIR_NEXT,
  GTK_MENU_DIR_PREV
} GtkMenuDirectionType;

この場合、型がGtkMenuDirectionTypeなので、シンボルのGTK_MENU_DIRの部分は型名だと思って切り捨てて、
gtkrcには next と書きます。

例

例えば「キー”Right”にアクションシグナル”activate”をバインド、引数なし」という設定は
次のように書けます:
bind "Right" { "activate" () }
連続して複数のアクションシグナルを送ることもできますから (;で区切る必要はありません)、
ある程度複雑な動作をキーに割り当てることができると思います。

パスによる指定

定義したスタイルはウィジェットに”装備”させないと意味がありません。
ウィジェットは、ディレクトリと同様に階層構造を成しているので、
パス (path) とよく似たウィジェットパスによって特定することができます
(ウィジェットにはクラスがあるのでCSSのセレクタの方が近い)。
パスの区切り文字は “.” です。
いわゆるshell glob構文が使えると書いてあるのですが、[abc]みたいのは使えないようなので、
ワイルドカードに使えるのは?と*のようです。

GTK+2.10以降では、クラスを指定する部分に<someclass>のように書くと派生クラスにもマッチします。
例えば “<GtkBox>” は GtkHBoxにもGtkVBoxにもマッチします。

widget

例えば

widget "mainwindow.GtkHBox.okbutton" style "hoge"

のように、ウィジェットの名前でパスを指定します。
ウィジェットの名前はgtk_widget_set_nameで設定され、デフォルトではクラス名です。

widget_class

例えば

widget "GtkWindow.GtkHBox.GtkButton" style "hoge"

のように、パスをウィジェットのクラス名によって指定します。

class

例えば

class "GtkMenuShell" binding "fuga"

のように、階層構造を無視してウィジェット単体のクラス名によって指定します。

実際のところ、

widget_class "*GtkMenuShell" binding "fuga"

と書くのとほとんど変わらないと思うのですが……

まとめ

gtkrcを書くときに必要な知識を、分かりにくそうなことを中心になんとなくまとめてみました。
gtkrcを活用すればデザインをプログラムから分離することができ、開発が効率的になるでしょう。
Happy hacking!

前回は、DM355のブート処理を概観し、SDカード用のブートローダ (SD-UBL) を試してエラーを起こすところまで扱いました。今回はSD-UBLを分析・修正して、実際にインストールディスクを作ってみたいと思います。

メッセージを分析

SD-UBLが出すメッセージはけっこう冗長なので保存して比較してみると、ブートモードとインストールモードではカーネル (Linux) とRAMディスクのロード先が入れ替わっていることが分かります。関係するメッセージだけ引用します:

ブート時のメッセージ:
  * Loading kernel
 sdcard_read sdc_src_addr=0x00081000 dst=0x82000000 len=0x00200000
  * Loading ramdisk
 sdcard_read sdc_src_addr=0x00281000 dst=0x80700000 len=0x00400000
インストール時のメッセージ:
  * Flashing kernel
 sdcard_read sdc_src_addr=0x00081000 dst=0x80700000 len=0x00200000
  * Flashing Root FS
 sdcard_read sdc_src_addr=0x00281000 dst=0x82000000 len=0x00400000

SDカードにアクセスできないU-Bootを使っていますから、ロード先が入れ替わっては起動するはずがありません。しかし、ひとまずU-Bootのパラメータをデフォルトから変更すれば起動しそうです。実際にU-Bootの自動起動を中止して起動スクリプトを書き直してやると起動しました。

ただし、このままのメモリ配置では9MiBより大きなRAMディスクをロードできません。やはりSD-UBLの修正が必要です。それでハックの方針は以下のようになります:

• Linuxとramdiskのロード先アドレスを変更する
• ロードサイズを変更する

なお、インストールモードのフラッシュ書き換え機能は、ブートメッセージによれば、TIがリリースしているユーティリティをベースにしているらしいので使いません。そのTIのユーティリティはNANDフラッシュの書き込みエラー処理とかしてないっぽいので、信用できないからです。

SD-UBLを解析する

まずはディスクイメージからSD-UBLを探します。RBLの仕様はTIが公開しているDM355のARM subsystemのデータシートに書かれていますから、RBLになったつもりでディスクイメージを見ていきます……すぐに見つかりますね。ダンプしてみると、第1セクタにUBLディスクリプタが書かれています:

 00000200:  00 ed ac a1 00 01 00 00  2e 00 00 00 09 00 00 00

左から順に、マジックナンバー0xa1aced00、エントリポイントが0×100、サイズが0×2eセクタ、先頭は第9セクタ、という意味です。なおUBLはメモリ空間の0×0020にロードされるので解析には注意が必要です。

位置が分かったのでSD-UBLを切り出します:

 dd if=dm355_boot.sdcard of=sd-ubl.bin bs=512 skip=9 count=$((0x2e))

逆アセンブルします:

 arm_v5t_le-objdump -b binary -m arm -D sd-ubl.bin > sd-ubl.s

逆アセンブルしたソースを検索してみると、ロード元のアドレス0×41000とか0×81000を引数にして同じサブルーチンが3回ほど続けて呼ばれていることが分かります。関係する部分を引用します:

    2fd8:	e59f3064 	ldr	r3, [pc, #100]	; 0x3044
    2fdc:	e59f4064 	ldr	r4, [pc, #100]	; 0x3048
    2fe0:	e5932000 	ldr	r2, [r3] 	; 0x15aa4
    2fe4:	e1a01004 	mov	r1, r4
    2fe8:	e1a02482 	mov	r2, r2, lsl #9
    2fec:	e3a00a41 	mov	r0, #266240	; 0x41000
    2ff0:	ebfffe76 	bl	0x29d0

    3044:	00015aa4 	andeq	r5, r1, r4, lsr #21
    3048:	81080000 	tsthi	r8, r0
    304c:	00015594 	muleq	r1, r4, r5

    5a84:	0000012c 	andeq	r0, r0, ip, lsr #2

ARMのgccの関数呼び出し規約ではr0からr3が引数ですので、そっちのレジスタも見てみると、ロード先とサイズも引数として渡されているらしいことが分かります (簡単に書いてますが劇的な場面ですよ)。実にExcellentなコードですね。

0×15aa4という変なアドレスにアクセスしているので解説しておきましょう。TCMは0×00000と0×10000の両方からアクセスできるようになっているので、アドレス0×15aa4は0×5aa4と同じです。さらに、UBLのロードされるアドレスは0×00020ですから、0×15aa4へのアクセスは 0×15aa4 = 0×10000 + 0×20 + 0×5a84 と分解することができ、ソースの5a84:の部分へのアクセスになるわけです。

同様に解析するとU-Boot、Linux、ramdiskのロードがほぼ同じように書かれているらしいことが分かります。ロードする長さだけは変数としてメモリ上に置いてあります (グローバル変数なのでしょう……なぜだろう)。

バイナリパッチ

結局、具体的には以下のようにバイナリエディタでハックします (Emacsでは M-x hexl-find-file):

• Linuxとramdiskのロード先はハードコードされているので入れ替える:
  • 3000: e3a01482 を e59f1054 に変更
  • 301c: e59f1038 を e3a01482 に変更
• グローバル(?)変数になっているそれぞれのイメージサイズを変更する:
  • 5a84: U-Bootのセクタ数
  • 5a88 ramdiskのバイト数
  • 5a8c Linuxのバイト数

淡々と結果だけ書いてしまいましたが、ARM命令は32bit固定長なのでバイナリパッチが簡単なのです。今回は値を入れ替えたりそのままメモリ上に変数として置いてある値を書き換えるだけなのでコードも増えませんし、PC相対のディスプレースメントだけちょっと計算すればお終いです。

あとはU-Bootの環境変数を書き換えておいて、SDカードに書き込めばインストールディスクのできあがりです。好きなインストーラが起動するように仕込みましょう:

 dd of=/dev/sdc bs=512 seek=9 if=sd-ubl.bin
 dd of=/dev/sdc bs=512 seek=520 if=uboot.bin
 dd of=/dev/sdc bs=512 seek=1032 if=uImage  #linux
 dd of=/dev/sdc bs=512 seek=5128 if=fs.bin    #ramdisk

おしまい

SD-UBLがバグっているので多少バイナリパッチをしましたが、ARMのバイナリは割とハックしやすいと思います。ブートローダ程度のものなら皆さんもハックしてみてはいかがでしょうか?

今どきのPCは、買ってくるとHDDが内蔵されていてOS (Windowsとか) がインストールされているのが普通です。組み込みの機器も、やはり工場でファームウェアをインストールされて出荷されます。例えばNOR型のフラッシュROMを使う場合、最初からファームウェアの書かれたチップをハンダ付けするそうです。対してNAND型のフラッシュROMだと、生ROMを載せておいて基板が完成してから書き込むことになります。これはNANDフラッシュには不良ブロックがあるので、各自で対策を講じつつ書き込まないといけないからです。ちょうどPCのインストールで使うようなインストールディスクを作って量産工場に渡しておかないといけません。つまり今回はブートローダとかインストーラとかそういう話です。

DM355のブート処理

CPUに電源が入ると、PCの場合はROMに入っているBIOSが最初に走りだすわけですが、私が今相手にしているTI (Texas Instruments) のDM355でもやはりROMに入っているBIOSのようなものが走ります。TIの用語ではこれをRBL (ROM BootLoader) と呼んでいます。なおRBLによってロードされるプログラムのことは、TIの用語でUBL (User BootLoader) と言います。RBLはCPUに直結したスイッチによって四通りの場所からUBLをロードすることができます:

• NANDフラッシュROM
• NORフラッシュROM
• SDメモリカード
• シリアルポート

したがってインストール“ディスク”はSDカードだったりします。もちろんシリアルポートにPCを繋げてインストールとかいう方法も使えなくはありませんが、遅いしPCが必要だし面倒なのでやらないと思います。

RBLはロード作業以外の、DDRメモリの初期化とかは (恐らくは) してくれません。この辺はややこしいこと満載なのですが、DM355のCPUコアはARMなので、TCM (Tightly Coupled Memory――密結合メモリ) とかAIM (ARM Internal Memory――ミサイルじゃないよ) とか呼ばれるメモリを *CPUに内蔵* することができるのです。キャッシュとは別物です。DM355の場合、TCM領域は64KiBあり、32KiBのRAMと、8KiBのROMと、24KiBの予約領域が配置されています。ともかく、RBLはCPU内のROMに書かれていて、CPU内のRAMにプログラムをロードしてくれるわけです。RBLではCPU内部のメモリしか使わないので、DDRメモリの初期化なんかは段階的にロードされたプログラムがやる必要があるわけですね。その後、ロードされたUBLは、DDRメモリを初期化してNANDフラッシュなりSDカードなりからU-BootなどのLinux用ブートローダを読み込むわけですが、この辺はフツーなので割愛します。

DM355の起動に関する仕様はだいたいこんな感じです。身も蓋もない言い方をすれば、インストールSDカードにはSDカード用のUBLを入れればいいのです。ところが、TIはSDカード用のUBLをリリースしていません。TIの掲示板を見ると……
https://community.ti.com/forums/p/1970/7286.aspx
さすがはTIだ。SDカード対応のU-Bootを先にリリースする予定とは……順序が逆なんじゃないのか。

有志のSDカード用UBLを試す

というわけで、TIよりも先にSDカード対応のUBL (勝手にSD-UBLと呼びます) を開発して、インストールディスクのデモを作った人がいます:
http://community.ti.com/forums/t/2299.aspx
U-BootとLinuxとramdiskイメージをロードして、単に起動したりNANDフラッシュに書き込んだりしてくれるようです (一応、ディスクイメージを見なくてもなんとなく分かるように記事を書いたつもりですが、気になる人はダウンロードして見てください)。これを適当に解析して改造すればインストールディスクが作れそうです。

とりあえずSDカードに書き込んで動かしてみると、シリアルコンソールにバナーとメニューが出ます。ブートとインストール、二つの機能があります:

 SD Card DM35x boot loader
 by Constantine Shulyupin http://www.LinuxDriver.co.il/, sponsored by Applitec
 based on TI DM35x FlashAndBootUtils 1.10  SFT and SpectrumDigital evmdm355 v1
 Compiled on Dec 18 2008 at 13:16:08
 scd_nand_copy
 sd_init
 MMCSD_initCard
 1 - boot; 2 - install; 3 - global flash erase and install

まずは単純にブートさせてみると……正常に起動しません。U-BootがLinuxを起動してすぐリセットがかかります。一方、インストール機能は正常に動作します。まずはデバッグが必要なようです。

つづく

次回の後編では、SD-UBLのバグを探して、バイナリを直接書き直し、実際にインストールディスクを作ります。

すこし間があいてしまいましたが、Beagle Board用第２弾をお送りしたいと思います。

今回は、BeagleBoard上で実行することが可能なバイナリが作成できるようになるための準備をしたいと思います。

その後、ツールチェインをつくるだけではおもしろくないので、Androidをコンパイルして起動してみましょう。といっても、Androidの場合、ツールチェインが必要になるのは、カーネルコンパイル時だけだったりしますが。

ツールチェインとは

まずは、ツールチェインって何？というところですが、私の理解では、コンパイラ、リンカなどのBeagleBoard上で動くプログラムを作成するためのツール集です。linuxの場合は、大抵、binutils+gcc+glibc or uclibcなどの組み合わせになると思います。(newlibとかもあるのかな)

そして、こういった組込機器向けの場合、これらツールチェインは、ストレージ容量やコンパイル速度の都合上、ビルドはPC上で行うことが多いかと思います。その場合、クロスコンパイラとして、ツールチェインを作成し、PCでビルドして、BeagleBoard上で動作させるという流れになります。

ツールチェイン作成のための環境

まず、今回のビルド作業を２パターンの環境で試しました。どちらでも、作業する内容は同じで問題なく動作しました。

• KVM(qemu)上のi386なマシン（ホストは、Phenom 9950BE,メモリ8GBで、ゲストには2GB割り当てています。）のGentoo
• Amazon EC2 c1.xlarge上のGentoo

今回は、EC2を使って作業というのを体験してみたかったので、同時に試してみました。

EC2 c1.xlargeは確かに速いんですが、高いです。今回の作業で20hくらいつかったのですが、結局、カスタムAMIをS3においたり、ビルド作業用ディレクトリをEBSに置いたりすると、30$近くかかりました。興味半分で、c1.xlargeにしたのですが、c1.mediumで十分だと思います。

メリットとしては、自宅などに簡単にlinuxの環境なんか用意できねーよ、みたいな人にはかなりよいかも。ツールチェイン作りって基本的に、CPUパワー命なので、あまり非力なマシンだと時間かかりまくりで悲しくなってしまいますし。

ツールチェイン作成

さて、本題のツールチェイン作成です。作成には、結構いろんなパターンがあります。

一番、漢な手段は全部、手動でコンパイルとかなのでしょうが、当然、そんなのはやりたくありません。逆に、一番、お手軽なパターンは、BeagleBoard向けの場合、もっともメジャーなのは、バイナリな形で配布されているCode Sourcery ARM Sourcery G++ 2007q3.をダウンロードしてきてインストールするというパターンです。

今回は、その中間くらいのパターンとして、ツールを利用して、コンパイルする手段をとりたいと思います。どういう流れでツールチェインが作成されるのかを知りたかったのでこれでいきました。そこで、Gentooには、すばらしいツールがあります。crossdevです。これは、portageで提供されているツールチェイン作成ツールです。

# PORTAGE_OVERLAY=/opt/crossdev crossdev -t arm-gentoo-linux-gnueabi

と実行するだけで、ツールチェインが作成できます。
ただ、”-S”オプションやバージョンを指定しないと、最新バージョンが選択され、結構、Floating Exceptionなどでコンパイルに失敗したりします。その場合は、バージョンをオプションで指定しましょう。
今回は、かなり新しめのでもいけるかなーということで、そのまま実行したら、とりあえず、うまくいったので、それを利用しています。

• binutils: 2.19
• gcc: 4.3.2
• glibc: 2.9

コマンドが完了すると、arm-gentoo-linux-gccなどのコマンドが入ります。

簡単にためすなら、

$ echo 'int main(){return 0;}' > crossdev-test.c
$ arm-gentoo-linux-gnueabi-gcc -Wall crossdev-test.c -o crossdev_test
$ file crossdev_test
crossdev_test: ELF 32-bit LSB executable, ARM, version 1 (SYSV), for GNU/Linux 2.6.16, dynamically linked (uses shared libs), not stripped

と実行して、ARM向けのバイナリであることが確認できます。

Androidのビルド

さて、最後にAndroidのビルドを試してみます。

Android on BeagleBoardに関しては、先人がすでにポーティングしてくれています。それに従いましょう。

Android Porting guide for Beagle Board

最初のカーネルコンパイル時に、

    $make ARCH=arm omap3_beagle_android_defconfig
    $make ARCH=arm CROSS_COMPILE=PATH_TO_CODE_SOURCERY_TOOL_CHAIN uImage

となっていますが、このPATH_TO_CODE_SOURCERY_TOOL_CHAINに先ほど作成したarm-gentoo-linux-gnueabi-を渡します。そうすると、コンパイルされるかと思います。

あとは、ほぼ書かれている手順どおりでいけました。パッチがうまくあたらない部分などは手動であててみました。

実際には、はじめは、linux-omap3のツリーに手動でAndroid用の拡張を自力でパッチを当てていたのですが、そのあとパッチを発見してちょっと悲しい思いをしたりしました。

そして、起動したときのムービーが以下です。

最後に

というわけで、ツールチェインの作成はおわりました。これで、BeagleBoard上で様々な自作プログラムを動作させられるところまでは来ました。あとは、このツールチェインをつかってrootfsを構築すれば、自分でBeagleBoard上のすべてソフトウェアをコンパイルできるようになります。あとは、お好みの構成を考えて、なんでも好きなものがつくれるようになる。。。はずです。

今回の内容は、Gentoo Embedded Handbookをかなり参考にしています。ユーザランドの構築もこちらには書かれています。是非、参考にしてみてください。

初見
このブログをご覧になっている方達に「chumbyとは…」という話は不要でしょう。
最近はビックカメラやソフマップでも入手できるようになりました。
ところで、頂いたchumbyは外側のカバーが剥がされて、中の臓物がむき出しのちょっと可哀想な状態でした。

さてさて、どこから手をつけましょうか…

まずは電源投入
見つめていても仕方ないので、何はともあれまずは電源を投入してみます。
フロントのLCDに何か表示されるかな、と思っていたのですが、何も映りません。。。
一瞬でも変化しないか、と数回電源のON/OFFをしてみましたが、何の変化もしません。。。
本当に電源が投入されているのか確認したくなってきました。
一度、電源電圧をテスタで測定してみたほうが良さそうです。
テスタでどこに当たればよいのか？それを知るためには回路図を入手する必要があります。

回路図を入手
Chumbyはほんの一部のソフトを除いて、ハードウェアを含めたほぼ全ての情報がオープンになっています。
回路図ももちろん入手可能です。
ただし、一度 http://www.chumby.com/developers にアクセスしてアカウントを登録する必要があります。
アカウント登録後は、Hardwareのページから “Complete schematics and layout for the chumby core unit with cross-references” のリンクを辿ることで Rev37_release.pdf がダウンロードできるはずです。

大元の電源電圧を確認してみる
電源回路は4ページ目になります。
(大きな画像で見る)
今回はバッテリを使わずACアダプタで動かします。ACアダプタ出力電圧はACアダプタを良く見ると書いてあって +12V です。
回路図を見てみると、内部ではこの+12Vから+5V, +3.3V, +1.8Vが生成されているようです。
信号名 DCIN_PROTECTED は元々 RAW_PWR の入力に対してフィルタやヒューズ、逆流防止用のダイオードを経由して生成されていて、(ほぼ)ACアダプタ出力なので、R300の片側が測定ポイントに出来そうです。
測定がしにくいので、測定に関係のないLCDは外すことにします。
外す前の状態は↓のような感じです。

LCDがメインボードと薄い銅板のようなモノでハンダ付けされているので、これを外さないといけません。
外した後の状態は↓のような感じになります。あとはLCDから伸びているフレキシブル基盤を外すことで、メインボードがむき出しにできます。

メインボードのプリント基板外周の金色のパターンはGNDなので、まずはR300の片側とGND間の電圧を測定してみます。
測定結果は…何だか良く分かりません。+12Vではなく値がフラフラして安定していません。
どうも、どこかで電源関係がおかしくなっているようです。

電源とGNDの抵抗値を測定してみる
こんなときは電源とGNDがどこかでショートしていることを疑ったほうがいいです。
ちょっとしたコツとしては、末端の方から調べてみるということでしょうか。
回路図を見ると、chumbyの場合はACアダプタ入力(+12V)→+5V→+3.3V, +1.8Vという系統になっていることが分かります。
そのため、一度chumbyの電源をOFF(意外と忘れやすい)にしてから、まずは+3.3V, +1.8VとGND間の抵抗値を確認してみます。
+3.3VはJ302で確認できるので、GND間との抵抗値を測定します。
測定結果は…801Ω、大丈夫そうです。
次に+1.8VはJ304で確認できますので、同じ調子で測定してみます。
測定結果は…3Ω、これはちょっと低すぎです。
モノにもよりますが、通常電源ラインとGND間の抵抗値は数100Ω～数kΩ程度の値になります。3Ωはあまりにも低い値です。
抵抗値が低いということは+1.8Vには多くの電流が流れるということを意味しています。
ここで先程説明した系統を思い出してほしいのですが、+1.8Vに多くの電流が流れるということは、遡るように+5Vにも多くの電流が流れて、最終的に+12Vにも多くの電流が流れることになります。
電源ICには流すことが出来る電流が仕様で決まっていて、それ以上になると電圧が下がります。
もしかして+1.8Vの過負荷が原因で、+12Vの電圧が不安定になっているのでしょうか…

負荷を減らしてみる
+1.8Vがおかしいのは何となくわかりましたが、何が原因なのかは良く分かりません。
こういうときは負荷となっているモノをばっさりと切り離してしまうとはっきりします。
+1.8Vが回路に供給されないようにすればいい訳です。
今回の場合は、+1.8Vを生成する電源ICを外してみるのが手っ取り早い感じです。
そこで+1.8Vを生成しているIC、U302を外します。
この程度の大きさのICであれば、ハンダゴテ2本を使うと以外と簡単に外せます。
U302を外したあと、+1.8V～GND間の抵抗値を測定してみます。
測定結果は…2.6kΩなので、負荷側には問題なさそうです。どうやらこのU302が壊れているようです。
ここまできたので改めて電源を投入してみます。+12Vの値が正常になりました！

次回の予告
さて+12Vはマトモになりましたが、じゃあ次の系統の+5Vはというと…まだフラフラして安定していません。
そして回路図を見てみると、+5Vを生成している電源チップに CHUMBY_ON という制御信号が接続されています。あやしいです。
(大きな画像で見る)
この辺りを少し追いかけてみようと思います。

私は組み込みソフトウェア開発の担当で、主にLinuxを扱っていますが、ボードに載っているマイクロコントローラのプログラミングもします。最近はMSP430というTIのマイコンを相手にしているので、MSP430のアセンブリ言語プログラミングについて、x86アセンブリの経験者を対象にして書きたいと思います。

MSP430のレジスタとアドレッシング

MSP430には16本のレジスタがありますが、そのうちのr0はPC (プログラムカウンタ)、r1はSP (スタックポインタ)、r2はSR (ステータスレジスタ) および定数ジェネレータ、r3は定数ジェネレータとなっていて、汎用レジスタとして使えるのはr4からr15の12本のレジスタです。スタックの扱いはx86と同じです (ARMにあるようなリンクレジスタはない)。

MSP430の2オペランド命令はソースとデスティネーションが直交していて、それぞれ以下のモードが使えます:

ソース:

1. r4          ; レジスタモード
2. foo(r4) ; インデックスモード
3. @r4        ; 間接レジスタモード
4. @r4+      ; 間接自動インクリメント

デスティネーション:

1. r4       ; レジスタモード
2. foo(r4) ; インデックスモード

ソース・デスティネーションの両方にメモリオペランドを使うこともできる点がx86とは大きく異なる点と言えます (x86だとそういう命令はpush、pop、movsくらいしかありません)。インデックスモードを使うとディスプレースメントが付くので命令は可変長です。

オペランドのエンコーディングは上記の4種類だけですが、PCおよび定数ジェネレータとの組み合わせによって以下のアドレッシングモード
が実現されています:

1. foo       ; シンボリックモード (PCを使ったインデックスモード、いわゆるPC相対)
2. &foo     ; 絶対モード (定数生成レジスタをインデックスにしたインデックスモード)
3. #foo     ; 即時モード (PC間接自動インクリメントモード……これは面白い実装だと思います)

MSP430命令の注意点

演算命令はx86とほぼ共通なものが揃っていますが細かいところが違います:

• オペランドはソース, デスティネーション の順に書きます。
• バイト演算でレジスタをデスティネーションにすると上位バイトがクリアされます。それで、and #0xff, r4 は mov.b r4, r4 で代用すると1ワード節約できます。
• シフト・ローテートは1ビットづつしかできません。上位バイトと下位バイトを入れ替えるswpb命令が用意されているので組み合わせてシフトすることになります。

フラグ関連は微妙でありながらけっこう重要な違いがあります:

• bic (ビットクリア)、bis (ビットセット) ではフラグは変化しません。
• andとxorでは、演算結果が0でなければキャリーフラグがセットされます。
• subとcmpで生じるキャリーフラグはx86とは逆です。けっこう混乱します。
• 補助キャリーとパリティはありません。x86でも滅多に使わないフラグですが。

callは、jmpのようなオフセット値によるエンコーディングではなく、通常のソースオペランドで実現されています。したがって、callを使ったコードをROMからRAMにコピーするときはリロケート処理が必要です。あるいはオペランドをレジスタやメモリ(PC相対)にしておく方が楽かも知れません。

MSP430の定数ジェネレータを利用する

定数ジェネレータは -1, 0, 1, 2, 4, 8 を生成することができ、これを使うと即値の分の1ワードを節約することができます。例えば7回ループしたいとき、普通は以下のようにします:

  mov #7, r4    ; カウンタ

foo:

  dec r4        ; 減算

  jnz foo

しかしこれを以下のように置き換えると1ワード節約できます:

  mov #2, r4    ; カウンタ

foo:

  add.b r4, r4  ; シフト

  jnz foo

定数ジェネレータのお蔭で、インクリメントに1以外の値を使ってもコードは短いままです。それで、例えば32回のループは以下のようにすれば短くなります:

  mov #0, r4

foo:

  add.b #8, r4   ; 32回ループ

  jnz foo

他に以下の回数のループは1ワード短く書くことができますので、暇があれば考えてみると面白いかも知れません:
3 5 6 7 9 13 14 15 16 31 63 127 255 8191 16383 32767 65535

MSP430の自動インクリメントも利用する

x86ではinc・decが1バイトでできるため、ループの終了条件はほぼカウンタ一択です。しかし、MSP430ではアドレスの自動インクリメントがあるため、メモリアクセスをループさせる場合は、終了アドレスとポインタを比較した方が短いコードになることがあります。例えば、通常のメモリ間コピーは以下のようにします:

  mov #src, r4

  mov #count, r5

foo:

  mov @r4+, dest-src-2(r4)  ; 自動インクリメント、メモリ間コピー

  dec r5

  jnz foo

しかしcountが定数ジェネレータで生成できない場合、mov #count, r5とdec r5で3ワードも消費してしまいます。これをアドレス比較に書き換えると1ワード節約できます:

  mov #src, r4

foo:

  mov @r4+, dest-src-2(r4)  ; 自動インクリメント、メモリ間コピー

  cmp #src+count*2, r4

  jnz foo

自動インクリメントと定数ジェネレータがあるMSP430ならではの最適化です。

最適化できない場合

x86だと即値とレジスタの間のmovには専用形が用意されていますが、MSP430にはありません。したがって、例えば r4 = r5 ^ 0×1234; を実行する場合、以下のどちらのコードでも結果は全く同じです:

 ; x86ではこっちの方が１バイト短い

 mov #0x1234, r4

 xor r5, r4

 ; x86では１バイト長くなる

 mov r5, r4

 xor #0x1234, r4

MSP430ではデスティネーションのエンコーディングが2種類しかないので、メモリデスティネーションをアクセスするとディスプレースメントが必ずついてしまいます。これを最適化する方法はありません。メモリマップされたペリフェラルを操作することが多いので多分これでいいのですが、なんだかすっきりしない気分になります。

終わりに

MSP430のROMは何KBとある上に、新しいチップは安くてRAMもたくさん載っているので、ここで書いたような1ワードを争う最適化は滅多に必要ありません。でも100クロックかかる処理が90クロックで済むようになったら、消費電力は10%減るわけです。そう考えると、21世紀もまだまだアセンブリ言語の出番はあるのかも知れません。あるといいな……

(2009-02-13追記) 下記の利用するシリアルケーブルの種類の説明で、Null Modem Cable＝ストレートケーブルという記述になっていましたが、Null Modem Cable=クロスケーブルの間違いでした。記事を修正しました。コメントでのご指摘ありがとうございます。

昨日、弊社岩佐個人Blogキャズムを超えろ！にて、スタートを宣言されたこのBlogですが、思ったより反応があり、すこし腰が引けつつ、最初の投稿です。

私自身は、主に、サーバ関連全般（Web系のアプリ〜サーバ、ネットワークインフラ等）を担当しています。そのため、各部品ののデータシートを読み込んで、ハード設計して、回路図も書けて、ハンダ付けもバリバリ！みたいな組み込み屋さんではありません。ただ、前職の関係で、組み込み関連の知識は多少あるという感じです。

今回は、そんな人間によるBeagleBoardというARM系のCPU搭載開発ボードをつかった組み込みLinuxの体験記です。
まずは、BeagleBoardの紹介、そして、購入から実際にLinuxが動くところまでをお送りします。
今後も連載という形で、

• BeagleBoard(OMAP3)向けtoolchainの構築
• linux kernelの構築とインストール
• NFSルートでの起動
• DebianやGentooのインストール
• DSPの使い方

なども紹介していきたいと考えています。

前置き

といいつつ、まず、すこしだけ前置きをさせていただきます。

まず、組み込みの世界は広大です。家電だけにフォーカスを当てても、電子レンジ、炊飯器などの白物で使われる8bitくらいのマイコンから、まるでPC並なARMが搭載された携帯電話、PowerPCが搭載されたゲーム機等まで、それぞれの用途に合わせて、ハードウェア、OS、開発環境、ライセンスなどすべてに違いがあるのが現状であり、一概に語れる状況ではないのはその通りだと思っています。
ただ、どうしても、組み込み系の開発といえば、基本的に個人が手を出せるようなものではなく、ベンダーのサポートを前提とした契約（多くの場合、NDAもセット）のもと、EVMなどの評価ボードと高価な開発環境を手に入れて開発をしていく、という形のものが多く、現在もメジャーであるとは思います。

ただ、近年、そのなかでも、高性能な機器向けを中心として、組み込みの世界で存在感を示しつつあるのが、組み込み向けのLinuxです。組み込み向けのLinuxの搭載を前提とするボードなどでは、ライセンスの関係などから、ソースが公開され、個人でもFreeに手に入れられるものも出てきています。
そういったものは、個人で入手可能な形で販売され、比較的、ローコストで開発に入れるようになっているものも増えています。
たとえば、プラットホームのOpenBlockS,OpenMicroServer、アットマークテクノのArmadilloシリーズなど、日本でも簡単に開発環境も含め、手に入るものがかなり増えてきました。玄人指向の玄箱もこれに含めてもよいかもしれません。

そんな組み込みLinuxな世界を、あまりコストをかけず、気軽に体験してみようというのが、今回の趣旨になります。

＃個人的には、マイナーですが、NetBSDなどの組み込みっぽいBSDも好きです。
＃NetBSDのどんな機器にもポーティングするぜ、みたいなパワーに憧れます。

Beagle Boardとは

長くなってしまいました。さて、本題のBeagle Boardです。本家のページに様々な説明があります。
このボードの特徴は、なんといっても高性能なのに安い、とりあえず回路図とかほぼすべてオープン、というところにあるんではないでしょうか。そのため、個人がx86系ではない環境で、Linuxを動かす、という目的においては、ローコスト、かつ、情報も集めやすい環境であり、今現在、かなりオススメな入門環境です。

ここからの内容は、基本的に、Embedded Linux Wiki を参考に書かれています。ここの情報＋αという形で書いていきます。
ここのWikiに、かなりの情報があります。とりあえず、ざっと読んでみて損はないと思います。

本家のページにも、いろいろ説明があるので、具体的なボードのスペックは簡単にだけご紹介します。

• OMAP 3530(Cortex-A8 500-600MHz + C64x DSP + Graphics Accelerator)
• 128MB SDRAM
• 256MB NAND Flash
• USB 2.0 OTG
• USB EHCI Host
• DVI-out x1
• SDスロット x1

というのが、大体の概要でしょうか。いわゆる、CPU(OMAP3550)、メモリ(SDRAM)、ストレージ(NAND,SD)がそろっており、USBも搭載しているので、結線がどうとか、回路がどうとか考えずに、ある程度の拡張が容易です。CMOSなどもスペック上はつながりそうです。

性能という点でみた場合、組み込み用途としては、かなりの高性能だと思います。TIのOMAPシリーズは携帯電話を中心に採用されているもので、OMAP 3530はそのシリーズの最新のものになり、OMAP3の中でもOMAP3530は最上位モデル？にあたり、OpenGL ES互換のグラフィックアクセラレータまで搭載しています。そのような性能のため、後述のAngstromのデモでは、普通にFirefoxなど追加で構築し直して使ってみると、かなり快適に動作します。
＃はじめは、ボード上に、チップぽいものが１つしかなく、PoP(Package On Package)というものを知らなかったので、どこにメモリやNAND Flashは搭載されているのだろう？と探し回っていたりしました。

購入

なにはともあれ、まずはBeagleBoardを購入します。
これは、現在、日本で購入する場合は、DigiKey日本語サイトからの購入が無難です。
価格は、約17,000円で、送料は無料です。ただし、税関手数料？が600円程度かかるようです。
現在、購入すると、Rev.Bのボードになります。これは、制限として、USB EHCIがうまく動きません。
Rev.Cでは直る予定だそうですが、2009/Q1の遅い時期にならないと手に入らないという感じのようです。

http://search.digikey.com/scripts/DkSearch/dksus.dll?pname?site=jp;lang=ja;name=296-23428-ND
ここで、注文をすると、UPSで海外から送られてきます。
注文ですが、個人として注文する場合は、ないかもしれませんが、法人名で購入した場合、確認の電話がかかってきます。
アメリカからの輸入になり、規制？を突破するために、用途等を聞かれます(電話は日本語でOKなのでご安心を)。

• 細かい用途、できれば、このボード上で動くアプリケーションの概要
• 軍事用途ではないことの確認

などを聞かれました。一応、どう答えるか、事前に考えておいた方がよいかもしれません。

これで、アメリカから、４〜５日程度でボードが届きます。しかし、これで、さあ、開発だ！というわけにはいきません。
BeagleBoardには、ケーブル等が全くついてきません。そのへんを用意する必要があります。

今回、別途用意をしたのは、

• 電源関連(ACアダプタ等)
• RS232C関連（IDC10←→DSub9pin変換、ストレートケーブル、USBシリアル変換）
• USB関連(USBハブ、A->MiniA変換ケーブル、USB-LANアダプタ)
• HDMI←→DVIケーブル
• SDカード

です。そのあたりについて、説明をしていきます。

電源関連

なにはともあれ、電源を用意します。
Beagle Boardは、USBからの給電でも動作可能なのですが、Rev.Bのボードでは、EHCIのほうのUSBが動作しません。そのため、OTGのポートを給電用に利用してしまうと、キーボード、マウスなどを接続するポートが無くなってしまいます。
したがって、今回は、DCジャックからの給電で動作させています。

これは、プラグの形状等(2.1mm径 センタープラス)だけ気をつけて、5VのACアダプタを買ってきます。秋葉原なら若松や千石などのパーツ屋さんに行けば、普通においてあります。
私は、手元にあるもので代用したので、モバイルクルーザー＋USB-DCケーブル(2.1mm径)のものという組み合わせで給電しています。

シリアルケーブル(RS232C)

基本的に、シリアルコンソール経由での操作が大半を占めますので、必須です。

ただし、Beagle Boardには、PCを使ってるような人になじみ深いDSUB9ピンのコネクタなどは実装されていません。
ボード上にピンが立っているので、そこに接続する形のケーブルを用意する必要があります。
おそらく、普通の組み込み屋さんなら、さくっと自作してしまうのだとおもいますが、購入も可能です。
海外では、それ用のケーブルも販売しているようですが、ケーブル一本を通販で購入するのは、さすがに送料が高すぎて現実的ではないと思います。
PC向けマザーボードには、同じようにRS232Cのピンが立っているものが多いので、付属品としてIDC10コネクタのケーブルが販売されてて、今回はこれを流用しています。
実際に利用しているものは、千石電商にIDC-BBという型番でおいていたものです。
検索してみても、結構出てくるので、通販でも買えると思います。
コネクタさえ一緒なら、他のものを買ってもいいのですが、注意するのは、結線をちゃんと確認することです。
BeagleBoard側がどのようなピン配置になっているかは、ハードウェアマニュアルに詳しく載っています。

IDC-BBの場合、以下のようになっています。

DB-9   IDC-10
Pin 1 - Pin 1
Pin 2 - Pin 2
Pin 3 - Pin 3
Pin 4 - Pin 4
Pin 5 - Pin 5
Pin 6 - Pin 6
Pin 7 - Pin 7
Pin 8 - Pin 8
Pin 9 - Pin 9

これだと、ストレートに結線されていることが分かります。
とりあえず、このタイプを選ぶのがよいと思います。

次は、シリアルケーブルを用意します。
こちらは、Wikiには、Null Modem Cableという表記になっていますが、要はストレートクロス結線のものを用意します。
こちらも、千石電商で一緒に買いました。
＃最終的に、相手側とTX/RXがうまく接続されればよいので、実際は、IDC-GB+クロスケーブルでも動きます。

最後に、PC側ですが、私は、MacBookProを利用しているため、RS232Cポートがないので、USB-シリアル変換ケーブルを用意しました。
また、なんらかのターミナルソフトが必要です。ここでは、ckermitを利用しています。

ここで、ひとつポイントがあります。
BeableBoardは、実際は、RS232Cと呼んではいますが、TX/RX(送受信用のピン),GNDしか使われません。
そのため、RS232Cのフローコントロールはなしに設定しないと、シリアルポートでの通信は動作しません。
これは、通常、ソフトウェア側で設定可能です。
しかし、私が利用していたUSBシリアルであるSUNTAC VS60-Rはどうもフローコントロールをなしに設定しても、CTSをチェックしてしまうようで、受信はできるが、送信はできないという状況に陥りました。
USBシリアルが原因でそうなっていることに気づくまで３時間以上はまってしまいました。
結局、Arvel SRC06-USBに交換することで、問題なく動作するようになりました。
もし、同じ状況になったら、疑ってみてください。
あ、SUNTAC VS60-Rなら、ドライバを入れなくても動作しましたが、Arvelのやつは別途インストールしました。

まずは、Macならターミナル等を立ち上げて、以下のような操作をおこないます。
・kermitの起動(kermit -l /dev/tty.usbserial-FTDCNAMX)
>set speed 115200
>set flow-control none
>set carrier-watch off
とコマンドをうち、
>connect
で、接続します。

この状態で、用意したケーブルを接続し、電源を入れます。
すると、以下のような表示になると思います。

bash-3.2# kermit -l /dev/tty.usbserial-FTDCNAMX
C-Kermit 8.0.209, 17 Mar 2003, for Mac OS X 1.0
Copyright (C) 1985, 2003,
Trustees of Columbia University in the City of New York.
Type ? or HELP for help.
(/Users/ku/) C-Kermit>set speed 115200
/dev/tty.usbserial-FTDCNAMX, 115200 bps
(/Users/ku/) C-Kermit>set carrier-watch off
(/Users/ku/) C-Kermit>set flow-control none
(/Users/ku/) C-Kermit>connect
Connecting to /dev/tty.usbserial-FTDCNAMX, speed 115200
Escape character: Ctrl-\ (ASCII 28, FS): enabled
Type the escape character followed by C to get back,
or followed by ? to see other options.
----------------------------------------------------
Texas Instruments X-Loader 1.4.2 (Aug  8 2008 - 16:59:05)
Reading boot sector
Booting from mmc

U-Boot 2008.10-rc2 (Oct  2 2008 - 09:02:46)

OMAP3530-GP rev 2, CPU-OPP2 L3-165MHz
OMAP3 Beagle board + LPDDR/NAND
DRAM:  128 MB
NAND:  256 MiB
In:    serial
Out:   serial
Err:   serial
Hit any key to stop autoboot:  0[return]
OMAP3 beagleboard.org #

というような画面がターミナルに表示され、returnなどを押して、コンソールが操作できれば、シリアルコンソールはうまく動いているということになります。これで、とりあえず、第一段階突破です。

USB関連

Angstromのデモでは、とりあえず、EnlightmentというWindowManagerが立ち上がるので、キーボードとマウスをつないで操作する必要があります。それと、ネットワークも使うなら、BeagleBoardにはEthernetがないので、USB-LANアダプタも接続する必要があります。

それらを接続するために、まずは、USBハブを用意します。
ここでの注意点は、セルフパワーのものを用意することです。BeagleBoardのポートから給電される電流は非常に少ないので、USB-LANとかは確実に電力不足で直結しても動きません。

また、BeagleBoardに実装されているコネクタは、Mini-ABコネクタになります。ABコネクタは、A,Bどちらも挿せるということだそうです。今回は、Hostとして操作させるので、USB Aメス←→USB Mini Aのケーブルを買ってきて、USBのコネクタを変換する必要があります。
これも、千石電商にいけば、変換アダプタがおいていたので、それを購入するので良いと思います。

USB-LANは、Linuxで安定して動くものであれば、なんでもいいとは思います。
私は、手元にあったCorega FEther USB-TXCという製品を利用しています。これは、dm9000というモジュールで動作しました。NFSルートとかやるなら、100BASEのはやいものにしたほうがよいかも。

HDMI←→DVIケーブル

これは、そこらじゅうで売っているとおもうので、適当に用意します。
ちなみに、BeagleBoardではHDMIコネクタになっていますが、仕様としては満たしていません。単に、DVIのちっこいコネクタとして、流用しているだけのようです。

SDカード

容量はそこそこ大きめのほうがよいと思います。
今後、Debianなどをインストールして、Xもうごかすなら、1GBでは足りないかもしれないです。
私は、上海問屋の2GBのを使っていますが、問題なく動いています。

ここまでできると、開発に入る準備は完了です。

Angstromデモの起動

ここからは、とりあえず、なにか動かしてみようということで、デモイメージが公開されているAngstromのデモを動作させてみます。

SDカードのフォーマット

まず、SDカードからブートできるように、SDカードのフォーマットを行います。
ここからの操作は、なんからのLinux(今回はGentoo)上での操作を前提としています。fdiskが動けば、ほかのOSでもいけるかも。Linuxが手元にない場合、VMware等でLinuxをインストールするか、UbuntuやKNOPPIXなどのLiveCDを活用するとよいかもしれません。

SDカードは、カーネル等を置くFAT32のパーティションとユーザランドを配置するext3のパーティションの２つに分けます。
詳しい説明は、MMC boot formatというページでまとめられています。

一応、私がおこなった具体的な操作は以下になります。
/dev/sddがSDカードだとします。

最初に、パーティションテーブルをクリアします。

peng ~ # fdisk /dev/sdd
Command (m for help): o
Building a new DOS disklabel with disk identifier 0x226a3c58.
Changes will remain in memory only, until you decide to write them.
After that, of course, the previous content won't be recoverable.

Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)

SDカードの容量を確認します。

Command (m for help): p
Disk /dev/sdd: 2041 MB, 2041577472 bytes
....

ここの2041577472 bytesの数字は、使うのでメモしておきます。

expertモードに入ります。

Command (m for help): x
Expert command (m for help):

あんまりよく分かってないのですが、255 heads,63sectors,容量に応じたcylindersに変更します。

Expert command (m for help): h
Number of heads (1-256, default 4): 255
Expert command (m for help): s
Number of sectors (1-63, default 62): 63
Warning: setting sector offset for DOS compatiblity

Expert command (m for help): c
Number of cylinders (1-1048576, default 1011):248

容量に応じたという部分は、上の容量の数字を使って、
2041577472 / 255 / 63 / 512　という式で算出しています。

通常モードにもどり、あたらしいパーティションを作成します。

Expert command (m for help): r
Command (m for help): n
Command action
e   extended
p   primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-15, default 1): 1
Last cylinder or +size or +sizeM or +sizeK (1-15, default 15): 15

DOSパーティションなので、bootableフラグを設定し、FAT32にパーティションタイプを変更します。

Command (m for help): a
Partition number (1-4): 1
Command (m for help): t
Selected partition 1
Hex code (type L to list codes): c
Changed system type of partition 1 to c (W95 FAT32 (LBA))

そして、のこりの領域をlinuxのパーティションに割り当てます。

Command (m for help): n
Command action
e   extended
p   primary partition (1-4)
Partition number (1-4): 2
First cylinder (52-245, default 52):
Using default value 52
Last cylinder or +size or +sizeM or +sizeK (52-245, default 245):
Using default value 245

これで、wを入力して、パーティションテーブルを書き込みます。

その後、それぞれのファイルシステムでフォーマットします。

# mkfs.msdos -F 32 /dev/sdd1 -n LABEL
# mkfs.ext3 /dev/sdd2

これで、SDカードの準備は終了です。

Angstromデモイメージの書き込み

ここからAngstromのデモイメージ（rootfs, uImage, u-boot.bin, MLO）をダウンロードします。
そして、rootfs以外をFATのパーティションにコピーします。ただし、MLO最初にコピーする必要があります。

# wget 〜
# mount /dev/sdd1 /mnt/sdcard/p1
# cp MLO /mnt/sdcard/p1/
# cp u-boot.bin /mnt/sdard/p1/
# cp uImage /mnt/sdcard/p1/
# umount /mnt/sdcard/p1

という感じで実行します。

起動シーケンス

それぞれのファイルは、起動シーケンスなどの紹介などができれば、そこでまた詳しく説明すべきだとはおもいますが、簡単にだけ説明しておきます。
基本的に、BeagleBoardは、(On Chip Bootrom) -> X-Loader -> U-Boot -> Linuxという順で起動します。

• X-Loader　→　BeagleBoard On chip Bootromからロードされるstage2のBoot Loader（と呼んでいいのかどうかはよくわかりません。。。）
• U-Boot　→　こいつがNAND FlashやSDカードからLinuxカーネルをロードします。

X-Loaderが、いわゆる、NAND,SD,serialなどから、Bootloaderをロードし、起動する役割を担います。一応、U-Boot非依存になっているようなので、ほかのBootloaderをポーティングすることも可能かとは思います。
というわけで、今回は、SDにU-Boot,Linuxカーネルを入れておいて、X-Loaderには、ボード上のスイッチを押して、電源をいれることで、X-LoaderにSD上のU-Bootをロードしてね、と伝えることで、SDブートをしています。

Rootfsの配置

rootfsは、最新は、Angstrom-Beagleboard-demo-image-glibc-ipk-2008.1-test-20080920-beagleboard.rootfs.tar.bz2のようです。これを、ext3でフォーマットしたパーティションに展開します。
/mnt/sdcard/p2に、/dev/sdd2をマウントしているとして。

# tar jxpvf Angstrom-Beagleboard-demo-image-glibc-ipk-2008.1-test-20080920-beagleboard.rootfs.tar.bz2 -C /mnt/sdcard/p2

という感じ。

これで、umontすれば、セットアップは完了です。

boot

あとは、BeagleBoardにセットアップしたSDカードを挿して、電源を入れます。このとき、USR1のボタンを押したまま起動することで、SDからのbootが有効になります。

そして、うまくU-Bootが起動したら、コンソールに入ります。

そこで、

# setenv bootargs 'console=ttyS2,115200n8 root=/dev/mmcblk0p2 rw rootwait'
# setenv bootcmd 'mmcinit;fatload mmc 0 80300000 uImage;bootm 80300000'
(もし、毎回、この設定で起動したいなら)
# saveenv

と実行します。

そして、bootです。

# boot

これで、Linuxカーネルのロードが始まるはずです。

2198180 bytes read
## Booting kernel from Legacy Image at 80300000 ...
Image Name:   Linux-2.6.27
Image Type:   ARM Linux Kernel Image (uncompressed)
Data Size:    2198116 Bytes =  2.1 MB
Load Address: 80008000
Entry Point:  80008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK

Starting kernel ...

Uncompressing Linux............................................................................................................................................. done, booting the kernel.
Linux version 2.6.27 (voodoo@voodoo-desktop) (gcc version 4.3.2 (Sourcery G++ Lite 2008q3-41) ) #1 Fri Oct 31 12:04:40 CDT 2008
CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), cr=00c5387f
Machine: OMAP3 Beagle Board
Memory policy: ECC disabled, Data cache writeback
OMAP3430 ES2.1
SRAM: Mapped pa 0x40200000 to va 0xd7000000 size: 0x100000
CPU0: L1 I VIPT cache. Caches unified at level 2, coherent at level 3
CPU0: Level 1 cache is separate instruction and data
CPU0: I cache: 16384 bytes, associativity 4, 64 byte lines, 64 sets,
supports RA
CPU0: D cache: 16384 bytes, associativity 4, 64 byte lines, 64 sets,
supports RA WB WT
CPU0: Level 2 cache is unified
CPU0: unified cache: 262144 bytes, associativity 8, 64 byte lines, 512 sets,
supports WA RA WB WT
....

Angstromは、初回起動にいろいろ準備をするようで、かなり時間がかかります。無事起動することを祈りながら待ちます。

そして、起動完了したら、シンプルなユーザ設定画面が表示されるはずです。
適当なユーザ名とパスワードを入力してください。
そうすると、Enlightmentが起動するはずです。
このデモイメージには、

• 画像編集ソフト(GIMP)
• Webブラウザ(GNOME Web Browser, Midori)
• ワープロソフト(AbiWord)
• 表計算ソフト(Gnumeric)
• 動画再生ツール(mplayer,omapfbplay)

などが含まれています。使ってみてください。動画再生などは、DSPをつかってない状態でも、そこそこの解像度（320×240）とかのMPEG-4なら再生できたりして、ちょっとびっくりしました。

ちなみに、私がつかったデモイメージではうまくUSB-LANが認識されませんでした。その場合、カーネルをほかのものにかえてみたり、自分でコンパイルすると解決するはずです。

最後に

今回は、ここまでで一旦、切らせていただきます。
ここまでだけでも、かなりの分量になってしまいましたが、これ以降、自分の造るアプリを動かすための開発環境構築などをおこなっていきます。ここからが本番です。

とりあえず、組み込み環境なので、ペリフェラルやSDのセットアップは大変ですが、Linuxが動いてしまえば、アプリ等はPCとあまり変わりません。これが、組み込みLinuxのメリットだと思います。

次回は、最初にも書きましたが、

• OpenEmbeddedの開発環境を使ってみる
• Gentooのcrossdevをつかって、独自のツールチェイン作成し、クロスコンパイルに挑戦
• カーネル再構築

あたりをご紹介できたらな、と考えています。

ひっじょーに長い記事になってしまいましたが、だれかひとりでも参考にしていただける人がいれば幸いです。

株式会社Cerevoのエンジニアコミュニティ向けの技術情報発信Blogとして、本Blog「Cerevo tech blog」を開始しました。

組み込みソフトウェアの情報はWeb上に少なく、Webベースソフトウェア開発者コミュニティなどと比べ会社の枠を超えた技術的コミュニケーションの機会をもっと作るべきと考えました。そこで、まずは弊社から積極的に情報を発信すべきとの考えから、本Blogの開始に至りました。

弊社ではWeb系の技術についても積極的に開発に取り組んでいるため、組み込みに限らずWeb系の情報などもあわせて発信してまいります。

今後ともCerevoを宜しくお願いいたします。