コグノスケ


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

link もっと前
2019年3月28日 >>> 2019年3月19日
link もっと後

2019年3月28日

マンガ紹介

目次: マンガ紹介

お気に入りのマンガ紹介シリーズ。

マンガ紹介 その1

こわもてかわもて(1巻)(アマゾンへのリンク

子育ては奥さんにまかせきりで子供の扱いが良くわからない「こわもて」の爺ちゃん龍之介と、突然帰ってきた「かわもて」の孫の虎々(ことら)のコメディマンガ。

虎々のフリーダム加減は、よつばと!に似てるけど、周りの大人のキャラが違うので、作品としてはそんなに似てない気がする。今後が楽しみ。

マンガ紹介 その2

我が驍勇(ぎょうゆう)にふるえよ天地〜アレクシス帝国興隆記〜(2巻)(アマゾンへのリンク

自国の貴族の罠により、故郷を隣国に攻め落とされ、親しい人も帰るべき地も失った王子が、英雄となり新たな帝国を築く(たぶん、タイトルから推測して)。王道の戦記物です。

主人公は不幸な生い立ちですが、復讐の鬼にはならず、器のデカさを感じます。2巻の時点ではまだまだ序盤ですから、今後はわからないですけども。画も迫力あっていい感じです。今後が楽しみです。

タイトルは最近あまり見ない厳つい感じですね。

異世界転生物に多いのですが、
「〜したら〜でした」
「〜が〜なんですが」
「〜は〜します」
のような説明的なタイトルって、個人的には冗長であまり好きじゃないです。面白いんだから、大丈夫だよ!もっと自信もって言い切って!!なんてことを思います。

その点、この本はタイトルからして目に留まって、とても印象的でした。

編集者:すずき(2022/08/30 22:51)

コメント一覧

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



2019年3月27日

Clangのmain関数ってどこ?

目次: LLVM

ふとClangのmain関数ってどこにあるんだろう?と思って、grepしたのですが、それらしい箇所がありません。

GDBでClangのmainにブレーク掛けてみると、llvm/tools/clang/tools/driver/driver.cppがヒットしました。んん?clangディレクトリではなく、llvmディレクトリにあるんですか?ちょっと初見ではわかりませんでした。GDBありがとう。

ClangというかLLVMの困ったところは、シンボルが多すぎてGDBの起動に数分かかることです。GDBがメモリを1.5GBほど使うのも特徴的です。デバッグのために1GBメモリを使うなんて今まで見たことありません。

この時点で既に低性能PCお断り感がビシビシ出ていますが、LLVMの極めつけはリンク時にリンカがメモリ8GBも使う(しかも1プロセスで)ことです。

その辺のショボいPCではデバッグがどうこう言う前に、そもそもビルドできず門前払いです。LLVMムチャクチャが過ぎる……。

RISC-V向けLLVMビルド

LLVMにはRISC-V向けの実装があるのですが、デフォルトでは有効になっていないようです。LLVMのCMakeLists.txtのLLVM_ALL_TARGETSにRISCVを足します。

LLVMのRISCV向け実装を有効にする

diff --git a/CMakeLists.txt b/CMakeLists.txt
index ee6b77990b3..ce8f24afad1 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -327,6 +327,7 @@ set(LLVM_ALL_TARGETS
   MSP430
   NVPTX
   PowerPC
+  RISCV
   Sparc
   SystemZ
   WebAssembly

ビルドすればRISC-V用のLLVMやツールチェーンがビルドできます。

リンク時のメモリ節約方法(特定アーキテクチャ向けLLVMビルド)

LLVMは何も指定せずにビルドすると、対応可能な全てのアーキテクチャに対応したバイナリをビルドしようとします。ビルドがメチャクチャ遅いので、cmakeにLLVM_TARGETS_TO_BUILDでビルド対象を1つだけに制限すると、ビルド、特に最後のリンクが速くなります。

RISCVのみをデバッグシンボル付きでビルドする
$ cmake -G Ninja \
  -D LLVM_TARGETS_TO_BUILD="RISCV" \
  -D CMAKE_C_COMPILER=clang \
  -D CMAKE_CXX_COMPILER=clang++ \
  -D LLVM_USE_LINKER=gold \
  -D CMAKE_BUILD_TYPE=RelWithDebInfo \
  -D LLVM_ENABLE_ASSERTIONS=ON \
  ../llvm

$ ninja

CMAKE_BUILD_TYPEに渡せる値は何種類かあります。Debugだとリンク時間がバカみたいに長く、リビルドが辛いです。Releaseだとビルドは速いですがデバッガがほぼ使えず、デバッグが辛いです。リリース相当だけどデバッグシンボルは付けるRelWithDebInfoが普段遣いには良いかもしれません。

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

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

コメント一覧

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



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 この記事にコメントする



link もっと前
2019年3月28日 >>> 2019年3月19日
link もっと後

管理用メニュー

link 記事を新規作成

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

最近のコメント5件

  • 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手動での回復パ...」

最近の記事3件

  • link 24年3月19日
    すずき (03/20 02:52)
    「[モジュラージャックの規格] 古くは電話線で、今だとEthernetで良く見かけるモジュラージャックというコネクタとレセプタク...」
  • link 23年4月10日
    すずき (03/19 11:48)
    「[Linux - まとめリンク] 目次: Linuxカーネル、ドライバ関連。Linuxのstruct pageって何?Linu...」
  • link 24年3月18日
    すずき (03/19 11:47)
    「[画面のブランクを無効にする] 目次: LinuxROCK 3 model CのDebian bullseyeイメージは10分...」
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 www2.katsuster.net
RDFファイル RSS 1.0

最終更新: 03/20 02:52