MZK-WD300DHってもしかしてMiracastになるんだろうか?

PLANEX Directからメールが来た。

「残り僅か!ワンセグチューナー、Wi-Fiディスプレイシステム最終価格で販売中!」だそうな

Wi-Fiディスプレイシステムって、どんなんだろ?と見てみると、MZK-WD300DHというものだった。

ぶっちゃけ、あまし評判はよくないようだ。

ただ、なんかうたい文句的にはいまで言うMiracastっぽいけど、別のモノ、ということにはなっている。

PLANEXページからドライバをダウンロードしてみた。
3種類のドライバと、関連ソフトの詰め合わせだった。

「92_DU_Driver」は、Realtek RTL8192D USBドライバ(rtl8192du.sys)でバージョンは「1002.1.816.2011」(日付:2011/11/21 0:00)

「WiDi_Driver」は2種類。
「RTKVideo」PLANEX Wifi Display VGA Adapter(RtlvVga.sys)でバージョン「1005.2.622.2011」(日付:2011/11/21 0:00)
「RTKAudio」PLANEX Wifi Display Audio Adapter(RtlvSound.sys)でバージョン「1005.1.526.2011」(日付:2011/11/21 0:00)
どちらもinfファイル内には「Realtek Semiconductor Corporation」の文字。

この情報を持って、チップメーカであるRealTekのページを探すと、以下がでてきた。

RTL8192DU-VC
Single-Chip IEEE 802.11a/b/g/n 2T2R WLAN Controller with USB 2.0 Interface
(PCI Express対応だとRTL8192DE-VCになる)

そして、プレスリリース系として、以下が・・・

2012年9月19日:「Realtek Selected for the Wi-Fi CERTIFIED Miracast™ Test Bed
 Miracastのテスト環境にRealtekが選ばれました! RTL8192DE, RTD1185,RTL8192DUです!

2013年1月7日:「Realtek to Demonstrate Full Range of Connectivity and Multimedia Solutions during 2013 CES
 RealShare Smart Display(RTD1185 Digital Media Processor とRTL8192DU Wi-Fi moduleの組み合わせ)

もしかして!?と一瞬期待をしてみる。

RTL8192DU関連のソフトウェアは、RTL8192DU-VC用としていくつか提供されていた。
こちらの中身は、普通に無線LAN用ドライバだった。

よくよく確認してみれば「RTL8192DU」自体は、普通のWiFiアダプタとして使っている普通のチップでもあった。
ただ、Miracastで使えるだけの能力を持っている、というだけだった。

つまりは、「WiDi_Driver」の方が本命。

で・・・「WiDi_Driver」に相当するものをRealTekページで探してみたけど見付からない。

いろいろ探していると
Dishing Tech:「Realtek Wi-Fi Direct Programming Guide」という記事が見付かった。

「Wireless_tools_porting_guide.pdf」という資料を元に解説をしている。
入手元を調べたところ、RealtekのドライバページにあるUnix(Linux)用のファイルに含まれていた。
v4.0.0_4074.20120518からWiDiのサポートが入ったらしい。

この資料の中に、AndroidでWiFi Directに対応させるためのコードとかも含まれているようだ。

なので、もしかしたら、送信側はRTL8192DUを使っていれさえすれば対応できるかもしれない。

しかし、受信側は、改造できなさそうなので、対応は難しいような気がする・・・

えぇ・・・気がする、というところ。
もしかすると動くのかもしれませんが・・・
ダレカ、チャレンジしていませんか?

DOSブートディスクをWindows64bit環境で作成する

BIOSアップデートがDOSプログラムしかないサーバ用マザーボードで、BIOSアップデートを実施する必要が出た。
そんなわけで、DOSブート環境が必要になったわけだが、USB FDDを使うのではなく、USBメモリを使用したい、ということで調査した。

しばらく前の定番。
hpのUSB-keyメモリからのブート作成ツール
HP Drive Key Boot Utility
  cp006049.exe (45 MB) v7.41.3790.0 (8 Nov 2005)
USB-keyメモリからのシステムブートに関して
  cp004916.exe (28 MB) v7.10.3790.0

こいつをVista 64bit環境で実行したら、管理者権限+互換モードを必要とする、というのはまだいいのだが、
「フォーマット中、プログラムから応答がなくなる」
とか
「フォーマット後、ファイルが見付からない、というエラー出力」
とか
「作成できたもので結局のところブートできない」
とか発生した。
(なお、実行ファイルが日本語ディレクトリとか長いとかかな、と短い場所に置いても同現象)

代替を探したところ「RMPreUSB」がうまいこと動作した。

これの利点
・Portableエディションという、インストール不要バージョンもある
・USBメモリの認識のさせ方を3種類(FDD認識/ZIPドライブ認識/HDD認識)から選ぶことができる
・Free DOSが同梱されていてライセンスを気にしないでDOSブートできる
・DOSブート以外も作成できる

1. RMPreUSBを起動すると以下のような画面が現れる。
001

2. 以下のように、USBメモリが表示されていることを確認する。
005
ここで選択されているUSBメモリの内容が全て削除、フォーマットされ、DOSブートメモリとなります。

3. 「3 Bootloader Options」にて「FREEDOS bootable」を選択します。
002

4. 「4 Filesystem and Overrides」は「FAT16」「Boot as HDD」でひとまずやってみてください。
003
うまくブートしなかった場合は「Boot as FDD」とか「Boot as ZIP」を試してみてください。

5. 「6 Prepare Drive」をクリックするとフォーマット開始です。
004

使わなかったボタンがいろいろありますが、Free DOSのブートディスクを作るくらいであれば、これだけで問題ありませんでした。

ECCエラー多発してるエラーが取れたのでメモ

CentOS6サーバに、2GBメモリが2枚刺さってる。
久々に起動したら、ECC関連のエラーメッセージを吐きまくってるのでメモ書き。

Feb  8 16:42:15 cent6server kernel: EDAC MC0: CE page 0x1e23, offset 0x980, grain 128, syndrome 0x64, row 0, channel 1, label "": i3000 CE
Feb  8 16:42:16 cent6server kernel: EDAC MC0: CE page 0x1e23, offset 0x980, grain 128, syndrome 0x64, row 0, channel 1, label "": i3000 CE
Feb  8 16:42:17 cent6server kernel: EDAC MC0: CE page 0x1e23, offset 0x980, grain 128, syndrome 0x64, row 0, channel 1, label "": i3000 CE
Feb  8 16:42:18 cent6server kernel: EDAC MC0: CE page 0x1e23, offset 0x980, grain 128, syndrome 0x64, row 0, channel 1, label "": i3000 CE
Feb  8 16:42:19 cent6server kernel: EDAC MC0: CE page 0x1e23, offset 0x980, grain 128, syndrome 0x64, row 0, channel 1, label "": i3000 CE
Feb  8 16:42:20 cent6server kernel: EDAC MC0: CE page 0x1e23, offset 0x980, grain 128, syndrome 0x64, row 0, channel 1, label "": i3000 CE
Feb  8 16:42:21 cent6server kernel: EDAC MC0: CE page 0x1e23, offset 0x980, grain 128, syndrome 0x64, row 0, channel 1, label "": i3000 CE
Feb  8 16:42:22 cent6server kernel: EDAC MC0: CE page 0x1e23, offset 0x980, grain 128, syndrome 0x64, row 0, channel 1, label "": i3000 CE
Feb  8 16:42:23 cent6server kernel: EDAC MC0: CE page 0xfb802, offset 0x200, grain 128, syndrome 0x64, row 1, channel 1, label "": i3000 CE
Feb  8 16:42:24 cent6server kernel: EDAC MC0: CE page 0xfab1b, offset 0xa00, grain 128, syndrome 0x64, row 1, channel 1, label "": i3000 CE
Feb  8 16:42:25 cent6server kernel: EDAC MC0: CE page 0xfb8ac, offset 0x780, grain 128, syndrome 0x64, row 1, channel 1, label "": i3000 CE

ちなみに、読み込まれているドライバは以下でした。

# lsmod|grep edac
i3000_edac              3471  0
edac_core              46581  3 i3000_edac
#

ちなみに「rmmod edac」を実行すると、エラーログを出力させなくすることもできます。
(もちろん、エラーがなくなるわけではない)

Proxmox上のOpenVZ仮想マシンをCLIでlive motion

Proxmox 2.xでは、共有ディスク無しでのホストサーバ移行(Live Motion/vMotion)みたいなことができる。
Web GUIでの方法はわかったが、CLIでのやり方についてのドキュメントが見つけにくく難航した。

使用するコマンド「pvectl」

ただし、このコマンドは、自サーバ上のみのコントロールを担当する。

「pvectl list」で、サーバ上にある仮想マシンリストを表示

root@pve1:~# pvectl list
Use of uninitialized value in printf at /usr/bin/pvectl line 46.
      VMID NAME                 STATUS     MEM(MB)    DISK(GB)
       101 server1.osakana.net  running    1024       8.00
       102 server2.osakana.net  running    1280       30.00
#

他にもサーバがある場合は以下の様な形で他サーバに対してssh経由でコマンドを発行して状態を取得する。

root@pve1:~# ssh root@pve2 pvectl list
Use of uninitialized value in printf at /usr/bin/pvectl line 46.
      VMID NAME                 STATUS     MEM(MB)    DISK(GB)
       103 server3.osakana.net  stopped    1024       10.00
       104 server4.osakana.net  stopped    1024       8.00
# 

移動させる時は「pvectl migrate VMID サーバ名 -online」

root@ns5:~# pvectl migrate 101 pve2 -online
Jan 31 15:56:51 starting migration of CT 101 to node 'pve2' (192.168.1.102)
Jan 31 15:56:51 container is running - using online migration
Jan 31 15:56:51 starting rsync phase 1
Jan 31 15:56:51 # /usr/bin/rsync -aHAX --delete --numeric-ids --sparse /var/lib/vz/private/101 root@192.168.1.102:/var/lib/vz/private
Jan 31 15:57:31 start live migration - suspending container
Jan 31 15:57:31 dump container state
Jan 31 15:57:32 copy dump file to target node
Jan 31 15:57:32 starting rsync (2nd pass)
Jan 31 15:57:32 # /usr/bin/rsync -aHAX --delete --numeric-ids /var/lib/vz/private/101 root@192.168.1.102:/var/lib/vz/private
Jan 31 15:57:35 dump 2nd level quota
Jan 31 15:57:35 copy 2nd level quota to target node
Jan 31 15:57:36 initialize container on remote node 'pve2'
Jan 31 15:57:36 initializing remote quota
Jan 31 15:57:37 turn on remote quota
Jan 31 15:57:38 load 2nd level quota
Jan 31 15:57:38 starting container on remote node 'pve2'
Jan 31 15:57:38 restore container state
Jan 31 15:57:39 removing container files on local node
Jan 31 15:57:40 start final cleanup
Jan 31 15:57:40 migration finished successfuly (duration 00:00:49)
root@pve1:~ #

で、うちの環境だと、CPUがpve1はIntel, pve2がAMDなので、移行後の起動に失敗する。
なので、別途、起動させる必要がある。

root@pve1:~# ssh root@pve2 pvectl start 101
Starting container ...
Container is mounted
Adding IP address(es): 192.168.1.201
Setting CPU units: 1000
Setting CPUs: 1
Container start in progress...
root@pve1:~#

これで、以下のような感じで移行が完了する。

root@pve1:~# pvectl list
Use of uninitialized value in printf at /usr/bin/pvectl line 46.
      VMID NAME                 STATUS     MEM(MB)    DISK(GB)
       102 server2.osakana.net  running    1280       30.00
root@pve1:~# ssh root@pve2 pvectl list
Use of uninitialized value in printf at /usr/bin/pvectl line 46.
      VMID NAME                 STATUS     MEM(MB)    DISK(GB)
       101 server1.osakana.net  running    1024       8.00
       103 server3.osakana.net  stopped    1024       10.00
       104 server4.osakana.net  stopped    1024       8.00
# 

さて、この処理を自動化すると・・・

#!/usr/bin/bash

SERVER=pve2
for vid in `pvectl list 2>&1 |grep running | awk '{ print $1 }'`
do
  echo === $vid ===
  echo pvectl migrate $vid $SERVER -online
  pvectl migrate $vid $SERVER -online
  ssh root@$SERVER pvectl list 2>&1 |grep  stop | grep $vid
  echo ssh root@$SERVER pvectl start $vid
  ssh root@$SERVER pvectl start $vid
done

ほんとは、移行後に起動しているか確認した上で、pvectl startを実行させるべきなんだろうけど、起動状態でpvectl startを実行しても影響がないので、無視している。

Firefox OSをビルド中

Firefox OSの開発機「Otoro」「Unagi」ってのは、どうもあまりスペックが高くない端末らしい、という話は把握していたものの、実体がよく分からないなぁ、と放置していました。

で、このたび、「Announcing the Firefox OS Developer Preview Phone!」ということで、Geekphone取り扱いで「Keon」と「Peak」の2機種が入手可能になるということがアナウンスされた。

外見とかスペック(Snapdragon S1 1GHz, HVGA, RAM 512MB)とかを考えると、ZTE V788D(MSM7225A)や、Xperia E(MSM7227A)あたりが該当しそうだなぁ、と

そして、先日手に入れたK-Touch W619も同じQualcommのMSM7225A系統。
もしかしたら動くかなぁ?とビルドしてみることにしました。

とりあえず、ソースファイル群を取得し、確認したところ、otoroとunagiの構成に関するファイルは、「B2G/device/qcom/」ディレクトリにありました。
CPUはどちらもMSM7627A、と予想よりはちょっとだけ上でした。
無線LANはunagiは、NL80211とath6kl_sdio(SDIO接続)
otoroは、ar6000という違いがありそうな感じ。
まぁ、見方が間違っているような気もしますけど・・・

とりあえず、otoro想定で、buildを開始してみてます。

まだ、Build途中ですが、すでにはまった点があるので公開しておきます。

・Ubuntu 12.10にしてたらはまった。
すでにUbuntu 12.10 32bit環境があったので、そこに構築したらビルドが早々にエラーになった。
公式の「Firefox OS ビルドの必要条件」にあるように「デフォルトホストコンパイラの変更方法」をおこなう必要があったようだ。
まぁ、64bit環境にかえた方がよさそう、というのもあったので、Ubuntu 12.04 64bit環境で作り直しました。

Firefox OS側の手順Android側の手順とでパッケージ選択に差異がある
同じAndroid開発環境をベースとしているわりに、差異があった。
とりあえず、両方に書かれているパッケージ選択をそのままやっておいた。

また、javaについては「openjdk-6-jdk」を選択しておいた。

・build.sh実行時に「-j2」を指定したら失敗した
オプションなしで実行したら進んだ。

・割り当てメモリが少ないと失敗しやすい?

make[7]: *** [TabChild.o] エラー 1
make[7]: *** 未完了のジョブを待っています....
arm-linux-androideabi-g++: Internal error: Killed (program cc1plus)
Please submit a full bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

In the directory  /work/firefox/B2G/objdir-gecko/dom/ipc
The following command failed to execute properly:

こんな感じのエラーがでます。
公式の「Boot to Gecko のビルド」に空きメモリがないから、と書いてあります。

まぁ、仮想マシンで1.2GBの割り当てで構成しているからですね。
もう1回、build.shを実行すると先に進む程度の失敗のようです。

そんなわけで、終わるのにはまだまだ時間がかかりそうです。