link もっと前
   2019年 4月 1日 -
      2019年 3月 23日  
link もっと後

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

日々

link permalink

簡易 CPU 消費電力測定

簡易的に CPU の消費電力を測ってみました。測定ポイントは ATX 電源と AC コンセントの間です。要はワットチェッカーで PC 全体の消費電力を測っています。

アイドル状態から 1スレッド、2スレッド、と負荷を増やし、
(負荷時の消費電力) - (アイドル時の消費電力) = CPU の消費電力
と見なしています。負荷には仮想通貨のマイニングソフトのベンチマークモードを使っています。それなりに複雑な計算と、スレッド数の制御が容易いので便利です。

Ryzen 7 2700 の TDP は 65W なのに、消費電力が 70W 以上に計算されるところからわかるように、消費電力は若干多めに出ています。おそらく CPU の負荷に連動して冷却ファンが回ること、ATX 電源の変換効率が負荷によって変わること、などが原因だと思われます。


スレッド数と消費電力

Ryzen 7 2700 は 8コア 16スレッドですが、5スレッドを超えた辺りから、フルパワーの消費電力とあまり差がなくなります。


スレッド数と電力効率

また W 辺りの計算効率(kH/s・W)を計算すると、16並列が一番効率が良いです。逆に 5〜6 スレッド程度だと効率が悪いです。中途半端な並列度で計算するくらいなら、16 スレッドフルに使いきれということですね。

コア優先で割り当てたらどうなるか?

上記の実験方法を見て「スレッドをどの CPU に張り付けるかを制御しなくても良いのか?」疑問に感じた方、さすがです。手抜きしていたことがバレましたね。

マイニングソフトのコードを見たら、ちょいと改造すれば簡単にスレッドの affinity を設定できそうだったので、改造してもう一度測りました。

まず Ryzen 7 2700 は SMT 構成になっていまして、1コアが 2スレッド実行可能(OS からは 1コア = 2 CPU として扱う)です。私の環境 Debian Testing だと、

  • CPU 0: コア 0 スレッド 0
  • CPU 1: コア 0 スレッド 1
  • CPU 2: コア 1 スレッド 0
  • CPU 3: コア 1 スレッド 1
  • ...

以上のように割り当たるようです。ここで素直に CPU 0 から順にスレッドの affinity を設定すると、1つのコアに 2スレッドずつ張り付きます。どういうことかと言いますと、4スレッド起動したとき、コア 0 とコア 1 に 2スレッドずつ張り付いて、他の 6コアはヒマになるということです。これはあまり効率が良くなさそうですよね?

今回の測定では、コアを使い切ることを優先してスレッドを割り当てました。当然ながら 16スレッドの性能は変わらないのですが、途中の傾向が少し変わります。


スレッド数と消費電力、コア優先割り当て

消費電力は 4コアの時点でピークにかなり近くなります。8コアじゃないのは何ででしょうね?2コアがペアで電源制御されているんでしょうか……?


スレッド数と電力効率、コア優先割り当て

電力効率は 8スレッドが最大で、16スレッドに向かってやや下がります。SMT の特徴が出ている感じがします。

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

[編集者: すずき]
[更新: 2019年 4月 2日 00:33]
link 編集する

コメント一覧

  • hdk 
    去年Ryzen 7 1700で測りましたがやはりTDPより少し高めでした: http://www.e-hdk.com/diary/d201808b.html#15-1 
    (2019年04月02日 22:48:26)
  • すずき 
    どの CPU というかシステムでも同じ傾向ですね。CPU の消費電力だけ測れているわけではないですし、そんなもんかなーと思いました。 
    (2019年04月05日 11:03:13)
open/close この記事にコメントする



link permalink

RockPro64 のシリアル文字化け - 真因発見か?

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

RockPro64 のシリアル文字化け問題に進展がありました。結論から先に言えば、現在の linux-next の I/O ドメイン audio_gpio3d4a_ms の電圧設定が間違っていそうです。直したらシリアルの波形が綺麗になりました。

RK3399 は I/O ドメイン(正式な名前かどうか知らない)といって、いくつかの出力ピンがグループになっています。グループごとに電源ピンがあり、電源ピンに何 V を供給しているか設定する必要があるようです。audio_gpio3d4a_ms ドメインの電源は APIO5_VDD 端子です。

要は APIO5_VDD 端子に 1.8V を供給するなら、audio_gpio3d4a_ms ドメインの設定も 1.8V にする必要があり、APIOD5_VDD 端子に 3.0V を供給するなら、audio_gpio3d4a_ms ドメインの設定も 3.0V にする必要があります。

