今回この mruby を、MMU を持たない CPU (SH-2/SH7619) を搭載したボードのエミュレータである Ash エミュレータ 上の Linux 環境 (uClinux と uClibc) で 動作を確認することができたので、その手順を紹介したいと思います。

尚、確認を行ったホスト環境は Ubuntu 11.10 (32bit) です。

本エントリの内容は実験的なものです。Ash ボード、及び Ash エミュレータ上での mruby の動作を保障するものではありません。

クロスツールチェインのインストール

こちらの手順に従い、mruby をビルドするための SH-2 用クロスツールチェインをインストールします。

インストールするツールチェインは、2012.02-pylone5.tar.bz2 以降のバージョンとしてください。

尚、以降の手順では、インストールしたクロスツールチェインにパスが通っていることを前提としています。

Ash エミュレータの準備、起動まで

以下の手順で Ash エミュレータをビルド、起動を行います。

(Ash エミュレータのビルドに必要。環境に合わせてインストール)
# apt-get install libglib2.0-dev

(Ash エミュレータのビルド)
% wget http://downloads.pylone.jp/ash/src/qemu-ash-0.15.1-pylone2.tar.bz2
% tar xf qemu-ash-0.15.1-pylone2.tar.bz2 
% cd qemu-ash-0.15.1-pylone2
% ./configure --target-list=sh2-softmmu,sh2-linux-user
% make

(Linux 環境のダウンロード)
% wget http://downloads.pylone.jp/ash/images/20120419/ash_flash_linux.bin

(Ash エミュレータの起動)
% ./sh2-softmmu/qemu-system-sh2 \
  -nographic \
  -drive if=pflash,cache=writeback,file=ash_flash_linux.bin \
  -tftp /tmp

Ash エミュレータの擬似 TFTP サーバの公開ディレクトリ指定(-tftp オプション) に /tmp を指定しますが、これは後述の mruby の各バイナリファイルを転送するための一時的なディレクトリです (/tmp 以外でも可)。

ブートローダからの起動を経て、Linux の起動後、ログインプロンプトまでたどり着いたら、root でログインします(初回起動時はログインプロンプトまで時間がかかります)。

(ログイン)
ash login: root

尚、Ash エミュレータを終了するには、起動した shell を閉じるか、または同 shell 上で <Ctrl-a x> と 入力してください。

mruby のクロスビルド

ホストPC 上の 別の shell から、以下の手順で SH-2 向けに mruby をクロスビルドします。

(以降の手順に必要。環境に合わせてインストール)
# apt-get install git bison

(GitHub より、mruby の ソースを取得)
% git clone https://github.com/mruby/mruby.git

(mruby の ビルド)
% cd mruby
% make \
  CC=sh2-linux-gcc \
  LL="sh2-linux-gcc -Wl,-elf2flt=-ra" \
  AR=sh2-linux-ar \
  MRBC="(Ash エミュレータを展開したディレクトリ)/qemu-ash-0.15.1-pylone2/sh2-linux-user/qemu-sh2 -L /opt/pylone/ash/host/usr/sh2-linux ../bin/mrbc.gdb"

尚、今回取得した mruby は以下の時点のものです。

% git --no-pager show --pretty=oneline
b666b7d112b0c558fcec14ec1d36ceae2efc0a9b Merge pull request #102 from MobiRuby/add_const

生成されたバイナリファイルを、Ash エミュレータの擬似 TFTP サーバの公開ディレクトリとした /tmp にコピーしておきます

% cp bin/{mruby,mrbc} /tmp

mruby の実行

tftp コマンドによって Ash エミュレータの擬似 TFTP サーバから mruby の各バイナリファイルを取得し、実行権限を付与します (以降、Ash エミュレータ上の操作になります)。

(mruby、mrbc を取得し実行権限を付与)
# tftp -g -r mruby 10.0.2.2
# tftp -g -r mrbc 10.0.2.2
# chmod +x mruby mrbc

mruby が動作するか確認してみます。

# ./mruby -e 'p "Hello, world!"'
"Hello, world!"

mrbc (コンパイラ) が動作するか確認してみます。

# vi a.rb
[1,2,3].each {|x|
 p x
}
# ./mrbc a.rb
# ./mruby -b a.mrb
1
2
3

組込みスクリプトの確認

例として、以下のようなソースコードを ホストPC 上で準備します(ファイル名は a.c とします)。

#include <mruby.h>
#include <mruby/proc.h>
#include <compile.h>

int main(void)
{
  int n;
  mrb_state* mrb;
  struct mrb_parser_state* st;
  char* code ="\
[1,2,3].each {|x|\n\
  p x\n\
}\n\
";

  mrb = mrb_open();
  if (mrb == NULL)
    goto out;

  st = mrb_parse_string(mrb, code);
  if (st == NULL)
    goto out;

  n = mrb_generate_code(mrb, st->tree);
  if (n < 0)
    goto out;

  mrb_pool_close(st->pool);
  mrb_run(mrb, mrb_proc_new(mrb, mrb->irep[n]), mrb_nil_value());
  
out:
  return 0;
}

上記をホスト PC 上にて、下記のコマンドラインでビルドします。

% sh2-linux-gcc \
  -I(mruby のディレクトリ)/include \
  -I(mruby のディレクトリ)/src \
  -Wl,-elf2flt=-ra \
  a.c \
  (mruby のディレクトリ)/lib/libmruby.a \
  -lm

出力された a.out を、擬似 TFTP 転送のため、/tmp のディレクトリにコピーします。

% cp a.out /tmp

Ash エミュレータが起動していない場合は、前述と同じ方法で Ash エミュレータを起動し、ログインした状態まで進めます。

その後、以下のようにして動作を確認できます (以降、Ash エミュレータ上の操作になります)。

# tftp -g -r a.out 10.0.2.2
# chmod +x a.out
# ./a.out
1
2
3

mruby ビルドの補足

前述の手順で mruby を make する際、コマンドラインからいくつかの変数を指定していますが、それらは各 Makefile 中で設定される変数です。 その中にはクロスコンパイラ等のツール以外の変数も含まれます。その変数と目的を以下に示します。

MRBC

mruby では、全体のビルドプロセスの中で、mrblib (ライブラリ) をビルドするために、予めビルドが行われる mrbc を実行します。 しかし、SH-2 をターゲットとする今回においては mrbc もクロスビルドを行うため、ホストPC 上で直接 mrbc を 実行することは出来ません。

そこで、前回の記事で紹介した、Ash エミュレータのユーザスペース・エミュレーションを利用し、 SH-2 向けにクロスビルドされた mrbc をホスト PC 上で実行できるように MRBC 変数を変更します。

MRBC 変数は mrblib の Makefile にて、 以下のように mrbc へのパスが設定されています。

# mruby compiler
ifeq ($(OS),Windows_NT)
MRBC = ../bin/mrbc.exe
else
MRBC = ../bin/mrbc
endif

これを、Ash エミュレータを介して mrbc を実行するコマンドラインへと変更しています。

おわりに

NOMMU 環境ではアプリケーションの制約が多く、MMU 環境で動作しているものを移植しようとしても、 そのままではビルドすら不可能なケースもあります。

しかし、現時点の mruby では、SH-2 向けにクロスビルドも可能で、簡単なスクリプト内容であれば エミュレータ上ではありますが、その動作することが確認できました。

ここまで確認することが出来たため、もう少し複雑なスクリプトや実機上で動作確認も行ってみたいですが、 長くなってしまったため、今回はここまでにしたいと思います。

システム・エミュレーション

CPU と周辺デバイスを含めたシステム全体をエミュレートするモード

ユーザスペース・エミュレーション

別アーキテクチャ用にビルドしたユーザ・バイナリを起動するためのモード

Linux、BSD 等のシステムコールをエミュレート

です。

後者が役に立つ場面は Linux のユーザランドの構築など、手順の過程でクロス・ビルドが必要になるようなケースです。 システム・エミュレーションや実機などでセルフ・ビルドを行うより効率的です。

現在公開している QEMU-Ash は、システム・エミュレーションのみ可能でしたが、 Hello, World プログラムの起動が確認できる程度に、ユーザスペース・エミュレーション に対応してみました。

ユーザスペース・エミュレータのビルド

以下に Ubuntu 11.10 での手順を示します。

(QEMU-Ash のビルドに glib2.0-dev が必要。環境に応じてインストール)
# apt-get install libglib2.0-dev
(QEMU-Ash のダウンロード、ユーザスペース・エミュレータのビルド)
% wget http://downloads.pylone.jp/ash/src/qemu-ash-0.15.1-pylone1.tar.bz2
% wget http://pylone.jp/static/qemu_ash_user_space/qemu-ash-0.15.1-pylone1-user-space.patch
% tar xf qemu-ash-0.15.1-pylone1.tar.bz2 
% cd qemu-ash-0.15.1-pylone1
% patch -p1 < ../qemu-ash-0.15.1-pylone1-user-space.patch
% ./configure --target-list=sh2-linux-user
% make

Hello World プログラムのビルド

アプリケーション開発ガイドを参考に Hello World プログラムをビルドします。

実行

Hello World プログラムの ELF ファイルを ユーザスペース・エミュレータ で起動します。

% /(QEMU-Ash を展開したディレクトリ)/qemu-ash-0.15.1-pylone1/sh2-linux-user/qemu-sh2 -L /opt/pylone/ash/host/usr/sh2-linux hello.gdb 
Hello, World!

QEMU では ユーザスペース・エミュレータにフラットバイナリ(bFLT) のロード機能も実装されていますが、 SH2 用の bFLAT はロードに失敗しました。 (詳しい原因は未調査)

おわりに

本家 QEMU のSH4 のユーザスペース・エミュレーションの実装をそのまま流用しているため完成度はまだまだ低いですが、 使い方によっては有用ではないかと思います。

Ash にキャラクタ LCD モジュール ACM1602NI-FLW-FBW を接続し文字を出力してみたり、最終的には時刻を表示する簡易的な時計を作成してみたいと思います。

キャラクタ LCD モジュールの接続

このキャラクタ LCD モジュールのインターフェイスは I2C です。 Ash には I2C バスが外部に出ていませんが、今回は GPIO ポートを利用して I2C バスを擬似的に作成（I2C_GPIO）し接続します。

各ピンの割り振りは以下のようにしました。

Linux カーネルの変更

今回は専用のドライバを作成せず、ユーザーランドから直接 I2C デバイスを操作する方法を採ります。

まず、その仕組みを提供する i2c-dev という機能を有効にします。

Device Drivers  --->
  <*> I2C support  --->
  <*>   I2C device interface

次に、ボード初期化処理で GPIO ポートを I2C バスとして登録するパッチ ash_ext_i2c.patch を適用します。

以上の変更をしたカーネルを ビルド します。

ルートファイルシステムの変更

I2C 信号の送受信をユーザーランドから操作できる i2c-tools を buildroot から 導入 します。

Package Selection for the target  --->
  Hardware handling  --->
    [*] i2c-tools

i2c-tools に含まれるコマンドはデバイスファイル /dev/i2c-<BUS_ID> を経由して i2c-dev とやり取りします。

ASCII 文字の出力

このキャラクタ LCD モジュールは英数字・記号・カタカナなど(8bit 分)のキャラクタが出力できます。詳細は製品サイトのデータシートを参照してください。

幸いなことに ASCII 文字部分に関しては制御文字を除いて ASCII コードと一致している為 ASCII 文字の出力に限っては変換テーブルを用意する必要はなさそうです。

ディスプレイの初期化手順等の説明は省きますが、例えば "a"(0x61) を出力する場合はスレーブアドレス 0x50 とデータを意味する 0x80 に続き 0x61 を I2C バス上に送信します。

これを i2c-tools に含まれる i2cset コマンドで実現するには以下のようにします。

# i2cset -y 1 0x50 0x80 0x61

i2cset コマンドの使い方は man を参照してください。引数の簡単な説明は以下の通りです。

• -y: インタラクティブ・モードを無効化
• 1: I2C バス ID

時刻の表示

コマンドの出力結果をキャラクタ LCD に出力するシェルスクリプト acm1602_print.sh を作成しました。

Ash がサポートするのシェルは hush です。bash 等の拡張機能やビルトインコマンドの一部は使用できません。

date コマンドを使用すれば現在時刻をキャラクタ LCD に出力できます。

# date '+%F (%a) %H:%M:%S' | sh acm1602_print.sh

このスクリプトの仕様は以下の通りです。

• 制御文字（改行コードも含む）を除く ASCII 文字が対象
• 32文字まで（最初の16文字が上段、次の16文字が下段に表示）
• 33文字目以降は出力されない

今回は時刻表示でしたが Ash 応用例 - SPI に接続した A/D コンバータを制御 の記事で紹介した温度センサーと組み合わせて、温度を出力してみても面白いかもしれません。

SPI 接続の A/D コンバータを Ash の Linux システム上で使ってみます。

今回、 A/D コンバータとして Microchip Technology 社の MCP3002 を、 アナログ入力として Texas Instruments 社の温度センサ LM60 を用います。

Ash との接続

以下は Ash と MCP3002 の接続図です。

ドライバの組み込み

Linux カーネルにパッチを適用します。以下は linux-3.2.15-pylone1-ash に対応したパッチです。

パッチ: sample-spi-adc-mcp300x.patch

MCP3001, MCP3004 及び MCP3008 にも対応する形で実装していますが、動作は未確認です。

カーネルコンフィギュレーションで mcp300x ドライバを有効にします (CONFIG_HWMON, CONFIG_SENSORS_MCP300X)。

Device Drivers  --->
  <*> Hardware Monitoring support  --->
    <*>   Microchip MCP300X A/D converter

make を実行し、作成されたカーネルイメージを Ash に書き込んでください。

mcp300x ドライバインターフェース

sysfs インターフェースで A/D コンバータの入力値を読み出すことができます。

以下に関連するファイルを挙げます。 単位はいずれもミリボルト (mV) です。

リファレンス電圧が 3.3V ではない場合は、in_max を適切な値に設定してください。

LM60 による温度の測定

温度 T°C の時の LM60 の出力電圧は以下のようになります。

Vo = (+6.25mV/°C x T°C) + 424mV

例えば、チャンネル 0 に接続された LM60 からの入力値が

# cat /sys/class/hwmon/hwmon0/device/in0_input
580

の場合、温度 T°C は

T = (580 - 424) / 6.25 = 約 25°C

となります。

sysfs インターフェースのチャンネル入力値に関する注意点

mcp300x ドライバにおいて、sysfs インターフェースで読み出すことができる各チャンネルの入力値は、 MCP300X の 10 ビットデジタル出力コードとリファレンス電圧を基に以下の計算で求めています。

10 ビットデジタル出力コード x リファレンス電圧 (mV) / 1024

例えば、リファレンス電圧 3.3V で 出力コード 0000000001b の時、入力値は約 3.2mV ですが、Linux カーネルでは浮動小数点は使えないため、 sysfs インターフェースで読み出す値は 3mV になることに注意してください。

また、in_max を 1024 に設定することで sysfs インターフェースで読み出す値は MCP300X のデジタル出力コードになります。

したがって、in_max を 1024 に設定し、アプリケーションが直接 MCP300X のデジタル出力コードを処理する (浮動小数点演算を行う) ことで、 (元のアナログ入力の精度や回路の作りにも依りますが) より正確な値が得られる場合もあると思います。

aitendo さんから発売されている SPI 接続の液晶モジュール「1.8インチ液晶モジュール（SPI）［M018C7735SPI］」を Ash で使ってみます。

M018C7735SPI はコントローラーとして ST7735R が使われていますが、Adafruit さんから発売されている液晶モジュール「1.8" 18-bit color TFT LCD display with microSD card breakout - ST7735R」は同じ ST7735R が使われており、Linux カーネル用ドライバ (以後、st7735fb ドライバと呼びます) が Matt Porter 氏によって開発されています。

