2011年1月29日土曜日

XPにAHCIドライバをインストールする

いまさらながら、基本的にAHCIに対応していないXPにAHCIドライバを入れてNCQを有効にした状態で動作させる、というネタです。
普通にクリーンインストールをするときにAHCIドライブを認識させる、というだけのことならF6インストールをすればいいわけで、WEBで簡単に情報を見つけることができる。今回のポイントは、既にインストールされたXPにクリーンインストールも修復インストールも行わずにAHCIドライバを導入する、という点にある。

しかし、これもまた同様にWEBにはいくつかの情報が転がっていて2chなんかでも議論されているけれど、今回少し違うのはIDEドライバ→AHCIドライバへの変更ではなく、RAIDドライバ→AHCIドライバへの変更を行うという点で、この点ではWEBでは情報は見つからなかったので、今回やった方法をちょっとリークする。ちなみにターゲットとなるチップセットはICH7Rですが、分かる人なら適宜読み替えてICH8やICH9でも応用できるはず。

本題からそれるけれど、そもそも「なぜRAIDドライバをAHCIドライバに変えたいのか?」というと、「IntelのSSD X25-M用のToolboxがSSDを認識しないのはRAID BIOSが噛んでいるからだろう」という推測のもと、「SSDがあればRAID-0の御利益はほとんどないし、AHCIに戻そう」と思ったのが始まりです。

さて、やり方のおおまかな流れとしては、下記のようにやります。ただし、極めてクレイジーなやり方なので、よほどの自信と覚悟がない人にはオススメできない方法です。もし、果敢に(無謀にも?)トライしてみようと思う方は、あくまでも自己責任でお願いします。

  1. 現在RAIDドライバで起動しているシステムに、AHCIドライバを仮インストールする(詳細は後述)。
  2. BIOS設定をAHCIに変更して(RAID BIOSを切って)、再起動する。
  3. 1でうまくインストールできていれば、AHCIでWindowsが起動できると思う。しかし、デバイスマネージャはエラー(サービスの表示名かエントリが既に使われている、と何とか・・・)を出す。が、動いておればまずはOK。
  4. デバイスマネージャでRAIDドライバがもう読み込まれていないことを確認する。その後、レジストリエディタでRAIDドライバ関連のエントリを全部消す。
  5. 1でインストールしたAHCIドライバは仮ドライバなので、本AHCIドライバを入れ直す(実際にはレジストリエントリの書き換え)
  6. 再起動して、デバイスマネージャがエラーを報告しなければOK。
  7. (必要であれば)最新のIntel Rapid Technology Driverをインストールします。


