なんとなく分かるgtkrcの書き方

こんにちは、稲垣@Cerevoです。
今回はアセンブリ言語から離れてGTK+に関することを書いてみたいと思います。

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のインストールディスクを作る 後編

こんにちは、Cerevoの稲垣です。

前回は、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、エントリポイントが0x100、サイズが0x2eセクタ、先頭は第9セクタ、という意味です。なおUBLはメモリ空間の0x0020にロードされるので解析には注意が必要です。

位置が分かったので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

逆アセンブルしたソースを検索してみると、ロード元のアドレス0x41000とか0x81000を引数にして同じサブルーチンが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なコードですね。

0x15aa4という変なアドレスにアクセスしているので解説しておきましょう。TCMは0x00000と0x10000の両方からアクセスできるようになっているので、アドレス0x15aa4は0x5aa4と同じです。さらに、UBLのロードされるアドレスは0x00020ですから、0x15aa4へのアクセスは 0x15aa4 = 0x10000 + 0x20 + 0x5a84 と分解することができ、ソースの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のバイナリは割とハックしやすいと思います。ブートローダ程度のものなら皆さんもハックしてみてはいかがでしょうか?

DM355のインストールディスクを作る 前編

こんにちは、Cerevoの稲垣です。今回も割と低レイヤーな話です。

今どきの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用 ツールチェインとAndroidの起動のおまけ

Cerevo まつけんです。

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

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

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

ツールチェインとは

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

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

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

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

  • 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用の拡張を自力でパッチを当てていたのですが、そのあとパッチを発見してちょっと悲しい思いをしたりしました。

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

[youtube]http://www.youtube.com/watch?v=CR5rGia8GcY[/youtube]

最後に

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

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

電源が入らなくなったchumbyを復活させてみる ~その1~

はじめまして。Cerevoの鈴木です。
私も稲垣と同じく組み込みソフトウェアの担当なのですが、より低レイヤの方が守備範囲となっています。
最近デザインの参考に色々なガジェットを集めているのですが、先日ある方から「壊れているchumbyならあるけど」という連絡があり、頂けることになりました。
折角なのでchumbyの内部を勉強しつつ、いじくり回して復活させるまでの体験記みたいなものを今後紹介していこうと思います。

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

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

まずは電源投入
見つめていても仕方ないので、何はともあれまずは電源を投入してみます。
フロントの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ページ目になります。
0041(大きな画像で見る)
今回はバッテリを使わずACアダプタで動かします。ACアダプタ出力電圧はACアダプタを良く見ると書いてあって +12V です。
回路図を見てみると、内部ではこの+12Vから+5V, +3.3V, +1.8Vが生成されているようです。
信号名 DCIN_PROTECTED は元々 RAW_PWR の入力に対してフィルタやヒューズ、逆流防止用のダイオードを経由して生成されていて、(ほぼ)ACアダプタ出力なので、R300の片側が測定ポイントに出来そうです。
測定がしにくいので、測定に関係のないLCDは外すことにします。
外す前の状態は↓のような感じです。
002
LCDがメインボードと薄い銅板のようなモノでハンダ付けされているので、これを外さないといけません。
外した後の状態は↓のような感じになります。あとはLCDから伸びているフレキシブル基盤を外すことで、メインボードがむき出しにできます。
003
メインボードのプリント基板外周の金色のパターンは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 という制御信号が接続されています。あやしいです。
0051(大きな画像で見る)
この辺りを少し追いかけてみようと思います。