Ash での制約

今回、st7735fb ドライバを流用しますが、Ash として以下の大きな制約があります。

• アプリケーションは fsync を実行する必要がある

st7735fb ドライバは Deferred IO を使っています。Deferred IO は MMU のページフォルトを利用しているため、Ash の非 MMU 環境では期待した動作をしません。 具体的にはアプリケーションが描画処理を行っても、ドライバ内の仮想画面が更新されるだけで、実際の画面には反映されません。

但し、幸いにも Deferred IO が fsync をサポートしているため、アプリケーションが fsync を実行することで、仮想画面を実際の画面に反映させることができます。 逆に言えば fsync を実行しなくてはいけないため、既存のフレームバッファを使用したアプリケーションを使う場合はソースコードを修正する必要があります。

このような制約はありますが、ちょっとした表示を行いたい場合には役に立つでしょう。

Ash との接続

以下は Ash と M018C7735SPI の接続図です。

なお、M018C7735SPI は 3V 単一電源ですが、今回は Ash の 3.3V 外部出力をそのまま用いています。とりあえず動作していますが、弊社で保証するものではありません。

st7735fb ドライバの組み込み

Linux カーネルにパッチを適用します。以下は linux-3.2.15-pylone1-ash に対応したパッチです。

パッチ: sample-spi-lcd.patch

カーネルコンフィギュレーションで st7735fb ドライバを有効にします (CONFIG_FB, CONFIG_FB_ST7735)。

Device Drivers  --->
  Graphics support  --->
    <*> Support for frame buffer devices  --->
      <*>   ST7735 framebuffer support

make を実行し、作成されたカーネルイメージを Ash に書き込んでください。

サンプルアプリケーション

今回、サンプルアプリケーションとして fbv (FrameBuffer Viewer) を使います。fbv は BMP, JPEG, PNG 及び GIF 形式の画像を表示することができる画像ビューワーです。

fbv の組み込み

fbv は Buildroot にパッケージとして含まれていますので、fbv を組み込んだ rootfs を作成することにします (Buildroot を使うことで、libjpeg 等の必要なライブラリも自動的に組み込まれます)。

先に述べたように、fbv のソースコードを修正する必要があります。以下は buildroot-2012.02-pylone3-ash に含まれる fbv に対応したパッチです。

パッチ: fbv-1.0b-ash.patch

Buildroot ではパッチを所定のディレクトリに置くことで自動的にパッチを適用する仕組みがあります。 fbv の場合は buildroot-2012.02-pylone3-ash/package/fbv/ にパッチを置いてください。

Buildroot のコンフィギュレーションで fbv を選択します (BR2_PACKAGE_FBV)。

Package Selection for the target  --->
  Graphic libraries and applications (graphic/text)  --->
    [*] fbv

make を実行し、作成された rootfs イメージを Ash に書き込んでください。

fbv の実行

パッチを適用した Linux カーネルと fbv を組み込んだ rootfs を書き込んだ Ash を起動し、 コンソールから画像ファイルを指定して fbv コマンドを実行してください。

# fbv /PATH/TO/IMAGE.FILE 

fbv は画像のパンやリサイズといった機能もあります。詳しくは fbv のヘルプを参照してください。

Ash に microSD カード・スロットを接続し microSD カードを利用してみます。

microSD カード・スロットの接続

Ash の SPI バスにカードスロットを接続します（SPI モード）。

Linux カーネルの変更

MMC_SPI 関連のオプションを有効にします。

Device Drivers  --->
  <*> MMC/SD/SDIO card support  --->
  <*>   MMC block device driver (NEW)
  (8)     Number of minors per block device (NEW)
  [*]     Use bounce buffer for simple hosts (NEW)
  <*>   MMC/SD/SDIO over SPI

VFAT 関連のオプションを有効にします。

File systems  --->
  DOS/FAT/NT Filesystems  --->
    < > MSDOS fs support
    <*> VFAT (Windows-95) fs support
    (437) Default codepage for FAT
    (iso8859-1) Default iocharset for FAT
    < > NTFS file system support
  Native language support  --->
    (iso8859-1) Default NLS Option
    <*>   Codepage 437 (United States, Canada)
    ....
    <*>   NLS ISO 8859-1  (Latin 1; Western European Languages)
    ....

ボード初期化処理で SPI デバイスを登録するパッチ ash_mmc_spi.patch を適用します。

以上の変更をしたカーネルをビルドします。

microSD カードをマウント

上記の変更したカーネルで起動して、 microSD カードを挿入するとシリアル・コンソールに以下のようなメッセージが出力されます。

mmc0: host does not support reading read-only switch. assuming write-enable.
mmc0: new SD card on SPI
mmcblk0: mmc0:0000 00000 1.86 GiB
 mmcblk0: p1

この状態で以下のコマンドを実行しマウントします。

# mount /dev/mmcblk0p1 /mnt

df コマンドで使用状況を確認してみます。

# df
Filesystem           1K-blocks      Used Available Use% Mounted on
ubi0_0                    9952      1848      8104  19% /
/dev/mmcblk0p1         1954496    103840   1850656   5% /mnt

以下のコマンドでアンマウントします。

# umount /mnt

microSD カードを抜くと以下のメッセージがシリアル・コンソールに出力されます。

mmc0: SPI card removed

パース対象の XML として、Weather Hacks の「お天気 Web サービス」で配信されている XML データを使用します。

Ash 固有の機能やハードウェアなどには依存しないので、まずは開発ホストで試してみるのがいいでしょう。

Weather Hacks の XML を取得する

お天気 Web サービスの仕様 に従って XML データを取得します。

「東京の明日」であれば、リクエスト URL は

http://weather.livedoor.com/forecast/webservice/rest/v1?city=63&day=tomorrow

となります。city=63 が「東京」、day=tomorrow が「明日」を指定するパラメータです。詳しくは お天気 Web サービスの仕様を参照してください。

リクエストして取得した XML データを weather-tokyo-tomorrow.xml に保存するとしたら以下のようにすればよいでしょう。

$ wget -q -O - "http://weather.livedoor.com/forecast/webservice/rest/v1?city=63&day=tomorrow" > weather-tokyo-tomorrow.xml

xmllint でパース

取得した XML データ weather-tokyo-tomorrow.xml の内容は

<lwws version="livedoor Weather Web Service 1.0">
    <author>livedoor Weather Team.</author>
    <location area="関東" pref="東京都" city="東京" />
    ...
    <telop>曇時々晴</telop>
    ...
</lwws>

のようになっているはずです。

これを xmllint でパースし、<telop/> のテキストノードを取得してみます。

--shell オプションによりxmllint を対話型モードで実行すると、xmllint 組込みシェルコマンドの入力待ち状態となります。

$ xmllint --shell weather-tokyo-tomorrow.xml
/ >

xmllint のシェルコマンドには色々ありますが、ここでは cat を使って <telop/> のテキストノードを表示してみます。

cat は対象を XPath で指定できます。欲しいのは <telop/> のテキストノードです。 XPath で表すと /lwws/telop/text() になりますので、cat の実行は以下のようになります。

/ > cat /lwws/telop/text()
 -------
曇時々晴
/ >

シェルのコマンドは標準入力から流し込むこともできます。

$ echo "cat /lwws/telop/text()" | xmllint --shell weather-tokyo-tomorrow.xml
/ > cat /lwws/telop/text()
 -------
曇時々晴
/ >

プロンプトなど不要な行を除いて「曇時々晴」だけを取り出してみます。

$ echo "cat /lwws/telop/text()" | xmllint --shell weather-tokyo-tomorrow.xml | tail -2 | head -1
曇時々晴

シェルスクリプトにする

XML を取得する処理とパースする処理を組み合わせてシェルスクリプト weather-tokyo-tomorrow.sh を作成します。

#!/bin/sh
# weather-tokyo-tomorrow.sh - 天気予報（東京の明日）を表示する
wget -q -O - "http://weather.livedoor.com/forecast/webservice/rest/v1?city=63&day=tomorrow" > weather-tokyo-tomorrow.xml
echo "cat /lwws/telop/text()" | xmllint --shell weather-tokyo-tomorrow.xml | tail -2 | head -1

Ash でシェルスクリプトを実行

Ash 向けに xmllint を含んだルートファイルシステムを buildroot で構築します。

buildroot の menuconfig で libxml2 を追加したルートファイルシステムを作ります。

$ cd (buildroot のディレクトリ)
$ make menuconfig
Package Selection for the target  --->
  Libraries  --->
    JSON/XML  --->
      [*] libxml2
$ make

作成したルートファイルシステムで起動した Ash に、シェルスクリプト weather-tokyo-tomorrow.sh を転送し実行します。

# ./weather-tokyo-tomorrow.sh
曇時々晴

リンク

• The XML C parser and toolkit of Gnome
• xmllint

外部から HTTP で GPIO を制御する簡単な HTTP サーバを Ash で動かしてみます。 HTTP サーバの実装には libmicrohttpd を使用します。

写真は GPIO に LED をつなげて Web ブラウザからの制御を確認しているところです。

libmicrohttpd を使ってみる

GPIO を制御する前に A tutorial for GNU libmicrohttpd の Hello browser example を Ash で動かしてみます。

ソースコード: hellobrowser.c

まず、buildroot で libmicrohttpd をビルドします。

Package Selection for the target  --->
  Libraries  --->
    Networking  --->
      [*] libmicrohttpd
      [ ]   https support (NEW)

hellobrowser.c をダウンロードして Ash 向けにクロスコンパイルします。

(ダウンロード)
$ wget http://pylone.jp/static/ash-cookbook-libmicrohttpd/hellobrowser.c
(クロスコンパイル)
$ sh2-linux-gcc \
  -Wl,-elf2flt=-ra \
  -I(buildroot のパス)/output/staging/usr/include \
  -L(buildroot のパス)/output/staging/usr/lib/ \
  hellobrowser.c -o hellobrowser \
  -lmicrohttpd -lpthread

実行ファイル hellobrowser を Ash に転送し、Ash 上で実行します。

# ./hellobrowser

外部から Web ブラウザで http://(Ash の IP アドレス):8888/ を開きます。

ブラウザに Hello, browser! と表示される筈です。

HTTP で GPIO を制御

hellobrowser.c に GPIO を制御する処理を追加してみます。

ソースコード: gpio.c

動作としては、

• http://(Ash の IP アドレス):8888/on を開くと GPIO (J2-3) が H
• http://(Ash の IP アドレス):8888/off を開くと GPIO (J2-3) が L

という単純なものです。

GPIO を制御するには Ash 応用例 - GPIO に接続した LED を制御 で紹介した 方法 1: sysfs インターフェースでGPIOを制御 を使いますので、CONFIG_GPIO_SYSFS を有効にしたカーネルを用意します。

Device Drivers  --->
  [*] GPIO Support  --->
    [*]   /sys/class/gpio/... (sysfs interface)

gpio.c をダウンロードして Ash 向けにクロスコンパイルします。

(ダウンロード)
$ wget http://pylone.jp/static/ash-cookbook-libmicrohttpd/gpio.c
(クロスコンパイル)
$ sh2-linux-gcc \
  -Wl,-elf2flt=-ra \
  -I(buildroot のパス)/output/staging/usr/include \
  -L(buildroot のパス)/output/staging/usr/lib/ \
  gpio.c -o gpio \
  -lmicrohttpd -lpthread

CONFIG_GPIO_SYSFS を有効にしたカーネルで動作する Ash に実行ファイル gpio を転送し、GPIO の設定を行ってから実行します。

# echo 36 > /sys/class/gpio/export (J2-3 を GPIO として有効にする)
# echo out > /sys/class/gpio/gpio36/direction (出力設定)
# ./gpio

Web ブラウザで http://(Ash の IP アドレス):8888/on または http://(Ash の IP アドレス):8888/off を開くと GPIO が制御できる筈です。

リンク

• A tutorial for GNU libmicrohttpd

Ash の GPIO に LED を接続して、Linux システムのユーザー空間から制御してみます。

ここでは2つの方法を紹介します。

1. Linux カーネルにはユーザー空間から sysfs インターフェースで GPIO を制御するための機能があり、それを利用する方法
2. Linux カーネルには GPIO 接続の LED を制御するためのドライバ（leds-gpio）があり、それを利用する方法

方法 1: sysfs インターフェースでGPIOを制御

Ash の Linux カーネルのデフォルトコンフィギュレーションでは機能が無効になっているため、有効にする必要があります（CONFIG_GPIO_SYSFS）。

Device Drivers  --->
  [*] GPIO Support  --->
    [*]   /sys/class/gpio/... (sysfs interface)

機能を有効にしたカーネルを起動して、制御したい GPIO 番号を /sys/class/gpio/export に書き込みます。

ここで GPIO 番号は Linux カーネルで定義された値で、Ash では以下のようになります。

次に入出力方向を設定します。/sys/class/gpio/gpio{GPIO番号}/direction に "in" または "out" を書き込みます。 /sys/class/gpio/gpio{GPIO番号}/value に 0 もしくは非 0 を書き込むことで、それぞれ low、high を出力します。それによって LED が消灯、点灯します。

例えば、J2-3 の場合、

# echo 36 > /sys/class/gpio/export (J2-3をGPIOとして有効にする)
# echo out > /sys/class/gpio/gpio36/direction (出力設定)
# echo 1 > /sys/class/gpio/gpio36/value (点灯)
# echo 0 > /sys/class/gpio/gpio36/value (消灯)

となります。

方法2: leds-gpio ドライバ

Ash の Linux カーネルのデフォルトコンフィギュレーションではドライバは無効になっているため、有効にする必要があります（CONFIG_NEW_LEDS, CONFIG_LEDS_CLASS, CONFIG_LEDS_GPIO）。

Device Drivers  --->
  [*] LED Support  --->
    --- LED Support
    [*]   LED Class Support
    ...
    <*>   LED Support for GPIO connected LEDs

また、ドライバに対応したデバイスを登録する必要があります。そのためにソースコードの修正が必要です。 以下のパッチは修正例です。各 LED の名前は区別できれば何でも構いません。

パッチ: sample-gpio-led.patch

ドライバを有効にし、デバイスの登録を行うようにしたカーネルを起動します。 /sys/class/leds/{名前}/brightness に 0 以上の値を書き込むことでLEDの制御ができます。0 は消灯、それ以外は点灯です。

例えば、J2-3に接続された LED の場合（LED の名前はパッチを適用したものを仮定しています)、

# echo 1 > /sys/class/leds/J2-3/brightness (点灯)
# echo 0 > /sys/class/leds/J2-3/brightness (消灯)

カーネル空間で GPIO 接続の LED を扱いたい場合にも、leds-gpio ドライバ（及び LED トリガー）を用いることで柔軟な制御ができます。

Ash 向け TOPPERS/ASP の詳しい使い方については下記のドキュメントを参照してください。 また先日お知らせいたしました Ash エミュレータ上でも起動を確認することが出来ます。

尚、本ソフトウェアは株式会社パイロンが独自に配布する非公式なバージョンです。

ドキュメント

• TOPPERS/ASP カーネル for Ash マニュアル
• Ash エミュレータマニュアル

Interface (インターフェース) 2012年 05月号 [雑誌]
価格:￥980

特集内容はシミュレータやエミュレータを使用した実機を伴わない組込み開発についてで、 今回は 「SH-2エミュレータでLinuxとTOPPERSを起動しよう」と題し、Ash エミュレータの使い方についての記事を執筆しました。

今月号では他にも QEMU の概要から詳しい使い方、さらには内部構造についても触れており、 組込み開発向けに QEMU を色濃く取り上げた内容となっています。

