EC2とS3をうまく使い分けてワールドビジネスサテライト砲を確実に乗り切る方法

まつけんです。

今回は、とれたまのコーナーで有名なテレビ東京さんの番組「ワールドビジネスサテライト」(以下、WBS)で紹介されるにあたって、どういう負荷対策をしたのかを紹介します。
WBSに紹介されて直後にサーバーアクセス殺到して落ちました、というような話は結構聞いていたので、機会損失という意味でも落ちるのはなんとか避けたいね、ということで対策をしましょうという話になりました。

前提

今回の負荷対策の前提となる条件を挙げます。

まず、ありがたいことにCerevoは最近、WBSに2度紹介されています。
LiveShellの紹介(映像はこちら)とCerevo DASHの紹介(映像はこちら)の2回です。
Cerevo DASHでは現在、iConvexというiPhoneアプリと連動する電子巻き尺ガジェットの支援を募集しています。是非、ご覧ください。
ということで、それぞれでの紹介内容にあわせて、別のサイト+コーポレートサイトがあるので、アクセスが増える可能性があるサイトは計3つあります。

LiveShell – http://shell.cerevo.com
Cerevo DASH – http://dash.cerevo.com
コーポレートサイト – http://www.cerevo.com
になります。

また、弊社は基本的に現時点では、ほぼすべてのサイトをAWS上で運営しているので、インスタンスの追加や変更は比較的に容易に行うことができます。
最後に、WBSに限らずなのですが、取材がくるよと決まってから実際に放映されるまでは大抵の場合、あまり時間がないです。
今回の場合も、1週間もないくらいの期間でできる対策をしないといけないという縛りもありました。

静的なサイト

まずは、負荷対策というか、もともとある程度であれば負荷が急に増えたとしても問題ないサイトがCerevo Dashとコーポレートサイトです。
これは単純にS3 websiteをつかって、静的なファイルしか置いてません。
そのため、S3が勝手に頑張ってくれるので、少々アクセスが増えたところで、なんなく乗り切ってくれました。
ログを見る限り、ピークでは500req/sくらいのアクセスがあったようですが、なんの問題もありませんでした。
TokyoにBucketがあって、テレビ番組の負荷であれば、アクセスの大半が国内からであることもわかっている場合、S3に置いておくだけで、充分っぽいねということが分かりました。

LiveShellサイト

そして、本題のLiveShell向けのサイトです。
こちらは、R53,ELB,EC2,RDSを使った、割とスタンダードな構成(だと思っています)のサイトです。

まずは、負荷対策をどこにどういう風に施していくかという部分です。
LiveShell向けサイトはその機能を考えると、大きくわけて2つの種別のページに分けることができます。
1つ目は、上記のLiveShellを操作するためのDashboardに関連する、ログイン後に操作されるLiveShell関係のページ。
2つ目は、それ以外の製品紹介、事例紹介、スペック、マニュアル、FAQなどのLiveShellの購入前に主に閲覧されるページ。

そして、テレビで紹介された場合に、アクセスが増えると予想されるのは、2つめの購入前に閲覧されるページです。
逆に、1つ目のページのアクセスが増える(LiveShellの配信が一時的に急増する)上がるという場合は、正直、スケールアップぐらいしか短期間ではできそうにありません。ここの負荷があがった場合はどこまででもスケールアップで後追いで対応しようということで、c1.mediumまでスケールアップしておき、当日は張り付いてモニタリングだけすることにしました。
#基本的に、メモリは常に余っている状態で、CPU負荷の方が高いため、HighCPUなインスタンスを選択しています。

では、2つ目のページ群の負荷対策をどうするかということになります。
まず、LiveShell向けのページは全般的にすべて多言語対応されており、日本語、英語の両方の表示に対応しています。
その言語切替などのためもあり、製品紹介などのページなども、他のページと同様に、基本的にテンプレートを読み込んで動的に毎回生成している状況でした。
しかし、アクセスが急増した場合、トップページ、製品紹介、特徴、スペックといったページに集中した場合、そこがボトルネックになる可能性が高いのは明らかです。
そのため、memcachedでキャッシュするとか、いくつか案を考えましたが、そもそもキャッシュをしたところで、動的なコンテンツになっている時点で、様々な箇所に負荷がかかる可能性があり、チューニングをするにしても慎重に行う必要がありそうで、間に合う気がしませんでした。
というわけで、もうすこしシンプルな手として、そういったページは、開発時は動的に生成、実際に本番環境に適用されるタイミングで、静的ページに書き出してデプロイという風に運用することに変更しました。

