コグノスケ

レジスタダンプ、書き換えツールmemaccess

ツールのソースコードは GitHubに置いています。

前職のころレジスタダンプと、レジスタ値書き換えのためのfaという素敵なアプリ（Free Accessの略と聞いた）を使っていました。

このアプリは、/dev/mem経由でメモリの指定したアドレスを読んだり書いたりできるアプリです。何だそんなもの……と思うかもしれませんが、低レイヤデバッグには便利でして、開発の皆さんが愛用していたことを覚えています。

オリジナルのfaはデカくて無駄の多いコードだったので、何年か前に全部捨てて書き直しました。さらに他の人が書き直していなければ、今も使われているのではなかろうか？

現職とレジスタダンプ

なんと転職後もレジスタダンプが必要なシーンによく遭遇します。半導体の仕事と低レイヤデバッグは切っても切れない関係みたいです。

最初はカーネルドライバを書いてreadlで読んで、printkして…、などとやっていましたが、あまりにも面倒くさくてやってられません。やっぱりfaのようなものが欲しいなあと思い立ち、土日でパパパーっと書いて、GitHubに放り込んでおきました。

アプリの実装は /dev/memをmmapして読み書きするだけで、特に知識も要りません。たぶん誰でも書けます。

アプリの名前ですが、Free AccessだとWi-Fiスポットみたいで変だな……と思って、ma（memaccess, memory accessの略）にしておきました。memory dumpにしたかったのですが、有名なツールと同じ名前で紛らわしいのでやめました。

もしmemory dumpでレジスタ読み書きができれば、わざわざアプリを作る必要はなかったのですが、しかしmemory dumpはバイナリで出力する方に重きを置いており、エディト機能もなさそうで、設計の方向性が違いました……。残念。

初めてのOpenVX on ARM

目次: OpenCL

先日（2018年11月14日の日記参照）動かしたOpenVX + OpenCVのデモをAArch64上でも動かそうと思います。クロスコンパイルではなくARM上でセルフコンパイルします。環境はDebian 9、ボードはROCKPro64です。

ビルド

前回同様OpenVXライブラリをビルドする必要がありますが、単純にmakeするとビルドに失敗します。

[GCC] Compiling C99 vx_debug.c
gcc: error: unrecognized argument in option '-mabi=aapcs-linux'
gcc: note: valid arguments to '-mabi=' are: ilp32 lp64
gcc: error: unrecognized command line option '-mapcs'; did you mean '--specs'?
gcc: error: unrecognized command line option '-mno-sched-prolog'; did you mean  -Wno-sign-promo'?
gcc: error: unrecognized command line option '-mno-thumb-interwork'; did you mean '-fno-sched-interblock'?
concerto/finale.mak:289: recipe for target '/home/katsuhiro/projects/openvx/out/LINUX/aarch64/release/module/debug/vx_debug.o' failed

Makefileに不要なオプションが指定されていてビルドが失敗しているようなので、削除します。

diff --git a/concerto/compilers/gcc.mak b/concerto/compilers/gcc.mak
index aca2556..0295e39 100644
--- a/concerto/compilers/gcc.mak
+++ b/concerto/compilers/gcc.mak
@@ -125,9 +125,9 @@ endif
 endif

 ifeq ($(TARGET_FAMILY),ARM)
-$(_MODULE)_COPT += -mapcs -mno-sched-prolog -mno-thumb-interwork
+#$(_MODULE)_COPT += -mapcs -mno-sched-prolog -mno-thumb-interwork
 ifeq ($(TARGET_OS),LINUX)
-$(_MODULE)_COPT += -mabi=aapcs-linux
+#$(_MODULE)_COPT += -mabi=aapcs-linux
 endif
 endif

ちなみにcmakeによるビルドも可能ですが、ARMに対応できていないように見えます。

diff --git a/cmake_utils/CMake_linux_tools.cmake b/cmake_utils/CMake_linux_tools
.cmake
index caaa017..dc2371f 100644
--- a/cmake_utils/CMake_linux_tools.cmake
+++ b/cmake_utils/CMake_linux_tools.cmake
@@ -32,10 +32,10 @@ if(BUILD_X64)
 else()
   if (TARGET_CPU STREQUAL "Atom")
     # architecture will be according to ATOM
