2012-01
あけました。
- 2011はなんとか積み基板(MARY,RX62N,SH2A)の消化が出来ました。
- 今年は積み基板を作らないようにしよう。
持ち越し案件
- USBオシロみたいな奴。
- SH2AのFPU使いこなし。
- MinGWクロスgccのビルド。
- STM32F4Discovery、まだ買ってません。(今のところ需要無し)
とりあえず、MinGWのクロスgccの作り方をお勉強。
- ただいま大絶賛サボリ中。
- むしろubuntu上でXen-serverを動かそうとしている今日この頃。
- 脱線するする。
動いたっ!
- grub起動時に普通にkernelを起こしたらダメ
- まず、Xenを選択して、次に、kernel-3.0.4とかを選択するよろし。
- って、知ってたけどその大事なことを守ってなかった。
- キーボードで毎回操作するのは面倒。/etc/default/grub を編集して
GRUB_DEFAULT=3
- に変更する。(たぶんgrub Menuの 03 番目にXenが来てる筈。そうでなかったら数える)そして、
# update-grub
- する。
- 再起動する。
# xm info # xm list
- とか出来たらOK。
- そして、適当な4GBとか8GBのバイナリーファイルをddで作って、
- xm-ubuntu.cfgを書いて仮想ドライブをそのファイルに設定しておいて、
- dom-Uにubuntuをnet install する。
- もいっかい、
# xm create -c xm-ubuntu.cfg
- すると仮想マシンを操作できる。
- 仮想マシンに接続しているscreenというか仮想コンソールの終わらせ方が分からない。 ^Aかと思ったけど違うし。
どうしよう困った <--- 今ここ
あいかわらず間抜け。
- CTRL+']' でOKだった。
# xm create xm-ubuntu.cfg
で起動したvmにconsole接続するには# xm console oneiric (oneiricは vmのid名)
とかでOK. consoleを抜けるには CTRL + ']'
vmを停止させるのは
# xm shutdown <vmのid>
VMWareみたいにサスペンドしたいなら、
# xm save <vmのid>
だ。
- 一応vmの中からnetも繋がるようになったけれど、外からvmのサービスに繋げられない。
というかNICのブリッジ接続のやりかたが分からない(xenbr0とかbr0は無いと言われる)
xenbr0:分かったこと。
- xenbr0は自分で作っておかないとだめらしい。
- /etc/network/interfaces に追記する。
# Xenのブリッジインターフェース. auto xenbr0 iface xenbr0 inet static bridge_ports eth0 address 192.168.1.200 broadcast 192.168.1.255 netmask 255.255.255.0 gateway 192.168.1.1
- dom-Uのeth0が仮に 192.168.1.2になっていて、vm側を適当に192.168.1.200にすると仮定。
- ifconfig して、xenbr0が出来ていることを確認したのち、
- /etc/xen/xm-ubuntu.cfg (自分用vmの起動設定)のvif項目をvirbr0からxenbr0に変更する。
- vif = ['','bridge=virbr0'] + vif = [ "mac=00:16:3e:17:d4:87,bridge=xenbr0" ]
- vmを起動する。
# xm start -c xm-ubuntu.cfg
- なぜかvmのipアドレスは固定ではなくDHCPで割り当てられてしまったが、vmが外界からアクセスできるようにもなった。
とりあえず成功。
参考URL (StrayPenguin)Xenについて非常に詳しく解説されている。
Xen: ubuntu11.04 : 単純な外界接続用ブリッジ xenbr0 を作る、いんちきくさいやり方。
- 上記
- xenbr0は自分で作っておかないとだめらしい。
- /etc/network/interfaces に追記する。
# Xenのブリッジインターフェース. auto xenbr0 iface xenbr0 inet static bridge_ports eth0 address 192.168.1.200 broadcast 192.168.1.255 netmask 255.255.255.0 gateway 192.168.1.1
- dom-Uのeth0が仮に 192.168.1.2になっていて、vm側を適当に192.168.1.200にすると仮定。
- /etc/xen/xm-ubuntu.cfg (自分用vmの起動設定)のvif項目をvirbr0からxenbr0に変更する。
- vif = ['','bridge=virbr0'] + vif = [ "mac=00:16:3e:17:d4:87,bridge=xenbr0" ]
これでいいのだけれど、192.168.1 のドメイン内に、
- (1)dom-0のインターフェース eth0: (仮に192.168.1.10とする)
- (2)dom-Uのインターフェース (vm側のeth0:)(192.168.1.2)
- (3)ブリッジのインターフェース xenbr0:(192.168.1.200) の3つのIPアドレスが出てしまう。
- それで、xenbr0のIPを隠蔽したかったので(というかプロバイダーの事情でIP8本しか貰えないとかあるので)
- xenbr0のIPを192.168.1以外に振ってみたりとか、IPを振らないでみたりとか(DHCPにしておいて、DHCPサーバー置かないとか)
- (2)と(3)を同じにしてみたりとか・・・
いろいろやってみたのだけれどどれもpingが通らなかったりそもそもOSが起動しなかったりで;;;汗
そこで、裏技を考えた。
- いっそdom-0のeth0:を消しちゃえばいいんじゃね?
さっそくやってみる。
- /etc/network/interfaces から xenbr0 の記述を全部消す。
- /etc/network/interfaces のeth0の記述の最後に、
iface eth0 inet static ・・・ bridge_ports eth3
- を追加する。(をを?何をする?) eth3はまだ実在しない。
- 次に、デバイス名eth0をeth3にリネームしておこう。
- /etc/udev/rules.d/70-persistent-net.rulesを編集する。
# PCI device 0xaaaa:bbbb (r8169) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="xx:xx:xx:yy:yy:yy", ATTR{dev_id}== "0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0" <== ここをeth3に書き換え。
- 再起動
- そうすると、実デバイスeth3にはIPアドレスを割り当てず、eth0がブリッジ名になってしまう。
- その状態で、/etc/xen/xm-ubuntu.cfg を書き換え。
#vif = [ "mac=00:16:3e:17:d4:87,bridge=xenbr0" ] vif = [ "mac=00:16:3e:17:d4:87,bridge=eth0" ]
- vmを起動して、vm内のinterfacesを書き換えて、外界と/から通信できることを確認。終わり。
なんということでしょう。IPアドレス2個で2台のマシン(1台はvm)が使えました。
さらに続くXen-hypervisor試用記
- ubuntu 32bit/64bitのvmを4Gの仮想ファイル上にインストール。
- だいたいどっちも1Gちょっと消費する。
- /dev/xvda内にパーティション( / とswap)を切ってインストールする方法と
- /dev/xvdaを/(root)に、/dev/xvdbをswapにする方法の両方を試してみた。
- 両者ともdom-0上では実パーティションではなくて単なる4Gのファイルだ。
- 後者のインストールでは、/dev/sdaにgrubをインストールしても起動してくれない。
- 後者のインストールでは、grubのインストールポイントは/dev/xvda1 を指定しないといけないようだ。(インストールの最終過程あたりにCUIで指定する)
- pvm(準仮想化vm)をhvm(完全仮想化vm)に変更したり、その逆をやる技が分からない。
- xm-ubuntu.cfgのようなファイルを手で書き換えたりしてみるけれど難しい。なかなか思うようにうごいてくれない。
- 実働しているVineLinuxのようなLinuxの/dev/sda1をddで吸い出して、Xen上で動かそうとしてみたけれど、これもうまくいっていない。(hvmでは、vmが見つからないといわれるし、pvmではカーネルが対応していないといわれる。)
- とりあえず習得したのはubuntu(11.10)上のdom-0で別のubuntu(11.10)32bit/64bitを飼うこと。
Linusさんも言うように、仮想化でサーバーを多重化するのはあまり美しくないやりかたなのかもしれない。単一のカーネルが複数のユーザーランド(とOSコンテキスト)を完全に環境分離して動かせるのであれば、仮想化する必要なんて最初から無いからだ。(懐古OSを動かす用途以外ではね)
UM232H
秋月電子
- http://akizukidenshi.com/catalog/g/gM-05273/
- 1680円
- Single ChannelだけどHigh-Speed(480Mbps)、MPSSEあり。
- UARTモードで12Mbpsまで出せるらしい。
- FT2232Dのほうは2channelだけどFullSpeed(12Mbps)1450円。
今ごろになって消化中の2010年版SH2A基板
- gccビルドしたUSB-CDCの安定化に成功。
- ブートローダーとして使えるようになりました。
- FPUはやはり使えない。gccではどうしようもないのか?
- 内蔵RAMだけ、無駄に1MBもある。
- 動作クロックも、無駄に144MHzもある。
なんに使おうか。
米、昨夏に未臨界補完の核実験
- 核実験といっても爆発させたのではなくて強力なX線を当てて反応を調べるらしい。
日本だって負けてないぞ。
- http://nikkan-spa.jp/106058
- というか実験ではなくて過酷事故だけど。
- え、肝心のデータ取ってないの?じゃあ、意味無いじゃん>日本。
もっと頑張ろう日本。
2010年版SH2A基板。まだやってるよ。
- FPUが使えないのはcygwin版gccの問題かもしれないと思って、KPITのGNUSHに乗り換え。
- PATHが通らない。ディレクトリ名に"KPIT Commuins"とか空白が入っていて駄目だ。
- 空白を'_'にリネームして凌ぐ。
- Makefileの-I/usr/local/sh-tools/include とかを取り除く。(そうしないとエラー)
- crt1.oが参照している _edata とか _stack とかのラベルを吐くように ldscriptを書き換え。
- makeしてみる。
sh-elf-gcc (GCC) 4.5-GNUSH_v11.02 Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Linking: SH2A-1C000000.elf Errors: none -------- end -------- -------- begin (mode: ROM_RUN) -------- d:/kpit/hew/tools/kpit_cummins/gnush-elf/v11.02/sh-elf/bin/../lib/gcc/sh -elf/4.5-GNUSH_v11.02/../../../../sh-elf/bin/ld.exe: final link failed: Section has no contents collect2: ld returned 1 exit status make: *** [SH2A-1C000000.elf] Error 1
リンクできない。同じgccなのに!--- ldscriptをKPITのものに差し替えて、またごにょごにょしたらとりあえず動いた。しかし、リンクできないし、io_cwb()とかいう暗黙の関数が抜かれていて困る。
- 動いたし、USB-CDCとしても使用できた。
- しかし、FPUを有効にして浮動小数命令を使うとハングする。
- デバッガがないので、どういうハングなのか分からない。困った
原因が判明
- 犯人はFPSCR
- FPSCRの値は、リセット初期値(単精度)=0x40001、倍精度演算/転送=0x1c0001に設定される。(FPU例外を使うときはさらにbitを立てる)
- FPSCRの値が倍精度に設定された時点で割り込みが発生すると、
fmov fr0,@-r15 fmov fr1,@-r15 fmov fr2,@-r15 ・・・
- のようなレジスタ退避コードが実行できない。(倍精度時は偶数frレジスタしか使えないからだ)
- 上記の退避コードの直前にFPSCRを単精度モードに戻しておかないといけない。
- 対策をしたら、浮動小数演算を行なってもハングしなくなった。
- しかし、printf("%g",3.14);のようなことをすると、結果は決まって"nan"になる。
- m2a-nofpuでコンパイルしたものは正常にprintされる。
- バイナリーダンプする限りではFPUは正常に動いているように見える。
コンパイラをKPITに変えてやってみた。
- コンパイルオプション -m2a-single-only を与えたときだけ、printfも正常に行なわれる。
- おそらく倍精度はsoft-floatになるからうまくいっているのだろう。
- それ以外では、printf結果はおかしい数値になった。(nanではないが、でたらめな数値)
- もしかしたら、mathライブラリの初期化関数を明示的に呼ばないとだめなのか?ううむ。
- Cygwin版gccで-m2a-single-only を与えるとリンク時エラーで実行ファイルが作れない。
ここまでのまとめ
使用コンパイラ | コンパイルオプション | 浮動小数点演算動作 | 説明 |
Cygwin版 sh-elf-gcc | -m2a-nofpu | 正常 | FPUを全く使わないので遅い |
Cygwin版 sh-elf-gcc | -m2a / -m2a-single | 演算のみたぶん正常 | printf("%g",x)が常にnanをprintする |
Cygwin版 sh-elf-gcc | -m2a-single-only | 評価不能 | リンク時エラー。未定義関数多数 |
KPIT版 sh-elf-gcc | -m2a-single-only | 正常 | 倍精度演算はFPUを使用しない |
KPIT版 sh-elf-gcc | -m2a-single-only 以外 | 演算のみなら正常かも | printf("%g",x)が常にでたらめ |
さてどうしよう。
- KPITでもだめだめだったので、Cygwin版でprintがうまくいかない理由でも調べてみようか。
調べてみた。
- どうやら、-m2a とか -m2a-single オプションを付けても、リンクするライブラリは SHデフォルト のものがリンクされていた。
- isnan(double num)という関数の引数がfr4レジスタで渡されるのに、isnanの実装は整数レジスタで受け取っていたらしい。
- そこで、-Lオプションで指定するディレクトリに /m2a とか /m2a-single を付け足してやればうまくいくかというと・・・
- -m2aのときは、デフォルトが倍精度、すなわち、FPSCRの値が0x1c0001になっていると仮定したライブラリがリンクされている。
- -m2a-singleのときは、デフォルトが単精度、すなわち、FPSCRの値が0x40001になっていると仮定したライブラリがリンクされている。
- なので、コンパイルオプションを変えたときは、crt0の初期化モジュールのどこかで、FPSCRの初期化が必要だ。
- (リセット時は常に0x40001になる)
- そうするとうまくいくかと思いきや、printでハングするのだな。なんとかしてくれ。
さらに挑戦!
- KPIT版gccを使って、KPIT版crt0.oでやっている初期化と同じようなことを( _init() や ___set_fpscr() 呼び出し実行により)行なうようにした。
- KPIT版では、自前の __fpscr_vaules[] の初期化やfpscrの初期化を行なわないようにした。
そうすると、-m2aオプション使用にて、FPUが正常に使用でき、printfも使えるようになった
- read more :SH2A
- KPIT版では、__fpscr_vaules[]の値は、0x40000,0xc0000 になっている。
- Cygwinで同様にしても正常に動かないのでCygwin版でのFPU使用は諦めた。
互換機:激安マザーを買った。
某所で。
- お年玉セールのようなもので、CPUとマザーのセットが¥5980で売ってあったので捕獲。
- CPUはCeleron G530 (2.4GHz 2core SandyBridge)、マザーはBIOSTARのH61マザー。一応GigaLAN+HDMIありだ。
- セレG530の最安価格は3400円程度なので、なんとH61マザーは2600円だ。嘘だろ?いくらチップセット機能がCPUに内蔵されたからって、こんなに安くていいのか。
- 円高のせいもあるけど、GPU内蔵のCPUが、昔のCPUクーラー(だけ)と同じような価格で売られていて、比較的最新のマザーボードが生基板と同じくらいの価格で売られているのは違和感を覚えた。
- 実際のところ、レシート見たら1500円引きとなっていたので、通常価格だと4100円だ。それなら納得はいく。
- メモリー8Gと合わせて買ったけど、1万円からおつりが来た。
- いまだにHDDだけは、入手難が続いているようだ。というよりは、このままHDD終了なのか。
- SSDが速いのは結構なことだけど、1TBとか2TBになってくるととても高すぎて買えない。
Lenovoが世界初のIA+Androidスマートフォンを発売
世界で初めてIA(Intel Architecture)に基づいたAndroidスマートフォン「K800」を中国で販売開始することを明らかにした。
- ARMではないAtomがまさかのスマホに使えるようになったとはねー。
- OSがAndroidで、kernelはLinux。アーキテクチャーがia32と来れば、
- wine入れたらWin32も動くんじゃない。
で、なんで中国?中国人ってintel入ってると買うのか?
ARM: STREX{B|H|} Rd, Rt, [Rn] って、何の命令なの?
STore Register EXclusive | 排他的なメモリー書き込み
- 教えて!Google先生
- つ これだ ・・・
STREX は、メモリへの条件付きストアを実行します。 条件を以下に示します。
物理アドレスに共有 TLB 属性が設定されておらず、実行中のプロセッサによってまだアクセスされていないタグ付きの物理アドレスが存在する場合は、この命令によるストアが実行され、タグがクリアされて、Rd に 0 が戻ります。
物理アドレスに共有 TLB 属性が設定されておらず、実行中のプロセッサによってアクセスされていないタグ付きの物理アドレスが存在しない場合は、ストアは発生せず、Rd に 1 が戻ります。
物理アドレスに共有 TLB 属性が設定されており、その物理アドレスに実行中のプロセッサによる排他的アクセスのタグが付けられている場合は、ストアが発生してタグがクリアされ、Rd に 0 が戻ります。
物理アドレスに共有 TLB 属性が設定されており、その物理アドレスに実行中のプロセッサによる排他的アクセスのタグが付けられていない場合は、ストアは発生せず、Rd に 1 が戻ります。
- TLB(Translation Lookaside Buffer) はもっとも最近使われた PTE(Page Table Entry:論理->物理アドレスへの変換を記憶する表) を保存するための(CPU内部にある小さな)キャッシュ。
- 要はセマフォみたいなやつで、排他的に書き込めたときは結果が0、失敗したら1。
- そもそもCortex-M3には仮想記憶も、複数プロセッサ間のメモリー共有も無いので、共有TLBなんかない。
- やってみたらどうなるんだろう・・・?。
Linux: Text Editor jed の64bit版
- 自分はemacs嫌い派、viも嫌い派で micro-emacs系のエディタ(ngとかjed)を好んで使っている。
- VineLinux 4.2の頃のjedを少しカスタマイズしてVz風味にして使っている。
- OSの流行がubuntuになり、64bitになった今でも、VineLinuxのjedとlibslang.so.1 (全部32bit版)を後生大事にコピーしてきて使っている。(32bitエミュレーション)
- しかし、Xen-hypervisor上の64bit-linuxで動かそうとすると、ia32-libsを入れなければならなくなって
- そのfoot printが馬鹿にならないため、重い腰を上げて64bit版のjed-jaを作ることにした。
- ていうか、vi使えない>俺
ここにある、arm版の tar-ballをubuntu-64上に展開し、
$ cd slang-1.4.9 $ make distclean $ ./configure $ make $ sudo make install $ make elf $ sudo make install-elf
とやる。
- インストール先は /usr/local/libになる。ロード出来ないシステムでは /usr/libに適宜コピー。
次
$ cd .. $ cd jed-B0.99-14 $ make distclean $ ./configure $ make
で、出来たsrc/objs/jed を好きな実行ファイル名にリネームして /usr/bin か、自分ローカルの ~/bin/ にコピーすると使える。
- ちなみに、このjed-jaパッケージは EUCとS-JISのサポートはあるが、UTF-8が使えない。
- UTF-8を使う場合は、ubuntu標準のjedを使うと良い。(逆にubuntuのjedにはEUCとS-JISのサポートがない)
- ARM用にconfigure済みのtar-ballなので、make distcleanしてからconfigureするのがコツ。
- 先に
# apt-get install build-essential
とか# apt-get install autoconf
とかも入れといたほうがよい。