x86プロセッサでの組み込みLinuxの対応作業はソースコードの改変なしでメニューの選択だけで行うことができましたが、ARMプロセッサボードを開発した場合にはソースコードの改変作業が発生します。

各種ドライバを含めたLinuxカーネルの部分は、Kernel Version 3.２以降ではDevice Tree Blobといったメカニズムによってカーネルソースコードの改変が最低限で済むよう設計されています。そのため、新規にARMプロセッサを採用したボード上にLinuxを移植しようとするときに、作業量が最も多くなると思われる部分は、ブートローダの移植になります。

CPUメーカの提供しているリファレンスボードや、開発ツールメーカーの開発ボードなどでは最初からU-BootやRedBootなどのブートローダーが最初から書き込まれており、リファレンスボードでソフト、別の場所でハードの開発を並行して進めて、最後に自社のボードに乗せ換えようとする場合などで、最後の段階においてブートローダがうまく移植できないといった問題が発生することもままあります。ブートローダーの最初の部分は、メインメモリも見えない状態で動く必要がありますので、問題が発生した場合のデバックも簡単ではありません。したがって、リファレンスボードでの開発を並行して行うのであれば、ハードウェアを設計する段階で、製品とリファレンスボードでは全く同じDRAMを使用する、製品ボードにはコネクタは実装しないが、JTAGのパターンを残しておくなどの工夫が重要です。

カーネルのDevice Tree Blobの改変も少々癖があるので、最初は非常にとっつきにくいのと、デバッグがやりにくいといった欠点もありますが、慣れてしまえばなんとかなりますので、いろいろいじってみましょう。

U-Bootをはじめとするブートローダーは、x86 PCでは、最初からマザーボードに実装されているBIOSや、UEFIとして実装されていて、メインメモリの容量や、アクセスタイミング、キーボードや、初期メッセージを出すためのスクリーンの準備など、ハードウェアの構成に依存する部分の初期化作業を行ってくれますが、新規開発ボードではそのBIOSに相当する部分を自分で作る必要があります。

ここで、実際のボードでどのようにU-Bootを移植していくのかを解説していきたいところですが、市販のリファレンスボードや、開発ボードなどでは、ブートローダーはさわるなといった感じのボードが多いですし、CPUのデーターシートがNDA契約がないと見れないボードの開発はしたくないので、実機での開発手順の公開をどのようにしていくかは検討中です。

いまのところ、BeagleBoardなんかがいいのかな？と考えているところです。

前回の「組み込みシステム用Linuxを作ってみよう(1)」からの続きです

仮想マシンで実行することも考えましたが、仮想マシンで動いたところで動いてる実感に乏しかったので、実機をUSBメモリで起動する方法を解説していきます。当然、同様のことを仮想マシンで実行することも可能ですので、実機を準備するのが面倒な場合は仮想マシンで実行してみてください。

前回作成した、イメージをＵＳＢメモリーに書き込んで、ＵＳＢブート可能なＰＣで起動してみましょう。
まずは、ＵＳＢメモリーのパーティショニングから

% sudo fdisk /dev/sdX

※　sdXは、USBメモリのデバイス名

Command (m for help): n
Partition type:
p primary (2 primary, 0 extended, 2 free)
e extended
Select (default p): p
Partition number (1-4, default 1): 1
First sector (2048-15196159, default 2048): (Enter)
Using default value 2048
Last sector, +sectors or +size{K,M,G} (2048-15196159, default 15196159): (Enter)
Using default value 15196159
Command (m for help): a
Partition number (1-4): 1
Command (m for help): w
Command (m for help): q

数値は、メモリによって異なりますが、とりあえず全体をLinuxで使用するように設定します。
続いてフォーマットと、メディアにデーターを書き込むことはないので、定期的なfsckの実行を抑制するためのパラメーターの設定をします。

% sudo mkfs -t ext2 /dev/sdb1
% sudo tune2fs -c -1 -L system /dev/sdb1

次に、MBRを書き込みます。これは、BIOSがセクター０を読み込んでOSを起動するまでのコードが格納されているコードです。このコードは前回ブートローダーにsyslinuxを選択したため、output/build/syslinux-6.03以下にビルドされています。

% sudo cat output/build/syslinux-6.03/bios/mbr/mbr.bin > /dev/sdb

MBRを書き込んだら、ファイルシステムをマウントして、MBR以降のブートローダーのコードを書き込みます。

% sudo mkdir /mnt/usb
% sudo mount -t ext2 /dev/sdb1 /mnt/usb
% sudo output/host/sbin/extlinux --install /mnt/usb

最後に、カーネルとRAMディスクイメージをコピーして、syslinuxのブートメニューを設定してUSBメモリーをアンマウントします。

% sudo cp output/images/bzImage /mnt/usb
% sudo cp output/images/rootfs.cpio.gz /mnt/usb
% sudo cat  << _EOF > /mnt/usb/extlinux.conf
> DEFAULT linux
> PROMPT 0
> LABEL linux
> LINUX bzImage
> INITRD rootfs.cpio.gz
> EOF
> _EOF
% sudo sync
% sudo umount /mnt/usb

これで、起動メディアの完成です。USBブート可能な、PCにメディアを刺して起動すると、今回作成したLinuxが起動するはずです。
起動したLinuxでは、rootでログインして、コマンドを消したり、変な設定をしても、USBメモリを書き込み可能でマウントしない限り、再起動すると元に戻ります。また、書き込み可能メディアをマウントしていないので、シャットダウン処理の必要もありません。（いきなり電源ケ

How toの途中ですが、ちょっと読み物を