-    set(ARCH_BIT -m32 )
+    # set(ARCH_BIT -m32 )
   else ()
     # need to force a more modern architecture than the degault m32 (i386).
-    set(ARCH_BIT "-m32 -march=core2" )
+    # set(ARCH_BIT "-m32 -march=core2" )
   endif (TARGET_CPU STREQUAL "Atom")
 endif()

正しい直し方ではありませんが、とりあえずx86向けの設定を改造して、x86用のオプションを外すとビルドが通ります。

サンプルのビルド

OpenVXライブラリのビルドが通ったら、サンプルをビルドします。

$ cd openvx_tutorial/tutorial_exercises/solution_exercise1
$ g++ -I ../include -L /path/to/openvx/out/LINUX/aarch64/release/ solution_exercise1.cpp \
  -lopencv_imgproc -lopencv_highgui -lopencv_core -lopenvx

もしcmakeでライブラリを作った場合は、ライブラリの生成先ディレクトリが異なります。下記のようにします。

$ cd openvx_tutorial/tutorial_exercises/solution_exercise1
$ g++ -I ../include -L /path/to/openvx/build/sample/framework/ solution_exercise1.cpp \
  -lopencv_imgproc -lopencv_highgui -lopencv_core -lopenvx

実行する際は、HDMI出力などのGUI画面に表示してもよいですし、vncserverなどの画面にも表示できます。下記の例はvncserverに表示する例です。

$ DISPLAY=:1 \
  LD_LIBRARY_PATH=/path/to/openvx/out/LINUX/aarch64/release/ \
  ./a.out

もしcmakeでビルドしたライブラリを使う場合、ライブラリがバラバラのディレクトリに置かれているため、LD_LIBRARY_PATHに指定するパスがやや長くなります。

$ DISPLAY=:1 \
  LD_LIBRARY_PATH=/path/to/openvx/build/sample/framework/:/path/to/openvx/build/sample/targets/c_model/:/path/to/openvx/build/sample/vxu/:/path/to/openvx/build/libraries/extras/:/path/to/openvx/build/libraries/debug/ \
  ./a.out

もしcmakeでビルドしたライブラリでトラブルが起きたときは、cmake -DCMAKE_BUILD_TYPE=RelWithDebInfoと指定してデバッグ情報を有効にしてビルドすることで、デバッグしやすくなります。

VNCとOpenCV

TightVNCサーバーを使うとアプリケーションの実行時に下記の警告が出ます。

Xlib:  extension "RANDR" missing on display ":1".

警告が出ても動作はするのですが、気になる方は下記のようにTigerVNCをインストールするなど、RANDRに対応したVNCサーバーを使ってください。

# apt-get install tigervnc-standalone-server

たまにズレちゃうWindows 10

目次: Windows

Windows 10は自動的にWindows Updateを実行し、勝手にPCを再起動することがあります。その際にウインドウの幅がズレることがあります。

タイトルバーとウインドウの幅がずれる

ウインドウの幅が多少ズレても実用上害はありませんが、この状態と同時に発生する、フォント表示がボヤボヤになって、サイズがおかしくなり、非常に読みづらくなる症状が辛いです。目が痛くなってきます。

いずれの症状もPCを再起動すると直ります。直る理由すらわかりませんが、今のところ直らなかったことは一度もありません。

不思議なことにWindows Update後に必ずズレた状態になる訳ではなく、何か他の条件があるようです。人が見ていない夜中に再起動して、勝手にこの状態にハマるので、詳細は確認しようがないです。

我が家でのWindowsの存在意義

最近のWindowsは再起動により、作業中のアプリケーションが全て終了され、当初かなりイライラしていました。

しかし今は「Windowsで大事な作業をしない」ことにより、諦めがつきました。デスクトップPCは勝手に再起動されては困るので、Windowsごと消しました。さようなら〜。

ノートPCは再起動されても特に問題ないのでWindowsを残しています。なぜなら最近Windows上で実行しているアプリケーションは、

ブラウザ

強制終了されても最後に開いていたページを覚えている。

VNCクライアント

強制終了されてもLinuxマシンが動き続けているので問題ない。

しかないからです。あとは、たまに音楽プレーヤーやSteamを起動しますが、起動しっぱなしにはしません。たとえ強制終了されたとしても問題はありません。

