Freescale社製PowerPCボードADS512101へLinuxカーネルを移植する手順を紹介します。

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とボードを接続します。通信設定は以下のとおりです。

ボーレート

115200

ビット長

8

フロー制御

なし

ストップビット

1

ボードの電源を投入後、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

とします。

block2mtdドライバを使えば、jffs2イメージファイルをloopbackでmountできます。

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

組込みLinux開発用CPUボードBishopに同梱されるソフトウェアのバージョンアップを実施いたします。

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

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

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

• バージョンアップ手順

関連リンク

• Bishop - ソフトウェア仕様

組込みLinux開発用CPUボードBishopエミュレータの正式版をリリースしました。

ドキュメント

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

ダウンロード

関連記事

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

正式版を公開しました - 記事: Bishopバージョンアップのお知らせ

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

以前の記事で sysfs からモジュールパラメータにアクセスする簡単な方法を紹介しましたが、今回はパラメータの型を独自に定義する例として Base36 のパラメータを持つ簡単なモジュールを紹介します。

コード

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(2) より使い勝手がよいかもしれません。

関連記事

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

Linux kernel の機能の一部である Power supply class を利用した、仮想バッテリドライバを公開します。

概要

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 が発生するので、バッテリの状況を動的に把握することが可能です。

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

正式版を公開しました - 記事: Bishopエミュレータ正式版リリース

組込み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 開発用 CPU ボード Bishop の ドキュメントに サンプルコードを追加しました。

Bishop のカーネルを distcc による分散クロスコンパイル環境 でクロスコンパイルしてみました。

distcc の FAQ によると

You should use about twice the total number of CPUs available, but it dependson your network, program being compiled, available memory, etc. Experimentwith 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 による分散クロスコンパイル環境

正式版を公開しました - 記事: Bishopエミュレータ正式版リリース

組込み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エミュレータに関する記事

カスタムボードへのLinuxカーネル移植の初期段階でとりあえずのrootfsが必要になる場合は多いと思います。とりあえずのものにそれほど手間はかけたくないですが、カーネルのデバッグや動作確認のために機能はそれなりに欲しいところです。

方法は色々あると思いますが、パイロンでは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/

何もインストールされていないターゲット向けにDebian基本システムを作る手順です。Debianの作法的に正しいかどうかはわかりません。

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

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の基本的な使い方を知っている方向けの記事です。

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

となります。

正式版を公開しました - 記事: Bishopエミュレータ正式版リリース

組込み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エミュレータに関する記事

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

最新版は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パッケージ を 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

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

# yum update

必要なツールをインストールします。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: 公開

About

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 ./

アーカイブの鍵を導入します。

# 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を使わせて頂きました。

sysfs経由でモジュールパラメータにアクセスする方法を紹介します。

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エミュレータ正式版リリース

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}を弄りたくなければ、既存のロゴを上書きするだけでもいいと思います。

これから何回かにわたって、7月発売予定の組込み Linux 開発用 CPU ボード Bishop についての情報をお伝えしたいと思います。予定している内容は以下の通りです。

• CPU
• タッチパネルと LCD
• カメラ
• フラッシュメモリ
• フラッシュメモリの書き込み
• JTAG-ICE
• U-Boot
• uClibc によるルートファイルシステム
• Debian GNU/Linux
• 開発環境