lightMPDのルートイメージの作成方法について説明します。
lightMPDは
の３つのコンポーネントからなります。
lightMPDではルートイメージの作成にbuildrootを使用しています。buildrootは上記のコンポーネントをまとめてbuild および管理できますが、
lightMPDではルートイメージの作成だけに使用しています。kernel,boot loaderに付いては別途用意する必要があります。
kernelはお好きなバージョンを用意して下さい。
boot loaderについてはboot loaderで音が変わるという事はないので、lightMPDにパッケージ内の物を使うようにします。
boot loader を新たにbuildしたり他のシステムのを流用する場合はlightMPD付属のuEnv.txtが使えなくなる場合がありますので注意して下さい。
この文書の為にbeaglebone用のbuildroot設定ファイルを公開しました。
最近lightMPDでは扱わないbeagleboneのI2SのDACをlightMPDで使用する動きあり、具体的にlightMPDを改造したいと要望があるためbeagleboneで説明します。
公開した設定ファイルはbeaglebone用ですが、すこしの手直しでcubox,raspi,raspi2,cuboxi4などのlightMPDがサポートしているARM系のシステムに対応することが可能です。
その説明もこの文書で行います。
公開するに当たってbuildrootの最新版であるbuildroot-2016.11.1用の物を改めて用意しました。また、この設定で作成したuInitrdを含むlightMPDのパッケージも用意しました。
この設定ファイルではmpd-native-dsdというパッケージを追加してあります。mpd-native-dsdはmpd-0.19.21にnative-dsdおよびlightMPDで作成したパッチを適用したmpdです。
注意
buildrootにはコンパイラーをダウンロードして設定する機能もありますが、lightMPDの様に複数システムを構築する場合、システム毎にコンパイラーをダウンロードするのも煩わしいので、
lightMPDではbuildrootとは別にコンパイラーを用意します。
説明にあたってディレクトリを下記のシンボルで表します。
ダウンロード
下記の物を$DOWNLOADにダウンロードして下さい。
gccは開発環境に合わせてダウンロードして下さい。
gcc のバージョンを変更する場合は、設定ファイルを変更する必要があります。
パッケージのインストール
下記の通りにパッケージを展開して下さい。
下記例では64bit OSを前提にしています。
$TOOLCHAINSは$BASEDIR/toolchainsにしました。
# ディレクトリを作成しますmkdir $BASEDIR <--- $BASEDIRは適当に設定して下さいmkdir $BASEDIR/beaglebonemkdir $BASEDIR/toolchains#コンパイラーの設定を行いますcd $BASEDIR/toolchainstar xvfi $DOWNLOAD/gcc-linaro-6.2.1-2016.11-i686_arm-linux-gnueabihf.tar.xz#buildrootの設定を行います。cd $BASEDIR/beaglebonetar xvfi $DOWNLOAD/buildroot-2016.11.1.tar.bz2ln -s $TOOLCHAINS/gcc-linaro-6.2.1-2016.11-x86_64_arm-linux-gnueabihf lightmpd-gcc
#buildrootにlightmpdの設定ファイルをコピーします。cd $BASEDIR/beaglebone/buildroot-2016.11.1tar xvfz $DOWNLOAD/lightmpd-buildroot-beaglebone.tgz# lightMPDの追加ファイルを展開しますcd $BASEDIRtar xvfz $DOWNLOAD/lightmpd-root-v15.tgz注意
ln -s $TOOLCHAINS/gcc-linaro-6.2.1-2016.11-x86_64_arm-linux-gnueabihf lightmpd-gccのリンク先($TOOLCHAINS/gcc-linaro-6.2.1-2016.11-x86_64_arm-linux-gnueabihf)は
/から指定して下さい。相対パスで指定するとbuild時にエラーになります。
$BASEDIRは下記のようになります。
$BASEDIR
├── beaglebone
│ ├── buildroot-2016.11.1
│ └── lightmpd-gcc -> $TOOLCHAINS/gcc-linaro-6.2.1-2016.11-x86_64_arm-linux-gnueabihf
├── lightmpd-root-v15
└── toolchains
└── gcc-linaro-6.2.1-2016.11-x86_64_arm-linux-gnueabihf
build
下記のコマンドを実行します。
$ cd $BASEDIR/beaglebone/buildroot-2016.11.1 $ make lightmpd_beaglebone_defconfig $ makeこれで$BASEDIR/beaglebone/buildroot-2016.11.1/output/imagesに
ができます。(mac mini-2011(cpu 2GHz corei7)上のvmwareで構築したubuntu-16.04(64bit)で約１時間ほどかかります)
rootfs.romfsの再構成
rootfs.romfsはmount の -t loop オプションを使ってマウントできますが、rootfs.romfs がリードオンリーなファイルシステムなので直接変更する事ができません。
そこで、rootfs.romfsの内容を別なディレクトリにコピーして変更します。その後、変更したディレクトリをromfsにします。
作業ディレクトリは適当に作成して下さい。下記説明では$BASEDIR/beaglebone で行います。
# rootfs.romfsを展開するディレクトリ(rootfs)を作成します
cd $BASEDIR/beaglebonemkdir rootfscd rootfs
# rootfs.romfsをrootfsに展開します。## /mntにrootfs.romfsをマウントしますsudo mount -o loop ../buildroot-2016.11.1/output/images/rootfs.romfs /mntsudo cp -a /mnt/* .
sudo umount /mnt
# lightmpd用にrootfsを再構成します。## 書き込む必要なファイルを書き込み可能な領域へのシンボリックリンクにします。sudo ../../lightmpd-root-v15/prepare.sh## lightmpdの各種ファイルをrootfsに展開します。sudo cp -a ../../lightmpd-root-v15/rootdir/* .# roofsを initrd.romfsに戻します。sudo genromfs -f ../initrd.romfscd ../# initrd.romfsをu-bootの形式にします。gzip initrd.romfsmkimage -A arm -O linux -T ramdisk -C gzip -a 0 -e 0 -n "lightMPD@bbb-v1.0.3 romfs" -d initrd.romfs.gz uInitrduInitrd がu-bootでロード出来るルートイメージになります。
これで lightMPD-bb-v1.0.3.zipに含まれるuInitrdと同じ物が作成できます。
buildrootでmake menuconfigとすると下記のメニューよって設定ができます。menuconfigの結果は.configファイルに保存されます。
Target options ---> Build options ---> Toolchain ---> System configuration ---> Kernel ---> Target packages ---> Filesystem images ---> Bootloaders ---> Host utilities ---> Legacy config options --->lightMPDでのbuildrootの使い方はルートイメージの作成だけです。このような場合、buildrootの設定は以下のように分類できます。
---
lightMPDで用意したconfigファイルを元にbeaglebone以外のシステムに対応する場合は以下のように変更して下さい。
Target optionos
ターゲットシステムのCPUの情報を設定します。
これはクロス開発環境をbuildする時に参照されます。 ターゲットのCPUに関する知識が必要になりますが、解らない場合はconfigsに各種システムのconfigがあります。configはxxxx_defconfigsとなっています。xxxxがボード又はCPU名になっています。
Build options
buildする環境を設定します。
これは殆どいじる必要がありません。あるとすれば gcc optiomiztion levelぐらいです。
Toolchain
クロス開発環境の設定を行います。
lightMPDで用意したconfigファイルを使う場合、arm系のシステムでは変更の必要はありません。
Toolchain type で buildroot toolchain を選ぶとbuildrootで用意したgccをbuildします。gccのバージョン、libcのバージョン等を選択できます。
gccのbuildには相当の時間がかかります。arm系の場合はlinaroのバイナリーを別途用意したほうがいいと思います。
Target Optimizastionsで最適化のオプションを指定しますが、ここでいろいろ設定するとパッケージのbuild時にエラーがでたり実行時にエラーが場合があるので、"-O2" ぐらいにして下さい。
さらなる最適化が必要な場合はパッケージ毎に指定します。
System configuration
ターゲットシステムの実行時の環境を指定します。
System hostname,System bannerは必要に応じて変更します。Run a getty after boot をチェックした場合は、ボードの仕様に合わせてTTY port, Baudrateを指定します。
これをチェックしないとシリアル接続のコンソールが使えなくなります。
Target packages
rootイメージに含むパッケージを選択します。
Filesystem images
結果として作成するイメージファイルを指定します。
lightMPDの設定ファイルでは
をチェックしてありますが、実際につかっているのはromfsです。
cpio the root filesystem
initramfsという仕組みを使ってramdisk上にルートファイルを構築します。ファイルシステムはrootfsでこれは読み書きできます。
initramfsの前はinitrdという仕組みが一般的でした。initrdはramdisk上にext2ファイルシステムを作ってそこにルートファイルを構築します。
私はinitramfsはinitrdと殆ど同じ物と考えていました。ルートファイルシステムにext2を使うのを嫌ってromfsを採用しましたが、これならinitramfsを採用すればよかったとちょっと後悔しています。
将来romfsからinitramfsに変更するかもしれません。これから独自にシステムを構築する場合もinitramfsの方がシンプルになります。
romfsではramdiskのサイズをkernelのパラメータで指定しましたが、initramfsでは実メモリの1/2に設定されています。
cramfs root filesystem
cramfsはromfsと同じで読み込み専用のファイルシステムです。cramfsは圧縮されたままディスクに展開されるのでメモリの小さなシステムでは有効です。
romfs root filesystem
romfsはその名の通り読み込み専用のファイルシステムです。
lightMPDではプログラムをロードしたらディスクへのアクセスは行わないのでなるべく大げさなファイルシステムは使いたくありませんでした。
ファイルシステムはデータの読み書きの他に、領域の管理や排他制御などの機能があります。
領域管理というのはデータを書き込む際ににまだ使われていない領域を探し出したり、データを削除したときにその領域をまだ使われていない状態にする機能の事です。
排他制御は同じ領域に同時に読み書きが行われたときに適切に処理する機能です。読み込み専用のromfsではこれらの機能は必要なくとてもシンプルになります。
/var配下のファイルの様に書き込みが出来ないと困るファイルもあるので、/varはtmpfsにマウントしシステム初期化時にその配下のファイルを作成しています。
linuxでのブートは一般的に以下のようになります。
このうち、4.までの処理はブートローダーと呼ばれるプログラムが行います。arm系(raspi系は除く）はu-boot,X86系ではgrubがよく使われます。raspi系は独自のブートロードを持っています。
カーネルの初期化ではIOの初期化なども行われますが、ドライバーがモジュールになっている場合はミニルートからロードします。また、デバイスにアクセスするためのデバイスファイル（特殊ファイル)もミニルートになければなりません。
rootファイルをマウントするとミニルートが格納されているramdiskは破棄されます。rootとして/dev/ram0(ミニルートのあるramdisk) を指定した場合はこの処理は行われません。
初期化が終わるとミニルートがinitrdの場合はlinuxrcを起動します。linuxrc終了後、kernelが/sbin/initを起動します。
initramfs(romfsも該当)の場合はinitを起動します。init内で/sbin/initを起動します。
現在のinitは/sbin/initを起動する為の簡単なスクリプトです。
#!/bin/sh# devtmpfs does not get automounted for initramfs/bin/mount -t devtmpfs devtmpfs /devexec 0</dev/consoleexec 1>/dev/consoleexec 2>/dev/consoleexec /sbin/init $*このスクリプトを修正してシステム独自の処理を加える事も可能ですが、/sbin/initが起動する前の状態ではいろいろと制約があります。
/sbin/initは全てのプログラムの親プロセスになり、本来デーモンというのはinitの事を言ってました。initの他に最近ではsystemdもよく使われます。
busybox menuconfigの System Configurataion -> Init System で下記より選択できます。
BusyBox,systemVを選択すると/sbin/initがデーモンに成ります。
systemdはkernelとも密接に関連します。Control Group Supportとかがないとエラーになります。
lightMPDではInit System に BusyBoxを選択しています。
/sbin/initについて
BusyBoxの/sbin/initとsystemvのそれとは仕様が異なります。systemvの方が本家になります。最も大きな違いがsystemvにはrunlevelという概念がありますが、BusyBoxにはそれがありません。
ここではBusyBoxの/sbin/initについて説明します。
/sbin/initは/etc/inittabに従ってシステムの初期化を行います。システム初期化後、常駐します。
/etc/inittabは以下のようになっています。
# Copyright (C) 2001 Erik Andersen <andersen@codepoet.org>## Note: BusyBox init doesn't support runlevels. The runlevels field is# completely ignored by BusyBox init. If you want runlevels, use# sysvinit.## Format for each entry: <id>:<runlevels>:<action>:<process>## id == tty to run on, or empty for /dev/console# runlevels == ignored# action == one of sysinit, respawn, askfirst, wait, and once# process == program to run# Startup the system::sysinit:/bin/mount -t proc proc /proc#::sysinit:/bin/mount -o remount,rw /::sysinit:/bin/mkdir -p /dev/pts::sysinit:/bin/mkdir -p /dev/shm::sysinit:/bin/mount -a::sysinit:/bin/hostname -F /etc/hostname# now run any rc scripts::sysinit:/etc/init.d/rcS# Put a getty on the serial portttyS0::respawn:/sbin/getty -L ttyS0 115200 vt100 # GENERIC_SERIAL# Stuff to do for the 3-finger salute#::ctrlaltdel:/sbin/reboot# Stuff to do before rebooting::shutdown:/etc/init.d/rcK::shutdown:/sbin/swapoff -a::shutdown:/bin/umount -a -rコメントにあるように各行はid:runlevels:action:process になっています。
busyboxではid,runlevelsに特に意味はないようです。
actionはプロセスの起動方法を指定し、以下の物を指定します。
processは起動するプロセスです。
起動時の処理の内
::sysinit:/bin/mount -t proc proc /proc::sysinit:/bin/mkdir -p /dev/pts::sysinit:/bin/mkdir -p /dev/shm::sysinit:/bin/mount -aはディスクのマウントの準備およびマウントを行います。
::sysinit:/bin/hostname -F /etc/hostnameは/etc/hostnameをホスト名として設定しています。
::sysinit:/etc/init.d/rcSは /etc/init.d/内のS00xxxx から S99yyyy までのスクリプトを数字の順に実行します。
ttyS0::respawn:/sbin/getty -L ttyS0 115200 vt100 # GENERIC_SERIALはシリアル回線(ttyS0)に対してgettyを起動します。gettyはlogin処理を行うプログラムです。beagleboneのシリアル回線はttyS0ですが、他のシステムではデバイス名が異なります。
これでシステムが起動したことになります。
lightMPDの初期化
lighMPDではシステム起動前に
を行います。
この処理は/etc/init.d/rcSの起動前に行う必要があります。lightMPDでは/etc/init.d/S00setupvar を用意して /etc/init.d/rcSからS01***以降のスクリプトの起動に先立って行うようにしました。
その他の方法としては
が考えられます。
1.の方法ではinittabを見て解るように/procすらマウントされていませんので、いろいろと制約があります。
2.,3.はすでにマウントもされているのでいずれの方法でも問題ありません。
1.の方法では,S00setupvarをsetupvarにリネームして/etc/init.d/rcSのS??* 起動する前でこれを呼び出します。
2.の方法の場合、inittabのmount -aの行の後に
::sysinit:/etc/init.d/setupvar
を追加します。
buildrootのバージョンによってinittabやrcSが変更されるとその部分を変更しなければならず煩わしいのでこれらのファイルを変更しない方法を選択しました。
特定のアプリケーションだけを起動すればいい場合は、/sbin/initの代わりにそのアプリケーションを起動する事も可能です。但し、そのアプリケーションが起動する環境を先立って構築しておかなければなりません。（私は実施したことはありません)
/etc/init.d/S00setupvar
syssetup.scm
make menuconfig
mpd-native-dsdについて
パッケージの追加（polipoを例にとって)
新しいパッケージの作成(mpd-0.20を例にとって)
soxのopenmp対応