で、具体的な方法は次のようになります。

  1. 現在RAIDドライバで起動しているシステムに、AHCIドライバを仮インストールする。

    IBMが出している資料が非常に参考になりました。要点は、PnPマネージャによるインストールではなく、ドライバサービスエントリとPnPエントリを手動で追加することでドライバをインストールする、という方法です。
    (1)
    Intelのサイトからマトリックスマネージャをダウンロードしてsetupを実行します。インストールの途中でc:\Windows\temp\iifというフォルダが作成されていますので、この中にあるAHCIドライバ本体とinf/catファイルを別ディレクトリにコピーしておきます(x86とx64用があります)。コピーしたらインストーラは中止します。
    (2)
    コピーしたドライバファイルiaStor.sysをiaStor2.sysにリネームして、c:\windows\system32\drivers\フォルダに置きます(iaStor.sysはRAID用ドライバとして既に居座っているので、これを置き換えることはできない)。
    (3)
    次のレジストリエントリを追加する(.regファイルなどに保存して「結合」する)。
    ここでの注意点は、ここにあるデバイスIDはICH7R用のものである(下のリストの'dev_27c1'となっている部分全部)から、お使いのPCにあわせて適宜変更する必要があるということです。サービスエントリが'iaStor'ではなく、'iaStor2'に変更していることもポイント。

    ~ここから~
    Windows Registry Editor Version 5.00

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CriticalDeviceDatabase\pci#ven_8086&dev_27c1&cc_0106]
    "Service"="iaStor2"
    "ClassGUID"="{4D36E96A-E325-11CE-BFC1-08002BE10318}"

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\iaStor2]
    "Type"=dword:00000001
    "Start"=dword:00000000
    "Group"="SCSI miniport"
    "ErrorControl"=dword:00000001
    "DisplayName"="Intel AHCI Controller"
    "ImagePath"="system32\\drivers\\iaStor2.sys"
    "Tag"=dword:00000019

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\iaStor2\Parameters]
    "queuePriorityEnable"=dword:00000000

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\iaStor2\Enum]
    "0"="PCI\\VEN_8086&DEV_27C1&SUBSYS_03451014&REV_01\\3&61aaa01&0&FA"
    "Count"=dword:00000001
    "NextInstance"=dword:00000001

    ~ここまで~
  2. (特に説明なし)
  3. (特に説明なし)
  4. の「その後、レジストリエディタでRAIDドライバ関連のエントリを全部消す。」については、ICH7Rの場合はデバイスIDが'DEV_27c3'となっていたので、これに関連するレジストリエントリはすべて消しました。
  5. 1でインストールしたAHCIドライバは仮ドライバなので、本AHCIドライバを入れ直す。

    これについては、まずドライバ本体を先ほどインストールしたiaStor2.sysからiaStor.sysにリネームします(この段階ではRAID用のiaStor.sysはもう使用されていないので削除できるはず)。
    そして、上の.regファイルで追加したレジストリエントリの'iaStor2'となっている箇所を、'iaStor'にリネームします。具体的には、レジストリエントリ
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\iaStor2→iaStorとするのと、
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CriticalDeviceDatabase\pci#ven_8086&dev_27c1&cc_0106キーにある値"Service""iaStor"に、
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\iaStorキーの"ImagePath""system32\\drivers\\iaStor.sys" と書き換える。

ポイントとしては以上ですが、(言うまでもありませんが)このような極めてクレイジーな操作が一発でうまくいくとも限らないので、私はTrue Imageでバックアップしてから行いました(ええ、一度はリカバリする羽目になりましたよ)。


....


で、なんとかAHCIに切り替えることはできたわけだけれど、当初の目的であった「SSD Toolboxを使えるように」という目標は叶わなかった。結局、ドライバを変えてもToolboxはSSDを認識してくれずドライブ一覧は空白のまま・・・。なんで?

2011年1月25日火曜日

上棟打ち合わせ

先週末は、上棟打ち合わせだった。

なんか変な気分。自分が家を建てているという事実、そして実際に家が建ってきているという事実が。


上棟打ち合わせの前は・・・

これまでも何回も打ち合わせを重ねてきていたし、もうン千万も支払ってきたというのに、なんとなく実感がなかった。そして、常に「これでいいんだろうか?」という自問自答が繰り返し頭の中を駆けめぐっていた。
地縄確認のときなんかは、実際に土地の上に建物の場所を示す縄が張られていたのを見て、「こんなに狭いのか?」と感じてしまい、「こんなはずではない。。。」「これは現実ではない・・・」とかちょっと現実逃避をしていたのかもしれない。

実際に建った家に入って見たときの第一印象は「やっぱりちょっと狭い?・・・かな」と思ったと同時に、これまでの打ち合わせで何度も何度もイメージしたとおりの間取りだったのであまり違和感というか始めてきた場所のような感じは覚えず、「やはりこれは現実なのか!」と今更ながらに実感するところもアリで、これまた不思議な感覚。

それでも、上棟打ち合わせが終わる頃には、「広さも、まあこんなものかー」と思うくらいになっており、「現物を見たらガックリするかも?」という不安を杞憂に終わったように思う。

とりあえずは、「完成が楽しみになった」という気持ちで終わったという点では、これまでの数々の選択はそんなに間違っていなかったのかな、と思う。

2011年1月24日月曜日

Pavilion Desktop PC HPE-360jp/CT販売終了

現時点で6コアCPU搭載でこの価格はかなりお買い得なのでは?と思って注目していたHPのPavilion Desktop PC HPE-360jp/CT 価格.com限定モデルが急に販売終了となってしまったようだ。


主なスペック
Phenom II X6 1045T(2.7GHz)
DDR3 PC3-10600 4GByte
HDD 500GByte(7200rpm)
光学ドライブ DVD±R/±RW/RAM/±RDL
IEEE1394+光デジタル出力
Windows7 Home Premium


これで\45,150-だった。
まあ特に買う理由は見あたらないしそもそもそんな予算はないのだけれど、お買い得なだけに買えなくなった悔しさがにじみ出るのは何故だろう?


敢えて買う理由をこじつけるなら、職場のメインPCは未だにPen4 3.4Gzという3世代?4世代前くらいのもので、もう5年以上毎日8時間以上使っているので元は取れたので、そろそろ買い換えてもいい時期かと。
景気のいいときなら会社に談判すればサクッと買ってもらえるのだけれど(いや、実際『買ってもいいよ』というお墨付きはもらっているのだけれど)、このご時世ですから無駄遣いせずに自制モードです。

2011年1月22日土曜日

RAID用に使っていたHDDを別のPCにつなぐと。。。

あるPCで3台のHDDを使ってRAID-0を組んで使っていた。1台160GBだったので3台で480GBだった(実容量は447BGくらいだったけど)

このHDDのうち2台で再度RAID-0を構築し直して、残りの1台はRAIDではなく単独で使うことにした。
USB-SATA変換で接続しているときは問題なく160GBのHDD1台と認識していたのに、RAIDを組んでいたPCとはまったく別のWindows7をインストールしたデスクトップPCの内部SATAポートに直結すると、HDD単独の160GBの容量ではなく、RAID構築時の447GBのドライブとして見えている。何故だろう?RAID構築時の情報がHDDのどこかに残っていてそれを誤認しているのだろうか?

このHDD、困ったことにフォーマットどころか、パーティションの作成・解放はおろか、MBR/GPT初期化すら行えないという、非常に困ったことになってしまった。
まずBIOSの設定としてRAIDではなくAHCIを選んでいるので、HDDがRAIDボリュームとして見えることは無いはずだと思う。あとは、IntelのRapid Storage Technologyドライバを入れているので、そのせいでRAIDに関する情報を誤認している可能性があるかも。そうだとしたら何とかしてその情報を消さねばならない。しかし、いまはどのようにアクセスしてもエラーになるので消すための操作すらままならないな。

と思ったら、True Image 2009の起動ディスクで起動すると今度はちゃんと160GBのディスクとして認識した(HDDが物理的・電気的に壊れている訳ではなさそうだ)。やはりWindows(かIntel RSTドライバ)が余計な気を利かせているのだろう。TI2009のcleanse diskで本当にまっさらに戻せば直るのか?と思ってcleanseを始めて見たもののものすごく時間がかかるみたいなので、HDDの先頭部分のみcleanseして(後でdiskをダンプするとMBRとその後ろの部分がキレイさっぱり00hに消えていた!)再度Windows7を起動するとやはり447GBの不明なボリュームとして認識されて、エラーが発生した。
RAIDの識別情報ってHDDの後ろの方にあるのかな~。知っている人がいましたら、教えてください>誰ぞ。


(2011/1/25追記)

解決した。

結局は、RAID BIOSの設定画面からRAIDのメンバ登録を抹消しなければいけないみたいです。
基本中の基本的なことで躓いていたわけですが、今回は

○RAIDを組んでいたPCとは別のPCにつないで再利用としていたこと
○そのPC間ではチップセットが異なること(旧PCは945で新PCは965)
○その新しいPCではRAID BIOSを切っていたこと

