ハードウェア Archive

こんにちは、Cerevoの鈴木です。
今回はパワーマネージメントを支えるハードウェアということで電源回路を扱ってみます。
実際にどんな電源回路を選定すべきかにフォーカスしたいと思います。
と言っても、そんなに電気回路の知識が必要ない程度で紹介しますので、ご安心をw

電源回路の基本の基本

よく使用される電源回路は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が実際に省電力モードになるまでの動作に興味をもたれる方もいると思いますので、次回はその辺の具体例を紹介する予定です。

まつけんです。

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〜をご紹介したいと思います。

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

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

こんにちは、Cerevoの鈴木です。
今回はモバイル機器では必須のパワーマネージメントについて扱ってみます。

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

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

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

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

ソフトウェアスタンバイ

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

ハードウェアスタンバイ

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

電源制御

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

まとめ

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

こんにちは、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、エントリポイントが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のバイナリは割とハックしやすいと思います。ブートローダ程度のものなら皆さんもハックしてみてはいかがでしょうか?

Cerevo まつけんです。

すこし間があいてしまいましたが、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をかなり参考にしています。ユーザランドの構築もこちらには書かれています。是非、参考にしてみてください。

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

初見
このブログをご覧になっている方達に「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 という制御信号が接続されています。あやしいです。
(大きな画像で見る)
この辺りを少し追いかけてみようと思います。

はじめまして。Cerevo まつけんです。

(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をつかって、独自のツールチェイン作成し、クロスコンパイルに挑戦
• カーネル再構築

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

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