linux一覧

クロス向けのgdbを用意する

前回はターゲット上で作成しましたが、今回は開発ホスト想定のUbuntu上でターゲット向けのgdbを準備します。
ここでのターゲットはARM(32bit)でEABIHF(hard float)を想定しています。まぁJetson TK1想定です。

※ Ubuntuではarm向けのツールチェインをインストール済みであるとします。apt-get等でインストールしておいて下さい。

まずはxmlで必要になってくるので expat をインストールしておきます。

sudo apt-get install libexpat1-dev

gdbを本家サイトからダウンロードしてきて、展開します。また、buildディレクトリを作ってmake作業を行います。
他のユーザーに影響を与えないようにするため、 ホーム以下の host-tools にインストールされるようにしてみました。

$ tar xzf tar gdb-7.8.tar.gz
$ mkdir gdb-7.8/build
$ cd gdb-7.8/build
$ ../configure 
 --prefix=/home/appuser/host-tools \
 --target=armv7l-unknown-linux-gnueabihf \
 --with-expat --disable-nls \
 --disable-sim --disable-install-libbfd \
 --program-prefix=arm-linux-gnueabihf-

ここで –with-expatをつけてmakeしないと、XML読み込めていないエラーが発生するようです。
これをつけない場合、下記にしめすようなエラーが一緒に消えました!

Remote 'g' packet reply is too long:
09ea1180ffffffff009500000000000000000000000000000000100000000
(ゼロの連続なので省略)

このエラーはリモートのgdbserverに接続した際に出ていたものです。
gdbが用意できたことで、Ubuntu環境の中からgdbでデバッグすることが可能になりました。


gdbをターゲットでビルドしてみた

先日のARM開発環境をというネタからの流れではあるものの随分と手こずっています。手こずっているのはgccやglibcなどの
クロス環境のツールチェインのmakeでして、今のところ失敗の連続です。
 それで寄り道をして gdbserver をmakeしてみようと思います。ターゲット環境で gcc が使用可能な状態であることが条件です。幸いにして、Jetson TK1 は最初からgccが使用可能で、gdbもあるのであまりこの必要性は感じませんが、gdbserver を用意しておくことは開発時において貢献してくれそうです。

準備

gdb(gdbserver)だけではコンパイルできないので依存関係にある物をインストールしておきます。

$ sudo apt-get install texinfo
$ wget http://ftp.gnu.org/gnu/gdb/gdb-7.8.tar.gz
$ wget ftp://ftp.gnu.org/gnu/termcap/termcap-1.3.1.tar.gz

$ tar xzf termcap-1.3.1.tar.gz
$ tar xzf gdb-7.8.tar.gz

$ cd termcap-1.3.1
$ mkdir build
$ cd build
$ ../configure
$ make
$ sudo make install
$ cd ../..

コンパイルとインストール

gdb(gdbserver) をmakeします。

$ cd gdb-7.8
$ mkdir build
$ cd build
$ ../configure --prefix=/home/ubuntu/tools/debugger
$ make
$ make install

/home/ubuntu/tools/debugger/bin/gdbserver の場所にインストールされます。都合が悪い場合には prefixの値を変更して下さい。

動作テスト

別のUbuntu環境で arm linux eabihf対応の gdb を用いて、gdbserver に接続して動作確認をします。
手っ取り早くやるためには、UbuntuでLinaro gcc-linaro-arm-linux-gnueabihf-4.7 をダウンロードして展開し、この中のgdbを使用しました。
他にも
sudo apt-get install gcc-arm-linux-gnueabi
sudo apt-get install gcc-arm-linux-gnueabihf

とかやったのですが、うまく対象の gdb をいれることができなかったためです。
また、linaroのパッケージの物が 32bit のものだったので、下記のコマンドを入力して 32bit のものが動作するようにしています。

sudo apt-get install lib32z1 lib32ncurses5 lib32bz2-1.0

これら、昔は apt-get install ia32-libs でインストールしていましたが、今(14.04)は上記のようにやるような感じでした。