これから組み込みシステムを開発しようと思っている方は、大きく２つの方向からのアプローチをとっていると思います。

１つは、これまで８Bitマイコンのシステムを作ってきてデーター量の増加や、扱うデバイスの複雑化などによって、より高機能なシステムを利用するためにLinuxを採用してみようというアプローチ。もう一方は、これまでデスクトップOSでシステムを組んできたが、専用機にすることによって、メンテナンス性の向上や、ユーザーの自由度を制限することによって、システムの安定性を望んでの組み込みLinuxを採用してみようというアプローチです。

どちらからのアプローチでも、システムが完成してしまえば、それなりの効果は得られるはずです。しかし、そのためには、これまで組んできたシステムでは全く考慮しなくてよかった部分を考慮する必要が出てきます。

まず、最初にマイコンからのアプローチについて検討してみましょう。

Linuxの基本は、マルチユーザー、マルチタスクのOSです。マルチユーザのOSとは、Aさんでログインしたら、Aさんの環境、BさんでログインしたらBさんの環境が準備されていることを前提としています。８Bitマイコンシステムでは、マルチユーザーを意識したものはほとんど無いと思いますので、この概念を理解して進めるかどうかによって、アプローチ方法が大きく変わります。今後、インターネットにつながって、システムとしてセキュリティを考えていかなくてなならないのであれば、マルチユーザの概念を理解しておく必要があります。

ここでは、温度センサを例に解説していきましょう。一般的な温度センサであれば８Bitマイコンで十分なのですが、一定時間毎に温度を記録してグラフを出しましょう。また、そのグラフはPCやスマートフォンなどからWebブラウザで見えるようにしましょうとなると、LinuxなどのWebサーバーが利用できるOSを採用したほうがいいことにまります。また、データーも永遠に増え続けるので、誰かが操作してバックアップするなりクリアするといったメンテナンスも必要になってきます。このあたりから、マルチユーザーの機能が必要になってきます。メンテナンスを行う権限を持ったユーザーと、見ることだけが可能なユーザーといった２種類のユーザー権限を定義したシステムを考えていく必要が出てくるといった具合です。

また、ファイルシステムいった概念も、８Bitマイコンにはなかったものです。How Toのページでルートファイルシステムをどうするかなどの解説もしてきましたが、マイコンでは、OSもアプリケーションも最終的に１つの実行形式ファイルにリンクしてROMに書き込むといったアプローチが一般的であるのに対して、Linuxでは、ファイルをコピーするコマンド、システムをシャットダウンするコマンドなど、それぞれの機能を別々のファイルとして実現しています。今後、ブートローダーの移植などの話題もこのブログで取り上げていく予定ですが、ブートローダーのプログラムなどは、８Bitマイコンのプログラムに非常に似ています。逆に、一般的に使用されているブートローダの機能を拡張するだけである程度のシステムであれば実現することも可能であるともいえます。

デスクトップOSからのアプローチはどうでしょう

デスクトップOS（Windowsや、一般的なLinuxのディストリビューション)では、システムは、エンドユーザーが使いながら進化させていくことを前提に設計されています。文章を書きたいなら、ワードプロセッサをインストール、セキュリティを向上させるために、ウィルススキャンをインストールなどして、システムの状況は日々進化していくものとして設計されています。一方、組み込みシステムでは、システムそのものの変更は基本的に行われません。工作機械に組み込んだコンピュータの能力が余ってるからといって、工作機械で、ゲームやネットサーフィンをしようとはユーザーも思わないでしょう。逆に、できるからといって、ネットサーフィンの機能などをつけたら、ウィルスなどで工作機械が誤動作でもしようものなら目も当てられません。

そのまま、工作機械を例に話を進めますが、システム設計者は、どのような機能を実現するかだけでなく、機械を組み立てる際に設定すべき項目（モーターがいくつあって、それぞれのモーターの性能、温度センサの位置とそれぞれの意味など）と、エンドユーザーが設定すべき項目（どのモーターに何ミリ径のドリルをつけるかなど）のように、だれが何を設定し、どのように操作するかを考えながら設計する必要がります。特に、設定項目については最低限、シンプルで目的を達成するためにわかりやすくすることが重要です。なんでもできるようにしてしまうと、Linuxなので表計算ソフトを入れてしまえということになりかねません。オープンソースなどのLinuxの便利なツールを最大限に生かしながら、ユーザーにはLinuxであることを意識させない設計が必要です。

Linuxは非常にパワフルなOSで、８Bitマイコンの代わりをすることもできますし、データーセンターの巨大サーバーのようなシステムを構築することができるOSです。どのような機能を追加して、どのような機能を隠蔽していくかは設計者のセンスにかかってきます。

今後、このブログで、８Bitマイコンに近い使い方や、デスクトップOS的な使い方など、様々な例をあげながら解説していく予定です。How Toの解説だけでなく、考え方やアプローチの方法なども追記していきます。

また、ぽよんテックでは、Linuxだけでなく、ｘｘＢＳＤや、Windows、マイコンなどの開発も行っていきますので、よろしくお願いします

Sorry, this article is Japanese only.

PoyonTech will use Buildroot system for our embedded Linux based projects.

Buildroot

Buildroot system is simple and flexible solution to create embedded systems.　The is different from major desktop Linux distributions, all codes are distributed by source code. Thus you have to compile yourself, but Buildroot source tree include source code of cross compiler. This makes you can control firmware versions very strictly.

Also Buildroot system is simple, thus, you can migrate some code provide by chip maker to the Buildroot system easy.

I will post details of how did I port Buildroot to my embedded systems later.