link もっと前
   2019年 3月 26日 -
      2019年 3月 17日  
link もっと後

link 未来から過去へ表示(*)
link 過去から未来へ表示

日々

link permalink

link 編集する

LLVM の本を買った

コンパイラが良くわからないまま放置してきましたが、最近、きつねさんでもわかる LLVM(アマゾンへのリンク)を買って読んでいます。

タイトルの通り LLVM のフロントエンド、バックエンドをコードを交えて紹介する書籍です。かなりマニアックですね……。本の中でも言及されていますが、本を読むだけより、実際にコードを動かして試すのがおすすめとのことです。

LLVM のビルド

コードを変更するにせよ、そのまま動かすにせよ、まずビルドできないと始まらないので、ビルドにチャレンジします。環境は Debian Testing です。

Debian Testing の GCC は 8.2
$ gcc --version
gcc (Debian 8.2.0-21) 8.2.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

まずは何も考えずに cmake, make してみました。

GCC 8.2 で LLVM をビルド、ダメだった
$ mkdir build
$ cmake ../llvm
$ make
...

[ 74%] Building NVCC (Device) object projects/openmp/libomptarget/deviceRTLs/nvptx/CMakeFiles/omptarget-nvptx.dir/src/omptarget-nvptx_generated_omp_data.cu.o
In file included from /usr/include/host_config.h:50,
                 from /usr/include/cuda_runtime.h:78,
                 from <command-line>:
/usr/include/crt/host_config.h:119:2: error: #error -- unsupported GNU version! gcc versions later than 7 are not supported!
 #error -- unsupported GNU version! gcc versions later than 7 are not supported!
  ^~~~~
CMake Error at omptarget-nvptx_generated_omp_data.cu.o.Debug.cmake:215 (message):
  Error generating
  /home/katsuhiro/share/projects/oss/clang/build/projects/openmp/libomptarget/deviceRTLs/nvptx/CMakeFiles/omptarget-nvptx.dir/src/./omptarget-nvptx_generated_omp_data.cu.o


make[2]: *** [projects/openmp/libomptarget/deviceRTLs/nvptx/CMakeFiles/omptarget-nvptx.dir/build.make:135: projects/openmp/libomptarget/deviceRTLs/nvptx/CMakeFiles/omptarget-nvptx.dir/src/omptarget-nvptx_generated_omp_data.cu.o] エラー 1
make[1]: *** [CMakeFiles/Makefile2:39936: projects/openmp/libomptarget/deviceRTLs/nvptx/CMakeFiles/omptarget-nvptx.dir/all] エラー 2
make: *** [Makefile:152: all] エラー 2

エラーメッセージを素直に解釈すると GCC 7 より後だとダメっぽいです。GCC 6.0 を使おうと思いましたが、Debian Testing に gcc-6 というパッケージはありますが、g++-6 は見当たりません。LLVM は C++ のコードがあるので GCC だけではビルドできないのです。無念……。

ひとまず GCC は諦め、Clang を試してみます。

