HP ProLiant ML310e Gen8 v2にUbuntu Server 14.04LTS

職場のオフィス内サーバーをそろそろリプレースしないとな、というのでHP ProLiant ML310e Gen8 v2を購入してもらって、Ubuntu Server 14.04LTSをセットアップしたりしています。

いくつか気づいた点などあったので、ブログに書いてみようと。

トルクスドライバーが付いてない

HPのサーバー(MicroServerなども)では、HDDの固定にネジ穴が星形のネジが使われています。以前はL字型のトルクスドライバーがサーバーに付いてたのですが、ML310e Gen8 v2からは付いてないそうです。

HPのサポートページに「注意：一部の ProLiant Gen8 サーバー - HP ProLiant Gen8 サーバーからの T-10/T-15 トルクスドライバー工具の除去」と説明されています。

結局、トルクスドライバーを購入しました。

HDDの取り付けはT-10というサイズのトルクスネジでした。トルクスネジはネジ穴中央に突起があるパターンもありますが、サーバに使われているのは突起無しでした。

RAIDコントローラー

HP Dynamic Smartアレイ B120i コントローラーというのが搭載されています。結局は、IntelのチップセットのRAID対応機能をベースにしたものらしいのですが、BIOSの初期設定では、Ubuntuは起動できないようです。

サポートページをあさったところ、RHELやSuSEでは、ドライバが提供されるようなのですが、Ubuntuなどではサポートされないようです。というので、BIOSでB120iコントローラーの動作モードを非RAIDなAHCIモードに設定すると、Ubuntuも動くようになりました。

LPC15xxのSCT(2)

その後もLPC15xxのSCT (State Control Timer)についてアプリケーションノートなども見て考えましたが、結局、やりたいことは実現できそういないかな、というのが今の結論です。

結局、一番やりにくいのが
「ソフトウェアからイベントのトリガを生じさせられないのでは？」
という点です。見落としているのかもしれませんが…。

変則な手としては、ソフトウェアからGPIOに出力し、SWM (SWitch Matrix)経由でSCT inputに信号を入れる、というのができるかもしれません。感覚としては、何かな～、というところです。

デューティ比を更新すること自体は、reload register (別のマイコンだとshadow registerって言うのかも)があって、割り込みなど連動させてうまくreload register更新していけば、デューティ比更新していけそうです。これは、cookbookにもサンプルがありました。

そんな感じで、最近は横道にそれて、他のマイコン(dsPICとか)ではどうか?とあちこちデータシートをつまみ食いして回ったりしてます。

LPC15xxのSCT(1)

考えとかまとまってないですが、たまにはブログ更新しようかなというので、メモ的な内容です。

最近、NXPのマイコンLPC15xxのSCT (State Control Timer)をいじってみています。ひとまずの実機はLPCXpresso 1549です。

SCTは1個で出力10chあって(Largh SCTの場合)、かなり複雑な信号生成ができそうです。電源制御やモーター制御の場合、3相で6ch、ブレーキなどがあっても7chで足りることが多そうなので十分そうです。

が、私が以前仕事で作ったのは12ch以上必要で、そういう場合はSCT 1個では足りないので2個以上を同期連動させることになりそうです。電源制御などでは、単にchごとのデューティ比がそろっていればいいのではなく、各chが同期している必要があるので考慮が必要です。厳密にいうと

• 運転開始時の信号の挙動がきっちり決まること
• 運転中にノイズなどによっても信号の位相がずれないこと
• 運転停止時の信号の挙動がきっちり決まること

といったことが求められます(私が関わったのは試作品だったので、実際の製品だともっと厳しいかもしれませんが)。

その仕事の時は別のマイコンを使っていたのですが、複数のPWMモジュールを同期させる仕組みがきっちりしていたので、若干のひねりは必要でもユーザーマニュアルやアプリケーションノートを見れば実装できました。

LPC15xxのユーザーマニュアルやSCT関連のアプリケーションノートをあたった限りでは、複数SCTの同期についてドンピシャな説明は見当たりませんでした。SCTの場合、SCT0とSCT1でカウンタを同期させるという説明は無かったですが、SCT0とSCT1間での信号接続はあるので、それを使って同期させるのかなと考えています。ユーザーマニュアルによれば下図のような接続関係があるようです(UM10736 "LPC15xx User manuarl"より引用)。

そこら辺から考えて、以下のような方法でいいのではないかなと (まだ実機で試してはいませんが)。

• SCT1のHALTはソフトウェアで解除しておいてSTOP状態にしておく
• SCT0からカウンタクリアされる時にSCT1にパルスが出るようにしておく(SCT0のイベント2つ使う?)
• SCT1ではSCT0からの信号でSTARTするようにしておく（SCT1のイベント1つ使う)
• SCT1でSCT0からの信号とSCT1カウンタがずれたらエラーとして止まるようにしておく(SCT1のイベント1つ使う)
• SCT1でエラー検出したら割込か制御信号経由でSCT0も止める