などから、まったく新しいHDDと認識されると思っていたのですが・・・。やはり、HDD上のどこかにRAIDのメンバであることを識別する「何か」が書き込まれていて、Windowsさんはそれを(勝手に)探すのですかもね。
後日インテル系チップセットでのRAIDメンバ認識に仕組みについて調べてみることにしよう。

2011年1月14日金曜日

出会いは突然に・・・

出会いはいつも突然にやってくるものです。
いつもすれ違いばかりで出会うことはないと諦めていた矢先に、
それは突然目の前に現れたのです!

それは・・・

2010年12月から実線運用が始まった225系新快速

毎日のように乗っている新快速なのに、現行の編成では私の通勤時間帯に出会うはずのない列車。
しかし昨日はダイヤの乱れの影響か、223系で運行されるはずの新快速が225系に振り返られていた。外から舐め回すように見回したあと、おもむろに車内に。そのインプレッションは・・・

○噂どおり黄色い吊革に手すり。目新しく感じはするけれどちょっとクドいのでは?

○新しいデザインのシート。まだそんなに日が経っていないからか、キレイで毛並みもまだ長くフワフワ。色合いも好み。

○へー、電車でもクルマと同じ新車の香りがするんだね~。

○発車時、インバータの音が223系よりもかなり小さく静か。そして加速も非常に滑らかな印象。

○高速走行時は、話に聞いていたように確かに揺れがかなり抑えられている。
このときお客さんが多かったのでいつもは乗らない一番前よりの座席に座ったのだけど、それでも揺れはいつもより少なかった(いつもは揺れの少ない車両の真ん中よりの座席に座る)。

ちょっと厳めしい感じになったフロントマスクも含めて、なかなか良くなった225系。
しかし、今度はいつ出会うことができるのやら・・・

2011年1月12日水曜日

組み込みhttpサーバー

サクッと使える組み込み用httpサーバーがないものかと思って探してみたけど,
意外と引っかからないものだな。

有名どころとしてはhttpdがあるけれどちょっと組み込み用には重そうなのでパス。
コンパクトで一通りの機能(authrizationとかCGI、SSLなど)が揃っているものとしてMongooseを発見!とりあえずこれを元にして、組み込み用途に合うようカスタマイズしてみるか。
ざっとソースコードを拝見したところ、

○ソースコード1ファイルで完結するほどコンパクトなのはgood!
○CGIやSSLにも対応。ただしSSLはOpenSSLを前提にしている?
○組み込み用というよりは、Linux/Windows環境での動作を前提にしているため、malloc/freeやスレッドをバンバン使用。しかも、TCP/IPとのインターフェースはsocketであることを前提としている。
 ○(当然ですが)ファイルシステムがあるものとして実装されている。
○else if節を連発して一連の処理のエラー処理を書いているのは、どうも(私には)読みにくいのでNG

という感触。
最終目的は組み込み機器に入れることなので、できれば128KByte程度のROM容量にすべて収まるのが望ましいけど無理かなぁ。
当座の方針としては、

○何らかのRTOS上で動くことを前提とする(スレッド-->タスクに置き換えてマルチセッションに対応させる)
○WEBサーバとして機能させるならファイルシステムの概念は必須だが、組み込み系では苦しい場合があるのでファイルシステムがない状態でも動作可能なようにする。
○CGIは関数呼び出しに置き換える(組み込み系ではコマンドのダイナミックローディングに対応しない場合がほとんど)
○なるべくローカルスタックを消費しないような実装に変更。
○なるべくmalloc/free系関数は使用しないような実装に変更。
○不要な機能は#defineなどで切り離せるように変更。(CGIやSSLの使用有無)

という方向で進めてみたい。
うまくいけば、open sourceとして公開するか?

2011年1月11日火曜日

[STM32]USBダブルバッファエンドポイントの挙動