Debian Testing の Clang は 7.0
$ clang --version
clang version 7.0.1-6 (tags/RELEASE_701/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

通常と異なるコンパイラを使うときは cmake に CMAKE_C_COMPILER と CMAKE_CXX_COMPILER 変数を渡します。さて、ビルドできるでしょうか?

LLVM 7.0 で LLVM をビルド、うまくいった
$ cmake -G Ninja -D CMAKE_C_COMPILER=clang -D CMAKE_CXX_COMPILER=clang++ ../llvm
$ ninja

コンパイラのバージョンに敏感だと、将来ビルドできなくなりそうで不安になりますが、それはさておき。とりあえずビルドに成功したので、今後は clang を使うことにしましょう。

リンカが死ぬ

LLVM のビルドはリンクで死ぬほどメモリを使う(1プロセスが 8GB 使ったりする)ので、16コア CPU だからといって ninja -j16 などとするとリンクの時にメモリが足りなくなってリンカがクラッシュします。

恐ろしいことにメモリ 32GB だと全然足りなくて、ninja -j8 でもクラッシュします。LLVM の開発者は一体どんなモンスターマシンでビルドしているんでしょうか……。

私の PC はもうメモリを増設できない(空いている DIMM スロットがない)ので、対象アーキテクチャを減らすか、ビルドの並列数を減らして、メモリを節約するしかなさそうです。

[編集者: すずき]
[更新: 2019年 3月 26日 23:34]

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link permalink

link 編集する

RockPro64 のシリアル文字化け - U-Boot との比較

RockPro64 シリアル文字化けの話のまとめ、第二章。

RockPro64 は「U-Boot だと文字化けしない」という指摘をいただいたので確認したところ、確かに文字化けしません。

Drive Strength の設定はデフォルト値(3mA)のままにも関わらず、オシロスコープで UART TX 側の波形を見ると Rise/Fall Time が 77ns/59ns と優秀な値です。


RockPro64 U-Boot のシリアル出力の波形

とりあえずボード不良ではなかったことがわかって良かったものの、何が原因で linux-next は文字化けしているかわからず、振出しに戻ってしまいました。

あえて波形を劣化させる設定?

電源 ON から波形を観察し続けると linux-next もブートプロンプトの途中までは波形が綺麗です。linux-next は途中で波形が鈍る設定をわざとしていることになります。

原因がわからないので、当てずっぽうでデバイスツリーの色々なノードを ON/OFF していったところ、io_domains ノードの audio-supply プロパティを変更すると UART TX の波形が劣化することがわかりました。

このプロパティを読み取るドライバは drivers/power/avs/rockchip-io-domain.c にあります。追ってみると RK3399 の GRF のレジスタ 0xff77e640 の bit 1(audio_gpio3d4a_ms)の値を設定していました。仕様書を見ると IO domain(とは何だ?)の駆動電圧を設定するビットでした。クリアすると 3.0V、セットすると 1.8V の意味です。

現在の linux-next は 1.8V 設定にしており、波形が鈍っています。U-Boot はレジスタに何も設定しないらしく、デフォルトの 3.0V 設定のままでした。

試しに linux-next 起動後、UART TX の波形が鈍ったことを確認したのちに、audio_gpio3d4a_ms を無理やりクリア、つまり IO domain works as 3.0V 設定に変えてみたところ、波形がシャキーンと綺麗になりました。

ああー、原因はこれだ。

どう直すべきか

レジスタの値を色々変えてみたところ、bit 1 audio_gpio3d4a_ms を 3.0V にするか、bit 1 audio_gpio3d4a_ms と bit 3 gpio1830_gpio4cd_ms を両方とも 1.8V 設定に変えると直ることがわかりました。

しかし RockPro64 の回路図を見ると、GPIO1830 は 3.0V で、VCCA1V8 は 1.8V に設定する方が正しいように見えます。

正しいはずの設定になのに UART の波形が鈍ってしまい、設定を間違えているはずの U-Boot は UART の波形が綺麗です。どうしてこうなるのか良くわかりません。原因はわかったものの、真因がわからなくて直し方もわからない、困ったタイプですね。

おまけ

IO domain を 3.0V に変更し、Drive Strength 12mA の設定と組み合わせると、Rise/Fall Time が 30ns/34ns とさらに速くなります。


IO domain 3.0V + Drive Strength 12mA のときの RockPro64 シリアル出力の波形

あまりに急激に立ち上がりすぎるせいか、良く見ると Rise Edge がオーバーシュートしていますね……。

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

[編集者: すずき]
[更新: 2019年 10月 21日 14:42]

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link permalink

link 編集する

レジスタダンプ、書き換えツール 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 はバイナリで出力する方に重きを置いており、エディト機能もなさそうで、設計の方向性が違いました……。残念。

[編集者: すずき]
[更新: 2019年 3月 27日 21:52]

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link permalink

link 編集する

初めての OpenVX on ARM

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

ビルド

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

OpenVX ライブラリのビルド on AArch64
[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 に不要なオプションが指定されていてビルドが失敗しているようなので、削除します。

concerto の 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 に対応できていないように見えます。

make の設定からオプションを削除

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 ライブラリのビルドが通ったら、サンプルをビルドします。

concert でビルドしたライブラリを指定して、サンプルをビルド
$ 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 でライブラリを作った場合は、ライブラリの生成先ディレクトリが異なります。下記のようにします。

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 に表示する例です。

concert でビルドしたライブラリを指定して、サンプルを実行
$ DISPLAY=:1 \
  LD_LIBRARY_PATH=/path/to/openvx/out/LINUX/aarch64/release/ \
  ./a.out

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

cmake でビルドしたライブラリを指定して、サンプルを実行
$ 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 サーバーを使うとアプリケーションの実行時に下記の警告が出ます。

VNC サーバーによっては下記の警告が出る
Xlib:  extension "RANDR" missing on display ":1".

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

TigerVNC サーバーのインストール
# apt-get install tigervnc-standalone-server
[編集者: すずき]
[更新: 2019年 3月 25日 23:23]

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link permalink

link 編集する

たまにズレちゃう Windows 10

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 以外で活用されることはありません……。

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

[編集者: すずき]
[更新: 2019年 3月 23日 15:06]

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link もっと前
   2019年 3月 26日 -
      2019年 3月 17日  
link もっと後

管理用メニュー

link 記事を新規作成

合計:  counter total
本日:  counter today

link About www.katsuster.net
RDF ファイル RSS 1.0
QR コード QR コード

最終更新: 3/15 02:33

カレンダー

<2019>
<<<03>>>
-----12
3456789
10111213141516
17181920212223
24252627282930
31------

最近のコメント 5件

  • link 13年11月28日
    すずき 「ご指摘ありがとうございます。投稿の古さに...」
    (更新:03/08 17:39)
  • link 13年11月28日
    yut 「古いので、見てもらえるか不明ですので、、...」
    (更新:03/08 13:16)
  • link 13年11月28日
    yut シムズ 「古い投稿に対して、申し訳ありません。\n...」
    (更新:03/08 13:14)
  • link 19年09月01日
    すずき 「私も正直びっくりです。間違って違う製品を...」
    (更新:09/04 23:39)
  • link 19年09月01日
    hdk 「車向けの製品の中でも、車載コンピューター...」
    (更新:09/02 23:20)

最近の記事 3件

link もっとみる
  • link 20年03月10日
    すずき 「[誕生日] 37歳になりました。おめでとう俺、ありがとう俺。30代...」
    (更新:03/15 02:33)
  • link 20年03月14日
    すずき 「[GCC を調べる - その 7 - machine mode] ...」
    (更新:03/15 02:21)
  • link 20年03月06日
    すずき 「[GCC を調べる - その 6 - GCC の regist] ...」
    (更新:03/11 22:47)

こんてんつ

open/close wiki
open/close Java API

過去の日記

open/close 2002年
open/close 2003年
open/close 2004年
open/close 2005年
open/close 2006年
open/close 2007年
open/close 2008年
open/close 2009年
open/close 2010年
open/close 2011年
open/close 2012年
open/close 2013年
open/close 2014年
open/close 2015年
open/close 2016年
open/close 2017年
open/close 2018年
open/close 2019年
open/close 2020年
open/close 過去日記について

その他の情報

open/close アクセス統計
open/close サーバ一覧
open/close サイトの情報