尚、記事内容の補足については本エントリに順次追記していきます。

記事内容の補足

EXT4 上で動作が遅い

EXT4 ファイルシステムを利用したLinux ホスト環境下で、記事の手順にて QEMU-Ash を起動すると、ゲストソフトウェアによっては QEMU-Ash の動作が極端に遅くなる場合があります。 詳細な原因と解決方法は下記のリンク先を参照してください。

• Ash エミュレータマニュアル: EXT4 上で動作が遅い

関連ページ

• Ash エミュレータマニュアル
• Ashエミュレータに関するブログ記事

Ash エミュレータとは、先日発売しました SH-2 搭載 Linux 対応小型 CPU ボード Ash のエミュレータで、 Ash 用にパイロンが公開した各種ソフトウェアの起動の確認を PC 上で行って頂く事を主な目的としています。

Ash エミュレータの詳しい使い方については下記のドキュメントを参照してください。

ドキュメント

• Ash エミュレータマニュアル

ダウンロード

SH-2搭載Linux対応小型CPUボードAshの発売についてご案内いたします。

製品概要

ハードウェア

• ルネサスエレクトロニクス SH7619（コアクロック:117MHz）
• 32MB SDRAM
• 16MB NOR Flash ROM
• 10/100Base-TX Ethernet（CPU 内蔵 PHY）
• デバッグ用シリアル I/F（USB-シリアルコンバータ内蔵）
• 外部 I/O: SPIx1, UARTx1, GPIOx8, RTC バックアップ電源, 外部電源
• 汎用 DIP スイッチ: 3ビット
• RTC: SII S−35190A（電気二重層コンデンサにて約 650 時間のバックアップ）
• 消費電力: 最大約400mA
• 基板寸法: 85mm x 35mm
• 温度範囲: 0-50℃
• 電源: USB コネクタまたは外部電源より DC+5V

ソフトウェア（Linux）

プリインストールされるのはLinuxです。

• Linux 3.2.0
• u-boot v2011.09
• buildroot v2012.02
• uClibc 0.9.31
• busybox 1.19.4
• gcc 4.6.2
• QEMU 0.15.1

ソフトウェア（TOPPERS）

• TOPPERS/ASPカーネル 1.7.0

価格

発売日

2012年3月24日

購入方法

弊社の通信販売でお求め頂けます。

ある程度の規模のプロジェクトのビルドを効率化したり、 LinuxカーネルやAndroid、OpenJDKなどで使われている（kbuild)ビルド機構を理解するのに役立つでしょう。 記述はGNU Makeの拡張機能が使えることを前提としていますが、BSD系のmakeでも類似の技法は機能するはずです。

Recursive Make Considered Harmful

過去にはよく使われたmakefileの書きかたとして、makefileのルールから別のmakeを (recursiveに) 呼びだす、というものがありました。 そのようなmakeの使い方は

• なぜかビルドにとても時間がかかる
• ときどきファイルが正しく再生成されない

といった問題を起こすのでやめるべきといわれて10年以上たちますが、いまだにそのような構成のプロジェクトはよく見られます。 makefileを適当に動くものを雛形にして作るなら、できるだけ内容を理解して適切なコピー元を選びましょう。

サンプルプロジェクト

以降では例としてソースファイルの構成が

- (toplevel)
  - src/
      main.c
  - parser/
      parser.grammar

ビルド手順は

1. parser.grammarからパーサジェネレータ(lemon)でparser.cとparser.hを生成
2. parser.cをコンパイルしてparser.oを生成
3. parser.hとmain.cからmain.oを生成
4. main.oとparser.oをリンクして実行ファイルappを生成

という場合を想定したmakefile群の書き方を考えます。

分割しない場合

今回の例のサイズであれば、単一のmakefileに全ての依存関係を書く：

all: app

src/main.o: src/main.c parser/parser.h

parser/parser.o: parser/parser.c
parser/parser.c parser/parser.h: parser/parser.grammar
        lemon $<

app: src/main.o parser/parser.o
        $(CC) $(LDFLAGS) -o $@ $+

ことも十分可能です。

しかし、現実的なサイズのプロジェクトを単一のmakefileでビルドするのは難しいでしょう。

再帰バージョン

旧い方法に従うと、

1. サブディレクトリのためのmakefile群 (parser/Makefile, src/Makefile) を用意する
2. トップレベルのMakefileのルールとして、サブディレクトリでmakeを実行する

ということになります。

トップレベルのMakefile

parser/、src/それぞれのディレクトリでmakeコマンドを起動することになります。

#Makefile
SUBDIRS := parser src
all: $(SUBDIRS) app

$(SUBDIRS):
        $(MAKE) -C $@

app: src/main.o parser/parser.o
        $(CC) $(LDFLAGS) -o $@ $+

.PHONY: all $(SUBDIRS)

サブディレクトリのmakefile

関連するファイルの生成規則だけを含むように分割すると

#parser/Makefile
parser.o: parser.c
parser.h parser.c: parser.grammar
        lemon $<

#src/Makefile
main.o: main.c ../parser/parser.h

となるでしょう。

再帰的makeの問題点

とりあえず使える程度の動作はしますが、

• 必要がなくても下位makeプロセスが起動されるので遅い
• makeに平行処理を許した (たとえば make -j3) 場合はビルドに失敗することがある

といった問題を解決するのは困難です。

非再帰バージョン (include directive)

GNU Makeの、makefile内に別のファイルを読み込む拡張機能(include directive)を使えばmakefileの一部を別のファイルへと分割可能です。

この例の場合、src/、parser/以下の依存関係を

#src/build.mk
src/main.o: src/main.o parser/parser.h

および

#parser/build.mk
parser/parser.o: parser/parser.c
parser/parser.h parser/parser.c: parser/parser.grammar
        lemon $<

として抜きだして、トップレベルのMakefileからそれぞれを読みこむ

#Makefile
all: main

main: src/main.o parser/parser.o
        $(CC) $(LDFLAGS) -o $@ $+

include src/build.mk
include parser/build.mk

ようにできます。

非再帰バージョン (下位へのパラメータ渡し)

前の例ではincludeされるファイル内で明示的にディレクトリ名 (src/、parser/) を都度書いていますが、もしこれを修正することになるとかなりの手間がかかります。 makeの変数を使ってincludeする側から渡すようにして、ディレクトリ名に依存してしまう要素を減らしましょう。

makeの変数RELに対象ディレクトリ名が格納されるようにすれば、(ディレクトリ名を$(REL)に置きかえることで) src/build.mkを

$(REL)main.o: $(REL)main.c parser/parser.h

parser/build.mk を

$(REL)parser.o: $(REL)parser.c
$(REL)parser.c $(REL)parser.h: $(REL)parser.grammar
        lemon $<

のように書きなおすことができます。

この場合、トップレベルのmakefile側でincludeする前にRELを設定しておく

all: app

REL := src/
include $(REL)build.mk

REL := parser/
include $(REL)build.mk

app: src/main.o parser/parser.o
        $(CC) $(LDFLAGS) -o $@ $+

ことになります。 なお、includeされるファイル毎に値を変えたいRELはsimply-expanded な (:=を用いた) 変数にしないと、最後の定義によって全ての$(REL)の値が上書きされてしまうことに注意してください。

非再帰バージョン (上位へのパラメータ渡し)

関連するオブジェクトファイルが多くなる場合、すべてを手作業で列挙するのは危険なので、includeされる側でファイルのリストを構築した方がよいでしょう。

トップレベルのmakefileを(simply-expandedな)変数OBJSを利用するように：

all: app
OBJS :=

REL := src/
include $(REL)build.mk

REL := parser/
include $(REL)build.mk

app: $(OBJS)
        $(CC) $(LDFLAGS) -o $@ $+

書いておくと、OBJSはmakefile全体で共有されるため、 src/build.mk、parser/build.mk内でOBJSへ加えた変更がトップレベルの "app" のルール処理に反映されます。

src/build.mk、parser/build.mk 内では、

# src/build.mk
OBJS += $(REL)main.o

# parser/build.mk
OBJS += $(REL)parser.o

のようにして、必要なオブジェクトファイルを順に追加していけばよいでしょう。

ただし、includeされる側で行なう操作はリストへの追加だけにするべきです。リスト自体を上書きしてしまう (「+=」ではなく「:=」を使う)

OBJS := $(REL)foo.o

と、グローバルなOBJSの内容は破壊されます。 下位のmakefileの作成者が信用できないなら、OBJSへの操作を (includeされる側には委ねないで) 上位側に移した方がよいかもしれません。

非再帰バージョン (自動include)

下位ディレクトリが多数存在し、それぞれに対する個々のincludeをトップレベルに書きたくない場合、GNU Make自身に等価な記述を生成させることができます。

下位のmakefileの名前をbuild.mkとしたとき、build.mkが存在する下位ディレクトリのリストは

$(dir $(wildcard */build.mk))

で得られます。これと

• 引数を与えると

        REL := [引数のディレクトリ名]
        include $(REL)build.mk

  を生成するmakeのユーザー定義関数
• 組み込み関数foreachによるリスト要素への関数適用

を組み合わせれば、下位ディレクトリのbuild.mkを自動的にincludeするmakefileを

all: app

SUBDIRS := $(dir $(wildcard */build.mk))
OBJS :=

define include_fragment
 REL:= $(1)
 include $(1)build.mk
endef

$(foreach i, $(SUBDIRS), \
        $(eval $(call include_fragment, $(i))))

app: $(OBJS)
        $(CC) $(LDFLAGS) -o $@ $+

のように書くことができます。

こうしておけば、下位ディレクトリを追加した際にはbuild.mkを置くだけでトップレベルのmakefileから自動的に読みこまれます。 あとからmakefileを解読するのは難しくなってしまいますが、目的によっては便利に使えるのではないでしょうか。

ターゲットごとに変数値を設定

includeを使ってmakefileを合成する場合、makeの変数は全体で共有されます。 しかし、一部のターゲットについてだけCFLAGS、LDFLAGSといった変数の値を変更したい場合もあるでしょう。

幸いGNU Makeには

ターゲット : 変数定義

とすることで、ターゲットごとの変数値を設定する機能 (target-specific variable value) が存在します。

たとえば main.o の生成規則を

$(REL)main.o: $(REL)main.c parser/parser.h

として定義していたとき、

$(REL)main.o: CFLAGS += -I parser/
$(REL)main.o: $(REL)main.c parser/parser.h

のように定義を追加することで、このルールを実行する時だけ CFLAGS に「-I parser/」が追加されます。

この機能はincludeディレクティブによって展開された時点の変数の値を保存しておくのにも使えるので、makefile自体のデバッグにも役立ちます。たとえば

$(REL)parser.o: LOCAL_REL := $(REL)
$(REL)parser.o: $(REL)parser.c
        @echo "LOCAL_REL=" $(LOCAL_REL)
        $(CC) $(CFLAGS) -c -o $@ $<

とすれば、上書きされてしまう前にRELを保存しておいて確認することもできるでしょう。

まとめ

新しく作るmakefileでは「$(MAKE) -C」を止めて「include」を使いましょう。

makefileを書くとき、makeの出力に大量の「Entering directory」「Leaving directory」(残念な環境では「入りますディレクトリ」) といったメッセージが含まれるようなプロジェクトを参考にするのは避けるべきです。

Logic Cube LAP-C(16032)

ZEROPLUS 社製 ロジックアナライザ Logic Cube を紹介します。 Logic Cube にはいくつかのラインナップがありますが、本記事で紹介するのはローエンドモデルの LAP-C(16032) です。

パイロンでは、カスタムボードにブートローダや OS を移植する際やデバイスドライバ開発のデバッグに大変重宝しています。また、コンパクトでUSBバスパワーで動作するので客先出張デバッグでも役立っています。

リンク先のサイトを見て頂ければわかる通り、実に様々なプロトコルに対応しています。 標準で添付される、7-SEGMENT LED, I2C, SPI, UART(RS-232C/422/485) に加えて、オプションとしてライセンス購入によりプロトコルが追加できます。

パイロンでは ストロベリー・リナックス さんから購入しました。

本記事執筆時点ではプロトコル解析が30本無料となっているようです。

ロジック・アナライザ

バスタイミングの設定やドライバ開発のデバッグにおいて

• バスタイミングに従った波形が出ているか
• (その波形から)プロトコルが成立しているか

この2点が確認できればざっくりとした問題の切り分けが可能になります。

ロジアナでは波形の確認もさることながら、その波形からプロトコルを解析しグラフィカルに表示してくれるので容易にプロトコルの確認が行えます。

RTC(via I2C)のデバッグを例にとると、RTCが動作しない場合はI2CドライバとRTCドライバの両方を疑う必要があります。

1. そこでまず、I2Cコントローラを制御しきちんとした波形が出ていることが確認できればI2Cドライバは問題なさそうと判断できます。
2. 次に、その波形からプロトコルを読み取ることができれば、RTCドライバのどの箇所が問題なのかが判明します。

といった具合にロジアナがあるとデバッグがグッと楽になります。

SBC6000X上での使用

では実際に SBC6000X で使用してみます。

RTCをプローブしI2Cバス上の通信を見てみます。I2CではSDAとSDLとGNDの3本をプローブします。 RTCチップは基板上のU32のRX8025SAです。

各ピン配置は以下のようになっています。

よって、写真のように付属のクリップ(白と黒)を使って茶色線(A0)をPin13に、赤色線(A0)をPin4に、黒色線(GND)をPin11に接続します。

アプリの設定方法は省略しますがアプリ設定後、本体のボタンを押すかアプリのRun[F5]を押したらhwclockコマンドを実行しRTCとの通信を発生させます。

すると以下のようなスクリーンショットの結果が得られます。

RTCのI2Cアドレスである0x32に対して

1. (時刻)データを要求(write)し
2. (時刻)データの応答(read)

があるのが見て取れると思います。

最後に

組込み系のデバッグではロジアナによる可視化が問題の切り分けの手助けになることがあります。

通常のロジアナはオシロのようにモニタを有し単体で動作するものが一般的ですが、その中で Logic Cube は画面出力をPCのモニタに任せることによりコンパクトでかつ低価格な製品になっています。

昨今のAndroidブームで評価ボードを個人で所有されている方もいるかと思います。デバッグのお供にこの Logic Cube も所有してみても面白いのではないでしょうか。 個人的にはLinuxから使えれば満点をあげたい製品です。

ベースにした QEMU のバージョンは 0.15.1 です。

概要

ARM926 は本家 QEMU でサポートされているため、同コア の SoC を搭載したプラットフォームがいくつかサポートされています。 しかし、同コアを使用した SBC6000X のマイクロプロセッサである AT91SAM9261 は今のところサポートされていません。

そこで、Linux の起動に必要となる周辺デバイスのエミュレーションを追加しました。

現状

SBC6000X 用 Linux が起動できる必要最小限のエミュレーションを目標にしたため、実機を完全にエミュレート出来るまでに至っていません。

クイックスタート

ホスト OS として Debian GNU/Linux Squeeze を例に説明します。

SBC6000X 用の Buildroot を用いたビルド にて環境一式が整っていることを前提とします (以降、SBC6000X 用 Buildroot のディレクトリを ~/buildroot-sbc6000x とします)。

現時点では、NAND デバイスをまだエミュレートできないため、ここでは、rootfs に NFS を使用します。 以下の設定を追加し、反映します (以降、NFS として export するディレクトリを /opt/sbc6000x とします)。

# vi /etc/exports
/opt/sbc6000x    127.0.0.1(rw,sync,subtree_check,no_root_squash,insecure)
# exportfs -a

次に、QEMU をビルドするためのライブラリ (開発版パッケージ) をインストールします。 既にインストール済みの場合は不要です。

# apt-get install libglib2.0-dev
# apt-get install zlib1g-dev
# apt-get install libsdl1.2-dev

最後に、ビルドして実行するまでの手順です。

$ mkdir ~/qemu-sbc6000x
$ cd ~/qemu-sbc6000x
$ wget http://downloads.pylone.jp/sbc6000x/src/qemu-sbc6000x-0.15.1-pylone1.tar.bz2
$ tar xjf qemu-sbc6000x-0.15.1-pylone1.tar.bz2
$ cd qemu-sbc6000x-0.15.1-pylone1
$ ./configure --target-list=arm-softmmu
$ make
$ ./arm-softmmu/qemu-system-arm \
      -M sbc6000x \
      -m 256 \
      -serial stdio \
      -kernel ~/buildroot-sbc6000x/output/images/uImage \
      -append "console=ttyS0 root=/dev/nfs rw nfsroot=10.0.2.2:/opt/sbc6000x ip=dhcp"

起動後にログイン可能なユーザーは "root"、または "default" (一般ユーザ) です (何れもパスワードはありません)。

終了するには、QEMU ウィンドウを閉じるか、起動した端末上で Ctrl-C を発行して QEMU を終了してください。

その他の詳しい使い方については SBC6000X エミュレータマニュアル を参照してください。

既知の問題点

起動中、まれに、

mmc0: host doesn't support card's voltages
mmc0: error -22 whilst initialising SDIO card
mmc0: host doesn't support card's voltages
mmc0: error -22 whilst initialising MMC card
mmc0: host doesn't support card's voltages
mmc0: error -22 whilst initialising SDIO card
mmc0: host doesn't support card's voltages
mmc0: error -22 whilst initialising MMC card

というタイミングで起動が停止してしまいますが、終了して再起動してみてください。

おわりに

QEMU に対して追加実装した部分の完成度はまだ低いですが、Linux の基本的な動作は確認できると思います。 SBC6000X のソフトウェアの検討や、組み込み Linux 開発の入門を目的とした使い方をしていただければ幸いです。

ドキュメント

• SBC6000X エミュレータマニュアル
• ソフトウェア仕様

組込み Linux 開発用 CPU ボード SBC6000X の発売についてご案内いたします。

本製品について

SBC6000X は Embest 社が製造販売している CPU ボードです。輸入元の 株式会社エヌ･エム･アール 様のご協力のもと、付属するソフトウェアを弊社で開発したソフトウェアに置き換えて提供させていただきます。

価格

発売日

2011年10月24日

購入方法

弊社の通信販売でお求め頂けます。

製品概要

ハードウェア

• Atmel AT91SAM9261 SoC (16KB I-Cache, 16KB D-Cache, MMU)
• 64MB SDRAM
• 128MB NAND Flash
• SD (SD Host interace version 1.0)
• USB 2.0(Full Speed) Host x2
• USB 2.0(Full Speed) Device x1
• 100Base-T Ethernet x1
• UART x2
• Audio (CODEC: TSC2301)
• RTC
• 20ビットバス x1
• SPI x1
• USB x1
• UART x1

ソフトウェア

• u-boot-2010.09
• linux-3.0.4
• buildroot-2011.08
• uClibc-0.9.32
• gcc-4.5.3

概要

クロス開発環境のDebianパッケージ (gcc-4.4) を参照してください。

対応状況

クロス開発環境のDebianパッケージ (gcc-4.4) を参照してください。

yumによるインストール (Fedora)

以下の内容で/etc/yum.repos.d/pylone-jp.repoを作成して、yumレポジトリを追加します。

[cross-toolchain]
name=Cross Toolchain
baseurl=http://downloads.pylone.jp/cross-toolchain/squeeze/rpm/
enabled=1
gpgcheck=0

必要なツールをインストールします。 TARGET-SUFFIX は arm-linux-gnueabi、mipsel-linux-gnu、sh4-linux-gnu、powerpc-linux-gnu の何れかに置き換えてください。

gcc-4.4

# yum install gcc-4.4-TARGET-SUFFIX-linux-gnu

g++-4.4

# yum install g++-4.4-TARGET-SUFFIX-linux-gnu

gdb

# yum install gdb-TARGET-SUFFIX-linux-gnu

依存関係について

alienによる変換ではパッケージ間の依存関係が一部われますが、本パッケージではspecファイルを修正して依存関係を追加しています。

更新履歴

• 2010/11/22: 公開

更新履歴

• 2010/11/16: 公開
• 2010/12/17: powerpcspeを追加

概要

• ホストアーキテクチャ: i386
• ターゲットアーキテクチャ: armel, mipsel, powerpc, sh4, powerpcspe^New!
• コンパイラ: gcc-4.4, g++-4.4
• ターゲットのlibc: testing (squeeze) の eglibc
• biarch: 無効

基本的には (2010/11/11時点の) squeeze の binutils と gcc-4.4 を debian/README.cross 等の手順にそってビルドしたものですが、 依存するパッケージを調整するなどして、lenny にもインストールできるようにしてあります。

powerpcspe だけは sid/squeeze でないとインストールできません。

対応状況

• ○:動作を確認済み
• △:パッケージはあるが、まだ動作が確認できていないもの

インストール

sources.list (5) に以下の apt line を加えます。

deb http://downloads.pylone.jp/cross-toolchain/squeeze/deb ./

(まだ行っていなければ) pylone.jp の鍵を導入します。

# wget http://pylone.jp/pubkey.asc -O - | apt-key add -

パッケージ情報を更新します。

# apt-get update

必要なツールをインストールします。TARGET-SUFFIX は arm-linux-gnueabi, mipsel-linux-gnu, sh4-linux-gnu, powerpc-linux-gnu, powerpc-linux-gnuspe の何れかに置き換えてください。

gcc-4.4

# apt-get install gcc-4.4-TARGET-SUFFIX

g++-4.4

# apt-get install g++-4.4-TARGET-SUFFIX

gdb

# apt-get install gdb-TARGET-SUFFIX

リンク

• Embedded Debian Cross Development Environments
• クロス開発環境のDebianパッケージ (gcc-3.4, gcc-4.1)

さて、この度弊社では業務拡大に伴い、下記に本社移転することになりましたのでご案内申し上げます。

これを機に、皆様の信頼にお応えできるよう倍旧の努力をしてまいる所存でございます。今後とも一層のご支援ご指導のほどお願い申し上げます。

新住所

〒160-0023 東京都新宿区西新宿7-11-3 平田ビル4F

2010年6月8日をもちまして組込みLinux開発用CPUボード Bishop 6.4インチLCDタイプPE-201Bの販売を終了致します。

なお、4インチLCDタイプPE-201Aは引き続き販売を継続いたします。

今後とも、弊社ならびに弊社製品をご愛顧賜りますよう、お願い申しあげます。

本件に関するお問い合わせ

E-mail: sales@pylone.jp

Freescale社ではADS512101用のLinuxBSPを公開しており、ソースコードから環境を構築することが可能ですが、Linuxカーネルのバージョンが2.6.24と若干古いため、比較的新しいバージョンを移植することが目的です。

予め

• PowerPC向けクロス開発ツール
• tftpサーバ

をインストールした環境を前提とします。

尚、使用するU-Boot、及びLinuxカーネルのバージョンは以下のとおりです。

• U-Boot 2009.1
• Linuxカーネル 2.6.28

U-Bootのビルド

オフィシャルサイトからソースコードを取得し、展開します。

% wget ftp://ftp.denx.de/pub/u-boot/u-boot-2009.01.tar.bz2
% tar xjfv u-boot-2009.01.tar.bz2

ターゲットにADS5121を指定してビルドします。

% cd u-boot-2009.01
% make ads5121_config
% CROSS_COMPILE=powerpc-linux-gnu- make

Linuxカーネルのビルド

オフィシャルサイトからソースコードを取得し、展開します。

% wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.28.tar.bz2
% tar xjfv linux-2.6.28.tar.bz2

ADS5121ボード用(v2.6.28向け)のパイロン製パッチを取得・適用します

% wget http://code.pylone.jp/hg/linux-2.6-ads5121-mq/raw-file/tip/ads5121
% cd linux-2.6.28
% patch -p1 < ../ads5121

カーネル設定ファイルを設置後、必要に応じて設定を変更しビルドします(デフォルトでU-Boot形式が生成されます)。

% cp arch/powerpc/configs/ads5121_defconfig .config
% ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- make menuconfig
% ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- make

デバイスツリーのビルド

デバイスツリーとは簡単に説明すると、

• PowerPC/Linux固有の仕組みで、ボード依存のデバイス情報(I/Oアドレス等)を定義したもの
• デバイスツリーを定義したソースファイル(*.dts)をコンパイラ(dtc)にてコンパイルしバイナリファイル(*.dtb)を得る
• *.dtbファイルはLinuxカーネルイメージとは別にメモリ上に置かれ、Linuxカーネルはその内容からボードに関する各デバイス情報を把握する

といったものです。

デバイスツリーコンパイラはLinuxカーネルに含まれているため、以下の様にしてADS5121向けデバイスツリーソースをコンパイルします。

% cd (Linuxカーネルのディレクトリ)/arch/powerpc/boot
% ./dtc -O dtb -o ads5121.dtb dts/mpc5121ads.dts

Flash更新

tftpに備えて、これまで生成したバイナリファイルを、tftpサーバのディレクトリ(/srv/tftp/とします)にコピーしておきます。

# cp (U-Bootのディレクトリ)/u-boot.bin /srv/tftp/
# cp (Linuxカーネルのディレクトリ)/arch/powerpc/boot/uImage /srv/tftp/
# cp (Linuxカーネルのディレクトリ)/arch/powerpc/boot/ads5121.dtb /srv/tftp/

シリアルコンソールとしてシリアルクロスケーブルをHostPCとボードを接続します。通信設定は以下のとおりです。

ボードの電源を投入後、SW1を押下しボード標準のU-Bootを起動します。このとき、

Hit any key to stop autoboot:  

のカウントダウンが開始されたらキャンセルします。

tftpに備え、必要に応じて環境変数を設定します。 (ここでは、tftpサーバとなるHostPCのIPアドレスを192.168.0.26、ボードのIPアドレスを192.168.0.120とします)

=> setenv netmask=255.255.255.0
=> setenv ipaddr=192.168.0.120
=> setenv serverip=192.168.0.26

先ほどビルドしたU-BootをFlashに書き込みます。FlashのI/O開始アドレスは 0xFC000000 で、内容は以下の様になっています。

まず、更新するU-BootをRAM上のダウンロード領域(0x20000000)へダウンロードします。

=> tftp 2000000 u-boot.bin
Using FEC ETHERNET device
TFTP from server 192.168.0.26; our IP address is 192.168.0.120
Filename 'u-boot.bin'.
Load address: 0x2000000
Loading: ################################################
done
Bytes transferred = 241680 (3b010 hex)

そして、Flashのライトプロテクトを解除、該当のセクタを消去し、書き込みます。

=> protect off bank 1
=> erase 1:252-252
=> cp.b 2000000 fff00000 3b010

上記cpコマンドのサイズ(0x3b010)はtftpコマンドで実際に転送されたサイズを指定しています

Linuxカーネルを更新する場合も同様の手順になります。

=> tftp 2000000 uImage
=> protect off bank 1
=> erase 1:241-250
=> cp.b 2000000 FFC40000 <size>

FlashのライトプロテクトはU-Boot更新時に解除していますので続けて更新する場合は不要です。

デバイスファイルも同様の手順です。

=> tftp 2000000 mpc5121ads.dtb
=> protect off bank 1
=> erase 1:251-251
=> cp.b 2000000 FFEC0000 <size>

起動

ボード標準のU-Boot起動コマンドでFlash上のrootfsから起動するには以下の様にします。

=> run jffs2boot

カーネルコマンドラインを指定して起動する場合は以下の様にします

=> set bootargs console=ttyPSC0,115200 root=/dev/mtdblock1 rw rootfstype=jffs2 mem=256M
=> bootm ffc40000 - ffec0000

bootmコマンドの引数はそれぞれ、

• ffc40000 : カーネルのアドレス
• - : initial ramdiskのアドレス(未使用なので省略を示す'-')
• ffec0000 : デバイスツリーのアドレス

と言う意味になります。

Flashを更新せずにRAMから起動する場合

デバッグ段階などで、Linuxカーネルやデバイスツリーを頻繁に更新するようなケースで、毎回Flashに書き込みをしていては非効率です。そこで両ファイルをFlashに書き込まずにRAMから起動する場合は以下の様にします。

=> tftp 2000000 uImage
=> tftp 3000000 ads5121.dtb
=> set bootargs console=ttyPSC0,115200 root=/dev/mtdblock1 rw rootfstype=jffs2 mem=256M
=> bootm 2000000 - 3000000

または、Flash上のデバイスツリーファイルを使用する場合は、最後のbootmコマンドのデバイスツリーファイルのアドレスを、

=> bootm 2000000 - ffec0000

とします。

erasesize 128K (131072) のrootfs.jffs2を/mntにmountする場合

mount:

# modprobe jffs2
# modprobe mtdblock
# losetup /dev/loop0 rootfs.jffs2
# modprobe block2mtd block2mtd=/dev/loop0,131072
# mount -t jffs2 -o ro /dev/mtdblock0 /mnt

umount:

# umount /mnt
# rmmod block2mtd
# losetup -d /dev/loop0

TOPPERS/JSPカーネルとは、μITRON4.0仕様に準拠したリアルタイムカーネルで、TOPPERSプロジェクトの開発成果です。 TOPPERS/JSPカーネルの詳細についてはTOPPERSプロジェクトサイトを参照してください。

株式会社パイロンが独自に配布する非公式なバージョンです。本ソフトウェアについてTOPPERSプロジェクトへの質問はお控えください。

今回の移植は実験的なものです。実用レベルに達していないことを予めご了承ください。

移植概要

ゼロからの移植ではなく、標準TOPPERS/JSPカーネルに既に含まれる同一のCPUコアを持つシステムをベースにして移植を行いました。 BishopのCPUコアはARM920Tであるため、ベースにするシステムはIntegrator/AP+CM920Tとしました。

また、サポートしたデバイスは、TOPPERS/JSPカーネルの動作が最低限確認出来るものとして、

• インターバルタイマ
• UART

のみとしました。

Bishopエミュレータによる実行

Bishopエミュレータにて実行する手順です。 予めBishopエミュレータをインストールしたLinux環境を想定しています。

Windows上のBishopエミュレータでの実行手順、及びBishopボードでの実行手順に関しては後述の関連リンクを参照してください。

前述のTOPPERS/JSPカーネルのROMバイナリファイルをダウンロードして、ダウンロードしたディレクトリに移動後、

$ mv toppers-jsp-bishop-1.4.3-pylone0.bin u-boot.bin

としてファイル名称を変更して、

$ qemu-bishop -M pe201a -serial stdio -kernel dummy -mtdblock /dev/null -nographic

としてqemu-bishopを起動します。この時、

failed to open: led.img
failed to open: led.img
failed to open: led.img
failed to open: led.img
failed to open: pe201a.img
bishop_reset: splash image splash480.bmp.gz was not found
bishop_reset: failed to load a kernel image file

と、qemu-bishopがメッセージを出力しますがTOPPERS/JSPカーネルの動作に影響はありません。

次いで、

TOPPERS/JSP Kernel Release 1.4 (patchlevel = 3) for ARM - Pylone Bishop board (Feb 24 2009, 15:21:58)
Copyright (C) 2000-2003 by Embedded and Real-Time Systems Laboratory
                            Toyohashi Univ. of Technology, JAPAN
Copyright (C) 2004-2006 by Embedded and Real-Time Systems Laboratory
            Graduate School of Information Science, Nagoya Univ., JAPAN