STマイクロエレクトロニクスSTM32シリーズのUSBドライバに関して、
ダブルバッファエンドポイントの挙動についてのまとめ。

リファレンスマニュアルRM008にはそこそこ説明があるものの、レジスタの詳しい挙動までは読み切れないので実機で調べてみた。

まずは、OUTパイプに関して。
USB_EPnRを以下のように設定してみる。


DTOG_RX : 0
STAT_RX : 10 [NAK]
EPTYPE : 00 [bulk]
EP_KIND : 1 [DBL_BUF]
DTOG_TX : 0 または 1
STAT_TX : 00 [DISABLED]
EA : 適宜

この状態でUSBホストからOUTトランザクションを発行すると、STAT_RXNAKに設定されているので当然NAK応答となり、パケットは受信されない。

続いて次のように設定。

DTOG_RX : 0
STAT_RX : 11 [VALID]
DTOG_TX(=SW_BUF) : 0

この設定でホストからOUTトランザクションを1つだけ送ると、そのパケットを受信してレジスタは以下のように変化した。これはリファレンスマニュアルから読み取れる範囲内の挙動。

DTOG_RX : 1
STAT_RX : 11 [VALID] =変化なし
DTOG_TX(=SW_BUF) : 0


ここでパケットの内容を読まずに、更にホストからOUTトランザクションをもう一つ送ってみる。

DTOG_RX : 0
STAT_RX : 11 [VALID] =変化なし
DTOG_TX(=SW_BUF) : 0

となった。特筆すべきは、このレジスタの状態は2つ前の状態と同じであることだ。
2つ前の状態はダブルバッファの両方が空の状態で2つのパケットを受信できる状態、そして現在の状態はダブルバッファが2つとも埋まっている状態。まったく異なる状態にあるにもかかわらずレジスタ上ではその違いを区別することができない。
リファレンスマニュアルでは明記されていないが、私はダブルバッファが両方とも埋まるとSTAT_RX10[NAK]に変わるものだと思っていた。実際、シングルバッファではNAKに変化する。
この状態でパケットの内容を読まずに、更にもう一つOUTトランザクションを送ってみる。当然だけど、ホストにはNAKで応答している。

ここで、DTOG_TX(=SW_BUF)に1を書いてみる。

DTOG_RX : 1
STAT_RX : 11 [VALID] =変化なし
DTOG_TX(=SW_BUF) : 1

これでSW_BUFがトグルされると同時に、3つ目のOUTトランザクションがNAK応答を繰り返していたのがACK応答を返して終了した(これに対応してDTOG_RXが再度に変化)。

これでようやく詳細な挙動が把握できた。まとめると以下のような感じ。

シングルバッファでOUTトランザクションを受け取る場合
○受信したくないときは、STAT_RX10=NAKに設定しておく。
○受信するときはSTAT_RX11=VALIDにする。
○OUTトランザクションが完了するとSTAT_RX10=NAKに自動的に変化する。次のパケットを受信するには、ソフトウェアでSTAT_RX01を書き込む(トグル動作に注意)。

ダブルバッファでOUTトランザクションを受け取る場合
○受信したくないときは、STAT_RX10=NAKにしておく。
○初めて受信させるときは、
    DTOG_RX=0
STAT_RX=11=VALID
DTOG_TX(=SW_BUF)=0
  とする。
○OUTトランザクションが完了するとDTOG_RXが自動的にトグルするが、パケットを2つ以上受け取っても今度はSTAT_RXは変化せずに、ただNAKを返すようになるだけ。受信割り込み(CTR_RX)を確認するなどしてパケットを受け取ったら、ソフトウェアでやるべきことはDTOG_TX=(SW_BUF)を書き込むことだけ(CTR_RXは適宜消すように)。DTOG_RXSTAT_RXの状態は気にする必要はなく、バッファ管理とNAK応答はハードウェア側で適宜処理されている。