この対策をすると、アクセスが急増したときに、nginxがどれくらいの負荷を捌けるかという問題のみに集中することができます。
というわけで、次はnginxからの静的ページ配信性能をどうするかを考えます。
静的なファイルとはいえ、アクセス時にディスクから読み込まれるような事態になれば明らかに間に合いません。
そうすると、メモリに乗っかっていることが前提になるので、メモリの使用状況を考えます。
このインスタンスでは、動的部分を担当するアプリも動いているので、そちらが使っているメモリを差し引きます。これは動作実績を見ると、多いときでも600MB程度です。
もともとm1.smallでも1.7GBはメモリがあり、その他のプロセスやカーネルの利用量を見ても、1GB程度のメモリは常に空いている状態です。上記で生成された静的コンテンツを集計しても、100MBにも届きません。つまり、基本的にはnginxがディスクから配信する際はOS側のページキャッシュに任せるだけで、メモリに載った状態でディスクアクセスなしにファイルを配信してくれるはずです。

ここまで検討したら、あとはnginxで配信できる性能をどこまで高めるかという問題です。
まず、m1.smallは1ECUということで、ここでも言及されているとおり、CPUを常につかえるわけではないインスタンスです。さすがに負荷がかかるときに、このインスタンスを増やしていくというのはナンセンスなので、メモリも足りていることをかんがえると、HighCPUなインスタンスを複数台用意して配信するのがいいだろうということになりました。
というわけで、abなどをつかって配信性能を測定して、最低でも2000req/sくらいのアクセスは耐えられるようにということで見積をして、c1.medium2台で充分だなとおもった後に、心の平穏のために盛って、c1.mediumを4台用意しました。

実際の負荷

WBSで紹介された場合、そのアクセスの増加ペースは想像以上に瞬間的です。
大体紹介がはじまって、1-2分の間に、いつもは20req/sくらいのアクセスが、800req/sくらいにぐぐっと伸びました。その後、コーナー終盤までくると、1000req/sくらいまでピークのアクセスがきます。
その後は、スーッとアクセスは減っていき、それでも2時間くらいは300req/sくらいのアクセスが観測されます。その後は順調にアクセスは減り、朝3-4時には50req/sくらいまで落ちました。その後は1日くらいかけて緩やかにアクセスは減っていき、4日目くらいには平常な状態に戻りました。
WBSのおもしろいところは、放送翌日の8-10時です、あきらかにアクセスがまた増えます。一瞬ですが、300req/sくらいまで上がりました。これはおそらく、自宅でWBSを見て、出勤後にチェックという人がかなりいるからなのだろうな、と。

時系列では
〜23:00 20req/s
23:15(紹介始まる) 800req/s
23:20(紹介終わり) 1000req/s
23:30 – 01:30 300req/s
02:00 – 08:00 50req/s
08:00 – 10:00 300req/s
10:00〜3日後くらい 50req/s
それ以降は平常に戻る
という感じの流れでした。

負荷としては、大体、CPU負荷で40-50%くらいがピーク時に出ただけで、応答速度も遅いときも600msくらいで、平均は200-300msくらいに落ち着いていました。
c1.medium 4台用意しておけば、このくらいのアクセスであれば、まったく問題なくむしろオーバースペックだった感が漂いましたが、まあ落ちてうわーっとなるよりは全然良いし、数日、c1.mediumを立ち上げておいてもそれほど大きなコストではないのでよしとしました。

まとめ

というわけで、負荷対策として、以下を行いました。
・アクセスが増えると考えられるページに関しては、デプロイ時に静的なコンテンツを生成して、配信をnginxに任せる
・nginxがページキャッシュを利用して、ディスクI/Oを発生させずに配信できるようにメモリ消費を調整する、もしくは、メモリが充分に確保できるインスタンスを使う
・nginxの配信性能をベンチマークして予測されるアクセスに耐えられる程度にインスタンスを増やす
という形で充分乗り切れました。
また、動的な部分に関しても、ログイン画面や新規登録画面へのアクセスは若干増えましたが、基本的には予想通り、アクセスが大幅に増えることもなく、c1.mediumで充分に乗り越えることができました。

