コグノスケ


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

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

2019年3月26日

LLVMの本を買った

目次: 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スロットがない)ので、対象アーキテクチャを減らすか、ビルドの並列数を減らして、メモリを節約するしかなさそうです。

編集者:すずき(2023/09/24 09:15)

コメント一覧

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



2019年3月25日

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

目次: ROCK64/ROCKPro64

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から転記しておくことにした。図を追加した。

編集者:すずき(2020/10/30 00:50)

コメント一覧

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



2019年3月24日

レジスタダンプ、書き換えツール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/03/27 21:52)

コメント一覧

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



2019年3月23日

初めてのOpenVX on ARM

目次: OpenCL

先日(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
編集者:すずき(2023/09/24 11:57)

コメント一覧

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



2019年3月17日

たまにズレちゃう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以外で活用されることはありません……。

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

編集者:すずき(2023/09/24 13:24)

コメント一覧

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



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

管理用メニュー

link 記事を新規作成

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

最近のコメント20件

  • link 21年3月13日
    すずきさん (03/05 15:13)
    「あー、このプログラムがまずいんですね。ご...」
  • link 21年3月13日
    emkさん (03/05 12:44)
    「キャストでvolatileを外してアクセ...」
  • link 24年1月24日
    すずきさん (02/19 18:37)
    「簡単にできる方法はPowerShellの...」
  • link 24年1月24日
    KKKさん (02/19 02:30)
    「追伸です。\nネットで調べたらマイクロソ...」
  • link 24年1月24日
    KKKさん (02/19 02:25)
    「私もエラーで困ってます\n手動での回復パ...」
  • link 24年1月24日
    すずきさん (02/13 11:48)
    「ありがとうございます。\n私のPCはもう...」
  • link 24年1月24日
    えはらさん (02/12 15:00)
    「Powershellのスクリプトは以下の...」
  • link 24年2月2日
    すずきさん (02/02 18:17)
    「サーバー側の設定はとても簡単でした。ちょ...」
  • link 24年2月2日
    hdkさん (02/02 08:54)
    「さくらのレンタルサーバの設定でLet's...」
  • link 24年1月24日
    すずきさん (01/28 11:35)
    「ご指摘ありがとうございます。確かに間違っ...」
  • link 24年1月24日
    通りすがりさん (01/27 14:05)
    「Powershellで解決しなかったのは...」
  • link 23年11月29日
    すずきさん (12/04 00:38)
    「あ、そうか。1nsですね。ありがとうござ...」
  • link 23年11月29日
    hdkさん (12/03 18:49)
    「>(本来1usなのに1msになって...」
  • link 23年11月29日
    すずきさん (12/03 00:35)
    「大山先生、お久しぶりです。コメントありが...」
  • link 23年11月29日
    大山恵弘さん (12/02 18:53)
    「すずきさんのX(旧Twitter)へのポ...」
  • link 20年7月12日
    すずきさん (10/19 11:17)
    「ご指摘ありがとうございます。9月の編集は...」
  • link 20年7月12日
    通り縋りさん (10/18 19:08)
    「上の記事2023年9月編集という事ですが...」
  • link 23年9月22日
    すずきさん (09/23 21:14)
    「そうなんですよ。賢いなーと思って自分でも...」
  • link 23年9月22日
    hdkさん (09/23 14:56)
    「+1だから、繰り上がる時は必ず下のほうに...」
  • link 23年9月2日
    すずきさん (09/06 18:21)
    「dアカウント自体はMNPと関係なく存在す...」

最近の記事3件

  • link 24年3月25日
    すずき (03/26 03:20)
    「[Might and Magic Book One TASのその後] 目次: Might and Magicファミコン版以前(...」
  • link 21年10月4日
    すずき (03/26 03:14)
    「[Might and Magicファミコン版 - まとめリンク] 目次: Might and Magicファミコン版TASに挑...」
  • link 24年3月19日
    すずき (03/20 02:52)
    「[モジュラージャックの規格] 古くは電話線で、今だとEthernetで良く見かけるモジュラージャックというコネクタとレセプタク...」
link もっとみる

こんてんつ

open/close wiki
open/close Linux JM
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 2021年
open/close 2022年
open/close 2023年
open/close 2024年
open/close 過去日記について

その他の情報

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

合計:  counter total
本日:  counter today

link About www.katsuster.net
RDFファイル RSS 1.0

最終更新: 03/26 03:20