今回のターゲットは Jetson TK1 だったのですが、無事にホストPCからgdbコマンドを実行しつつ、ソースコードデバッグができるところまでを確認しました。
注意点としては、当然ですが EABIのgdbではうまく動作しません。ターゲットのABIにあわせたシロモノが必要になります(だから今回はEABIHF となっています


クロスコンパイラgccのビルドがうまくいかない

ARMターゲットのプログラムをコンパイルするための、クロスコンパイラを自前でmakeしようと試行錯誤していますがうまくいきません。色々と調べてみて、1つ解決したかと思えば次また止まり、最終的にできあがったコンパイラでは正常に実行できるelfが出来上がらずといったところです。
折角なので、やってみたことを記録として残しておこうと思います。これでも誰かの参考になったら幸いです。

その1

gmp
mpfr
mpc
gcc
binutils
newlib

これらを用意してmakeしていきます。
gmp,mpfr,mpcらがgccで必要とするらしく・・・。またこれら出来上がった場所を LD_LOAD_LIBRARY に追加して soを参照できるようにしてみました。
というのも、gccのmake過程で GCC_NO_EXECUTABLES エラーがでてしまい・・・解決するかと思ったのですが。so解決しても結局解消することは不可能でした。また –disable-dlopenも試してみたのですがこれもまたNG

その2

export TARGET=arm-eabi
export PREFIX=/usr/local/gnu
configure –prefix=$PREFIX –target=$TARGET –enable-interwork –enable-multilib –enable-languages=c –with-newlib –disable-shared –disable-thread –without-headers –disable-libssp

これでgccを makeしてみるとうまくいった.ただし期待したシロモノができない。
理由は arm-eabi だったから。今ほしいのは eabihf の ABI
arm-linux-gnueabihf をターゲットとしてmakeさせると、エラーが発生。GCC_NO_EXECUTABLES 問題解決できず終了。

その3

どうやら gccのコンパイル過程で makeinfo が問題となっているよう。
apt-get install texinfo で makeinfo も片付くが、バージョンが問題になっている模様。新しいバージョンだとgccのmake過程でエラーが発生してしまう。
そこで、 makeinfo のバージョンを 5.0未満にすべく、古い物をソースからインストールしてみた。4.13あたりでチャレンジした。
これでgccのmakeはうまくいくようになるが、別の問題が発生。

arm-linux-gnueabihf のABIでパッチ当てたりしてmakeしてみるものの 失敗。armアセンブラが解釈できない何かでglibcの生成で失敗。
なお、 http://keropo.hatenadiary.com/entry/2013/04/14/232244 を参考にして eabi ならばうまくgccが生成できるところまではこぎ着けた。すごく参考になりました。

まとめ

クロスコンパイラgccを準備するのは非常に大変。
外部から提供される or 同梱されているならばそれを使うのが吉です。自力で用意してやろうとか欲を出すと、これに相当時間を取られそうです。
とはいえ、あまりにあまりな結果だったので他の方法もまだ探してみたいと思います。


NVIDIAドライバのインストール(Ubuntuにて)

Ubuntuで NVIDIA からドライバダウンロードしてきて最新版を追いかける人向けの内容です。今回は NVIDIA-Linux-x86_64-331.49 ドライバを用いての内容です。作業開始前にドライバはダウンロードしておきましょう。

まず Xサーバー関係の開発用パッケージのインストールをしておきます
sudo apt-get install xserver-xorg-dev

/etc/default/grub を開いて、GRUB_CMDLINE_LINUX_DEFAULT の行を編集

sudo grub-mkconfig -o /boot/grub/grub.cfg を実行

Xサーバーの停止
sudo /etc/init.d/lightdm stop

ここから ssh でつないでコンソールで作業.

このような結果になったらパッケージを削除していきます。

sudo apt-get --purge remove xserver-xorg-video-nouveau
sudo apt-get --purge remove nvidia-319 nvidia-common nvidia-settings-319

システムを再起動します。
再起動後再び Xサーバーを停止します。
sudo /etc/init.d/lightdm stop

再びコンソールでの作業をしたいので ssh 経由で作業します。
ここの段階までにNVIDIAからドライバをダウンロードしておいてください。

ダウンロードしたファイルの場所で、下記コマンドを実行します.

sudo sh NVIDIA-Linux-x86_64-331.49.run

Verifying archive integrity... OK
Uncompressing NVIDIA Accelerated Graphics Driver for Linux-x86_64 331.49..........................................

インストールを手順に沿って進めた後、再起動します。

インストール後うまくXが起動したら、NVIDIA X Server Settings を開いてみます。
(これは検索してみつけます)
いわゆるNVIDIAコントロールパネルですが、これでインストールしたドライバになっているかどうか確認して下さい。


LinuxをクライアントでOpenVPN

結局OpenVPNに戻ってきました。
L2TPより遙かに自分には扱いやすいです・・・。また以前はWindowsをクライアントとしてLinuxサーバーにOpenVPNを入れていたのですが、今回はLinuxをクライアントとして設定する方法にチャレンジしてみました。

続きを読む


LinuxクライアントでL2TP

L2TPについてLinuxをクライアントとして用いて接続を行ってみました。Windowsをクライアントとする場合、OS標準でサポートしているため単なる設定を行えばつながるようなので。

なお、サーバーは手軽にSoftEtherのオープンソース版で実験してみました。

続きを読む


久しぶりにVPN

ずいぶんと久しぶりにVPNの勉強(補強)をしています。以前はIPSecサーバーを立てて、自分で拠点間接続をしたところで満足して、その先に進むことをしませんでした。

あれからずいぶんと経って、今はL2TPやSSTPといったものが出現しています。これらについて、ちょっと勉強をしてみようと思っています。ひとまずは L2TP が良さそうな感じです。何より現時点においてはAndroidやiPhoneでも使用することができるようになっていると聞きます。


KVMでデバイスパススルー その4

PT2で実験中

PX-W3PEで仮想マシン内録画でさんざんな結果でしたが、
PT2ではどうなんだろうとおもってテストしてみました。
今までの環境構築テストで、録画自体はスクランブル解除なしでうまくいっていたというところまで確認は出来ていました。

結果

PT2の場合は、CPU使用率は低く抑えられた。
ピークで20%も使わないくらい。
W録画時にもこのような状況で、パケットのドロップは発生しなかった。

こういう状況なので、この仮想マシンにBCASカードリーダーを接続させ、
スクランブル解除までやらせてみた。
その結果もまた優秀でW録画時かつデコードありで、
CPU使用率は相変わらず低いままであった。

まとめるとPT2のほうが機器として良くできているということじゃないかと思う。
仮想マシンで録画ということを考えると、PT2は使える!ということになると思う。


KVMでデバイスパススルー その3

途中報告

確かにFedora14の環境下でKVM(0.13)を使うと、
デバイスパススルーの機能を用いて仮想マシン内で録画を行うことが出来た。

  • PT2
  • PX-W3PE

上記の2ボードで試してみたが、どちらでもひとまず録画が出来ることが確認できた。
すばらしい・・・。

ただ現時点では安定動作出来るかどうかは確認できていない

実験中1 (PX-W3PE)

PX-W3PEのほうが情報が少ないので、ネットに晒してみます。
どうも仮想マシン内で録画の際にCPU使用率が高い。
シングル録画時で30~50%ほど。W録画中では75~80%ほど。

しかもこれはスクランブルのデコードをしない状態でである。

スクランブルのデコードをした場合にはまず確実にドロップが発生する。

一応PX-W3PEのドライバ設定で、レジストリを変更しています。
・自動ゲインコントロール(ブースタ)
・内部ブースターの値は適当に0x0aあたり

このような状況のため、このボードの仮想マシン内録画は
デコードなし、シングル録画限定、
という制限を設けて使うのが精一杯かもしれない。

BonCasLink

別環境に用意したBCasLinkServiceに接続して、デコード処理をやらせる感じにしたらブルースクリーンが出たり、ドロップ多発したり色々発生した。

現時点の状態では、使用しない方が賢明。

W録画

どうにも安定して長時間録画できない。
シングル録画のみの使用に限定した方がいいかも。


KVMでデバイスパススルー その2

どうもネットを検索すると、KVMでデバイスパススルーを設定し、
仮想環境(ゲストOS)で録画出来ている、なんていう記事を見かけます。手元の環境では、録画できているけど常用できない、という状態なので、
他の人のうまくいっている環境は常用できるという点に着目して、
真偽を確かめてみたいなと思います。

うまくいく環境とは?

うまくいっている人の多くは、Fedoraを使用している。
CentOSでの報告もあるけど、Fedoraが多い傾向にある。

また、GUIでの設定で終わりという記載はあまりみない。
できた~という人はGUIで設定して終わっているようだが、きちんと記事にしている人は、コマンドラインでKVMのゲストを起動しているようにみえる。

デバイスはPT2を使用している。
他のPT1やPX-W3PEでうまくいっているという話を見ない・・・。
入手性の問題なのだろうか。あるいは、うまく動作するのがこれだけなのか。

調査方針

うまく行く率が高いFedoraをインストールしてみる。
KVMはOSインストール時には入れずに、後から導入する感じで。

デバイスパススルーできるKVMにもうまくいくバージョンがありそうなので。