おまけ

LiveShellサイトの構成のご紹介。割とスタンダードなAWSを使った構成(だと思っています)をしています。

ELB—EC2(nginx+gunicorn)—RDS(MySQL)+EC2+EBS(KyotoTycoon)

アプリは、基本的にPythonで書かれており、WEBフレームワークはWerkzeugというか、Flaskをベースとしたmyojinという独自フレームワークをつかっています。(これは実はBitBucketで公開しています。ドキュメントもなにもないですが。)

EC2上で、Ubuntu 11.10が動作しており、そこにnginxをリバースプロキシとしておいて、同一インスタンス上でgunicorn経由でmyojinが起動されています。
そのアプリが動いているEC2のインスタンスは、m1.smallが2台。
KyotoTycoonは、LiveShellの状態など一時保存のためのKVSとしてm1.small上で動作しています。
RDSもMySQLでMultiAZは有効になっているけれど、m1.smallインスタンスで動かしていて、特にリードレプリカなども用意していません。
(そもそも、一般的なサイトにくらべて、LiveShellを操作するという機能は情報を永続化する必要がないので、SQLを発行する回数はかなり少ないという側面がありますが。。。)
というくらいの上記の通りで、規模としては大変小さいというか、コストはあまりかけずに運営しています。

これ以外に、LiveShellをリモートで配信状況をモニタしたり、逆に音量、画質など様々な設定をリアルタイムに操作する機能があり、そのサーバー側の機能を総称してDashboardと呼んでいます。こちらのツール的な部分の機能は、websocket(というか、Socket.IO)をつかってページを開いている間はTCPが常時接続されていたり、LiveShellとはUDPでやりとりをしてNAT越えを実現していたりという感じで、そのために、node.jsやPythonでかかれたデーモンが動いています。
こちらも平常時は、m1.smallで動いており、わりと低い負荷で収まっています。

おまけ2

ちなみに、サイトの高速化の一環として、Javascriptは基本的にGoogle Closure Libraryで書かれていてADVANCED MODEでコンパイルされ、1つのファイルにまとまっています。
CSSに関しても、基本的に1つのファイルにまとめるようになっています。
そのうえで、そういったファイルは、リビジョン番号ごとにディレクトリを変化させ、一度読み込むとキャッシュさせるために、長大(1年)なExpiresを設定しています。
また、事前に静的ファイルはgzipに圧縮されており、nginxのgzip_staticによって配信されるようになっています。
画像ファイルに関しては、おなじようなことができていないですが、こちらも続いてやりたいなぁとおもっています。

このあたりによって、上のリクエスト数の数字は他のサイトに比べると、閲覧数の割に少なくなっている傾向にある可能性はあります。
そういう意味でも、この手の施策は、アクセス数の削減につながるので、負荷対策としてもそれなりの効果があるのではないかと思っています。

カテゴリー: Web

PicoPSU 120WI-25Vの効率を測定してみた

 

 

 

大変おひさしぶりのまつけん@TechBlogです。偶然ネタができたのでエントリーを。この後もエントリーが続くかどうかは謎です。

実は私が測定したわけではないのですが、PicoPSUは実際どれくらいの効率で各電圧の電流を抜くことができるのかというのを検証してみました。

そもそもということで簡単にだけ紹介をしておくと、PicoPSUというのは、マザーボードのATX電源入力に挿すことのできる小さな電源基板で、12Vや24Vの単一電圧を入れれば、ATX電源の各電圧を生成してくれるというものです。(いわゆるDC-DCですね。)すごく小型でマザーボードに直接挿せるような形状をしているので、よくACアダプタと組み合わせて小さなPCを作る場合なんかに使われているようです。

http://www.mini-box.com/s.nl/sc.8/category.13/.f

上記サイトを参照していただくとイメージは沸きやすいと思います。実際の入手はサイトで直接海外から入手するか、秋葉原であればいくつかの店舗で取り扱われているようです。(高いけど。。。)

Cerevoではサーバーの電源を小型化するためにこのパーツを使っています。(当然すべてのサーバーではないですが。)AC-DCは以前どこかで紹介したことがある気がしますが、TDKラムダのHWSシリーズと組み合わせて利用しています。実際、2年以上運用されているサーバーもあり、ざっくりとした感覚的な話ですが、故障率もそれほど高くありません。

前置きはこれくらいで、実際の計測結果です。

今回利用したのは、WideInputタイプで12V〜25Vの入力を受けるタイプです。12V単一入力のほうがお安く、よく使われているような気がしますが、そちらでの測定結果は今回のものと違うかもしれません。

前提

3.3V 5V 12Vの6Aの出力が可能なメインの3系統に関して1系統ずつ電流の引き抜きテストを実施。
入力はpicoPSUの直近の電圧が12V〜24Vとなるよう入力電圧を調整する。
出力の電圧と電流、入力の電流を計測する。
各系統を均一の電流量を引き抜いた場合での効率で計算を行う。
あくまで、picoPSUのDC-DCの効率を見るもので、実際の使用やACからの効率を、調査しているものではない。

結果
12V入力時
20Wから60Wの間で、90%前後の効率となった。
24V入力時
20W時77%、60W時86%と低い値が出たが、100Wから120Wにおいて、90%程度の効率となった。

問題点
12V入力時に出力が不安定になる、下記内容。
5V系統において、3.8Aを超える引き抜きで、出力を得られなかった。
よって60W時での計測になった。
12V系統において、引き抜くにつれて、電圧が降下し高出力時に11V程度まで低下した
24Vは、高出力時でも、問題無く、出力が得られた。

 

実際の各電圧の効率

 

まとめ

というわけで、確かにPicoPSUは、使い方を間違えなければ、90%以上の効率を得られることがわかりました。

12Vで使う場合は、5V系統であまり大きな電流を引き抜けない、電圧降下がかなり大きいなどの問題もあって、大きな負荷をかけないのがよさそうです。HDD等をあまりつながないようにして、別電源で駆動させるなどしつつ、Atomなどを利用するようなあまり消費電力が増えない状態が維持されるようなパターンの場合は12Vでも高効率で使えそうです。

逆にある程度以上の負荷をかける場合は24Vを入力すれば、100W以上を使うような場合でも90%程度の効率を得られるようです。ただ、逆に、上記のようにAtomなどのCPUを載せて実際の消費電力が60Wを切るような低負荷で使う場合には24V入力を使ってしまうと低い効率になってしまうことに注意が必要です。100-120Wくらいを推移するようなシステムの場合はなにも考えずに24Vで利用するのがよさそうです。

実際のところでは、この前段のAC-DCでの効率もあるのでもっと効率は落ちることにはなりそうですが、PicoPSUは24V入力で利用するとかなり高効率で安定して利用できると思われます。

私は自宅サーバーでも、DQ67OW + Core i5-2400S + DDR-3 16GB という構成をPicoPSUで駆動させて簡単な自作ケースにいれて駆動させていたりします。実際かなりコンパクトでいい感じです。

というわけで、今回はPicoPSUの効率を検証してみたという話題でした。

次はきっとWebチームの彼が更新してくれると信じています。

 

クラッシュ&移行 ~Cerevo社内開発用サーバ構築記~

まつけんです。

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

事の発端

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

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

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

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

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

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

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

新旧マシン構成の変化点

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

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

結局、開発マシンで壊れている部分を考えると、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〜をご紹介したいと思います。

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

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

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

Beagle Board 事始め

はじめまして。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など追加で構築し直して使ってみると、かなり快適に動作します。
#はじめは、ボード上に、チップぽいものが1つしかなく、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なのでご安心を)。

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

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

これで、アメリカから、4〜5日程度でボードが届きます。しかし、これで、さあ、開発だ!というわけにはいきません。
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シリアルが原因でそうなっていることに気づくまで3時間以上はまってしまいました。
結局、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のパーティションの2つに分けます。
詳しい説明は、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をつかって、独自のツールチェイン作成し、クロスコンパイルに挑戦
  • カーネル再構築

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

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