2013-06
2013-05 FM3 RX62N SH2A PIC32MX
6月
- とりあえず、220円で作るUSBオシロスコープは完成した(つもり)
- PIC32MXでFT2232互換ファームを作る計画があったんだけれど、また先延ばし。(FT232Hモジュールが秋月で安く買えるようになったので、わざわざマイコンでFT232の代わりをやらせるのも面倒面倒)
6月のテーマ:予定
- 急遽、LEDディマーを作る予定。内容は謎。
- マウスの修理
- 長いことIntelliPoint Explororを使っていたんだけど、ボタンが接触不良になった。
- それで、Comfort 6000を買ってきたのだが、こいつ、じっとしていてもこっくりさんをしたり、動かしてるときもポインタがふらつく。最悪だ。
- 古いのを修理して元に戻そう。
- オシロだと500kSPS程度が限界みたいなので、DMA叩いてPORTをサンプリングする、ロジアナっぽいやつを作ってみる。
- SPIインターフェースを使って1bit DACを書いてみようかなとかそんな奴。(SPIの先にDACを繋ぐ訳ではない)
Linux Containers
Linuxコンテナ(LXC)というのは、仮想マシン(VM)を使わない、Linux OSの多重化の実装。
荒っぽく言うと、chrootでユーザーランド切り替えて、ついでにcgroupsでプロセス空間とかもうまくホストOSから隔離してしまう奴。
どこが良いんでしょう?
- 仮想マシンを導入することによるパフォーマンスオーバヘッドが無くなって軽くなる。
- でかい仮想ドライブイメージとかも要らない。単にどっかのディレクトリにchrootするマウントポイントと、最小限のLinuxが置いてあればよい。
- ゲスト側で独立したOSが動いているわけではないので、多重化環境をたくさん用意してもあんまりリソース食わなくて済む。(高密度化出来る)
- 起動/シャットダウンがめちゃ速い。というか一瞬。(Xenのpvmも相当早いんだけど)
弱点?
- カーネルは全部共通になる。(ホストOSのカーネルが実行する)。
- Linux以外のOSは多重化できない。
- まだまだ開発途上なんだけど、ubuntu12.04以降ではだいたい動いてるよ。
LXCの導入
上記URLのとおりにする。えらく簡単。
# apt-get install lxc lxctl # lxc-create -t ubuntu -n raring # lxc-start -n raring
この3行でもう新しいubuntuが動いてしまうくらい。
落とし穴。(トラブルシュートともいう)
- 1)環境変数LANGをja_JP.EUC-JPやCにしてる人は全然インストール(lxc-create)出来ない。
# export LANG=ja_JP.UTF-8
- にすべし
- エラーメッセージに出てこないので、これは何が原因なのか分からない落とし穴。
- ubuntu12.04まではOKだったのに・・・。
- 2)LANのinterfaceはlxcbr0 というのが自動的に作られる。(10.0.3.1とかになる)
- ホストLinuxからゲートウェイするのであればそれでもOKだけど、普通にLAN内に晒したいならば、
- /etc/lxc/default.confを編集して
lxc.network.link = eth0
- とか(すでにXenのブリッジがあるなら)
lxc.network.link = xenbr0
- とかに書き換える。
- すでにcreate済みのゲストOSならば、
- /var/lib/lxc/ゲストOS名/config を同様に書き換える。
- ubuntuのユーザーランドが出来る場所。
- /var/cache/lxc/ 以下にはdebootstrapで取得された最小限のユーザーランドがダウンロードされる。
- # lxc-create -n <OSインスタンスの名前> すると、 /var/lib/lxc/<OSインスタンスの名前>/ 以下に、ユーザーランドがコピーされ、ついでにconfigも置かれる。
- # lxc-destroy -n <OSインスタンスの名前> を実行すると、/var/lib/lxc/<OSインスタンスの名前>/ 以下は消滅する。
おまけ:x86環境でarmのlinuxをホスティングすることも出来る。
- これはXenとかVMWareでは出来なかった芸。QEMUを使うけど。
# apt-get install qemu-user-static # lxc-create -n armhf -t ubuntu -- -a armhf # lxc-start -n armhf
- arm-linuxが動くということは、その中でchrootすればAndroidを動かすことも出来る(原理的に)
まだ試していない。-- 試してみたけど、だめだった。ログインしようとしてもプロンプトまで来ない。原因不明。- ubuntu12.04.2LTSだと動く。13.04だとパスワードを入力した後、だんまりになる。
- やはり原因不明。
- ubuntu12.04.2LTSで試す。
- psコマンドでsignal 11(SEGV)が出る。
- それ以外はだいたい動いている。(ような気がする。)
LXC:arm-linuxのベンチマーク
適当なベンチマークソフトが無かったので、古いPerl5.005のTarBallの圧縮時間で計測。
- tar.gzで5MB
5251351 2013-06-17 22:00 perl5.005_63.tar.gz
- これをgzipで一旦展開させて、
$ gzip -d perl5.005_63.tar.gz
- 再圧縮の時間を計る。
ubuntu@arm:~$ time gzip perl5.005_63.tar real 0m14.734s user 0m14.681s sys 0m0.048s
processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 Duo CPU E4500 @ 2.20GHz stepping : 13 microcode : 0xa1 cpu MHz : 1200.000 cache size : 2048 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0
- cpuinfoではintelになっているけれど、gzipはれっきとしたARMバイナリー
ubuntu@arm:~$ file /bin/gzip /bin/gzip: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs) ,for GNU/Linux 2.6.31, BuildID[sha1]=XXX, stripped
ubuntu@arm:/bin$ ldd gzip librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0xf67cc000) libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0xf67bb000) libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xf66d7000) /lib/arm-linux-gnueabihf/ld-linux.so.3 => /lib/ld-linux-armhf.so.3 (0xf6fe0000) libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0xf66bc000)
- 比較対象:玄箱Pro(MarvelのARM 266MHzシングルコア)
kurobox$ time gzip perl5.005_63.tar real 0m43.373s user 0m27.670s sys 0m0.440s
Processor : Feroceon rev 0 (v5l) BogoMIPS : 265.42 Features : swp half thumb fastmult edsp CPU implementer : 0x41 CPU architecture: 5TEJ CPU variant : 0x0 CPU part : 0x926 CPU revision : 0 Hardware : Buffalo/Revogear Kurobox Pro Revision : 0000 Serial : 0000000000000000
- 比較対象2:普通のintel LinuxBox(仮想マシン 1CPU)
ubu-vm:~% time gzip perl5.005_63.tar real 0m1.132s user 0m1.116s sys 0m0.008s
結論
- LXC(Linuxコンテナ)上のarm-linux(要はQEMU上で動いているARMのユーザーランド。Linuxカーネルだけはx86_64)の速度は
- 普通のintel上で動かすLinuxの1:14程度の速度でちゃんと動いている。(1/14を遅いと見るか速いと見るかはその人次第)
- その速度は、玄箱Pro(ARM 266MHz)のなんと3倍もある。(MarvelのARM CPU換算で800MHz程度!)
ただし測定方法がgzip圧縮の時間計測のみなので、結構不正確かもしれない。
LXC:arm-linuxのその後
その後やってみて分かったことのメモ
- ubuntu13.04にて、arm-linuxが動かない件は再現性あり。
# apt-get install qemu-user-static # lxc-create -n armhf -t ubuntu -- -a armhf # lxc-start -n armhf
不具合症状
- これで起動したarm-linuxにログインしようとすると、(ubuntu/ubuntu)パスワード入力まで出来ても、コマンドプロンプトまで来ないでだんまりになる。
試行錯誤した結果の、暫定的な解決策
- /var/lib/lxc/armhf/rootfs/ にchrootの根っこがあるので、その下の home/ubuntu/ 以下の .profile を編集して、 .bashrc を実行しないようにする。
- すると、一応プロンプトに来る。
- 普通にarm-linuxとして使ってみる。
Tips
- lxc-start に -d (デーモン起動)オプションを与えない場合(上記)は、arm-linuxから抜け出せなくなる。
- なので、以下のように変えてみる。
# lxc-start -d -n armhf # lxc-console -n armhf
- こうしておくと Ctrl+A、q の2キーストロークでarm-linuxから脱出できる。
- コンソールを繋いだ状態 (lxc-console -n armhf)で暫く置くと、(QEMUで動いているほうの) rsyslogd がSegVで何度も落ちるとか、時々QEMUが、Unsupported Syscall 37? とかのエラーを吐いているので、まだまだエミュレーションは完璧とはいえないようだ。
- 試しに
# apt-get update # apt-get install build-essential
- したのち、jed(小さなテキストエディタ)をソースからビルドしてみた。
- intel x64
real 0m17.860s user 0m16.480s sys 0m1.068s
- arm-linux On QEMU
real 2m26.298s user 2m15.752s sys 0m7.588s
- 速度比率
146sec:17.8sec = 8.20
- ただし、同様のテストを別のcore2なLinux hostでやってみたところ、6分くらい掛かったので、QEMUの実行速度は ばらつきが大きいかもしれない。
結論
- わざわざQEMU経由でarm-linuxを動かすのは置いといても、普通にLinux On Linuxが手軽に試せるのは良いし、
- Windows上のVMWarePlayerで動いているubuntuだろうが、レンタルサーバーの借りてる仮想マシン上だろうが、
- それがubuntu12.04以降であれば気軽にLXCを試すことが出来て、設定弄りに失敗しても即座にdestroyしたり cloneしたり出来るので、かなり便利です。動作も軽いし、各種リソースも最小限で動きます。
参考URL
PIC32MX:水晶発振から内蔵RC発振への変更。
- 一応うまくいった。
課題
- 当然ながら、水晶と比べて、動作周波数が不正確(不安定)になる。
- CLKIとRA4を接続する必要がある。CLKOは空きになる。差し引きで使用可能ピン数は変わらない。
- ファームサイズが1kBとまではいかないけれど少し肥大化する。
- 動作周波数が不正確でも良いけれど高密度実装したいとかそんな時には使えるかも。
- AVR-USB(V-USB)の内蔵RCよりは通信は安定する。(ハード実装のUSB SIEなので)
ソースはそのうち上げます。