目次: 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と指定してデバッグ情報を有効にしてビルドすることで、デバッグしやすくなります。
TightVNCサーバーを使うとアプリケーションの実行時に下記の警告が出ます。
Xlib: extension "RANDR" missing on display ":1".
警告が出ても動作はするのですが、気になる方は下記のようにTigerVNCをインストールするなど、RANDRに対応したVNCサーバーを使ってください。
# apt-get install tigervnc-standalone-server
目次: Windows
Windows 10は自動的にWindows Updateを実行し、勝手にPCを再起動することがあります。その際にウインドウの幅がズレることがあります。
ウインドウの幅が多少ズレても実用上害はありませんが、この状態と同時に発生する、フォント表示がボヤボヤになって、サイズがおかしくなり、非常に読みづらくなる症状が辛いです。目が痛くなってきます。
いずれの症状もPCを再起動すると直ります。直る理由すらわかりませんが、今のところ直らなかったことは一度もありません。
不思議なことにWindows Update後に必ずズレた状態になる訳ではなく、何か他の条件があるようです。人が見ていない夜中に再起動して、勝手にこの状態にハマるので、詳細は確認しようがないです。
最近のWindowsは再起動により、作業中のアプリケーションが全て終了され、当初かなりイライラしていました。
しかし今は「Windowsで大事な作業をしない」ことにより、諦めがつきました。デスクトップPCは勝手に再起動されては困るので、Windowsごと消しました。さようなら〜。
ノートPCは再起動されても特に問題ないのでWindowsを残しています。なぜなら最近Windows上で実行しているアプリケーションは、
しかないからです。あとは、たまに音楽プレーヤーやSteamを起動しますが、起動しっぱなしにはしません。たとえ強制終了されたとしても問題はありません。
この使い方はほぼシンクライアントですね。わざわざカスタムオーダーまでしてCore i5-8250と外部グラフィックスAMD Radeon RX550を積んだのに、彼らがSteam以外で活用されることはありません……。
つまり、もっとゲームをやりなさいということだな??
目次: 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の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/ROCKPro64
昔、私が投稿したパッチがLinux 4.20をデグレさせていました。Linux 4.20以降ではROCK64のUSBが動かなくなっています。全然気づきませんでした……。
Arch Linuxの人たちが「動かねーぞ??」とハマった挙句(リンク)に、指摘してくれたようです。
反省を込めて、ROCK64がデグレした理由をまとめておきます。
当時、私が直したのはピンに出力する信号の割り当て設定です。
GPIO0 A2
GPIO0 D3
上記のように、本来GPIO0 D3にはS/PDIF信号が割り当てられるはずですが、なぜか全く関係のないUSB電源供給信号が割り当てられており、S/PDIFが全く動作しない状態になっていました。
私のパッチはUSB電源供給信号のピンアサインをGPIO0 A2に直すパッチです。GPIO0 D3ピンからS/PDIFが無事出力できるようになりました。
しかし実装の間違いはこれだけではありませんでした。GPIO0 A2は信号の極性(Active High指定でしたが、本来はActive Lowが正しい)も間違っていたのです。
GPIO0 A2
私のパッチはピンアサインだけ直して、信号の極性を直さなかったため、USBの電源が常にダウンしてしまい、USBが全く動かなくなってしまったようです。
USB電源周りをいじったのに、USBの動作確認をせずにパッチを投稿してしまったのは、片手落ちだったなあと反省しきりです。
メモ: 技術系の話はFacebookから転記しておくことにした。
干支を3周しました。もう完全におじさんの仲間入りです。
若い人に自慢と説教だけはしないように気を付けよう。
< | 2019 | > | ||||
<< | < | 03 | > | >> | ||
日 | 月 | 火 | 水 | 木 | 金 | 土 |
- | - | - | - | - | 1 | 2 |
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
31 | - | - | - | - | - | - |
合計:
本日: