目次: RISC-V
Linuxが動くくらいのRISC-VのSoC搭載ボードを探していたのですが、どうやらまだ市販されてなさそうでした……。
代わり(?)にSiFiveの高性能RISC-V SoCであるHiFive Unleashed(リンク)のマニュアルを眺めていました。
HiFive Unleashedは高性能と紹介されていることが多いですが、現状RISC-VはArduinoくらいの小規模SoCがほとんどで、それらと比較して高性能、と言っているのだと思われます。
特に珍しい機能もないですし、最近のテレビやタブレット向けの巨大なARM系SoCと比べると、どうしてもショボく見えてしまうのは仕方ないでしょう。
ああ、でもErrataの章があるのは珍しいかもしれません。
などの豪快なバグがある様子が伺えます。特にROCK-2のWorkaroundは全然Workaroundになっておらずのが面白いです。アクセス違反をするな、と言ってアクセス違反がなくなるならOSの苦労はないでしょ。かなり悲惨なバグです。
ボードには修正したSoCを載せるのか、バグったSoCを強引に搭載するのか、どちらなんでしょうね……。
メモ: 技術系の話はFacebookから転記しておくことにした。
目次: Linux
昨今のキャッシュを持ったCPUでは、DMAを行う際にCPUのキャッシュのフラッシュ(ダーティデータをメインメモリに書きだす、パージともいう)やインバリデート(キャッシュから消しさる、クリーンともいう)が必須です。
しかしアーキテクチャやCPUの実装によってキャッシュの操作方法は異なるため、LinuxではDMA APIというレイヤでアーキテクチャの差分を隠蔽しています。
LinuxでDMAを行うドライバを書くときの一番単純な作法(=単一の領域にDMAを行う、スキャッターギャザーなどはしない)は、
ざっくりいってこのような感じです。先ほど述べた通り、LinuxのDMA APIにキャッシュのフラッシュやインバリデート関数はありません。ハード依存の操作をなるべく減らし、多数のアーキテクチャに対応しやすくなっているんですね。
そうはいっても、実際にどこでキャッシュフラッシュしているか、気になると思います。昔、Linux 4.4を調べた情報を引っ張り出してきました。アーキテクチャはAArch64つまり64bitのARMコアです。
AArch64の場合、キャッシュ操作をしているのはdma_sync_single_for_cpu() とdma_sync_single_for_device() です。前者がインバリデート、後者がフラッシュ+インバリデートを行っています。
前者のdma_sync_single_for_cpu() を追いかけてみると、
こんな感じですね。しつこいですがAArch64の実装を見ただけですので、将来的に変わるかもしれないし、他のアーキテクチャでは仕組みが違います。
昔のLinuxではキャッシュ操作関数をドライバから使うことができました。その記憶からなのか、たまにフラッシュやインバリデートのようなアーキテクチャ依存の操作を直接呼びたがる人がいます。
今のLinuxではキャッシュ操作関数は当然ありますが、ドライバからは呼べない、つまり呼ぶことを推奨していません。もちろんオープンソースなので改造すれば何でもできますけど、メンテナンス性や再利用性、移植性を下げるだけで、損しかないでしょう。
先日(2019年3月24日の日記参照)作ったmemaccess(GitHubへのリンク)細かい部分が色々バグっていたので直しました。
アドレスの指定は文句なしで64bit符号なし整数にしましたが、書き込む値については64bitの符号つき整数(今はこっち)と64bitの符号なし整数の、どっちが良いんでしょうね。贅沢を言えば、どちらも使いたいですけど。
以前の日記(2019年3月17日の日記参照)で、Windows Updateのあとにウインドウのタイトルがズレてしまう話を書きました。
その際に同時に発生する画面がぼやけてしまう現象についてもスクリーンショットを取ったので載せておきます。
このようにフォントがボヤけてしまいます。タスクマネージャの場合はあまり目立ちませんが、アプリケーションによってはさらに顕著です。
前回は「再起動で直る」と書きましたが、サインインしなおすだけでも直るようです。
ざっくりいうと、Windows Updateがテキストサイズの拡大縮小設定を元に戻した後に、サインインしなおさないからじゃないか?と思っています。
Windows 10にはアプリケーションのテキストサイズを調整する機能があります。[Windowsの設定] -> [システム] -> [ディスプレイ] から設定できます。
設定変更すると一部のアプリは、サインアウトするまで、拡大縮小の設定に応答しません、という警告文が表示されます。
購入当初は125% の設定になっていました。初期値はディスプレイの物理的なサイズと解像度によって決まっているそうです。あと、私は拡大縮小の設定を「100%」に変更して使用しています。
以上から導いた私の予想ですが、
こんな状態になっているのではないかと思っています。
簡易的に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から順にスレッドのaffinityを設定すると、1つのコアに2スレッドずつ張り付きます。どういうことかと言いますと、4スレッド起動したとき、コア0とコア1に2スレッドずつ張り付いて、他の6コアはヒマになるということです。これはあまり効率が良くなさそうですよね?
今回の測定では、コアを使い切ることを優先してスレッドを割り当てました。当然ながら16スレッドの性能は変わらないのですが、途中の傾向が少し変わります。
消費電力は4コアの時点でピークにかなり近くなります。8コアじゃないのは何ででしょうね?2コアがペアで電源制御されているんでしょうか……?
電力効率は8スレッドが最大で、16スレッドに向かってやや下がります。SMTの特徴が出ている感じがします。
メモ: 技術系の話はFacebookから転記しておくことにした。多少修正。
目次: ROCK64/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の回路図は自己矛盾しています。
配線ミスってるとか、そんなのありかよ……と思いつつ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の設計は、下記の通りです。
一方の回路図はというと、全然接続が違いますし、端子がなかったりします。
推測ですが、意図せずに2つのドメインで電源ラインVLDO8を共有したために、audio_gpio3d4a_msドメインの設定ミスが、gpio1830_gpio4cd側のドライブ能力に影響していると思われます。
VLDO8に想定してない負荷が掛かっているような気がしますが、大丈夫なんですかね……??まあ、コスパ重視だし、趣味のおもちゃですから、燃えたり爆発したりしなければ問題ないのかな。
(補足)audio_gpio3d4a_msドメインの設定は、GRF_IO_VSELレジスタ(アドレス0xff77e640)のビット1です。
目次: GCC
世界からgccがなくなるとどうなるのか?と思ったので、試してみました。その世界では、少なくともターゲットとなる実機上でセルフコンパイルが可能になるまで、別の環境(例えばPCなど)で、
を用いて世界を構築する必要があります。何もかも試すのは不可能なので、必要最小限の要素として、
を試すことにします。
最近はclangとgccは互換性も高いし、楽勝でしょ〜などと生半可な知識で楽観視していましたが、実際やると何かもう全然ダメです。そもそもx86向けのビルドが成功しません。クロスコンパイルなんか以ての外です。
RISC-Vの人たちがGCCに真っ先に対応して、LLVMを放置している理由はこれかなあ?特にGNU, Linux系システムをビルドしようと思ったら、LLVMだけでは話にならないのでは……??
まずはU-Bootです。
$ make CC=clang defconfig $ make CC=clang
うまくいきました。さすが!ARMとかAArch64向けなら、U-Bootは良い選択肢のはずです。RISC-Vは違うブートローダを使うので意味ありませんけど。
次はLinuxです。
$ 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
序盤でコケます。どうしたら良いんでしょう、これ。回避方法が見当たりません。
$ 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系だと思うようで、そんな古いコンパイラはダメよ?と怒られてしまいます。どうしろと。
GNU系列のglibcはclangに対応するとは思えませんし、newlibなら何とかしてくれるはず。
$ 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から転記しておくことにした。いろいろ追記した。
目次: LLVM
いつも忘れるので、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
目次: マンガ紹介
お気に入りのマンガ紹介シリーズ。
「我が驍勇(ぎょうゆう)にふるえよ天地」は最近あまり見ない厳つい感じのタイトルですね。
異世界転生物に多いのですが、
「〜したら〜でした」
「〜が〜なんですが」
「〜は〜します」
のような説明的なタイトルって、個人的には冗長であまり好きじゃないです。面白いんだから、大丈夫だよ!もっと自信もって言い切って!!なんてことを思います。
その点、この本はタイトルからして目に留まって、とても印象的でした。
目次: 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ムチャクチャが過ぎる……。
LLVMにはRISC-V向けの実装があるのですが、デフォルトでは有効になっていないようです。LLVMのCMakeLists.txtのLLVM_ALL_TARGETSに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は何も指定せずにビルドすると、対応可能な全てのアーキテクチャに対応したバイナリをビルドしようとします。ビルドがメチャクチャ遅いので、cmakeにLLVM_TARGETS_TO_BUILDでビルド対象を1つだけに制限すると、ビルド、特に最後のリンクが速くなります。
$ 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から転記しておくことにした。いろいろ追記した。
目次: LLVM
コンパイラが良くわからないまま放置してきましたが、最近、きつねさんでもわかるLLVM(アマゾンへのリンク)を買って読んでいます。
タイトルの通りLLVMのフロントエンド、バックエンドをコードを交えて紹介する書籍です。かなりマニアックですね……。本の中でも言及されていますが、本を読むだけより、実際にコードを動かして試すのがおすすめとのことです。
コードを変更するにせよ、そのまま動かすにせよ、まずビルドできないと始まらないので、ビルドにチャレンジします。環境はDebian Testingです。
$ 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してみました。
$ 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を試してみます。
$ 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変数を渡します。さて、ビルドできるでしょうか?
$ 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スロットがない)ので、対象アーキテクチャを減らすか、ビルドの並列数を減らして、メモリを節約するしかなさそうです。
目次: ROCK64/ROCKPro64
ROCKPro64シリアル文字化けの話のまとめ、第二章。ROCKPro64は「U-Bootだと文字化けしない」という指摘をいただいたので確認したところ、確かに文字化けしません。
Drive Strengthの設定はデフォルト値(3mA)のままにも関わらず、オシロスコープでUART TX側の波形を見るとRise/Fall Timeが77ns/59nsと優秀な値です。
とりあえずボード不良ではなかったことがわかって良かったものの、何が原因で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 | > | ||||
<< | < | 04 | > | >> | ||
日 | 月 | 火 | 水 | 木 | 金 | 土 |
- | 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 | - | - | - | - |
合計:
本日: