前の10件 | -
ErgoDox使い始めました [PC]
Windowsメインユーザの軟弱な私がErgoDoxに手を出してしまいました。
腱鞘炎とかが理由の方もいるようですが、それほど酷使していない私はただ単にキーボードを変えてみたかっただけです。何年かに一度あるんです。ちなみに今まで使ってたのはRealForce。
ErgoDox買うような人は、マウスに手を伸ばす時間がもったいないので基本コマンドライン、emacsやvimをばんばん使いこなし、長時間途切れずにキーを打ち続ける、そんな人だと思うのですが（勝手なイメージ）、私は一応タッチタイプは出来るけど危なっかしげ、Windowsベースでエディタはサクラエディタ、viはとりあえず基本の編集と保存は出来るぞ、emacsは間違えてセーブしちゃうかも、そんなレベルです。頭も固くなってきたお年頃、ErgoDoxなんて使えるのか、棚の肥やしにならないのか、一つの参考として見て頂ければと。
IBMPCコンパチ機がDOS/V機と名前を変える前、国産80486マシンがアホみたいに高価で、個人輸入が流行り、Linuxが5インチフロッピー50枚で回覧されてた、そんな時代からPC使ってるおっさんの私は、相変わらずUS101配置です。shift-2で@が出てくれないと困ります。
今回買ったのはErgoDox EZ。こちらの「ErgoDox EZ Bundle with Blank Keycaps — $295.00 」というもの。
https://ergodox-ez.com/
ハンダ付けが苦手というわけでも無いのでキットでも良かったんですが、作るのが面倒だったので完成品です。スイッチは白軸。最初は軽すぎでミスタッチしまくりでしたが、しばらくしたら慣れる物ですな～でもやっぱりもうちょっと重くても良かったかも。私が買った時からちょっと変わってて、今は最初に軸を選んでからカートに入れて、支払いまで行けばOKなようです。
到着したらErgoDoxだけにします。普段のキーボードを並べておいてあったら多分いつまで経っても移行できないでしょう。自分には甘い人間なので（笑）
ErgoDox初期マップは慣れる前に心が折れる事が想像できたので、101キーをベースにマップし直します。使いながらぼちぼち変わって行きます。マップ変更は以前はMassDropの簡単なGUIを使ってました。今は仮想環境のLinuxでmakeしています。
https://www.massdrop.com/configurator/ergodox
一時期落ちてたんですが復活したようです。
キーキャップ真っ黒でもタッチタイプできるから大丈夫～なんて思ってたら、単に自惚れ勘違いだったようです。ミスしまくり、迷い箸ならぬ迷い指です。変な癖がたくさん付いてて、
・数字キーがちゃんと押せてない
・Bを右手で、6を左手で押してる
・記号をちゃんと憶えてない、特に%とか&などを間違える
などなど。薬指に対して小指が短めな事もあって、1や0のキーは薬指です。
あと、ErgoDoxにして判明したのは、自分の親指はそれほど器用でも無い、ということ。考えてみればUS101キーではスペースキーとALTキーぐらいしか押しません。最初中央の親指キーに色々割り当ててみましたが、まぁ間違う間違う。結局SpaceとEnterだけになりました・・・
そんなこんなで2週間我慢、なんとか普通に打てるようになってきました。が、記号に関してはなぜか安定しません。昔ちゃんと憶えなかったからですかね～半ば諦めて、キーキャップをプリントタイプに変更することにします。
たまたま目に入ったこちら。
https://www.massdrop.com/buy/gmk-carbon-custom-keycap-set
到着まで1ヶ月ぐらいかかってます。
現在の外観。
レイヤー切り替えのキーキャップは逆さまに付けて、触ったときのアクセントにしてます。
キーマップ。
レイヤー切り替えであまりキーが変わらないようにしてます。Layer1はカーソル移動+ファンクション。右手で親指+カーソル移動しながら、左手でCtrl-zxcvを操作することが多いです。F1~12は数字キーとズレてますが、慣れちゃいますね。Layer2はほぼ表計算入力用。たまにしか使いません。
中央のキーはSpaceとEnterだけ使ってます。カーソルキーとHome,Endなどは一応マップしてますが、普段は使いません。ブラウザで右手がマウスに行ってるときにだらだら押すボタンとして入れてます。
ということで、あまりキーボードバリバリユーザでは無くてもErgoDoxに慣れることは出来ます。んで、慣れるとやっぱり楽になります。手首とか姿勢とかが楽になって、長時間作業でも疲労が少なくなった感じがします。
慣れるまでのコツとしては
・あまり奇抜な配置にしない
・無理に機能を活用しようとしない（中央キーとかレイヤーとかマクロとか）
・見栄を張らない（笑）。意外とタッチタイプできてるようで出来てません
あたりじゃ無いかな～と思います。
悩んでいる人がいたらどうするか？自分はオススメするとおもいます。楽な姿勢で作業できるのは魅力ですよ～
腱鞘炎とかが理由の方もいるようですが、それほど酷使していない私はただ単にキーボードを変えてみたかっただけです。何年かに一度あるんです。ちなみに今まで使ってたのはRealForce。
ErgoDox買うような人は、マウスに手を伸ばす時間がもったいないので基本コマンドライン、emacsやvimをばんばん使いこなし、長時間途切れずにキーを打ち続ける、そんな人だと思うのですが（勝手なイメージ）、私は一応タッチタイプは出来るけど危なっかしげ、Windowsベースでエディタはサクラエディタ、viはとりあえず基本の編集と保存は出来るぞ、emacsは間違えてセーブしちゃうかも、そんなレベルです。頭も固くなってきたお年頃、ErgoDoxなんて使えるのか、棚の肥やしにならないのか、一つの参考として見て頂ければと。
IBMPCコンパチ機がDOS/V機と名前を変える前、国産80486マシンがアホみたいに高価で、個人輸入が流行り、Linuxが5インチフロッピー50枚で回覧されてた、そんな時代からPC使ってるおっさんの私は、相変わらずUS101配置です。shift-2で@が出てくれないと困ります。
今回買ったのはErgoDox EZ。こちらの「ErgoDox EZ Bundle with Blank Keycaps — $295.00 」というもの。
https://ergodox-ez.com/
ハンダ付けが苦手というわけでも無いのでキットでも良かったんですが、作るのが面倒だったので完成品です。スイッチは白軸。最初は軽すぎでミスタッチしまくりでしたが、しばらくしたら慣れる物ですな～でもやっぱりもうちょっと重くても良かったかも。私が買った時からちょっと変わってて、今は最初に軸を選んでからカートに入れて、支払いまで行けばOKなようです。
到着したらErgoDoxだけにします。普段のキーボードを並べておいてあったら多分いつまで経っても移行できないでしょう。自分には甘い人間なので（笑）
ErgoDox初期マップは慣れる前に心が折れる事が想像できたので、101キーをベースにマップし直します。使いながらぼちぼち変わって行きます。マップ変更は以前はMassDropの簡単なGUIを使ってました。今は仮想環境のLinuxでmakeしています。
https://www.massdrop.com/configurator/ergodox
一時期落ちてたんですが復活したようです。
キーキャップ真っ黒でもタッチタイプできるから大丈夫～なんて思ってたら、単に自惚れ勘違いだったようです。ミスしまくり、迷い箸ならぬ迷い指です。変な癖がたくさん付いてて、
・数字キーがちゃんと押せてない
・Bを右手で、6を左手で押してる
・記号をちゃんと憶えてない、特に%とか&などを間違える
などなど。薬指に対して小指が短めな事もあって、1や0のキーは薬指です。
あと、ErgoDoxにして判明したのは、自分の親指はそれほど器用でも無い、ということ。考えてみればUS101キーではスペースキーとALTキーぐらいしか押しません。最初中央の親指キーに色々割り当ててみましたが、まぁ間違う間違う。結局SpaceとEnterだけになりました・・・
そんなこんなで2週間我慢、なんとか普通に打てるようになってきました。が、記号に関してはなぜか安定しません。昔ちゃんと憶えなかったからですかね～半ば諦めて、キーキャップをプリントタイプに変更することにします。
たまたま目に入ったこちら。
https://www.massdrop.com/buy/gmk-carbon-custom-keycap-set
到着まで1ヶ月ぐらいかかってます。
現在の外観。
レイヤー切り替えのキーキャップは逆さまに付けて、触ったときのアクセントにしてます。
キーマップ。
レイヤー切り替えであまりキーが変わらないようにしてます。Layer1はカーソル移動+ファンクション。右手で親指+カーソル移動しながら、左手でCtrl-zxcvを操作することが多いです。F1~12は数字キーとズレてますが、慣れちゃいますね。Layer2はほぼ表計算入力用。たまにしか使いません。
中央のキーはSpaceとEnterだけ使ってます。カーソルキーとHome,Endなどは一応マップしてますが、普段は使いません。ブラウザで右手がマウスに行ってるときにだらだら押すボタンとして入れてます。
ということで、あまりキーボードバリバリユーザでは無くてもErgoDoxに慣れることは出来ます。んで、慣れるとやっぱり楽になります。手首とか姿勢とかが楽になって、長時間作業でも疲労が少なくなった感じがします。
慣れるまでのコツとしては
・あまり奇抜な配置にしない
・無理に機能を活用しようとしない（中央キーとかレイヤーとかマクロとか）
・見栄を張らない（笑）。意外とタッチタイプできてるようで出来てません
あたりじゃ無いかな～と思います。
悩んでいる人がいたらどうするか？自分はオススメするとおもいます。楽な姿勢で作業できるのは魅力ですよ～
AXIの勉強（その2.2） [AXI]
書き込みの依存関係です。
3チャンネルあるので長くなりますが、読み込みと同じように分けてみます。
Write transaction dependencies
1• the master must not wait for the slave to assert AWREADY or WREADY before asserting AWVALID or WVALID
2• the slave can wait for AWVALID or WVALID, or both before asserting AWREADY
3• the slave can assert AWREADY before AWVALID or WVALID, or both, are asserted
4• the slave can wait for AWVALID or WVALID, or both, before asserting WREADY
5• the slave can assert WREADY before AWVALID or WVALID, or both, are asserted
実はAWとWの2チャンネルの依存関係が絡んでるここが結構面倒です。
1 マスターのAWVALIDやWVALIDは、AWREADYとWREADYに依存してはならない。
2,3 スレーブのAWREADYは、AWVALIDかWVALID、もしくは両方に依存しても、しなくても良い。
4,5 スレーブのWREADYは、AWVALIDかWVALID、もしくは両方に依存しても、しなくても良い。
「１」の制約は
・AWシーケンサーはAW自身のREADYだけでなく、WのREADYも参照してはならない
・WシーケンサーはW自身のREADYだけでなく、AWのREADYも参照してはならない
という２つの制約になっています。
なぜか。
書き込みなのでマスターのAWとWはソースですが、AWとWの順番には特に決まりはなく、アドレスが先でそれからデータ、先にデータを出してからアドレスを送る、もしくは同時、でかまいません。
・ マスターはAWとW、どちらを先に出すか、自由に選べる
・ スレーブはAWとW、どちらを先に受け取るか、自由に選べる
という状況です。相手がどちらを先だと想定しているのかが不明です。
この状態で、
・ もしマスターのWVALIDがAWREADYに依存していて （これが違反）
・ マスターはAW→Wの順番で送る
・ スレーブはW→AWの順番で来ると思ってる
という場合、マスターがAWREADY待ち、スレーブがWVALID待ち、となりデッドロックします。
普通アドレスが先でデータが後でしょう、って事で
AWVALID <= '1';
if (AWREADY = '1') then
AWVALID <= '0'; next_state;
WVALID <= '1';
if (WREADY = '1') then
WVALID <= '0'; next_state;
こんなマスター回路が思いつきます。当たり前な回路に見えますが、 WVALIDがAWREADYに依存しているので、実はこれ違反です。ただ、世の中、アドレスが先だと想定してるスレーブがほとんどなので、大体問題なくつながっちゃいます。
データが来るまでアドレスは受け付けない、というひねくれた（けど仕様に反してはいない）スレーブが、この回路につながるとデッドロックします。例えばこんな回路。
if (WVALID = '1') then
WREADY <= '1';
AWREADY <= '1'; データが送られ始めてからアドレスを受け取る
AWVALIDかWVALIDを動作開始のトリガーと考えると、そんなにひねくれて見えませんよね。2,3,4,5の項目から、これは正しい動作です。
この制約は多分、アドレスとデータを同時に転送できるようにするために作られたんだと思います。データを先に転送するような回路は、もちろん作っても良いですけど、不自然ですよね。
2,3,4,5の制約は、今までと同じく、VALID側を制約して、READY側は自由にすし、デッドロックを回避する、という項目です。
6• the slave must wait for both WVALID and WREADY to be asserted before asserting BVALID the slave must also wait for WLAST to be asserted before asserting BVALID, because the write response, BRESP, must be signaled only after the last data transfer of a write transaction
ちょっと長めですが、要するに
・全てのデータ転送を終えてから、BVALIDをアサートすること。
という制約です。リードのAR→Rの制約と似ています。
注意点としてはWLASTも見ている所です。今まではペイロードの中身がタイミングに影響することはなかったのですが、「全ての」が関係してきます。AXIはバースト転送が基本なので、Wチャンネルの転送が何回あるかはペイロードの中身を見ないとわかりません（転送が1回でも1バーストです）。WREADY&WVALID&WLASTが揃ったのを確認してから、BVALIDをアサート、レスポンスのステートに入ります。
7• the slave must not wait for the master to assert BREADY before asserting BVALID
8• the master can wait for BVALID before asserting BREADY
9• the master can assert BREADY before BVALID is asserted.
これは単純。Bチャンネルのデッドロック防止です。
AXI4になると書き込みの依存関係の図に、矢印が2本増えます。
項目はほとんど同じですが、、「6」だけ異なります。
• the slave must wait for AWVALID, AWREADY, WVALID, and WREADY to be asserted before asserting BVALID
the slave must also wait for WLAST to be asserted before asserting BVALID because the write response, BRESP must be signaled only after the last data transfer of a write transaction
これは
・アドレス転送と、全てのデータ転送を終えてから、BVALIDをアサートすること。
という内容になります。アドレス転送が条件に入ってます。
実はAXI3だと、アドレス転送を完了させないままレスポンスを返せるようになってます。制約がありませんので。AWREADYをずっと返さずにデータ転送を終えて、レスポンスを返して、それからアドレス転送を完了する、という順番でも良かったわけです。
まぁ、普通に考えればおかしな動作ですが。制約されてない以上、あり得る動作です。
AXI4ではこれが制約され、マスターがアドレスとデータ全ての転送を完了するまで、スレーブはレスポンスを返せなくなってます。
スレーブ側の制約です。AXI3のスレーブをAXI4のマスターに接続するときに注意が必要で、ペイロードの内容を変換する以外に、この書き込みの依存関係を満足させる必要があります。
3チャンネルあるので長くなりますが、読み込みと同じように分けてみます。
Write transaction dependencies
1• the master must not wait for the slave to assert AWREADY or WREADY before asserting AWVALID or WVALID
2• the slave can wait for AWVALID or WVALID, or both before asserting AWREADY
3• the slave can assert AWREADY before AWVALID or WVALID, or both, are asserted
4• the slave can wait for AWVALID or WVALID, or both, before asserting WREADY
5• the slave can assert WREADY before AWVALID or WVALID, or both, are asserted
実はAWとWの2チャンネルの依存関係が絡んでるここが結構面倒です。
1 マスターのAWVALIDやWVALIDは、AWREADYとWREADYに依存してはならない。
2,3 スレーブのAWREADYは、AWVALIDかWVALID、もしくは両方に依存しても、しなくても良い。
4,5 スレーブのWREADYは、AWVALIDかWVALID、もしくは両方に依存しても、しなくても良い。
「１」の制約は
・AWシーケンサーはAW自身のREADYだけでなく、WのREADYも参照してはならない
・WシーケンサーはW自身のREADYだけでなく、AWのREADYも参照してはならない
という２つの制約になっています。
なぜか。
書き込みなのでマスターのAWとWはソースですが、AWとWの順番には特に決まりはなく、アドレスが先でそれからデータ、先にデータを出してからアドレスを送る、もしくは同時、でかまいません。
・ マスターはAWとW、どちらを先に出すか、自由に選べる
・ スレーブはAWとW、どちらを先に受け取るか、自由に選べる
という状況です。相手がどちらを先だと想定しているのかが不明です。
この状態で、
・ もしマスターのWVALIDがAWREADYに依存していて （これが違反）
・ マスターはAW→Wの順番で送る
・ スレーブはW→AWの順番で来ると思ってる
という場合、マスターがAWREADY待ち、スレーブがWVALID待ち、となりデッドロックします。
普通アドレスが先でデータが後でしょう、って事で
AWVALID <= '1';
if (AWREADY = '1') then
AWVALID <= '0'; next_state;
WVALID <= '1';
if (WREADY = '1') then
WVALID <= '0'; next_state;
こんなマスター回路が思いつきます。当たり前な回路に見えますが、 WVALIDがAWREADYに依存しているので、実はこれ違反です。ただ、世の中、アドレスが先だと想定してるスレーブがほとんどなので、大体問題なくつながっちゃいます。
データが来るまでアドレスは受け付けない、というひねくれた（けど仕様に反してはいない）スレーブが、この回路につながるとデッドロックします。例えばこんな回路。
if (WVALID = '1') then
WREADY <= '1';
AWREADY <= '1'; データが送られ始めてからアドレスを受け取る
AWVALIDかWVALIDを動作開始のトリガーと考えると、そんなにひねくれて見えませんよね。2,3,4,5の項目から、これは正しい動作です。
この制約は多分、アドレスとデータを同時に転送できるようにするために作られたんだと思います。データを先に転送するような回路は、もちろん作っても良いですけど、不自然ですよね。
2,3,4,5の制約は、今までと同じく、VALID側を制約して、READY側は自由にすし、デッドロックを回避する、という項目です。
6• the slave must wait for both WVALID and WREADY to be asserted before asserting BVALID the slave must also wait for WLAST to be asserted before asserting BVALID, because the write response, BRESP, must be signaled only after the last data transfer of a write transaction
ちょっと長めですが、要するに
・全てのデータ転送を終えてから、BVALIDをアサートすること。
という制約です。リードのAR→Rの制約と似ています。
注意点としてはWLASTも見ている所です。今まではペイロードの中身がタイミングに影響することはなかったのですが、「全ての」が関係してきます。AXIはバースト転送が基本なので、Wチャンネルの転送が何回あるかはペイロードの中身を見ないとわかりません（転送が1回でも1バーストです）。WREADY&WVALID&WLASTが揃ったのを確認してから、BVALIDをアサート、レスポンスのステートに入ります。
7• the slave must not wait for the master to assert BREADY before asserting BVALID
8• the master can wait for BVALID before asserting BREADY
9• the master can assert BREADY before BVALID is asserted.
これは単純。Bチャンネルのデッドロック防止です。
AXI4になると書き込みの依存関係の図に、矢印が2本増えます。
項目はほとんど同じですが、、「6」だけ異なります。
• the slave must wait for AWVALID, AWREADY, WVALID, and WREADY to be asserted before asserting BVALID
the slave must also wait for WLAST to be asserted before asserting BVALID because the write response, BRESP must be signaled only after the last data transfer of a write transaction
これは
・アドレス転送と、全てのデータ転送を終えてから、BVALIDをアサートすること。
という内容になります。アドレス転送が条件に入ってます。
実はAXI3だと、アドレス転送を完了させないままレスポンスを返せるようになってます。制約がありませんので。AWREADYをずっと返さずにデータ転送を終えて、レスポンスを返して、それからアドレス転送を完了する、という順番でも良かったわけです。
まぁ、普通に考えればおかしな動作ですが。制約されてない以上、あり得る動作です。
AXI4ではこれが制約され、マスターがアドレスとデータ全ての転送を完了するまで、スレーブはレスポンスを返せなくなってます。
スレーブ側の制約です。AXI3のスレーブをAXI4のマスターに接続するときに注意が必要で、ペイロードの内容を変換する以外に、この書き込みの依存関係を満足させる必要があります。
AXIの勉強（その2.1） [AXI]
続いてリードの依存関係。
Read transaction dependencies
1• the master must not wait for the slave to assert ARREADY before asserting ARVALID
2• the slave can wait for ARVALID to be asserted before it asserts ARREADY
3• the slave can assert ARREADY before ARVALID is asserted
4• the slave must wait for both ARVALID and ARREADY to be asserted before it asserts RVALID to indicate that valid data is available
5• the slave must not wait for the master to assert RREADY before asserting RVALID
6• the master can wait for RVALID to be asserted before it asserts RREADY
7• the master can assert RREADY before RVALID is asserted.
なんかいっぱいありますが、分けてみるとわかりやすいかと思います。
まず上3つ。1,2,3。
・マスターのARVALIDは、ARREADYに依存してはならない
・スレーブはARVALIDを待ってからARREADYをアサートしても良い
・スレーブはARVALIDより前にARREADYをアサートしても良い
前の記事のソース・シンクの関係と同じです。ARチャンネルのデッドロックを防止する制約です。
下3つ。5,6,7。
・スレーブのRVALIDは、RREADYに依存してはならない
・マスターはRVALIDを待ってからRREADYをアサートしても良い
・マスターはRVALIDより前にRREADYをアサートしても良い
Rチャンネルのデッドロック防止です。
真ん中の一つ。4。
・スレーブはARREADYとARVALID両方がアサートされるのを待ってからRVALIDをアサートすること
ARREADYとARVALID両方がアサートされるということは、ARの転送が完了したということです。
ARVALIDはマスターがドライブしているので、スレーブ側のRのソースシーケンサーの制約になります。つまり、
・スレーブはARVALIDが来ないうちにRVALIDをアサートしてはならない
・スレーブはARREADYを先に返してからRVALIDをアサートすること
という制約です。
要は
・アドレス情報が与えられてもいないのに余計な情報を勝手に送るな
・アドレス情報を受け取ったことを、まずマスターに知らせてから、データを返せ
という制約です。1つ目はまあ良いですよね。
2つ目、例えばスレーブがARREADYを返さずに、ARの情報をゆっくり解析する回路にしたとします。これ自体は正しい動作です。
if (ARVALID) then
1クロック目：AR.addr評価
2クロック目：AR.length評価
3クロック目：
・・・・
nクロック目：ARREADY <= '1';
この途中でデータを返すのを違反としています。
if (ARVALID) then
1クロック目：AR.addr評価
2クロック目：AR.length評価
3クロック目：RVALID <= '1'; 違反
4クロック目：if (RREADY) then ここでデッドロック
・・・・
nクロック目：ARREADY <= '1';
なぜか。
例えばこれにつながるマスターがこんな風に順番に処理する回路の場合です。あり得る回路です。
アドレス処理ステート
ARVALID <= '1';
↑クロック
if (ARREADY = '1') then ここでデッドロック
ARVALID <= '0';
データ処理ステート
if (ARVALID = '1') then
RREADY <= '1'
・マスターのARシーケンサーがARREADYを確認してからデータの受信処理を行う
・スレーブのRシーケンサーがARREADYをアサートする前にRREADYの評価を行う
この2つがつながるとデッドロックします。
実際の犯人はRREADYを評価していることで、RVALIDをアサートしたこと自体ではないですが。RVALIDを操作したということは、スレーブがデータ処理ステートに入ったことを意味します。けどマスターがアドレス処理のステートのままだと、RREADYが返ってこないかも知れません。
この、スレーブがデータ処理ステートに入ったのに、マスターがアドレス処理ステートのところで止まったまま、となるのを防ぐための制約で、マスター・スレーブともアドレス処理ステートを完了させてからデータ処理ステートに移行しましょう、そのために、スレーブはARREADYを先に返してからRVALIDをアサートすること、という決まり事です。
下のような違反の回路、AXIに慣れてないうちだと、意外と作りがちな回路です。
ARVALIDをアドレスストローブ信号、ARREADYをウェイト制御信号、と認識してるとこんな回路になります。パケット式じゃない、普通のタイミング方式のバスに慣れてる人がはまりやすいパターンです。
AXIはただのインターフェースの仕様で、どんなコーディングしてるのかわからない相手が接続されます。デッドロックのパターンを決めておかないとエラいことになります。なので、こんな制約が存在します。
Read transaction dependencies
1• the master must not wait for the slave to assert ARREADY before asserting ARVALID
2• the slave can wait for ARVALID to be asserted before it asserts ARREADY
3• the slave can assert ARREADY before ARVALID is asserted
4• the slave must wait for both ARVALID and ARREADY to be asserted before it asserts RVALID to indicate that valid data is available
5• the slave must not wait for the master to assert RREADY before asserting RVALID
6• the master can wait for RVALID to be asserted before it asserts RREADY
7• the master can assert RREADY before RVALID is asserted.
なんかいっぱいありますが、分けてみるとわかりやすいかと思います。
まず上3つ。1,2,3。
・マスターのARVALIDは、ARREADYに依存してはならない
・スレーブはARVALIDを待ってからARREADYをアサートしても良い
・スレーブはARVALIDより前にARREADYをアサートしても良い
前の記事のソース・シンクの関係と同じです。ARチャンネルのデッドロックを防止する制約です。
下3つ。5,6,7。
・スレーブのRVALIDは、RREADYに依存してはならない
・マスターはRVALIDを待ってからRREADYをアサートしても良い
・マスターはRVALIDより前にRREADYをアサートしても良い
Rチャンネルのデッドロック防止です。
真ん中の一つ。4。
・スレーブはARREADYとARVALID両方がアサートされるのを待ってからRVALIDをアサートすること
ARREADYとARVALID両方がアサートされるということは、ARの転送が完了したということです。
ARVALIDはマスターがドライブしているので、スレーブ側のRのソースシーケンサーの制約になります。つまり、
・スレーブはARVALIDが来ないうちにRVALIDをアサートしてはならない
・スレーブはARREADYを先に返してからRVALIDをアサートすること
という制約です。
要は
・アドレス情報が与えられてもいないのに余計な情報を勝手に送るな
・アドレス情報を受け取ったことを、まずマスターに知らせてから、データを返せ
という制約です。1つ目はまあ良いですよね。
2つ目、例えばスレーブがARREADYを返さずに、ARの情報をゆっくり解析する回路にしたとします。これ自体は正しい動作です。
if (ARVALID) then
1クロック目：AR.addr評価
2クロック目：AR.length評価
3クロック目：
・・・・
nクロック目：ARREADY <= '1';
この途中でデータを返すのを違反としています。
if (ARVALID) then
1クロック目：AR.addr評価
2クロック目：AR.length評価
3クロック目：RVALID <= '1'; 違反
4クロック目：if (RREADY) then ここでデッドロック
・・・・
nクロック目：ARREADY <= '1';
なぜか。
例えばこれにつながるマスターがこんな風に順番に処理する回路の場合です。あり得る回路です。
アドレス処理ステート
ARVALID <= '1';
↑クロック
if (ARREADY = '1') then ここでデッドロック
ARVALID <= '0';
データ処理ステート
if (ARVALID = '1') then
RREADY <= '1'
・マスターのARシーケンサーがARREADYを確認してからデータの受信処理を行う
・スレーブのRシーケンサーがARREADYをアサートする前にRREADYの評価を行う
この2つがつながるとデッドロックします。
実際の犯人はRREADYを評価していることで、RVALIDをアサートしたこと自体ではないですが。RVALIDを操作したということは、スレーブがデータ処理ステートに入ったことを意味します。けどマスターがアドレス処理のステートのままだと、RREADYが返ってこないかも知れません。
この、スレーブがデータ処理ステートに入ったのに、マスターがアドレス処理ステートのところで止まったまま、となるのを防ぐための制約で、マスター・スレーブともアドレス処理ステートを完了させてからデータ処理ステートに移行しましょう、そのために、スレーブはARREADYを先に返してからRVALIDをアサートすること、という決まり事です。
下のような違反の回路、AXIに慣れてないうちだと、意外と作りがちな回路です。
ARVALIDをアドレスストローブ信号、ARREADYをウェイト制御信号、と認識してるとこんな回路になります。パケット式じゃない、普通のタイミング方式のバスに慣れてる人がはまりやすいパターンです。
AXIはただのインターフェースの仕様で、どんなコーディングしてるのかわからない相手が接続されます。デッドロックのパターンを決めておかないとエラいことになります。なので、こんな制約が存在します。
AXIの勉強（その2） [AXI]
何年ぶりでしょう（笑）
簡単にタイミングの依存関係について書いてみます。
元になる資料はARMからダウンロードできる「IHI0022E_amba_axi_and_ace_protocol_spec.pdf」です。Issue Eが多分最新版。
AXIは、
という5チャンネルでパケットのやりとりをしている感じなのですが、それぞれのチャネルがREADYとVALIDを持っていて個別にハンドシェイクを行う、という仕組みになっています。
けど、ハンドシェイクは個別ですけど、ちょっとは相手のことも考えないとダメよ、勝手に動くとデッドロックしますよという項目です。これが依存関係で、資料に書いてあります。A.3.3のRelationships between the channelsから始まる内容です。
A3.3.1 Dependencies between channel handshake signals
一番基本になる依存関係です。5系統それぞれにある、READYとVALIDの関係です。AXI Streamにも同じ制約がかかります。こんなことが書かれてます。
• the VALID signal of the AXI interface sending information must not be dependent on the READY signal of the AXI interface receiving that information
• an AXI interface that is receiving information can wait until it detects a VALID signal before it asserts its corresponding READY signal.
掻い摘まむと
・VALIDはREADYに依存してはならない（ソース側の制約）
・READYはVALIDに依存しても良い（シンク側の制約）
と言う事になります。
（マスター・スレーブと呼ぶとと5チャンネルを束ねたインターフェースを指します。だから英語の方ではちょっと持って回った言い方になってます。間際らしいので、ここでは個々のチャンネルのインターフェースをソース・シンクと呼んでます。ソースからシンクへデータが流れます。マスターは3つのソースと2つのシンク、スレーブは3つのシンクと2つのソースを持ちます。）
要するに、ソース側のシーケンサーを作るとき、
if (READY = '1') then
VALID <= '1';
みたいな回路は作っちゃダメですよ、という制約になります。
シンク側は
if (VALID = '1') then
READY <= '1';
という回路を作っても大丈夫です。
ソース側の制約な訳ですが、ダメな回路例と大丈夫な回路例をつないでみれば一目瞭然かと。ソースがREADY待ちで、シンクがVALID待ちとなり、デッドロックします。どちらかに制約をかける必要があり、AXIではVALID側を制約しています。
ちなみにシンク側ですが、この回路にしなければなりません、という’訳ではありません。VALIDに依存しない、
if (Im_free) then
READY <= '1';
という回路にしても良いです。
VALIDに関係なく、自分の都合でREADYをアサートしてもかまいません。READY側の方が自由になっています。
こんなのがAXIの依存関係です。他のチャンネルとの依存関係も読んでいきましょう。
簡単にタイミングの依存関係について書いてみます。
元になる資料はARMからダウンロードできる「IHI0022E_amba_axi_and_ace_protocol_spec.pdf」です。Issue Eが多分最新版。
AXIは、
という5チャンネルでパケットのやりとりをしている感じなのですが、それぞれのチャネルがREADYとVALIDを持っていて個別にハンドシェイクを行う、という仕組みになっています。
けど、ハンドシェイクは個別ですけど、ちょっとは相手のことも考えないとダメよ、勝手に動くとデッドロックしますよという項目です。これが依存関係で、資料に書いてあります。A.3.3のRelationships between the channelsから始まる内容です。
A3.3.1 Dependencies between channel handshake signals
一番基本になる依存関係です。5系統それぞれにある、READYとVALIDの関係です。AXI Streamにも同じ制約がかかります。こんなことが書かれてます。
• the VALID signal of the AXI interface sending information must not be dependent on the READY signal of the AXI interface receiving that information
• an AXI interface that is receiving information can wait until it detects a VALID signal before it asserts its corresponding READY signal.
掻い摘まむと
・VALIDはREADYに依存してはならない（ソース側の制約）
・READYはVALIDに依存しても良い（シンク側の制約）
と言う事になります。
（マスター・スレーブと呼ぶとと5チャンネルを束ねたインターフェースを指します。だから英語の方ではちょっと持って回った言い方になってます。間際らしいので、ここでは個々のチャンネルのインターフェースをソース・シンクと呼んでます。ソースからシンクへデータが流れます。マスターは3つのソースと2つのシンク、スレーブは3つのシンクと2つのソースを持ちます。）
要するに、ソース側のシーケンサーを作るとき、
if (READY = '1') then
VALID <= '1';
みたいな回路は作っちゃダメですよ、という制約になります。
シンク側は
if (VALID = '1') then
READY <= '1';
という回路を作っても大丈夫です。
ソース側の制約な訳ですが、ダメな回路例と大丈夫な回路例をつないでみれば一目瞭然かと。ソースがREADY待ちで、シンクがVALID待ちとなり、デッドロックします。どちらかに制約をかける必要があり、AXIではVALID側を制約しています。
ちなみにシンク側ですが、この回路にしなければなりません、という’訳ではありません。VALIDに依存しない、
if (Im_free) then
READY <= '1';
という回路にしても良いです。
VALIDに関係なく、自分の都合でREADYをアサートしてもかまいません。READY側の方が自由になっています。
こんなのがAXIの依存関係です。他のチャンネルとの依存関係も読んでいきましょう。
Dartが来た [PC]
Kickstarterでやってた、小型ACアダプタのFinsix、Dartが到着しました。
・・・来ると思ってませんでした（笑）。すっかり忘れてました。
履歴を見るとKSキャンペーンが2014年の5月ぐらいですかね。約2年前です。
遅れた理由の一つにLenovoへのライセンシングがあるんだと思います。人的リソースに限りがあるスタートアップで大企業へのサポートに手を出せばそっちでいっぱいいっぱいになるでしょう。一方ライセンス収入でキャッシュフローが潤沢になり、資金切れを起こすことなく製品化に持ち込めたわけで、結果的には良かったんだとは思います。
ということで、箱。
見開き状態に開く。ちなみに小口部分に磁石が入っていて、小気味よくパコンと閉まる。それほど品質の良い箱でもないのに無駄な（笑）
内容物。本体、ケーブル、各種チップ、チップのリスト、袋、取説
チップは9種類
コネクタは2ピン。チップ側も同じ形で、切り欠きの付いた円形。特にセンスピンなどはなく、テスタで当たってもツーツー。ACが入ると単純に20Vが出力される仕様。途中で5Vに落とすDCDCなどが入っていて、USBに供給してるようだ。ちなみにUSBにはLEDのインジケーターが付いてて、負荷がかかると明るくなる。
つないだところ。ケーブルの両端は同じ形なので、USBを本体側にしてもチップ側にしてもOKのようだ。
先にFinsixのライセンスを元に製造されたらしい、Lenovoの65W トラベルACアダプターと比較。半分ぐらい。量産する数が全然違うのはずなので、部品や組み立てのコストが大きさより優先されたのだろうと想像される。Lenovoは筐体もプラスチックだし、プラグが交換可能だし。Finsixは金属筐体。
オレンジと青を入手。
ここしばらくもって歩いてますが、普通のACアダプタとして使えてます。やっぱり小さくて便利。PCの負荷をかけると結構熱くなります。非接触温度センサーで50度ぐらい。ちょっとした小型カイロ。
Lenovoは元々20Vだから問題ないけど、他のPCはどうなんでしょ？18~21Vらしいんで、大体合ってればOKってことかな？
・・・来ると思ってませんでした（笑）。すっかり忘れてました。
履歴を見るとKSキャンペーンが2014年の5月ぐらいですかね。約2年前です。
遅れた理由の一つにLenovoへのライセンシングがあるんだと思います。人的リソースに限りがあるスタートアップで大企業へのサポートに手を出せばそっちでいっぱいいっぱいになるでしょう。一方ライセンス収入でキャッシュフローが潤沢になり、資金切れを起こすことなく製品化に持ち込めたわけで、結果的には良かったんだとは思います。
ということで、箱。
見開き状態に開く。ちなみに小口部分に磁石が入っていて、小気味よくパコンと閉まる。それほど品質の良い箱でもないのに無駄な（笑）
内容物。本体、ケーブル、各種チップ、チップのリスト、袋、取説
チップは9種類
コネクタは2ピン。チップ側も同じ形で、切り欠きの付いた円形。特にセンスピンなどはなく、テスタで当たってもツーツー。ACが入ると単純に20Vが出力される仕様。途中で5Vに落とすDCDCなどが入っていて、USBに供給してるようだ。ちなみにUSBにはLEDのインジケーターが付いてて、負荷がかかると明るくなる。
つないだところ。ケーブルの両端は同じ形なので、USBを本体側にしてもチップ側にしてもOKのようだ。
先にFinsixのライセンスを元に製造されたらしい、Lenovoの65W トラベルACアダプターと比較。半分ぐらい。量産する数が全然違うのはずなので、部品や組み立てのコストが大きさより優先されたのだろうと想像される。Lenovoは筐体もプラスチックだし、プラグが交換可能だし。Finsixは金属筐体。
オレンジと青を入手。
ここしばらくもって歩いてますが、普通のACアダプタとして使えてます。やっぱり小さくて便利。PCの負荷をかけると結構熱くなります。非接触温度センサーで50度ぐらい。ちょっとした小型カイロ。
Lenovoは元々20Vだから問題ないけど、他のPCはどうなんでしょ？18~21Vらしいんで、大体合ってればOKってことかな？
ML110 G7 ESXi+OpenIndiana 追記 [PC]
前の記事では、ESXi 5.1.0U2＋oi151a8で構成しましたが、問題が出てました。Windowsでファイル共有させ、大きめのファイルを転送すると止まる事がある、というものです。ネットワーク周りな感じです。
現在はESXi 5.0.0U3にしています。上記の問題も無く、PCIパススルーもちゃんと動いてます。やっぱりこの辺が一番安定しているようです。
導入方法は大体同じですが、ローカルストレージで追加したSATAカードを認識させるところで、ファイル名が異なります。
5.1では「/bootbank/sata_ahc.v00」ですが、
5.0では「/bootbank/sata-ahc.v00」です。
_と-が違います。
ESXiの外部データストアとしてRaspberryPiにNFSやらせ、ついでにファン制御もさせていましたが、データストアがローカルになったのでRaspberryPiも外しました。ファン制御は結局PICマイコンに任せてます。なんかず～っと遠回りしてスタート地点に戻ってきた感じですな(笑)NE555まで立ち戻ってはいないけど。
8ピンの12F683でデューティー比2～30％のPWM波形をソフトループで作ってるだけです。PWMの周波数が可聴域まで落ちてきましたが、コイル鳴きなどは無さそうです。
今後は温度センサとUSB-UART付けて回転数制御するかな～ぐらいは考えてますが、このままでも良いかも…（って思った時点で負けてるんですがｗ）
nwamdの大量エラーはVNCサーバー止めたらやみました。セキュリティがらみかその辺な感じですかね。ヒントは出たのでそのうち直せそうです。今はOIのVNCを止めてます。
Windowsのファイル共有をzfsのsharesmbにしていますが、ちょっと問題あるんですね。AndroidのESファイルエクスプローラーなどから見えないなど。SUNWsmbaでは普通に使えていたのでそっちに戻すかな～でもスナップショットが以前のバージョンから見えるのは便利だしな～で悩みどころ。
現在はESXi 5.0.0U3にしています。上記の問題も無く、PCIパススルーもちゃんと動いてます。やっぱりこの辺が一番安定しているようです。
導入方法は大体同じですが、ローカルストレージで追加したSATAカードを認識させるところで、ファイル名が異なります。
5.1では「/bootbank/sata_ahc.v00」ですが、
5.0では「/bootbank/sata-ahc.v00」です。
_と-が違います。
ESXiの外部データストアとしてRaspberryPiにNFSやらせ、ついでにファン制御もさせていましたが、データストアがローカルになったのでRaspberryPiも外しました。ファン制御は結局PICマイコンに任せてます。なんかず～っと遠回りしてスタート地点に戻ってきた感じですな(笑)NE555まで立ち戻ってはいないけど。
8ピンの12F683でデューティー比2～30％のPWM波形をソフトループで作ってるだけです。PWMの周波数が可聴域まで落ちてきましたが、コイル鳴きなどは無さそうです。
今後は温度センサとUSB-UART付けて回転数制御するかな～ぐらいは考えてますが、このままでも良いかも…（って思った時点で負けてるんですがｗ）
nwamdの大量エラーはVNCサーバー止めたらやみました。セキュリティがらみかその辺な感じですかね。ヒントは出たのでそのうち直せそうです。今はOIのVNCを止めてます。
Windowsのファイル共有をzfsのsharesmbにしていますが、ちょっと問題あるんですね。AndroidのESファイルエクスプローラーなどから見えないなど。SUNWsmbaでは普通に使えていたのでそっちに戻すかな～でもスナップショットが以前のバージョンから見えるのは便利だしな～で悩みどころ。
OpenIndiana設定メモ改 [PC]
改と言うほどでも無いですが、ESXi更新ついでにこちらも。
ちょっと変わったのでメモし直しです。
・「OpenIndiana 151a8 Desktop」にした（Xアプリが使いたくなった）。
・IP固定をnwamのままで行う（defaultにはしない）。
・zfsのsharesmbを使用（ACLがらみで敬遠してた）。
辺りが変更点です。
インストールは通常通り。isoをマウントしてブートすれば導入されます。DesktopにしてXが入ったことでサイズは増えてます。pkgなどのアップデート後は7～8GBほど消費します。ESXiの仮想ディスクをちょっと多めに作ります。
IPv4アドレスを固定にします。
終わったらpingやpkgを動かして設定が正しいか試します。
※現時点でpkg update, pkg image-updateを行うと、GNOMEのデスクトップがおかしくなります。私は元に戻しました。
追記：nwamdで大量エラー
nwamdで以下のエラーが大量に出てました。
前の設定方法
vncを有効にする。151a8デスクトップ版ではインストール済みなので設定だけです。
ユーザーの追加。
smb/cifsの設定。smbとcifsの違いとか、認証のルールとか正直よくわからんが動いてます。
pamの設定。
アクセス権限のところでACLが出てきて、自分には高度すぎて面倒なんですが、とりあえず
ファイルに標準で実行権限が付くのが…という場合は
共有フォルダとかに、所有者以外に権限を与える場合、
もちろん普通にowner,group,everyoneで権限切り分けることもできます。
けど家族数人とかなら個別に権限を管理してもそんなに手間では無いと思います。単純でわかりやすい気がするので自分はこちらでやってます。
NFSの場合はsharenfsをonにすればOKです。簡単。
iscsiはちょっと作業が必要です。
まずはファイル共有サーバーとしては動き出しました。sharesmbで共有してると、zfsで取ったスナップショットが、Windowsからはファイルのプロパティ、以前のバージョン、でアクセスできて便利です。
ちょっと変わったのでメモし直しです。
・「OpenIndiana 151a8 Desktop」にした（Xアプリが使いたくなった）。
・IP固定をnwamのままで行う（defaultにはしない）。
・zfsのsharesmbを使用（ACLがらみで敬遠してた）。
辺りが変更点です。
インストールは通常通り。isoをマウントしてブートすれば導入されます。DesktopにしてXが入ったことでサイズは増えてます。pkgなどのアップデート後は7～8GBほど消費します。ESXiの仮想ディスクをちょっと多めに作ります。
IPv4アドレスを固定にします。
# nwamcfg
nwamcfg> list
NCPs:
Automatic
Locations:
Automatic
NoNet
User
nwamcfg> select ncp Automatic Automaticを選択
nwamcfg:ncp:Automatic> list
NCUs:
phys e1000g0
ip e1000g0
nwamcfg:ncp:Automatic> select ncu ip e1000g0 e1000g0のIPを選択
nwamcfg:ncp:Automatic:ncu:e1000g0> list
ncu:e1000g0
type interface
class ip
parent "Automatic"
enabled true
ip-version ipv4,ipv6
ipv4-addrsrc dhcp
ipv6-addrsrc dhcp,autoconf
nwamcfg:ncp:Automatic:ncu:e1000g0> walkprop 変更開始
enabled (true) [true|false]>
ip-version (ipv4,ipv6) [ipv4|ipv6]>
ipv4-addrsrc (dhcp) [dhcp|static]> static 固定
ipv4-addr> 192.168.0.11 自機アドレス
ipv4-default-route> 192.168.0.1 デフォルトルート
ipv6-addrsrc (dhcp,autoconf) [dhcp|autoconf|static]>
ipv6-default-route>
nwamcfg:ncp:Automatic:ncu:e1000g0> list
ncu:e1000g0
type interface
class ip
parent "Automatic"
enabled true
ip-version ipv4,ipv6
ipv4-addrsrc static
ipv4-addr "192.168.0.11"
ipv4-default-route "192.168.0.1"
ipv6-addrsrc dhcp,autoconf
nwamcfg:ncp:Automatic:ncu:e1000g0> commit 変更を反映
「walkprop」で編集する時は変更が必要な項目だけ入力します。「commit」すると即アドレスが変更されるので、SSHなどで入っていた時は切断されます。再度接続してDNSを編集します。# nwamcfg
nwamcfg> list
NCPs:
Automatic
Locations:
Automatic
NoNet
User
nwamcfg> select loc Automatic Automaticを選択
nwamcfg:loc:Automatic> list
loc:Automatic
activation-mode system
enabled false
nameservices dns
nameservices-config-file "/etc/nsswitch.dns"
dns-nameservice-configsrc dhcp
nwamcfg:loc:Automatic> walkprop 変更開始
activation-mode (system) [manual|conditional-any|conditional-all]>
enabled (false) [true|false]>
nameservices (dns) [dns|files|nis|ldap]>
nameservices-config-file ("/etc/nsswitch.dns")>
dns-nameservice-configsrc (dhcp) [manual|dhcp]> manual マニュアルに
dns-nameservice-domain>
dns-nameservice-servers> 192.168.0.1 DNSサーバーアドレス(ルーター)
dns-nameservice-search>
nfsv4-domain>
ipfilter-config-file>
ipfilter-v6-config-file>
ipnat-config-file>
ippool-config-file>
ike-config-file>
ipsecpolicy-config-file>
nwamcfg:loc:Automatic> list
loc:Automatic
activation-mode system
enabled false
nameservices dns
nameservices-config-file "/etc/nsswitch.dns"
dns-nameservice-configsrc manual
dns-nameservice-servers "192.168.0.1"
nwamcfg:loc:Automatic> commit 変更を反映
Committed changes
同じく「walkprop」で変更していきます。終わったらpingやpkgを動かして設定が正しいか試します。
※現時点でpkg update, pkg image-updateを行うと、GNOMEのデスクトップがおかしくなります。私は元に戻しました。
追記：nwamdで大量エラー
nwamdで以下のエラーが大量に出てました。
nwamd[75]: [ID 234669 daemon.error] 3: nwamd_door_switch : need solaris.network.autoconf.read for request type 1検索してもいまいち意味がわかりませんでした。仕方ないので保留、physical:nwamを止めてphysical:defaultを使います。
前の設定方法
vncを有効にする。151a8デスクトップ版ではインストール済みなので設定だけです。
# vi /etc/gdm/custom.conf [security] DisallowTCP=false [xdmcp] Enable=true # svcadm enable xvnc-inetd # svcadm restart gdm # svcs | grep xvnc online 12:01:50 svc:/application/x11/xvnc-inetd:defaultこれでつながりますが、vncクライアントを終了させるとログインセッション以下、全て終了されてしまいます。
# svccfg -s xvnc-inetd svc:/application/x11/xvnc-inetd> editprop viが立ち上がるので、以下を編集、保存。 setprop inetd/wait = boolean: true svc:/application/x11/xvnc-inetd> exit # svcadm restart xvnc-inetdこの設定でvncを閉じてもログインセッションが維持されます。ただし、立ち上げっぱなしだとパスワード無しでいきなりつながるので、セキュリティ上は大問題でしょう。なにか設定はあると思いますが、今のところこのまま。
ユーザーの追加。
# useradd -u 1001 -g family -d /export/home/daresore -s /bin/bash -m daresore # usermod -R root daresore su可能にする場合
smb/cifsの設定。smbとcifsの違いとか、認証のルールとか正直よくわからんが動いてます。
pamの設定。
vi /etc/pam.conf other password required pam_smb_passwd.so.1 nowarnパスワードを与える。ユーザー毎に繰り返します。
# passwd daresore New Password: Re-enter new Password: passwd: password successfully changed for daresoreワークグループへ参加。
# smbadm join -w workgroup After joining workgroupthe smb service will be restarted automatically. Would you like to continue? [no]: yes Successfully joined workgroupzfsのプロパティを変更して公開。
# zfs sharesmb=name=daresore rpool/export/home/daresoreこれでまずは公開され、Windowsから見えます。
アクセス権限のところでACLが出てきて、自分には高度すぎて面倒なんですが、とりあえず
# chmod -R A=owner@:rwxpdDaARWcCos:fd:allow daresore
# ls -V
drwx------+ 9 daresore family 11 3月 18 02:47 daresore
owner@:rwxpdDaARWcCos:fd-----:allow
$ ls -l
./daresore : Permission denied ← 所有者とroot以外からは見えない。
と所有者に全権限継承有りを与えておくという手があります。まっ乱暴(笑)ファイルに標準で実行権限が付くのが…という場合は
# chmod A=\ owner@:rw-pdDaARWcCos:f:allow,\ owner@:rwxpdDaARWcCos:d:allow \ daresoreとするとファイルから実行権限だけ落ちます。
共有フォルダとかに、所有者以外に権限を与える場合、
user:family1:rwxpdDaARWcCos:fd:allow,\ user:family2:rwxpdDaARWcCos:fd:allowのようにユーザ指定で個別に権限付けるとか。
もちろん普通にowner,group,everyoneで権限切り分けることもできます。
けど家族数人とかなら個別に権限を管理してもそんなに手間では無いと思います。単純でわかりやすい気がするので自分はこちらでやってます。
NFSの場合はsharenfsをonにすればOKです。簡単。
iscsiはちょっと作業が必要です。
まずはファイル共有サーバーとしては動き出しました。sharesmbで共有してると、zfsで取ったスナップショットが、Windowsからはファイルのプロパティ、以前のバージョン、でアクセスできて便利です。
# cp /usr/lib/vmware-tools/configurator/X Free86-3/XF86Config /usr/lib/vmware-tools/configurator/XFree86-3/XF86_VMware
ML110 G7 ESXi導入改 [PC]
しばらく安定してましたが、機械の中の掃除(物理)を行うついでにちょっと構成変えてみます。
ESXi 5.5（U1含む）へのバージョンアップも試してみたのですが、SATAコントローラー（Intel Cougar）のPCIパススルーで問題が起きました。ESXiの設定からは一見パススルーできているように見えるのですが、ゲストからは謎のI/Oとされてしまいます。
ゲストのOIから見るとこんな感じ。
どうやらIOMMU周りに問題があるようで、VMwareでは「HPの最新ファームウェアを使うこと」的な記述が見えます。最新がどのバージョンなのかはわかりませんが。
現在の自機のファームウェアは
・System ROMが「07/01/2013」
・iLO3が「Jan 09 2014、1.70 」
で、これは現在HPのダウンロードから入手可能なものと同じです。しかし、HPはファームウェアなどの無償公開を止めてしまったので（個人の安サーバーで年間保守契約は無いよ…）これからの更新は期待できません。
これで動くESXiを選ぶことになります。全部は面倒なので一部だけ。パッチには手を出してません。
2014-03-11 | 5.5.0 U1 ×
2013-09-22 | 5.5.0 ×
2014-01-16 | 5.1.0 U2 ○
2013-04-25 | 5.1.0 U1 ×
上から試していってここまでです。ネットの情報を見ると、PCIパススルーは5.0の方がうまく動くという報告が多いみたいです。今回はとりあえず動いた5.1.0U2で行ってみます。インストール先はUSBメモリです。
※iLOが1.5の時は5.1.0U1が動いていた、ような気がする(笑)
Raspberry piのNFSサーバーをやめて、SATAボードを追加し、ローカルストレージに変更します。こちらの方が速くて安定するので…追加したSATAボードはこちら。
Asmediaチップです。wiki見るとMarvellとかの動作報告もありますね。
IntelのSATAコントローラーをパススルーさせるとSATAのドライバーが消えて、このボードもESXiから見えなくなります。ドライバとチップの対応テーブルを編集してSATAボードとして認識させます。手順はこちらのページの通りです。感謝。
クソゲ〜製作所
作業は全てESXiのSSHコンソールです。
デバイスのIDを調べます。
SATAのテーブルがあるファイルを展開します。
再起動でデータストアが使えます。Intel CougarはパススルーしてOpenIndianaに渡します。
ちなみに、OIネイティブから、上記SATAボード＋ちょっと古い64GB SSD（データストア）を追加して仮想化した事による消費電力のオーバーヘッドは+8Wぐらいでした。追加したハードウェア以上に増えているのは若干の処理増加分があるんでしょう。でも+8WでPCが複数台まとめられた、と考えるとお得だと思います。
ESXi 5.5（U1含む）へのバージョンアップも試してみたのですが、SATAコントローラー（Intel Cougar）のPCIパススルーで問題が起きました。ESXiの設定からは一見パススルーできているように見えるのですが、ゲストからは謎のI/Oとされてしまいます。
ゲストのOIから見るとこんな感じ。どうやらIOMMU周りに問題があるようで、VMwareでは「HPの最新ファームウェアを使うこと」的な記述が見えます。最新がどのバージョンなのかはわかりませんが。
現在の自機のファームウェアは
・System ROMが「07/01/2013」
・iLO3が「Jan 09 2014、1.70 」
で、これは現在HPのダウンロードから入手可能なものと同じです。しかし、HPはファームウェアなどの無償公開を止めてしまったので（個人の安サーバーで年間保守契約は無いよ…）これからの更新は期待できません。
これで動くESXiを選ぶことになります。全部は面倒なので一部だけ。パッチには手を出してません。
2014-03-11 | 5.5.0 U1 ×
2013-09-22 | 5.5.0 ×
2014-01-16 | 5.1.0 U2 ○
2013-04-25 | 5.1.0 U1 ×
上から試していってここまでです。ネットの情報を見ると、PCIパススルーは5.0の方がうまく動くという報告が多いみたいです。今回はとりあえず動いた5.1.0U2で行ってみます。インストール先はUSBメモリです。
※iLOが1.5の時は5.1.0U1が動いていた、ような気がする(笑)
Raspberry piのNFSサーバーをやめて、SATAボードを追加し、ローカルストレージに変更します。こちらの方が速くて安定するので…追加したSATAボードはこちら。
- 出版社/メーカー: エアリア
- メディア: Personal Computers
Asmediaチップです。wiki見るとMarvellとかの動作報告もありますね。
IntelのSATAコントローラーをパススルーさせるとSATAのドライバーが消えて、このボードもESXiから見えなくなります。ドライバとチップの対応テーブルを編集してSATAボードとして認識させます。手順はこちらのページの通りです。感謝。
クソゲ〜製作所
作業は全てESXiのSSHコンソールです。
デバイスのIDを調べます。
# lspci -v
0000:0d:00.0 SATA controller Mass storage controller: ASMedia Technology Inc. ASM1062 Serial ATA Controller
Class 0106: 1b21:0612
「1b21:0612」が必要な値です。SATAのテーブルがあるファイルを展開します。
/tmp # mkdir work /tmp # cd work/ /tmp/work # vmtar -x /bootbank/sata_ahc.v00 -o sata-ahc.tar /tmp/work # tar xvf sata-ahc.tar /tmp/work # rm sata-ahc.tarマップに1行追加。
/tmp/work # vi etc/vmware/driver.map.d/ahci.map regtype=linux,bus=pci,id=1b21:0612 0000:0000,driver=ahci,class=storage名前も追加。インデントはtabでした。
/tmp/work # vi usr/share/hwdata/driver.pciids.d/ahci.ids 1b21 ASMedia Technology Inc. 0612 ASM1062 Serial ATA Controller再アーカイブして保存。
/tmp/work # tar cvf sata-ahc.tar etc usr /tmp/work # vmtar -c sata-ahc.tar -o sata-ahc.vgz /tmp/work # mv sata-ahc.vgz /bootbank/sata_ahc.v00
再起動でデータストアが使えます。Intel CougarはパススルーしてOpenIndianaに渡します。
ちなみに、OIネイティブから、上記SATAボード＋ちょっと古い64GB SSD（データストア）を追加して仮想化した事による消費電力のオーバーヘッドは+8Wぐらいでした。追加したハードウェア以上に増えているのは若干の処理増加分があるんでしょう。でも+8WでPCが複数台まとめられた、と考えるとお得だと思います。
FlashAir + FAX （小ネタ）
久々ですがちょっとした小ネタなど。
FlashAir買いました。
本来の目的のデジカメに使うためですが、その前にちょっとSDHCカード対応のFAXに差し込んでみました。機種はPanasonicのおたくっすシリーズ。
事前に、こちらのページ（東芝）に従い、自分のSSIDの他、家のSSIDとパスワードを設定しておきました。FlashAirにワイヤレスで接続せずに、家のアクセスポイント経由でアクセスするとどうなるのかちと不明だったんですが、結論から言うと家のネットワークからアクセス可能でした。変なアクセス制限とかはかけてないみたいです。
FlashAir差し込んで、しばらくすると家のアクセスポイントにつながり、DHCPでアドレスもらってきます。同じネットワークの機器（有線でもOK）からブラウザでそのアドレスにアクセスすると、通常通りFlashAirの中身が見えます。このFAXではJPGで保存されてました。
これでFAXをネットワーク経由のPCで見られるようになりました。便利♪
インクリボンもったいないし、毎回印刷するほどの必要性もないし、あまり頻度は高くないのでFAXをネットワーク対応のものに買い換えるほどじゃないし、どうするかな～って思ってたんですが、これでも良いかな？小容量の買ってFAX専用にしてしまうのも。
ちょっと気になったのは消費電力が＋2～3W増えたこと。このカードサイズで常に2W喰ってたら熱々になりそうなので、本体側が増えたんだとは思いますが。
FlashAir買いました。
本来の目的のデジカメに使うためですが、その前にちょっとSDHCカード対応のFAXに差し込んでみました。機種はPanasonicのおたくっすシリーズ。
事前に、こちらのページ（東芝）に従い、自分のSSIDの他、家のSSIDとパスワードを設定しておきました。FlashAirにワイヤレスで接続せずに、家のアクセスポイント経由でアクセスするとどうなるのかちと不明だったんですが、結論から言うと家のネットワークからアクセス可能でした。変なアクセス制限とかはかけてないみたいです。
FlashAir差し込んで、しばらくすると家のアクセスポイントにつながり、DHCPでアドレスもらってきます。同じネットワークの機器（有線でもOK）からブラウザでそのアドレスにアクセスすると、通常通りFlashAirの中身が見えます。このFAXではJPGで保存されてました。
これでFAXをネットワーク経由のPCで見られるようになりました。便利♪
インクリボンもったいないし、毎回印刷するほどの必要性もないし、あまり頻度は高くないのでFAXをネットワーク対応のものに買い換えるほどじゃないし、どうするかな～って思ってたんですが、これでも良いかな？小容量の買ってFAX専用にしてしまうのも。
ちょっと気になったのは消費電力が＋2～3W増えたこと。このカードサイズで常に2W喰ってたら熱々になりそうなので、本体側が増えたんだとは思いますが。
最後のSONY製品
オーディオでちょっと思い出したので…
昔はSONY製品好きで、何かと買っていました。Walkmanシリーズはもちろん、MD関連とかグラストロンとか。VAIOも使ってたな～
SONY「だから」買ってみるか、みたいな所もありました。そしてこの製品。
MDR-DS5100
ホームシアターとかワイヤレスヘッドフォンなんてのが盛り上がった頃の高機能機種として出てきた製品です。気になってやっぱり入手してみました。
ところが
とりあえず光ケーブルでCDをつないでみたところ、アタックの入るところやsやthなどの摩擦音が入るとAGC（自動ゲイン調整）が強烈に入り、音量がばたばたしてとても聴いてて気持ち悪い製品でした。AGCが効くとサッと音量が下がり、数秒かけてゆっくり上がるというのを繰り返します。
これ現象をSONYのサービスに質問したところ「最近のCDは音量を高めに録音しているのでそういった現象が出る」という回答。「ダイナミックレンジと録音レベルは違う話なのでは？また、CD初期の1985年頃の頃の録音でも出るので時期は関係ないのでは？」と返したら「すぐに対策品を送るので元の本体を送り返して欲しい」と来ました。こちらから送り返す前に「対策品」が到着します。
到着した「対策品」にはアッテネータースイッチが付いていて、D/A変換後のレベルを下げるという物でした。結果再生側の音量を上げることになり、ヒスノイズが酷いことになります。
これは色々な意味で残念でした。
・まずは適当な対応（録音レベルの話）で反応を見る
・納得すればそれまで
・食い下がってきた人には素直に「対策品」を送る
というマニュアルができていたと考えられます。
私が購入したのはほぼ製品発売直後だったので、「対策品」は最初から用意されていたと考えるのが自然です。リアパネルのプリント自体はシールでしたが、綺麗に穴は空いてるし、アッテネーターのスイッチは基板に付いてて、パターンも引かれてます。手半田でリワークした跡はあり、アッテネータを有効にする作業を行ったのが「対策品」のようです。
つまり最初からこの製品はダメだとわかっており、クレームが来た顧客向けに回答と「対策品」を用意しておき、製品発売に踏み込んだ、と想像されます。
ダメだとわかった時点で製品化を見送れなかったのか、ユーザはこの程度か、好きだっただけに結構ショックで（今でも覚えてるぐらいですしｗ）、これ以降SONYの製品に興味が無くなってしまいます。嫌いになるならまだ救いがあったんでしょうが、好き・嫌いとは真逆の感情、無関心、になってしまったわけです。
PlayStationとかSONYの製品を持ってないわけではありません。けど、SONY「だから」買った、のはこの製品が最後となってしまいました。ちょっとしか使いませんでしたが、なんか捨てられず、15年目になった今も手元にあります。
昔はSONY製品好きで、何かと買っていました。Walkmanシリーズはもちろん、MD関連とかグラストロンとか。VAIOも使ってたな～
SONY「だから」買ってみるか、みたいな所もありました。そしてこの製品。
MDR-DS5100
ホームシアターとかワイヤレスヘッドフォンなんてのが盛り上がった頃の高機能機種として出てきた製品です。気になってやっぱり入手してみました。
ところが
とりあえず光ケーブルでCDをつないでみたところ、アタックの入るところやsやthなどの摩擦音が入るとAGC（自動ゲイン調整）が強烈に入り、音量がばたばたしてとても聴いてて気持ち悪い製品でした。AGCが効くとサッと音量が下がり、数秒かけてゆっくり上がるというのを繰り返します。
これ現象をSONYのサービスに質問したところ「最近のCDは音量を高めに録音しているのでそういった現象が出る」という回答。「ダイナミックレンジと録音レベルは違う話なのでは？また、CD初期の1985年頃の頃の録音でも出るので時期は関係ないのでは？」と返したら「すぐに対策品を送るので元の本体を送り返して欲しい」と来ました。こちらから送り返す前に「対策品」が到着します。
到着した「対策品」にはアッテネータースイッチが付いていて、D/A変換後のレベルを下げるという物でした。結果再生側の音量を上げることになり、ヒスノイズが酷いことになります。
これは色々な意味で残念でした。
・まずは適当な対応（録音レベルの話）で反応を見る
・納得すればそれまで
・食い下がってきた人には素直に「対策品」を送る
というマニュアルができていたと考えられます。
私が購入したのはほぼ製品発売直後だったので、「対策品」は最初から用意されていたと考えるのが自然です。リアパネルのプリント自体はシールでしたが、綺麗に穴は空いてるし、アッテネーターのスイッチは基板に付いてて、パターンも引かれてます。手半田でリワークした跡はあり、アッテネータを有効にする作業を行ったのが「対策品」のようです。
つまり最初からこの製品はダメだとわかっており、クレームが来た顧客向けに回答と「対策品」を用意しておき、製品発売に踏み込んだ、と想像されます。
ダメだとわかった時点で製品化を見送れなかったのか、ユーザはこの程度か、好きだっただけに結構ショックで（今でも覚えてるぐらいですしｗ）、これ以降SONYの製品に興味が無くなってしまいます。嫌いになるならまだ救いがあったんでしょうが、好き・嫌いとは真逆の感情、無関心、になってしまったわけです。
PlayStationとかSONYの製品を持ってないわけではありません。けど、SONY「だから」買った、のはこの製品が最後となってしまいました。ちょっとしか使いませんでしたが、なんか捨てられず、15年目になった今も手元にあります。
前の10件 | -