RockPro64 の回路図を見ると、P.4 の Power Domain Map というページに audio_gpio3d4a_ms には電源 IC(RK808)の VLDO7 が繋がっていて、1.8V だと書いてあります。linux-next はこの記述を見て設定していると思われます。

しかし P.16 の回路図を見ると、APIO5_VDD 端子には VCC_3V0(その先は VLDO8)という 3.0V 出力ピンが繋がっています。つまり RockPro64 の回路図は自己矛盾しています。


APIO5_VDD の配線図


VCC_3V0 の配線図

配線ミスってるとか、そんなのありかよ……と思いつつ P.16 の回路図を信じることにして、audio_gpio3d4a_ms を 3.0V 設定にするパッチを LKML に送りました。

偉そうに書いていますが、私は P.16 の回路図には全く気づいておらず、LKML のナイスガイ達に助けられました。ありがたいことです。

関係ないドメインなのに、なぜ影響するのか?

UART2 信号が出ている GPIO4_C3 ピンは gpio1830_gpio4cd ドメインに属しており、audio_gpio3d4a_ms ドメインでは「ない」です。にも関わらず、なぜか audio_gpio3d4a_ms ドメインの設定ミスで UART2 の波形がおかしくなります。

Power Domain Map と回路図の意図を整理すると、Power Domain Map の設計は、下記の通りです。

  • audio_gpio3d4a_ms - APIO5_VDD - VCCA1V8_CODEC - VLDO7
  • gpio1830_gpio4cd - APIO4_VDD - VCC1V5 - VLDO6, VCC3V0_IO - VLDO8

一方の回路図はというと、全然接続が違いますし、端子がなかったりします。

  • VCCA1V8_CODEC - VLDO7
  • VCC_1V5 - VLDO6
  • VCC3V0_IO 存在しない
  • audio_gpio3d4a_ms - APIO5_VDD - VCC3V0 - VLDO8
  • gpio1830_gpio4cd - APIO4_VDD - VCC3V0 - VLDO8


VLDO 系の配線図

推測ですが、意図せずに 2つのドメインで電源ライン VLDO8 を共有したために、audio_gpio3d4a_ms ドメインの設定ミスが、gpio1830_gpio4cd 側のドライブ能力に影響していると思われます。

VLDO8 に想定してない負荷が掛かっているような気がしますが、大丈夫なんですかね……??まあ、コスパ重視だし、趣味のおもちゃですから、燃えたり爆発したりしなければ問題ないのかな。

(補足)audio_gpio3d4a_ms ドメインの設定は、GRF_IO_VSEL レジスタ(アドレス 0xff77e640 )のビット 1 です。

[編集者: すずき]
[更新: 2019年 4月 1日 03:33]
link 編集する

コメント一覧

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



link permalink

GCC は必須

世界から gcc がなくなるとどうなるのか?と思ったので、試してみました。その世界では、少なくともターゲットとなる実機上でセルフコンパイルが可能になるまで、別の環境(例えば PC など)で、

  • clang
  • クロスコンパイル

を用いて世界を構築する必要があります。何もかも試すのは不可能なので、必要最小限の要素として、

  • ブートローダー(U-Boot)
  • カーネル(Linux)
  • libc(glibc, newlib)

を試すことにします。

最近は clang と gcc は互換性も高いし、楽勝でしょ〜などと生半可な知識で楽観視していましたが、実際やると何かもう全然ダメです。そもそも x86 向けのビルドが成功しません。クロスコンパイルなんか以ての外です。

RISC-V の人たちが GCC に真っ先に対応して、LLVM を放置している理由はこれかなあ?特に GNU, Linux 系システムをビルドしようと思ったら、LLVM だけでは話にならないのでは……??

U-Boot

まずは U-Boot です。

U-Boot を clang でビルド
$ make CC=clang defconfig
$ make CC=clang

うまくいきました。さすが!ARM とか AArch64 向けなら、U-Boot は良い選択肢のはずです。RISC-V は違うブートローダを使うので意味ありませんけど。

Linux

次は Linux です。

Linux を clang でビルド
$ make CC=clang defconfig
$ make CC=clang
HOSTCC scripts/asn1_compiler
HOSTCC scripts/extract-cert
Compiler lacks asm-goto support.
make: *** [arch/x86/Makefile:298: checkbin] Error 1

序盤でコケます。どうしたら良いんでしょう、これ。回避方法が見当たりません。

libc (glibc)

glibc を clang でビルド
$ mkdir build
$ cd build
$ ../configure --prefix="/usr" CC=clang
...
configure: error:
*** These critical programs are missing or too old: compiler
*** Check the INSTALL file for required versions.