この使い方はほぼシンクライアントですね。わざわざカスタムオーダーまでしてCore i5-8250と外部グラフィックスAMD Radeon RX550を積んだのに、彼らがSteam以外で活用されることはありません……。

つまり、もっとゲームをやりなさいということだな？？

ROCKPro64とPCI Express - 動作せず

目次: ROCK64/ROCKPro64

ROCKPro64にはPCI Expressスロットが実装されています。せっかくあるので試そうと思い、玄人志向のSATAインタフェース増設カード（SATA3-PCIE-E2）と、USB 3.0インタフェース増設カード（USB3.0R-P2H2-PCIE）を買いました。

結論から先に言うとRK3399のPCI Expressコントローラは有効にできましたが、ROCKPro64の信号品質が良くないのかUSBのカードしか認識しませんでした。残念です。

唯一認識されるUSBのカードもPCI Expressのライザーカードで延長すると認識しなくなります。認識できるギリギリの信号なんですかね。

rockchip-pcie f8000000.pcie: PCIe link training gen1 timeout!

認識されないときはこんなエラーログが出ています。うーん。

有効にするだけでは動かないRK3399のPCI Expressコントローラ

RK3399のPCIeコントローラもちょっと癖があって、ep-gpiosプロパティを指定しないとprobe時にエラーで落ちます。このドライバはGPIOを使ってレギュレータを操作し、PCI Expressへの電源供給を制御したいようです。

通常、デバイスドライバで電源制御を実装したい場合vpcie12v-supplyのようなレギュレータを指定するプロパティを使いますが、なぜGPIOを使っているのでしょうね……？

しかもうまくないことにROCKPro64の場合、既にPCI Express用レギュレータのデバイスノードが定義されており、常にPCI Expressの電源をONにしています。そのためPCI ExpressのデバイスノードにGPIOを追加すると「もう使われているよ！」と怒られてしまいます。

どう直すのが正しいのかわかりませんが、とりあえずPCI Expressのドライバを改造し、GPIOのエラー処理を削ったら先に進みました。しかし良くハングするようにもなりました。イマイチだ……。

後日、直すことができました（2019年5月9日の日記参照）。

メモ: 技術系の話はFacebookから転記しておくことにした。追記した。

ROCK64のUSBをデグレさせた

目次: ROCK64/ROCKPro64

昔、私が投稿したパッチがLinux 4.20をデグレさせていました。Linux 4.20以降ではROCK64のUSBが動かなくなっています。全然気づきませんでした……。

Arch Linuxの人たちが「動かねーぞ？？」とハマった挙句（リンク）に、指摘してくれたようです。

反省を込めて、ROCK64がデグレした理由をまとめておきます。

当時、私が直したのはピンに出力する信号の割り当て設定です。

GPIO0 A2

• 本来の出力: USB電源供給Enable/Disable信号
• 当時の出力: 何も割り当たっていない（が、なぜか動いていた…）

GPIO0 D3

• 本来の出力: S/PDIF信号
• 当時の出力: USB電源供給Enable/Disable信号

上記のように、本来GPIO0 D3にはS/PDIF信号が割り当てられるはずですが、なぜか全く関係のないUSB電源供給信号が割り当てられており、S/PDIFが全く動作しない状態になっていました。

私のパッチはUSB電源供給信号のピンアサインをGPIO0 A2に直すパッチです。GPIO0 D3ピンからS/PDIFが無事出力できるようになりました。

しかし実装の間違いはこれだけではありませんでした。GPIO0 A2は信号の極性（Active High指定でしたが、本来はActive Lowが正しい）も間違っていたのです。

GPIO0 A2

• 本来: USB電源供給Enable/Disable信号
• 実装: 何も割り当たっていない
• パッチ後: USB電源供給Enable/Disable信号（直った）
• 本来の極性: Active Low
• 実装の極性: Active High
• パッチ後: Active High（変化なし）

私のパッチはピンアサインだけ直して、信号の極性を直さなかったため、USBの電源が常にダウンしてしまい、USBが全く動かなくなってしまったようです。

USB電源周りをいじったのに、USBの動作確認をせずにパッチを投稿してしまったのは、片手落ちだったなあと反省しきりです。

メモ: 技術系の話はFacebookから転記しておくことにした。