System logging task is started on port 1.
Sample program starts (exinf = 0).
task1 is running (001).   |
task1 is running (002).   |
task1 is running (003).   |

とTOPPERS/JSPカーネルのバナー、及びTOPPERS/JSP付属のサンプルプログラムからのシリアル出力が表示されると思います。

サンプルプログラムは起動中の3つのタスクに関する指示を与えられるようになっており、 例えばレディーキューを回転する'r'を入力すると、task1からtask2へと実行状態のタスクが切り替わります。

Sample program starts (exinf = 0).
task1 is running (001).   |
task1 is running (002).   |
task1 is running (003).   |
#rot_rdq(three priorities)
task2 is running (001).     +
task2 is running (002).     +
task2 is running (003).     +

サンプルプログラムの詳細に関しては、TOPPERS/JSPカーネルソースコード内の sample/sample1.c 冒頭のコメント文を参照してください。

TOPPERS/JSPカーネルに標準で付属するWindows上で動作するシミュレータでもタスクの状態を検証する事が出来ると思いますが、今回のBishopエミュレータによる実行も併用すれば、実機によるデバッグをさらに軽減することが出来ると思います。

関連リンク

• TOPPERS/JSP カーネル for Bishop マニュアル
• Bishop エミュレータマニュアル

カーネルからユーザ空間へデータを渡す手段としては、 /proc や /sys 以下に作成した疑似ファイルを使うことが多いでしょう。

渡したい値が単純な型の場合はカーネル組込みのヘルパ関数を使えば十分(sysfs 経由でモジュールパラメータにアクセス、sysfs 経由でモジュールパラメータにアクセス (2))ですが、 より複雑なデータを渡すならば:

• 疑似ファイルの内容となるテキスト量が大きい場合、カーネル空間に全体を保持たくない。
• データ構造を操作に時間がかかる場合、ユーザ空間から要求された部分だけを処理することが望ましい。
• 同時に複数の読み手が存在したり、読み出し途中でデータが変更される場合の排他が必要。

などの点を考慮するべきです。

本記事では、シーケンシャルな疑似ファイルを実装するために用意されている補助関数群について解説します。 カーネル内でも広く使われている機構なので、知っておくとコードを読む際にも役立つでしょう。

seq_file

VFSの層ではファイル中の位置はバイト単位で扱われます。固定長のバッファで扱える程度のデータ量ならよいのですが、 疑似ファイル内容を一括生成・保持できない場合、自力で出力済のバイト数管理やバイト単位でのシークを実装するのは手間がかかります。

fs/seq_file.cには出力したいデータが

• 通し番号が付けられる(配列や木などの)要素の集合として表現できる
• 要素の番号がわかれば、その要素の文字列表現が得られる

という条件を満たすとき、各要素へのアクセスをイテレータ操作として抽象化する仕組みが用意されています。

これを使うと、所定のアクセサを作成するだけで、VFSに登録する struct file_operations のメンバのほとんどをカーネルから提供される汎用関数でまかなうことができます。

使用例

サンプルとして、全ttyについてdebugfs上の疑似ファイル経由として termios状態を一覧するカーネルモジュールのソースtermios_dumper.cを用意しました。

個別のttyの状態取得ならtcgetattr()でも十分なのですが、システム上で 現在activeな全てのttyをリストするために、カーネル内部のデータ構造を直接読んでいます。

疑似ファイルの登録

seq_fileを使用する場合でも、ファイルシステムへの疑似ファイルの登録は通常のまま

1. struct file_operationsを作成
2. ファイルシステム毎の登録関数の呼び出し

という手順で行います。

ただし、VFSに渡すstruct file_operationsのうち、読みこみ可能な疑似ファイルを実装するために必要な

• open
• read
• llseek
• release

のうちread, llseek, releaseとしては、seq_fileで実装されているseq_read, seq_lseek, seq_releaseをそのまま使用できます。

.openに登録する関数では、

• open()されたファイルに対して、seq_open()を呼んでハンドラを登録。
• 必要ならリソースの確保/ロック

を行ないます。

サンプルでは登録先のファイルシステムをdebugfsとしたので、以下のようにしています。

static const struct file_operations fops = {
    .open    = termios_dumper_open,
    .read    = seq_read,
    .llseek  = seq_lseek,
    .release = seq_release,
};

...

static int __init termios_dumper_init(void)
{
...
    if(IS_ERR(fs_root = debugfs_create_dir(KBUILD_BASENAME, NULL)))
        return PTR_ERR(fs_root);

    if(IS_ERR(fs_file = debugfs_create_file("state", 0444, fs_root, NULL,
                                            &fops)))
        return PTR_ERR(fs_file);

この例では、特にリソースの初期化が必要ないため、.openに登録したtest_seqfile_openの実装はseq_open()の呼び出しだけです。

static int test_seqfile_open(struct inode *inode, struct file *file)
{
    return seq_open(file, &seqfile_ops);
}

seq_operations

読み出し用のイテレータに必要な操作:

• 初期化
• 終了処理
• 「次」の要素に移動
• 値（文字列表現）の取得

は、

struct seq_operations {
        void * (*start) (struct seq_file *m, loff_t *pos);
        void (*stop) (struct seq_file *m, void *v);
        void * (*next) (struct seq_file *m, void *v, loff_t *pos);
        int (*show) (struct seq_file *m, void *v);
};

の各メンバとして登録されます。

start

seq_file用のファイルがopen()された時に呼ばれます。

• 使用するリソースの確保
• イテレータの初期化

を行ない、成功した場合には初期化済みのイテレータ、失敗した場合はNULLを返すことになるでしょう。

引数*posが0より大きい場合には、その位置を指すようにしたイテレータが返却されるべきです。

※ イテレータの更新処理は、(pos)ではなく、(*pos)を使います。

イテレータを進める処理は、next()からの処理でも必要となるため、共通化してもよいでしょう。サンプルでは update_iterator()としています。

next

seq_fileが、現在のイテレータからのデータを消費し終えた時、 現在のイテレータと次に指すべき位置を引数として呼ばれます。

読み手のread()に対応していると考えてよいでしょう。 ただし、カーネルによる先読み処理の対象となるため、read()の度にかならず呼ばれるわけではありあせん。 また、読み手が小量のデータしが要求していなくても、さらに先まで要求されることがあります。

指定位置を指すイテレータを用意して、それへのポインタを返します。 この場合返却したポインタは後述するshow()への引数として使われます。

処理に失敗した場合はNULLを返却します。このとき、続いてstop()が呼ばれますが、stop()の引数にはNULLしか渡らないため、リソースの開放にイテレータが必要なら、next()内で済ませておく必要があります。

stop

読み手に十分なテキストが渡ったか、next()からデータがもうないことを通知した(NULLを返した)後に呼びだされます。

リソースの開放を行なうべきですが、引数として渡されるポインタはNULLの場合があることに注意が必要です。

show

引数として渡されたイテレータから、読み手に渡す（疑似ファイルの内容となる）文字列を構築します。

構築にはseq_printf(), seq_puts()などのヘルパ関数を使用します。これらのヘルパは繰替えし呼ぶこともでき(追記されます)、最終的な長さは自動的に管理されるので、成功時には0を返せば適切に処理されます。

ただし、一度に構築できる文字列の全長はPAGE_SIZE程度なので、長くなりすぎる場合はイテレータの構造を変える必要があるでしょう。

サンプルコードでは、現在のイテレータが指しているtermiosの情報を、seq_printf()経由でgrepしやすい書式に変換しています。

サンプルtermios_dumper.cについての補足

サンプルとして使用したコードtermios_dumper.cでは、カーネルから公開されていはいttyドライバのリストの先頭要素のアドレスを知るために、struct tty_driverのmagic要素を用いて検索していますが、これは低い確率ですが(メモリ中の値が偶然TTY_MAGICと一致したり、get_current_tty()が呼べない場合に)失敗する可能性のある処理です。 確実を期すなら、カーネルの公開シンボルにtty coreのtty_driversを追加するか、専用のアクセサを追加するべきでしょう。

また、ttyサブシステム内の構造体を辿る処理はttyのmutexを取得した上で行うべきなのですが、

• tty_mutexを占有すると副作用が大きい(ロック中に新規にttyを開こうとした他のプロセス全てが停止するため）
• 改造して失敗したときにシステムをロックしてしまう
• 今回のサンプルでは読み出ししかおこなわないため、整合性が崩れても大きな問題にならない

ため、デモ目的では不要と判断してコメントアウトしてあります。 このため、疑似ファイルからの読出し途中でttyが増減すると、表示の一貫性が崩れることがあるでしょう。 同様の理由で、kobjectの参照数カウントについても省略しています。

2009年1月以降にご注文いただいた分から新バージョンにて出荷いたします。

既にご購入いただいたお客様へ

2008年12月までにご購入いただいたお客様につきましては、別途バージョンアップ手順をご案内いたします。

• バージョンアップ手順

関連リンク

• Bishop - ソフトウェア仕様

ドキュメント

• Bishop エミュレータマニュアル
• ソフトウェア仕様

ダウンロード

関連記事

• Bishopエミュレータに関する記事

ビットラン JTAGエミュレータ Code Debugger のデバッガソフト Code Stage 用 S3C2440Aペリフェラル定義ファイルを 公開 します。

定義ファイルをデバッガソフトに追加することによって、 直感的なユーザインタフェースでS3C2440Aのペリフェラルレジスタへアクセスできます。

入手方法や使い方については 「DR-01用S3C2440Aペリフェラル定義ファイル」 を参照してください。

関連記事

• DR-01用S3C2440Aペリフェラル定義ファイルの公開

Bishop 向け Linux カーネルのテスト版 (2.6.26.8) を公開します。

コード

base36param.c:

#include <linux/init.h>
#include <linux/module.h>
#include <linux/moduleparam.h>
#include <linux/kernel.h>

static int stored_value = 0;

static int param_set_base36(const char *val, struct kernel_param *kp)
{
    if (('0' <= val[0]) && (val[0] <= '9')) {
            stored_value = val[0] -'0';
            return 0;
    }
    if (('a' <= val[0]) && (val[0] <= 'z')) {
            stored_value = val[0] -'a' +10;
            return 0;
    }
    if (('A' <= val[0]) && (val[0] <= 'Z')) {
            stored_value = val[0] -'A' +10;
            return 0;
    }
    return -EINVAL;
}

static int param_get_base36(char *buffer, struct kernel_param *kp)
{
    if (stored_value < 0 || 36 < stored_value)
        return -EINVAL;

    if (stored_value < 10)
        buffer[0] = '0' + stored_value;
    else
        buffer[0] = 'A' + stored_value - 10;

    buffer[1] = '\0';

    return 2;
}

/* dummy checker */
#define param_check_base36(name, p) __param_check(name, p, void);

static int __init base36param_init(void)
{
    printk(KERN_INFO "%s called\n", __func__);
    return 0; /* succeeded */
}

static void __exit base36param_cleanup(void)
{
    printk(KERN_INFO "%s called\n", __func__);
    return;
}

module_init(base36param_init);
module_exit(base36param_cleanup);

module_param(stored_value, base36, 0644);
MODULE_PARM_DESC(stored_value, "can write [0-9A-Za-z], read as [0-9A-Z].");

MODULE_LICENSE("GPL");
MODULE_AUTHOR("MINAMI Hirokazu");
MODULE_DESCRIPTION("sample module which has a custom typed parameter");

Makefile:

KERNEL_SRC = /lib/modules/$(shell uname -r)/build
#CROSS_COMPILE =
#ARCH =
BUILD_DIR := $(shell pwd)
VERBOSE = 0

obj-m := base36param.o

all:
	make -C $(KERNEL_SRC) SUBDIRS=$(BUILD_DIR) KBUILD_VERBOSE=$(VERBOSE) modules

clean:
	rm -rf *.o *.ko *.mod.c .*.cmd .tmp_versions *~ Module.symvers

ビルド

環境に応じて Makefile の KERNEL_SRC, CROSS_COMPILE, ARCH を修正し、make を実行します。

使い方

値 (Base36) をパラメータに書き込む:

# echo 'h' > /sys/module/base36param/parameters/stored_value

パラメータを読み込む:

# cat /sys/module/base36param/parameters/stored_value
H

解説

モジュールパラメータに独自の型を持たせるためには、 module_param を使います。

module_param(stored_value, base36, 0644);

module_param は以下のようなマクロです。

/* Helper functions: type is byte, short, ushort, int, uint, long,
   ulong, charp, bool or invbool, or XXX if you define param_get_XXX,
   param_set_XXX and param_check_XXX. */
#define module_param_named(name, value, type, perm)			   \
	param_check_##type(name, &(value));				   \
	module_param_call(name, param_set_##type, param_get_##type, &value, perm); \
	__MODULE_PARM_TYPE(name, #type)

#define module_param(name, type, perm)				\
	module_param_named(name, name, type, perm)

param_set_##type と param_get_##type が肝です。 sysfs 経由でパラメータが読み書きされると、ここで登録される param_set_##type と param_get_##type が呼ばれます。 (module_param_call の説明は省きます)

base36param.c の場合、プリプロセッサによってマクロ展開された param_set_base36 と param_get_base36 が登録されることになります。

マクロのコメントにある通り、 独自の型ではなく int などの場合は あらかじめ用意されているヘルパー関数群が使われるので 自前で用意する必要はありません。

先日公開した 仮想バッテリドライバ はこれの応用です。 ファイルとして読み書きできるので ユーザ空間のプログラムとヘッダを共有する必要がない点は ioctl() より使い勝手がよいかもしれません。

関連記事

• sysfs 経由でモジュールパラメータにアクセス
• Virtual Battery Driver

概要

Power supply class は、sysfs 、及び uevent によってユーザースペースから電源状態に関するイベントの監視を可能にする仕組みですが、 本ドライバはその仕組みを利用して、コマンドラインからAC電源、バッテリに関するイベントを生成し、 電源状態の変化を仮想的に再現するためのものです。

パイロンでは、バッテリを持たないカスタムボードへ Android を移植する際に使用しています。

前提

本ドライバを使用するには、Linux kernel 2.6.25 以降を、

• CONFIG_POWER_SUPPLY

を有効にしてコンパイルした環境が必要です。

また、Android で Power supply class から uevent を受けとるには、

• CONFIG_SYSFS_DEPRECATED_V2

も有効にする必要があります。

導入手順

1. アーカイブを展開して、Makefile 中の各変数である、
   • 組み込むカーネルのソースへのパス(本Makefileでは'KERNEL_SRC'としています)
   • ARCH
   • CROSS_COMPILE
   の内容を利用する環境に合わせて修正し、

   # make
   

   します。(または、各変数をコマンドラインから直接、定義します)
2. 生成したモジュールを、対象のカーネルに組み込みます。

   # insmod virtual_battery.ko
   

   予め他のPower supply classドライバがロードされている状態で本ドライバを登録すると、Kernel Panic が起きてしまう点にご注意ください。

以上の手順を実行すると、sysfs のプラットフォームデバイスディレクトリ（/sys/devices/platform/） に、 「virtual_battery.0」というディレクトリが生成されいるはずです。

$ ls /sys/devices/platform/virtual_battery.0/
bus                   power_supply:ac       uevent
modalias              power_supply:battery
power                 subsystem

また、sysfs のモジュールパラメータのディレクトリにも以下のようなディレクトリパスと仮想ファイル群が生成されているはずです。

$ ls /sys/module/virtual_battery/parameters/
ac_status           battery_health      battery_status
battery_capacity    battery_present     battery_technology

使用方法

電源状態を変更するには、sysfs に生成されたモジュールパラメータを使用します。

各仮想ファイルの使用方法は以下の通りです。

使用例

まずは現在の各値を確認してみます。sysfs の class ディレクトリ以下に、power_supply ディレクトリがあるので、 そこの uevent を利用すると一覧を取得することができます。

# cat  /sys/class/power_supply/uevent
PHYSDEVPATH=/devices/platform/virtual_battery.0
PHYSDEVBUS=platform
POWER_SUPPLY_NAME=battery
POWER_SUPPLY_TYPE=Battery
POWER_SUPPLY_STATUS=Charging
POWER_SUPPLY_HEALTH=Good
POWER_SUPPLY_PRESENT=1
POWER_SUPPLY_TECHNOLOGY=Li-ion
POWER_SUPPLY_CAPACITY=50

バッテリ容量とバッテリ状態を変更してみます。

# echo 30 > /sys/module/virtual_battery/parameters/battery_capacity
# echo discharging > /sys/module/virtual_battery/parameters/battery_status

変更されているか確認してみます。

# cat /sys/module/virtual_battery/parameters/battery_capacity
30
# cat /sys/module/virtual_battery/parameters/battery_status
discharging

変更したタイミングで uevent が発生するので、バッテリの状況を動的に把握することが可能です。

組み込み用途向けのカスタムボードでは、バッテリを搭載していない事も多いと思いますが、 そのような環境においても、本ドライバを利用することによって、ユーザスペースにおける電源管理の評価を行えるのではないでしょうか。

リンク

• Test power driver（Virtual Battery Driver）について

組込みLinux開発用CPUボードBishopエミュレータBeta4を公開します。

更新履歴

• 2008/9/26: 初版公開

Beta3からの変更点

ボード画像/LED状態表示のサポート

Bishopの実機では、GPIOポートに対して出力を行うことで、基板上でLED5/LED4/LED8/LED7とラベルされたLEDを制御することができます。

QEMUウィンドウ内にLCDの内容だけでなく、これらのLED状態も表示されるようにしました。起動初期段階のデバッグ等に利用できます。

リリース内容

本エミュレータは、オープンソースのプロセッサエミュレータ QEMUの開発版をベースに、Bishop向けの機能を追加したものです。 本リリースでは Beta3 と比較してエミュレーション可能な機能自体に変更はありません。

各種ペリフェラルのサポート状況

コンパイル手順

本バージョンでは、ソースコード (qemu-bishop-0.9.1-pylone0rc4.tar.bz2) のみを公開しています。以下の手順でコンパイルすることができます。

必要なもの

• gcc-3.4 (4.x では動作しません)
• zlib
• SDL 1.2

手順

$ ./configure --target-list=arm-softmmu --enable-alsa
$ make

実行

まず、以下のイメージファイルをダウンロードします。画像データ以外のファイルは、従来バージョンで使用していたものがあればそのまま使用できます。

• U-Boot
• Linuxカーネル
• initrd
• ファイルシステム (NAND)
• NOR上スプラッシュ画像領域イメージ
• PE-201Aエミュレーション画像データ
• PE-201Bエミュレーション画像データ
• LED状態表示画像データ

イメージファイルが置かれたディレクトリでqemuを

$ qemu-system-arm -M pe201a -serial stdio -kernel dummy -usbdevice keyboard -mtdblock nand-bishop.img

$ qemu-system-arm -M pe201b -serial stdio -kernel dummy -usbdevice keyboard -mtdblock nand-bishop.img

のように起動してください。

-M オプションに指定された値（pe201a または pe201b） に従って、QEMUウィンドウ内にLCDの内容だけでなく、ボード画像/LED状態も表示されます。

Bishop標準のLinuxカーネルで起動した場合、実機と同様にHeartBeatの処理が開始されるとLEDの表示が変化します。

LEDはGPIOポートバンク'B'の 5,6,7,8 ビットに接続されているので、アドレス0x56000014に値を書くと（対応するピンが出力用に設定されていれば）反映されます。 なお、論理は負、0 から数えたビット番号とLEDの対応は以下となります。

例として、U-Bootプロンプトから4つのLEDすべてを消灯/点灯するには以下のようにします。

# mw.l 56000014 1e0
# mw.l 56000014 000

なお、QEMU上では 1e0 に代わりに ffff などの値を書いても同様の結果が得られますが、実機では 0x1E0 以外の値を設定すると他デバイスの動作に干渉してしまいます。

関連記事

• Bishopエミュレータに関する記事

前提

Linux kernel 2.6.21以降を

• CONFIG_USBMON
• CONFIG_DEBUGFS

を有効にしてコンパイルした環境が必要です。

準備

1. debugfsがまだマウントされていなければマウントします。 一般的に /sys/kernel/debug/ にマウントされるため、

   # mount -t debugfs none /sys/kernel/debug
   

   すればよいでしょう。
2. usbmon をモジュールとして作成していた場合、カーネルに組み込みます。

   # modprobe usbmon
   

以上の手順を実行すると、debugfs の下（/sys/kernel/debug/usbmon/） に、 「番号 ＋ "s"/"t"/"u"」 という仮想ファイル群が生成されているはずです。

$ ls /sys/kernel/debug/usbmon/
0s  0u  1t  2s  2u  3t  4s  4u  5t  6s  6u
0t  1s  1u  2t  3s  3u  4t  5s  5u  6t

実際に何個のファイルが見えるかは、システム構成によります。

キャプチャ

「USBバス番号 ＋ 'u'」という名前のファイルに、 USBの通信内容が配送されます。

とりあえずバス番号に 0 を指定して("0u"を使って)、全通信を監視してみるとよいでしょう。

# cat  /sys/kernel/debug/usbmon/0u
dfaac8c0 2557329542 S Bo:5:004:2 -115 31 = 55534243 214b0100 00000000 00000600 00000000 00000000 00000000 000000
dfaac8c0 2557329639 C Bo:5:004:2 0 31 >
dfaac8c0 2557329649 S Bi:5:004:2 -115 13 <
dfaac8c0 2557331148 C Bi:5:004:2 0 13 = 55534253 214b0100 00000000 01
dfaac8c0 2557331171 S Bo:5:004:2 -115 31 = 55534243 224b0100 12000000 80000603 00000012 00000000 00000000 000000
dfaac8c0 2557331388 C Bo:5:004:2 0 31 >

行の内容は以下のようになっています。

• URB Tag
• timestamp
• Event Type (S - submission, C - callback, E - error)
• 通信種類([CZIB][io]): バス番号 : Device address : Endpoint number
• URB Status word
• データ長さ
• データ内容

特定のデバイスだけを監視したい場合、lsusb の結果を参考にするとよいでしょう。たとえば

$ lsusb |grep PL2303
Bus 005 Device 005: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port

のようになっていた場合、 PL2303（USB-シリアルコンバータ）が5番に接続されているので、5uを使えばよいことがわかります。

その他の情報

疑似ファイルには他に 't'/'s'でおわるものがあります。

't'でおわるもの

'*t' は互換性のために残されている古い書式の疑似ファイルなので、 通常使用する必要はないでしょう。

's'でおわるもの

'*s' からは usbmon 自体の動作状況を読むことができます。たとえば

# cat /sys/kernel/debug/usbmon/5s
nreaders 1 events 350 text_lost 0

なら、

• 現在 1つのプロセスが バス#5 を監視して中
• いままでに 350 個のURBが読み出された
• 読まれる前にバッファから溢れてしまった URB はない

ことがわかります。

's' で終わるファイル群の処理では排他制御が考慮されないため、 このインターフェース経由に高負荷をかける場合は何をしているのかよく理解した上で行なってください。

distcc の FAQ によると

You should use about twice the total number of CPUs available, but it depends on your network, program being compiled, available memory, etc. Experiment with different values.

とのことなので、 とりあえず -j をプロセッサ・コア数の2倍にします。

まずは localhost 1台で計ってみます。 (Xeon 2.40GHz x2, コア x4)

$ time make -j8 ARCH=arm CROSS_COMPILE=arm-linux-gnu- uImage
real    4m0.051s
user    13m14.462s
sys     1m12.329s

ホストを一台追加します。 (host2: Pentium D 3.0GHz, コア x2)

$ export DISTCC_HOSTS="localhost host2"
$ time make -j12 ARCH=arm CROSS_COMPILE=arm-linux-gnu- CC="distcc arm-linux-gnu-gcc-4.1" uImage
real    2m4.114s
user    4m38.933s
sys     0m57.964s

もう一台追加します。 (host3: Core 2 Duo E6600 2.4GHz, コア x2)

$ export DISTCC_HOSTS="localhost host2 host3"
$ time make -j16 ARCH=arm CROSS_COMPILE=arm-linux-gnu- CC="distcc arm-linux-gnu-gcc-4.1" uImage
real    1m32.039s
user    3m41.718s
sys     1m0.260s

さらにもう一台追加します。 (host4: Celeron M 520 1.60GHz, コア x1)

$ export DISTCC_HOSTS="localhost host2 host3 host4"
$ time make -j18 ARCH=arm CROSS_COMPILE=arm-linux-gnu- CC="distcc arm-linux-gnu-gcc-4.1" uImage
real    1m22.078s
user    3m17.572s
sys     1m2.056s

グラフ

リンク

• distcc: a fast, free distributed C/C++ compiler
• distcc による分散クロスコンパイル環境

ビットラン DR-01 の 共通デバッガソフト用 S3C2440Aペリフェラル定義ファイルを 公開 します。

定義ファイルをデバッガソフトに追加することによって、 直感的なユーザインタフェースでS3C2440Aの ペリフェラルレジスタへアクセスできます。

入手方法や使い方については 「DR-01用S3C2440Aペリフェラル定義ファイル」 を参照してください。

組込みLinux開発用CPUボードBishopエミュレータBeta3を公開します。

更新履歴

• 2008/5/23: 初版公開

Beta2 からの変更点

オーディオサポート

再生のみですが、オーディオに対応しました。

SD/MMC サポート

SD/MMCに対応しました。 -sd オプションで指定したディスクイメージファイルをSDカードとして扱うことができます。 ディスクイメージの作成方法は「ディスクイメージのホスト側での操作方法」を参照してください。

バイナリパッケージ

debianパッケージ、RPM、Windows インストーラを用意しました。

リリース内容

本エミュレータは、オープンソースのプロセッサエミュレータ QEMUの開発版をベースに、Bishop向けの機能を追加したものです。 Beta1 や Beta2 と比較してエミュレーションの精度が向上していますが、まだ実機に存在する全ての周辺機器を正しくエミュレートできるわけではありません。

各種ペリフェラルのサポート状況

インストール

Debian

/etc/apt/sources.list に以下の apt-line を加えます。

deb http://downloads.pylone.jp/tools/deb ./

入手可能なパッケージの一覧を更新します。

# aptitude update

qemu-bishop パッケージをインストールします。

# aptitude install qemu-bishop

Fedora

/etc/yum.repos.d/pylone-jp.repo に yum レポジトリを追加します。

[tools]
name=Tools
baseurl=http://downloads.pylone.jp/tools/rpm/
enabled=1
gpgcheck=0

リポジトリ情報を更新します。

# yum update

qemu-bishopパッケージをインストールします。

# yum install qemu-bishop

Windows

インストーラ (qemu-bishop-0.9.1-pylone0rc3-setup.exe) をダウンロードして実行してください。

実行

Linux

まず、以下のイメージファイルをダウンロードします。

• U-Boot
• Linuxカーネル
• initrd
• ファイルシステム (NAND)
• スプラッシュイメージ

イメージファイルが置かれたディレクトリでqemu-bishopコマンドを

$ qemu-bishop -M pe201b -serial stdio -kernel dummy -usbdevice keyboard -mtdblock nand-bishop.img

として起動してください。

1. U-Bootがメモリに読みこまれて起動
2. U-BootがLinuxカーネルを読みこみ
3. LinuxカーネルがNANDのファイルシステムイメージをマウント

の順で実行されます。

-M オプションには、従来の pe201a と pe201b に加えて pe201q を指定することができます。

Windows

「スタート」 → 「すべてのプログラム」 → 「qemu-bishop」

コンパイル手順

ソースコード (qemu-bishop-0.9.1-pylone0rc3.tar.bz2) からビルドする場合の手順です。

必要なもの

• gcc-3.4 (4.x では動作しません)
• zlib
• SDL 1.2

手順

$ ./configure --target-list=arm-softmmu --enable-alsa
$ make

関連記事

• Bishopエミュレータに関する記事

方法は色々あると思いますが、パイロンではDebianの busybox-staticパッケージと initramfsを使うことが多いです。 手順は以下の通りです。

(例としてrootfsのディレクトリを/PATH/TO/ROOTFS/とします)

1. busybox-staticパッケージをdpkg -xでばらしてbin/busyboxを/PATH/TO/ROOTFS/bin/busyboxにコピー
2. /PATH/TO/ROOTFS/bin/busyboxへのシンボリックリンクPATH/TO/ROOTFS/initを追加
3. mkdir /PATH/TO/ROOTFS/{dev,etc,proc}
4. mknod /PATH/TO/ROOTFS/dev/console c 5 1

busyboxのinitは/etc/init.d/rcSを読み込むので起動直後の処理はrcSに加えます。最低でも/procのマウントさえしておけばよいでしょう。

/PATH/TO/ROOTFS/etc/init.d/rcS:

#!/bin/sh
mount -t proc proc proc

カーネルにinitramfsとして組み込むにはCONFIG_BLK_DEV_INITRDとCONFIG_INITRAMFS_SOURCEを指定します。

CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=/PATH/TO/ROOTFS/

ホスト側で前半部分を実行

NFS-Rootのホスト側ディレクトリを/nfsroot/etch-ARCH として説明します。

ARCHはアーキテクチャ(arm, mipsel, powerpcなど)に置き換えてください。

debootstrapを--foreignオプションで実行します。

# debootstrap --foreign --arch ARCH etch /nfsroot/etch-ARCH http://ftp.debian.org/debian/

NFS-Root用の/etc/fstabを用意します。

# echo "proc /proc proc defaults 0 0" > /nfsroot/etch-ARCH/etc/fstab
# echo "ホストのIPアドレス:/nfsroot/etch-ARCH / nfs defaults 0 1" >> /nfsroot/etch-ARCH/etc/fstab

/dev/consoleを作ります。

# mknod /nfsroot/etch-ARCH/dev/console c 5 1

NFS-Rootでターゲットを起動

NFSサーバの設定については触れません。

カーネルパラメータでホストの/nfsroot/etch-ARCHをNFS-Rootとして指定してカーネルを起動します。

カーネルパラメータの例:

console=ttyS0,115200n8 root=/dev/nfs nfsroot=ホストのIPアドレス:/nfsroot/etch-ARCH/ ip=ホストのIPアドレス:::サブネットマスク::eth0: init=/bin/sh

ターゲットで後半部分を実行

# mount -n -o remount,rw /
# mount -n /proc
# export PATH=/bin:/sbin:/usr/bin:/usr/sbin
# date -s "2008-2-27 18:33"

# /debootstrap/debootstrap --second-stage --no-resolve-deps

ターゲット向けの設定について

上記手順で作成したDebian基本システムをターゲットのNANDやCFなどに インストールして使う場合、 事前にターゲットの環境に合わせて設定が必要になります。

よくある設定としては

• /etc/inittab
• /etc/fstab
• /etc/securetty
• /etc/resolv.conf
• /etc/network/interfaces

といったところでしょうか。

シリアルコンソールであればttySnも作っておくといいかもしれません。

# cd /nfsroot/etch-ARCH/dev
# ./MAKEDEV ttyS

リンク

• Cross-installing Debian using debootstrap

dpkg-crossの--excludeオプションはクロスへ変換する際にDependsから特定のパッケージを取り除くオプションです。 最近追加されたらしいのですが、使ってみたら便利だったので紹介します。

こんな感じです。

普通にクロスパッケージ化すると

$ dpkg -f lib64gcc1_4.1.1-21_powerpc.deb | grep Depends
Depends: gcc-4.1-base (= 4.1.1-21), libc6-ppc64 (>= 2.3.6-7)
$ dpkg-cross -a powerpc -b lib64gcc1_4.1.1-21_powerpc.deb
Building lib64gcc1-powerpc-cross_4.1.1-21_all.deb
$ dpkg -f lib64gcc1-powerpc-cross_4.1.1-21_all.deb | grep Depends
Depends: gcc-4.1-base (= 4.1.1-21), libc6-ppc64-powerpc-cross (>= 2.3.6-7), libc6-ppc64-powerpc-dcv1

となります。

--excludeを使ってgcc-4.1-baseへの依存を削ると

$ dpkg-cross -a powerpc -b --exclude gcc-4.1-base lib64gcc1_4.1.1-21_powerpc.deb
Building lib64gcc1-powerpc-cross_4.1.1-21_all.deb
$ dpkg -f lib64gcc1-powerpc-cross_4.1.1-21_all.deb | grep Depends
Depends: libc6-ppc64-powerpc-cross (>= 2.3.6-7), libc6-ppc64-powerpc-dcv1

となります。

組込みLinux開発用CPUボードBishopのエミュレータのBeta2版を公開します。

更新履歴

• 2007/12/28: 初版公開
• 2008/1/18: ソースコードを qemu 0.9.1 に追従して更新

Beta1からの変更点

開発用仮想ターゲットPE-201Q

エミュレートする環境として提供される仮想ターゲットPE-201Qを追加しました。 実機より大きな画面(640x1024)および豊富なNOR領域(128MBytes)が利用可能となるので、開発環境としての利便性が向上します。

タッチスクリーンのサポート

エミュレータウィンドウ上のポインタ操作を、タッチスクリーンへの入力として変換するようにしました。 PE-201A/Bとしてエミュレーションを行う場合、タッチスクリーンはキャリブレーション済の状態で起動します。 PE-201Qでは変換係数の初期値に意図的にある程度の誤差を残してあります。 キャリブレータの動作確認にはPE-201Qを使用してください。

-appendオプション

QEMU起動時に-appendオプションが付加された場合に、U-Bootの環境変数"bootargs"へ反映するようにしました。 この環境変数はLinuxカーネルの起動時の引数として渡されます。

-append を指定しないか、空("")とした場合、bootargsの内容は

bootargs=console=ttySAC0,115200 console=tty0 preinit=/pylone root=/dev/mtdblock5 nfsroot=10.0.2.2:/ROOTFS/ ip=10.0.2.15::10.0.2.2:255.255.255.0:::

となります。この場合、特に操作しなければルートファイルシステムとしてNANDが使用されます。

-appendに"xxx=yyy"のような値を指定した場合、bootargsの内容の後半が書き換えられて

bootargs=console=ttySAC0,115200 console=tty0 preinit=/pylone xxx=yyy

となります(この例のままでは"root="が指定されなくなるため、起動に失敗します)。

-append "root=/dev/nfs nfsroot=xx.xx.xx.xx:/XXXXX ip=10.0.2.15::10.0.2.2:255.255.255.0:::"

のように有効な"root="と付加情報を設定すれば、指定に従って起動します（この例の場合は nfs サーバxx.xx.xx.xx の /XXXXX をルートとして）。

コード変換バッファ領域のサイズ変更

QEMU がエミュレーションのために使用するコード変換バッファ領域のサイズを増やしました。 エミュレータ上で複雑な処理をおこなわせた場合の速度低下が軽減されています。

QEMUのメモリ消費量がBeta1と比較して増加しているため、十分なメモリを確保しての使用をお勧めします。

ダウンロード

今回のリリースでは、ソースコードのみ提供します。以下のリンク先から取得してください：

ソースコード:

qemu-bishop-0.9.1-pylone0rc2.tar.bz2

今後

• Debianパッケージ
• Windowsインストーラ

も準備する予定です。

リリース内容

本エミュレータは、オープンソースのプロセッサエミュレータQEMUの開発版をベースに、Bishop向けの機能を追加したものです。Beta2ではBata1に比較してエミュレーションの精度が向上していますが、まだ実機に存在する全ての周辺機器を正しくエミュレートできるわけではありません。

各種ペリフェラルのサポート状況

ソースコードからのインストール

必要な環境

• gcc-3.4 (4.x では動作しません)
• SDL 1.2

Debian環境では、 # apt-get build-dep qemu を実行することで、必要なパッケージを一括してインストールすることもできます。

構築手順

ソースコードを展開したディレクトリ内で以下の手順を行うことで、実行可能ファイル ./arm-softmmu/qemu-system-arm が生成されます。

configure の実行

$ ./configure --target-list=arm-softmmu

コンパイル

$ make

エミュレータの実行

Bishopエミュレータに実機出荷状態と同様の動作をさせるためには、

• U-Bootイメージ
• Linuxカーネルイメージ
• initrdイメージ
• ファイルシステムイメージ
• スプラッシュイメージ

を与える必要があります。それぞれのファイルをリンク先からダウンロードし、ソースコードのトップディレクトリに置いた状態で

$ ./arm-softmmu/qemu-system-arm -M pe201b -serial stdio -kernel dummy -usbdevice keyboard -mtdblock nand-bishop.img

として起動してください。

1. U-Bootがメモリに読みこまれて起動
2. U-BootがLinuxカーネルを読みこみ
3. LinuxカーネルがNANDのファイルシステムイメージをマウント

の順で実行されます。

オプション”-M”には、従来の"pe-201a"と"pe-201b"に加えて"pe-201q"を指定することができます。

カーネルイメージを最新のBishop向けカーネルに差し替えると、起動時にタッチスクリーンからルートファイルシステムを選択することができます。

関連記事

• Bishopエミュレータに関する記事

最新版は2.6.26.8です。記事: Bishop向けLinuxカーネルのテスト版 - 2.6.26.8

• ソースコード:linux-2.6.24-rc6-pylone0.tar.gz
• バイナリ:uImage

主な変更点は以下の通りです。

• 2.6.22.1から2.6.24-rc6へ
• initrdからinitramfsへ変更
• エミュレータ上の開発用仮想ターゲットPE-201Qに対応

本カーネルは近日中に正式リリースされる予定です。 今後出荷するBishopにもプリインストールされます。 これまでご購入いただいたお客様につきましては、 アップデート手順をご案内させていただきます。

関連記事

• klibcベースのinitramfs

Bishopにプリインストールされている uClibcベースのinitrdを klibcによるinitramfsに変更する予定です。

klibcやinitramfsについては、カーネル付属文書Documentation/early-userspace/READMEを参照してください。JFプロジェクトによる日本語訳もあります。

klibcのサンプル実装として、起動時にタッチスクリーンからルートファイルシステムを選択する仕組みを用意しました。

起動時に表示される画面上のアイコンをタッチすることにより、NAND、NFS、USBマスストレージ、SDカードの何れかからルートファイルシステムを選択できます。

近日中にリリース予定のBishop向けカーネルでは、このカスタムinitramfsも 含まれます。

クロス開発環境のDebianパッケージ (gcc-3.4, gcc-4.1) を alien で変換したRPMパッケージを 公開します。

概要

クロス開発環境のDebianパッケージ を参照してください。

対応状況

クロス開発環境のDebianパッケージ を参照してください。

yumによるインストール (Fedora)

以下の内容で/etc/yum.repos.d/pylone-jp.repoを作成して、yumレポジトリを追加します。

[cross-toolchain]
name=Cross Toolchain
baseurl=http://downloads.pylone.jp/cross-toolchain/rpm/
enabled=1
gpgcheck=0

必要なツールをインストールします。 ARCH は arm、mipsel、sh4、powerpc の何れかに置き換えてください。

gcc-3.4

# yum install gcc-3.4-ARCH-linux-gnu

gcc-4.1

# yum install gcc-4.1-ARCH-linux-gnu

g++-4.1

# yum install g++-4.1-ARCH-linux-gnu

gdb

# yum install gdb-ARCH-linux-gnu

依存関係について

alienによる変換ではパッケージ間の依存関係が失われますが、 本パッケージではspecファイルを修正して依存関係を追加しています。

更新履歴

• 2007/12/12: 公開

Linux起動時にinitramfsを使用するためには、 以下のいずれかを用意する必要があります。

• 所定の形式のcpioアーカイブ
• 展開済みのディレクトリ
• usr/gen_init_cpio 用の設定スクリプト

このうち「usr/gen_init_cpio用の設定スクリプト」を使えると、ユーザ権限で作業ができるため、作業環境の扱いが簡単になります。

しかし、きちんと（間接的に必要となるライブラリ等まで考慮して）スクリプトを記述するのはそれなりの手間がかかり、使いこなすには経験が必要でした。

この作業の支援用として、実行可能ファイルに必要なライブラリ等の情報を抽出して設定スクリプトの雛形を生成するツールを公開します。

使いかた

ダウンロード

以下のリンク先から取得してください：

実行には python および binutils が必要です。

前準備

適当なディレクトリ以下に、initramfsに含めたいファイルを全て展開します。この段階では不要なファイルが含まれていても構わないので、手順としては

1. 関連するパッケージを dpkg -x で展開
2. その他のファイルをコピー

などとすればよいでしょう。

設定ファイル作成

最終的にinitramfsに含めたいファイルのリストを用意します。

例）FOO.def として

/bin/busybox
/bin/brcrl

誤認識されないなら、パスのディレクトリ部分（/usr/bin）は省略することができます。

busybox
brctl

スクリプトの実行

本スクリプトを「-l」 オプションにファイルリスト、続けて作業用の（ファイル一式を展開しておいた）ディレクトリのフルパスを指定して実行すると 、initramfs用の設定内容が作成されます。

$ gen_init_cpip_conf.py -l FOO.def /path/to/work/dir  > initramfs_script

作業用ディレクトリには、Linuxカーネル構築時に正しく参照が解決できるなら、相対パスを使用することもできます。

可視化

例えば、busybox, Xサーバ, matchbox について、実行に必要なライブラリとシンボリックリンクの関係は以下のようになりました。

高解像度版 (PNG) 原図 (SVG)

社内で使っているクロス開発環境のDebianパッケージを公開します。

更新履歴

• 2007/11/09: 公開
• 2007/12/15: apt-lineのtypoを修正
• 2008/02/26: update-alternativesについての記述を追加
• 2008/07/04: mipsel で gcc-4.1 の動作を確認
• 2008/12/22: アーカイブの鍵についての記述を追加
• 2009/03/09: powerpc で動作を確認

概要

• ホストアーキテクチャ: i386
• ターゲットアーキテクチャ: arm, mipsel, powerpc, sh4
• コンパイラ: gcc-3.4, gcc-4.1, g++-4.1
• glibc: 2.3.6 (etch の glibc)
• ssp: 無効

基本的にはetchのbinutils, gccを debian/README.cross等の手順通りにビルドしたものですが、 etchとsidの両方にインストールできるように依存関係を調整するなど 若干の変更を加えています。

対応状況

• ○:動作を確認したもの
• △:パッケージはあるが、まだ動作が確認できていないもの
• ×:まだパッケージが用意できていないもの

インストール

etchかsidであればインストールできる筈です。

/etc/apt/sources.listに以下のapt lineを加えます。

deb http://downloads.pylone.jp/cross-toolchain/deb ./

(まだ行っていなければ) pylone.jp の鍵を導入します。

# wget http://pylone.jp/pubkey.asc -O - | apt-key add -

パッケージ情報を更新します。

# aptitude update

必要なツールをインストールします。 ARCHはarm、mipsel、sh4、powerpcの何れかに置き換えてください。

gcc-3.4

# aptitude install gcc-3.4-ARCH-linux-gnu

gcc-4.1

# aptitude install gcc-4.1-ARCH-linux-gnu

g++-4.1

# aptitude install g++-4.1-ARCH-linux-gnu

gdb

# aptitude install gdb-ARCH-linux-gnu

gcc-3.4とgcc-4.1の切り替え

# update-alternatives --config ARCH-linux-gnu-gcc

リンク

• Embedded Debian Cross Development Environments
• Debian Wiki - SH4/CrossToolchain
• DebianCrossCompilerHowto

謝辞

sh4 用 glibc をビルドするにあたって、シリコンリナックス株式会社様が公開されていた glibc パッケージ の debian/patches/sh/*.diff を使わせて頂きました。

今回は、このディスクイメージを仮想環境の外側で作成/操作する手段について紹介します。

作業環境としてはLinuxを想定しています。

イメージの作成

希望の構成のディスクイメージを、ホスト環境で作成する手順を説明します。

ファイル作成

まず希望のデバイスサイズのファイルを用意します。

サイズさえ十分ならどのようにしても構いませんが、ddで作ることをおすすめします。例えば 512 MBytes のものを作りたいなら

$ dd if=/dev/zero of=FILENAME bs=1 count=1 seek=536870911

とするとよいでしょう。 (seek= の値は、512 MBytes = 524288 KBytes = 536870912 Byte なので、536870912-1 を指定しています)

素朴に /dev/zero からコピーして

$ dd if=/dev/zero of=FILENAME bs=1M count=512

としてもよいのですが、近代的な（ファイルにholeが作れる）ファイルシステムで作業しているならseek させた方が 終了が早く、実ディスク消費も抑えられます。

パーティション作成

エミュレーションされる環境を実際の環境に近付けるために、ディスクイメージ上にはパーティションが作成されている状態を用意できると便利です。そこで、ループバックデバイスを用いてファイルをブロックデバイスとして見せ、fdisk などの対象に取れるようにする方法について説明します。

パーティションを作成する必要がないなら、ディスクイメージに対してmkfsを実行すれば十分なので、この節の内容は不要です。

まず、losetupを用いてファイルをループバックデバイスに結びつけます。この操作にはroot権限が必要です。

# losetup /dev/loop0 FILENAME

losetupに成功すると、/dev/loop0がFILENAMEを内容とするブロックデバイスとして振る舞うようになります。

何らかの理由でloop0が使用中の場合は、適宜loop1などに読みかえてください。

ループバックデバイスに対してfdiskを実行します。後の作業で各パーティションの開始セクタ番号が必要になるので、-uオプションを付けておきます。

# fdisk -u /dev/loop0
Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
Building a new DOS disklabel with disk identifier 0xaf87fef0.
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)

パーティションを作成します。この例では一つだけ作ります。

Command (m for help): n
First sector (63-1048575, default 63):
Using default value 63
Last sector or +size or +sizeM or +sizeK (63-1048575, default 1048575):
Using default value 1048575

パーティションを作成したら、状態を確認します。

Command (m for help): p

Disk /dev/loop0: 536 MB, 536870912 bytes
255 heads, 63 sectors/track, 65 cylinders, total 1048576 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0xaf87fef0

      Device Boot      Start         End      Blocks   Id  System
/dev/loop0p1              63     1048575      524256+  83  Linux
Partition 1 does not end on cylinder boundary.

表示される値のうち、「Units」の値（ここでは 512 bytes）と「Start」の値（ここでは63）を覚えておきます。

作成結果に問題なければ変更をイメージに書き戻して終了します。

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.

WARNING: Re-reading the partition table failed with error 22: Invalid argument.
The kernel still uses the old table.
The new table will be used at the next reboot.
Syncing disks.
Command (m for help): q

使いおわったらループバックデバイスを開放します。

# losetup -d /dev/loop0

イメージ内のパーティションをフォーマット

ここまでの作業でディスクイメージにパーティションを作成できましたが、まだ個々のパーティションにはファイルシステムが書かれていません。 個別のパーティションに対してmkfsを実行するための手順を説明します。

mkfsの対象とするためには、（ディスクイメージ全体ではなく）対象となるパーティションの部分を取り出す必要があります。

losetupの-oオプションを使用することで、ファイルの途中からをループバックデバイスに結びつけます。

先ほどの例では 開始位置が 63、Unit が 512 bytes だったので、パーティション#1のオフセットとして63*512=32256バイトを設定します。

# losetup -o 32256 /dev/loop0 FILENAME

losetupに成功したら、好みのファイルシステムを作成できます。

# mkfs.ext2 /dev/loop0

使いおわったらループバックデバイスを開放します。

# losetup -d /dev/loop0

イメージ内のパーティションに外からアクセス

既にファイルシステムが作られているイメージ（上記の手順で作成したものや、仮想環境で使っていたrawイメージなど）を扱う場合、 mountの"loop"オプションを使用することで、イメージ内部のパーティションを直接ホスト環境にマウントすることができます。

この例の場合、loopのoffsetに開始位置（32256）を指定する：

# mount -o loop,offset=32256 FILENAME /mnt/

と、/mnt経由で先ほど作成したパーティションの内容を操作することができるようになります。

作業が終わったら通常のmountと同じように

# umount /mnt/

します。

注意

Linux-2.6でモジュールパラメータを定義するマクロがMODULE_PARMからmodule_paramに変更されました。

Linux-2.4のMODULE_PARM:

/* パラメータparamをint型で宣言 */
static int param = 0;
MODULE_PARM(param, "i");
MODULE_PARM_DESC(param, "Description");

Linux-2.6のmodule_param:

/* パラメータparamをint型で宣言 */
static int param = 0;
module_param(param, int, S_IRUGO | S_IWUSR);
MODULE_PARM_DESC(param, "Description");

insmodの引数として指定できるパラメータであることは同じですが、module_paramではsysfsからもパラメータにアクセスできます。

# echo 1 > /sys/module/モジュール名/parameters/param

似たようなことはprocfsでもできますが面倒です。 module_paramであればsysfsの詳細を知らなくても定義するだけでモジュール内の変数をパラメータとしてユーザ空間にexportできます。 デバッグ時など、ioctlを使うまでもない場合には便利じゃないでしょうか?

モジュールではなくカーネルにstaticリンクされててもアクセスできます。

sysfsによってファイルとして見えるパラメータのパーミッションはmodule_paramの引数で指定します。

パラメータとして使う変数が文字列の場合、module_param_string を使います。

関連記事

• sysfs 経由でモジュールパラメータにアクセス (2)

Bishopエミュレータのベータ版を公開しました。

パイロンでは組込みLinux開発用CPUボードBishopのエミュレータを開発しています。主要な構成要素についてエミュレーションの実装が終了したので、Beta1として公開します。

今回のリリースでは、ソースコードとWindows向けインストーラの形式で提供します。以下のリンク先から取得してください：

ソースコード:

qemu-bishop-0.9.0cvs20071001-pylone0rc1.tar.bz2

Windows向けインストーラ:

qemu-bishop-0.9.0cvs20071001-pylone0rc1-setup.exe

今後

• Debianパッケージ

についても準備していく予定です。

リリース内容

本エミュレータは、オープンソースのプロセッサエミュレータQEMUの開発版をベースに、Bishop向けの機能を追加したものです。Bata1の段階では、まだ実機に存在する全ての周辺機器を正しくエミュレートできるわけではありません。

各種ペリフェラルのサポート状況

ソースコードからのインストール

必要な環境

• gcc-3.4 (4.x では動作しません)
• SDL 1.2

※Debian環境では、 # apt-get build-dep qemu を実行することで、必要なパッケージを一括してインストールすることもできます。

構築手順

ソースコードを展開したディレクトリ内で以下の手順を行うことで、実行可能ファイル ./arm-softmmu/qemu-system-arm が生成されます。

configure の実行

$ ./configure --target-list=arm-softmmu

コンパイル

$ make

エミュレータの実行

Bishopエミュレータに実機出荷状態と同様の動作をさせるためには、

• U-Bootイメージ
• Linuxカーネルイメージ
• initrdイメージ
• ファイルシステムイメージ
• スプラッシュイメージ

を与える必要があります。それぞれのファイルをリンク先からダウンロードし、ソースコードのトップディレクトリに置いた状態で

$ ./arm-softmmu/qemu-system-arm -M pe201b -serial stdio -kernel dummy -usbdevice keyboard -mtdblock nand-bishop.img

として起動してください。

1. U-Bootがメモリに読みこまれて起動
2. U-BootがLinuxカーネルを読みこみ
3. LinuxカーネルがNANDのファイルシステムイメージをマウント

の順で実行されて、最終的にログインプロンプトが表示されます。

このスクリーンショットは現在パイロンで開発中のBishopエミュレータです。オープンソースのプロセッサエミュレータQEMUをベースにしています。ちょっと試しにやってみるかという軽い動機で始めたのですが、作業が進み QEMU への理解が深まるにつれて組込みソフトウェア開発ツールとしての可能性を感じるようになりました。まだ具体的な活用をご提案できるまでには至っていませんが、何か役にたつ使い方があれば紹介していきたいと考えています。

2007/10/12:

Beta1をリリースしました。

2007/12/28:

Beta2をリリースしました。

2008/5/23:

Beta3をリリースしました。

2008/9/26:

Beta4をリリースしました。

2008/12/21:

正式版をリリースしました。

以前はピクセル値が配列にベタ書きされたヘッダファイルを用意する必要がありましたが、Linux-2.6でフレームバッファ周辺が書き直されて PNM を直接ソースツリーに置けるようになりました。

例として、このfreedesktop.orgのロゴ画像 (PNG, 80x80) を224色の起動ロゴにしてみます。

まず、画像をPNMに変換します。

$ convert -colors 224 fdo_logo.png fdo_logo.pnm

pnm2ascで ピクセル値がASCIIのPNMに変換して、drivers/video/logo/ に放り込みます。

$ pnm2asc fdo_logo.pnm > drivers/video/logo/logo_fdo_clut224.ppm

drivers/video/logo/Makefileに以下を追加します。

obj-$(CONFIG_LOGO_FDO_CLUT224) += logo_fdo_clut224.o

drivers/video/logo/Kconfig に以下を追加します。

config LOGO_FDO_CLUT224
        bool "224-color freedesktop.org logo"
        depends on LOGO
        default y

drivers/video/logo/logo.cに追加したロゴ画像のプロトタイプ宣言を加えます。

extern const struct linux_logo logo_fdo_clut224;

drivers/video/logo/logo.c:fb_find_logo()の if (depth >=4) { } の最後に以下を追加します。

#ifdef CONFIG_LOGO_FDO_CLUT224
                logo = &logo_fdo_clut224;
#endif

あとは、CONFIG_LOGO_FDO_CLUT224=yでカーネルをリビルドするだけです。

drivers/video/logo/{Makefile,Kconfig,logo.c}を弄りたくなければ、 既存のロゴを上書きするだけでもいいと思います。

価格

発売日

購入方法

ソフトウェア構成

プリインストールされるルートファイルシステムは Debian GNU/Linux 4.0 (etch) を ベースにしたものになります。 以前の記事でお知らせした uClibc による ルートファイルシステムは中止しました。

組込み Linux 開発において、アプリケーションのクロスコンパイルだけでそれなりの 時間を取られてしまった経験のある開発者の方も多いかと存じます。 Debian の豊富な バイナリパッケージをお使いいただければ製品企画段階のデモ機作成などが手軽に行え ます。

U-Boot の特筆すべき点は移植性の高さです。 アーキテクチャに依存する部分と非依存の部分が分離されているため、 コアアーキテクチャさえ対応していれば 新しい CPU への対応も比較的少ない作業で済みます。 また、デバイスドライバが豊富に用意されているため、 対応しているデバイスであれば デバイス固有のパラメータを与えるだけで動いてしまう事が多いです。 例として、実際に U-Boot を Bishop へ移植した際に追加したコードの一部をご紹介します。

LANコントローラDM9000

DM9000 のドライバは common/dm9000x.c です。ターゲットで動かすためには アドレスとバス幅を指定します。

include/configs/bishop.h:

#define CONFIG_DRIVER_DM9000    1                        /* ドライバを有効化 */
#define CONFIG_DM9000_BASE      0x20000300
#define DM9000_IO               CONFIG_DM9000_BASE       /* アドレス (I/O) */
#define DM9000_DATA             (CONFIG_DM9000_BASE + 4) /* アドレス (データ) */
#define CONFIG_DM9000_USE_32BIT 1                        /* バス幅 */

NAND

NAND のドライバは drivers/nand/ です。動かすためにはチップの数と NAND コントローラのベースアドレスを指定し、NAND コントローラ固有の処理を追加します。

include/configs/bishop.h:

#define NAND_MAX_CHIPS          1
#define CFG_MAX_NAND_DEVICE     1
#define CFG_NAND_BASE           0x4E000010

board/pylone/bishop/nand.c:

#include <common.h>

#if (CONFIG_COMMANDS & CFG_CMD_NAND) && !defined(CFG_NAND_LEGACY)

#include <nand.h>
#include <s3c2440.h>

static int hwctl = 0;

static void bishop_hwcontrol(struct mtd_info *mtdinfo, int cmd)
{
        S3C2440_NAND * const reg = S3C2440_GetBase_NAND();

        switch (cmd) {
        case NAND_CTL_SETCLE:
                hwctl |= 0x1;
                break;
        case NAND_CTL_CLRCLE:
                hwctl &= ~0x1;
                break;
        case NAND_CTL_SETALE:
                hwctl |= 0x2;
                break;
        case NAND_CTL_CLRALE:
                hwctl &= ~0x2;
                break;
        case NAND_CTL_SETNCE:
                reg->NFCONT = reg->NFCONT & 0xfffffffd;
                break;
        case NAND_CTL_CLRNCE:
                reg->NFCONT = reg->NFCONT | 2;
                break;
        }
}

static void bishop_write_byte(struct mtd_info *mtdinfo, u_char byte)
{
        S3C2440_NAND * const reg = S3C2440_GetBase_NAND();

        if (hwctl & 0x1)
                reg->NFCMMD = byte;
        else if (hwctl & 0x2)
                reg->NFADDR = byte;
        else
                reg->NFDATA = byte;
}

static u_char bishop_read_byte(struct mtd_info *mtdinfo)
{
        S3C2440_NAND * const reg = S3C2440_GetBase_NAND();
        return reg->NFDATA;
}

static int bishop_dev_ready(struct mtd_info *mtdinfo)
{
        S3C2440_NAND * const reg = S3C2440_GetBase_NAND();
        while (!(reg->NFSTAT & 1));
        return 1;
}

void board_nand_select_device(struct nand_chip *nand, int chip)
{
        S3C2440_NAND * const reg = S3C2440_GetBase_NAND();
        reg->NFCONT = reg->NFCONT & 0xfffffffd;
        return;
}

int board_nand_init(struct nand_chip *nand)
{
        S3C2440_NAND * const reg = S3C2440_GetBase_NAND();

        nand->eccmode = NAND_ECC_SOFT;
        nand->hwcontrol  = bishop_hwcontrol;
        nand->read_byte  = bishop_read_byte;
        nand->write_byte = bishop_write_byte;
        nand->dev_ready  = bishop_dev_ready;
        reg->NFCONF = 0x0300;
        reg->NFCONT = 0x0063;

        return 0;
}
#endif /* (CONFIG_COMMANDS & CFG_CMD_NAND) && !CFG_NAND_LEGACY */

Bishop の推奨 JTAG-ICE は ビットラン株式会社様 の DR-01 です。 DR-01 の デバッガソフト は CPU 固有のペリフェラル定義を簡単に追加できます。 パイロンでは S3C2440 用ペリフェラル定義ファイルを公開する予定です。 このペリフェラル定義ファイルをデバッガソフトに追加することによって、直感的なユー ザインタフェースで S3C2440 のペリフェラルレジスタへアクセスできます。

2008/06/07: ペリフェラル定義ファイルを公開

Bishop にプリインストールされるブートローダ U-BootはOSのブートだけでなくフラッシュメモリの書き込みもできます。フラッシュメモリ上のLinuxカーネルやルートファイルシステムを書き換えるにはU-Bootを使うのがもっとも簡単な方法です。

U-BootによってU-Boot自体を書き換える事も可能ですが、書き込みに失敗した場合は起動できなくなります。お客様がU-Bootを上書きした事による起動の不具合についてはサポート対象外とさせていただきます。

ダウンロードケーブルによる書き込み

オプションとして販売予定のダウンロードケーブルとライタープログラムを使えば、 PC からNORフラッシュメモリへ書き込む事ができます。 U-Bootを使った書き込みでは U-Boot自体の上書きが失敗した場合に起動できなくなってしまいますが、本ケーブルを使えば起動できない状態でも書き込むことができます。 フラッシュメモリ書き込みのためだけにJTAG-ICEを購入する必要はありません。

S3C2440 のリセットベクタはメモリコントローラのバンク0 (ROM/RAM の先頭) になります。 出荷状態の Bishop では バンク0 は NOR になっていますので、 ブートローダは NOR にインストールされます。 S3C2440 の Stepping Stone と呼ばれる機能により NAND からもブート可能ですが、 Bishop では Stepping Stone をサポート対象外とさせていただきます。

6.4インチ (写真) はボードとほぼ同じサイズで解像度は VGA です。 4インチは QVGA をワイドにした感じの 480x272 というちょっと変わった解像 度です。PSP と同じ解像度といえばわかりやすいでしょうか。

タッチパネルからの入力は Linux Input Drivers が提供する仕組みによって 特定のデバイスに依存しない抽象的なイベントとして扱うことができます。 /dev/input/event0 や /dev/input/ts0 に対応したアプリケーションであれば修正す ることなくタッチパネルを使えるでしょう。 サンプルアプリケーションとしてタッチパネルを 利用した手書き入力やソフトウェアキーボードなどもご用意させていただく予定です。

S3C2440 の主な機能:

• ARM920T コア, 16/32ビット RISC マイクロプロセッサ
• MMU
• Internal Advanced Microcontroller Bus Architecture (AMBA2.0, AHB/APB)
• メモリバンク x8 (ROM/SRAM x6, ROM/SRAM/SDRAM x2)
• 64ウェイ・セットアソシエイティブ・キャッシュ (I-Cache: 16KB, D-Cache: 16KB)
• オンチップ MPLL/UPLL
• パワーモード: Normal/Slow/Idel/Sleep
• RTC
• GPIO (24ポートが外部割り込みとして使用可能)
• 4チャンネル DMA コントローラ
• LCD コントローラ: STN LCD, TFT LCD
• A/D コンバータとタッチスクリーンインタフェース
• 3チャンネル UART
• I2C バスインタフェース
• I2S バスインタフェース
• AC97 Audio CODEC インタフェース
• USB ホスト x2 (OHCI Rev. 1.0)
• USB デバイス x1 (USB Specification version 1.1)
• SD ホストインタフェース (SD Memory Card Protocol version 1.0, SDIO Card Protocol version 1.0, Multimedia Card Protocol version 2.11)
• SPI インタフェース x2 (Serial Peripheral Interface Protocol version 2.11)
• カメラインターフェース (最大入力解像度: 4096x4096, 出力フォーマット: RGB 16/24 ビット / YCbCr 4:2:0/4:2:2)
• コア電圧 1.3V @ 400MHz, メモリ: 1.8V/2.5V/3.0V/3.3V, I/O: 3.3V

• CPU
• タッチパネルと LCD
• カメラ
• フラッシュメモリ
• フラッシュメモリの書き込み
• JTAG-ICE
• U-Boot
• uClibc によるルートファイルシステム
• Debian GNU/Linux
• 開発環境