まず configure が通りません。門前払いです。どうも clang を使ったとき、configure は GCC 3.x 系だと思うようで、そんな古いコンパイラはダメよ?と怒られてしまいます。どうしろと。

libc (newlib)

GNU 系列の glibc は clang に対応するとは思えませんし、newlib なら何とかしてくれるはず。

newlib を clang でビルド
$ mkdir build
$ cd build
$ ../newlib/configure --disable-multilib CC=clang CXX=clang++
...
In file included from ../../../newlib/libc/ssp/gets_chk.c:39:
In file included from /home/katsuhiro/share/projects/oss/newlib-cygwin/newlib/libc/include/limits.h:132:
In file included from /usr/lib/llvm-7/lib/clang/7.0.1/include/limits.h:37:
/usr/include/limits.h:145:5: error: function-like macro '__GLIBC_USE' is not defined
#if __GLIBC_USE (IEC_60559_BFP_EXT)
^
1 error generated.

ええ、そう思っていた時代が私にもありました。救世主だと勝手に思っていましたが、まさかのコンパイルできず。

注意

いずれの手順も CC=clang を付けなければ(=GCC を使えば)成功することは確かめていますが、私の実行したビルド手順が正しい保証はありません。

GCC → clang への切り替えを行う際に「CC=clang を付ける」が正しい手順とは限らないからです。ソフトウェアによっては clang 専用に別のビルド手順が存在するかもしれません。

ビルド失敗していることからもわかる通り、私は正しいビルド手順は発見できていません。知っていたらぜひ教えて欲しいです……。

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

[編集者: すずき]
[更新: 2019年 3月 31日 23:10]
link 編集する

コメント一覧

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



link permalink

LLVM IR の作り方

いつも忘れるので、C 言語のコードから、オブジェクトコード、LLVM IR ビットコード、LLVM IR、アセンブラを生成する方法をメモしておきます。

C Source (.c) -> Object code (.o)

$ clang --target=riscv64 a.c -c -o a.o

C Source (.c) -> LLVM IR (.ll)

$ clang -c -S -emit-llvm a.c

C Source (.c) -> LLVM IR bitcode (.bc)

$ clang -c -emit-llvm a.c

LLVM IR (.ll) -> Assembly code (.S)

$ llc --march=riscv32 a.ll

LLVM IR (.ll) -> Object code (.o)

$ llc --march=riscv32 -filetype=obj a.ll
[編集者: すずき]
[更新: 2019年 3月 29日 23:00]
link 編集する

コメント一覧

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



link permalink

マンガ紹介

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

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

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

マンガ紹介 その 2

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

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

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

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

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

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

[編集者: すずき]
[更新: 2019年 3月 29日 22:48]
link 編集する

コメント一覧

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



link permalink

Clang の main 関数ってどこ?

ふと 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 から転記しておくことにした。いろいろ追記した。

[編集者: すずき]
[更新: 2019年 3月 27日 22:06]
link 編集する

コメント一覧

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



link permalink

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]
link 編集する

コメント一覧

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



link permalink

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年 4月 1日 01:49]
link 編集する

コメント一覧

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



link permalink

レジスタダンプ、書き換えツール 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]
link 編集する

コメント一覧

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



link permalink

初めての 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]
link 編集する

コメント一覧

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



link もっと前
   2019年 4月 1日 -
      2019年 3月 23日  
link もっと後

管理用メニュー

link 記事を新規作成

合計:  counter total
本日:  counter today

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

最終更新: 4/20 00:42

カレンダー

<2019>
<<<04>>>
-123456
78910111213
14151617181920
21222324252627
282930----

最近のコメント 5件

  • link 19年04月01日
    すずき 「どの CPU というかシステムでも同じ傾...」
    (更新:04/05 11:03)
  • link 19年04月01日
    hdk 「去年Ryzen 7 1700で測りました...」
    (更新:04/02 22:48)
  • link 19年03月05日
    すずき 「> オシロの波形見てて気がつかなか...」
    (更新:03/21 17:45)
  • link 19年03月05日
    kml 「> 自分が持っている RockPr...」
    (更新:03/20 21:30)
  • link 19年03月10日
    すずき 「ありがとー!!」
    (更新:03/13 09:46)

最近の記事 3件

link もっとみる
  • link 19年04月19日
    すずき 「[RISC-V の SoC を見ていた] Linux が動くくらい...」
    (更新:04/20 00:42)
  • link 19年04月18日
    すずき 「[Linux の DMA] 昨今のキャッシュを持った CPU では...」
    (更新:04/20 00:29)
  • link 19年04月13日
    すずき 「[レジスタダンプ、書き換えツール memaccess - ちょ] ...」
    (更新:04/19 23:35)

こんてんつ

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 過去日記について

その他の情報

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