運転開始時はSCT0に対してSCT1が1周期だけ遅れそうですが、制御信号の振り分けを選んで、ソフトスタートにすれば対処できるかなと。

いずれにしても、もちょっとドキュメント読み込んで実機でも試してみないとな、というところです。

PWM信号だけなら、FPGA使えば10chでも20chでも簡単に出せるのですが、A/Dとか通信とかの総合的な部分ではマイコンがやりやすいので、LPCの系列で実現できればmbedなどとの絡みでも良好かなと。

GNU Screenの日本語表示ズレ

ブログが放置状態なので、何か書こうかなというので、GNU Screenの日本語表示ズレについてです。

Putty + Screen + Vimで日本語を表示していると、表示がずれることがあります。

具体的には以下のような文字が含まれる行を編集したりコピーペーストしたりした場合です。

×÷○□※

調べてみると、どうもScreenに問題があるようです。

ちなみに各ソフトウェアのバージョン・設定等を抜粋するとこんな感じです。

• Putty
• バージョン: 0.63-jp20130916
• リモートの文字セット: UTF-8(CJK)
• CJK用の文字幅を使用する: Off
• 端末タイプを表す文字列: xterm-256color
• リモートPC
• CentOS 6.5 (x86_64)
• $LANG: ja_JP.UTF-8
• GNU Screen
• yumでインストールした screen.x86_64 0:4.0.3-16.el6
• screen -Uで起動
• Vim
• yumでインストールしたvim-enhanced-7.2.411-1.8.el6.x86_64
• ~/.vimrcでset ambiwidth=double

特にPuttyのUTF-8(CJK)というのと、Vimのambiwidth=doubleはこう設定していないと、上記以外の文字("～"など)でも表示に影響が出るようです。

それでもズレるというので、これまでは表示がずれたらCtrl-lで再描画させて凌いでいたのですが、ふと気になって調べて対策してみました。

ズレですが、FreeBSDでは起こらなくて、CentOSでは起こるというのの気がつき、FreeBSD Portsに含まれているopt-cjkwidthというパッチが効きそうというのが分かりました。

それで、手動でパッチをあててビルドしたら解決かと思いきや、CentOS上でScreenがconfigure & makeではビルドできず、手間がかかりました。

さらに調べてみると、yumでインストールされるパッケージは、素のscreen-4.0.3にいくつかパッチが適用されてビルドされているようです。ということで、最終的には以下の手順でビルド・インストールしました。

1. ScreenのSRPMパッケージをダウンロード、インストール
2. opt-cjkwidthパッチをコピー
3. SPECファイルを変更
4. RPMパッケージを作成
5. 前から入っているScreenをアンインストール
6. 生成したRPMパッケージから修正版Screenをインストール

詳細な手順は以下のようになりました。

ScreenのSRPMパッケージをダウンロード、インストール

手っ取り早くwgetでダウンロードし、rpmコマンドでインストールします。

wget 'http://vault.centos.org/6.5/os/Source/SPackages/screen-4.0.3-16.el6.src.rpm'
rpm -ivh screen-4.0.3-16.el6.src.rpm

一般ユーザ権限で実行して、~/rpmbuild/にファイルが展開されます。

opt-cjkwidthパッチをコピー

FreeBSDの/usr/ports/sysutils/screen/files/opt-cjkwidthを~/rpmbuild/SOURCES/にコピーします。
手元にFreeBSD PCが無くても、Web上からopt-cjkwidthパッチは取ってこれると思います。

SPECファイルを変更

~/rpmbuild/SPECS/screen.specを編集します。

opt-cjkwidthパッチを適用するように他のパッチを真似て以下2行を追加します。

Patch15: opt-cjkwidth
...
%patch15 -p0 -b .cjkwidth

他のパッチはほとんどが-p1となっていますが、opt-cjkwidthは-p0にします。

RPMパッケージを作成

rpmbuildコマンドでビルドを行いRPMパッケージを作成します。

rpmbuild -bb ~/rpmbuild/SPECS/screen.spec

必要なパッケージが足りない場合はエラーメッセージが出ますので、パッケージをインストール後に再度rpmbuildコマンドを実行します。私の場合は以下のように不足パッケージをインストールしました。

sudo yum install ncurses-devel pam-devel libutempter-devel texinfo

ビルドできると~/rpmbuild/RPMS/x86_64/screen-4.0.3-16.el6.x86_64.rpmができています。

前から入っているScreenをアンインストール

yumでインストールしたScreenをアンインストールします。この作業が必要なのかよく分かっていませんが念のため。

sudo yum remove screen

生成したRPMパッケージから修正版Screenをインストール

以下のようにrpmコマンドで作成したRPMパッケージからScreenをインストールします。

sudo rpm -ivh ~/rpmbuild/RPMS/x86_64screen-4.0.3-16.el6.x86_64.rpmd