コグノスケ

レジスタダンプ、書き換えツールmemaccess - ちょっと修正

先日（2019年3月24日の日記参照）作ったmemaccess（GitHubへのリンク）細かい部分が色々バグっていたので直しました。

• 32bit環境でビルドできない
• ビルド時にlibtoolを要求する（本来は要らない）
• 0x80000000_00000000以上のアドレスを指定すると0x7fffffff_ffffffffになってしまう
• 32bitを超える値を書き込めない

アドレスの指定は文句なしで64bit符号なし整数にしましたが、書き込む値については64bitの符号つき整数（今はこっち）と64bitの符号なし整数の、どっちが良いんでしょうね。贅沢を言えば、どちらも使いたいですけど。

LinuxのDMAとキャッシュフラッシュ

目次: Linux

昨今のキャッシュを持ったCPUでは、DMAを行う際にCPUのキャッシュのフラッシュ（ダーティデータをメインメモリに書きだす、パージともいう）やインバリデート（キャッシュから消しさる、クリーンともいう）が必須です。

しかしアーキテクチャやCPUの実装によってキャッシュの操作方法は異なるため、LinuxではDMA APIというレイヤでアーキテクチャの差分を隠蔽しています。

LinuxでDMAを行うドライバを書くときの一番単純な作法（＝単一の領域にDMAを行う、スキャッターギャザーなどはしない）は、

dma_alloc

バッファ確保

dma_map_single

バッファをCPUのメモリ空間にマップし、CPUから見えるようにする

dma_sync_single_for_cpu

CPUからバッファをアクセスする準備

CPUからバッファにデータを書き込む

dma_sync_single_for_device

デバイスからバッファをアクセスする準備

デバイスからDMAを行いデータを読み込む

dma_unmap_single

バッファのマップをやめる

dma_free

バッファ解放

ざっくりいってこのような感じです。先ほど述べた通り、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() を追いかけてみると、

dma_sync_single_for_cpu()

関数ポインタ経由でops->sync_single_for_cpu() を呼びます。AArch64の場合opsには通常 swiotlbのDMA操作関数が入っています。ですので __swiotlb_sync_single_for_cpu() が呼ばれます

__swiotlb_sync_single_for_cpu()

コヒーレントバッファでない（キャッシュフラッシュがいる）場合 __dma_unmap_area() を呼びます

__dma_unmap_area()

__dma_inv_range() を呼びます

__dma_inv_range()

キャッシュをインバリデートします

こんな感じですね。しつこいですがAArch64の実装を見ただけですので、将来的に変わるかもしれないし、他のアーキテクチャでは仕組みが違います。

直接フラッシュしたがるおじさん

昔のLinuxではキャッシュ操作関数をドライバから使うことができました。その記憶からなのか、たまにフラッシュやインバリデートのようなアーキテクチャ依存の操作を直接呼びたがる人がいます。

今のLinuxではキャッシュ操作関数は当然ありますが、ドライバからは呼べない、つまり呼ぶことを推奨していません。もちろんオープンソースなので改造すれば何でもできますけど、メンテナンス性や再利用性、移植性を下げるだけで、損しかないでしょう。

RISC-V SoC搭載ボード探し

目次: RISC-V

Linuxが動くくらいのRISC-VのSoC搭載ボードを探していたのですが、どうやらまだ市販されてなさそうでした……。

代わり（？）にSiFiveの高性能RISC-V SoCであるHiFive Unleashed（リンク）のマニュアルを眺めていました。

HiFive Unleashedは高性能と紹介されていることが多いですが、現状RISC-VはArduinoくらいの小規模SoCがほとんどで、それらと比較して高性能、と言っているのだと思われます。

特に珍しい機能もないですし、最近のテレビやタブレット向けの巨大なARM系SoCと比べると、どうしてもショボく見えてしまうのは仕方ないでしょう。

ああ、でもErrataの章があるのは珍しいかもしれません。

ROCK-2: High 24 address bits are ignored

Workaround
Do not access out-of-bound addresses in software.

I2C-1: I2C interrupt can not be cleared

Workaround
Poll the I2C controller state to wait for TIP (transaction in progress) to go low.

などの豪快なバグがある様子が伺えます。特にROCK-2のWorkaroundは全然Workaroundになっておらずのが面白いです。アクセス違反をするな、と言ってアクセス違反がなくなるならOSの苦労はないでしょ。かなり悲惨なバグです。

ボードには修正したSoCを載せるのか、バグったSoCを強引に搭載するのか、どちらなんでしょうね……。

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

クロスビルド用ツールチェーン - その1

目次: GCC

先日（2019年3月27日の日記参照）クロスビルド向けLLVMのビルド方法がわかったので、今度はクロスビルド向けGCCのツールチェーン（超基本的なbinutils + GCC + glibcの組み合わせ）を作ろうとしていますが、さっぱりうまくいかないです。

そもそもどのバージョンの組み合わせならビルドが通るのか全くわかりません……。対象となるクロス環境（ARM向けなのか、RISC-V向けなのか）と、ホスト側のコンパイラバージョンが影響するようで、昔ビルドが通っていた組み合わせを引っ張り出してきても、今の環境だとビルドが通らないなんてことがおきます。

やりたいこと

ビルドできる組み合わせは頑張れば見つけられるとは思いますが、本来やりたいことはクロスビルド用のコンパイラのソースコードリポジトリをダウンロードし、自分でソースコードに何か変更を入れ、変更した内容も含めてビルドすることです（ダウンロードは最悪手動でも良いですけど）。

世の中にはクロスビルド用のツールチェーンを作成できるツールはいくつかありますが、いずれもtarballからのビルドを想定していて、改変を入れて再ビルドする方法が良くわかりません。

ツールが想定しているリリース用のビルドは、

• リリースバージョンのtarballか、ソースコードリポジトリのリリースタグを持ってきてビルド
• 実機で使える形、インストーラなどにパッケージング

開発用は、リリース用に加え、

• 最新のソースコードリポジトリを持ってくる
• ソースコードに素早くアクセス、改変
• 改変した部分だけ差分ビルド
• （必要なら）モジュールを足す

が必要ですが、意外とできないです……。

クロスビルド用ツールチェーンを作成できるツール

いくつかツールを調べてみました。

Yocto

ソースコードはアクセスしづらいです。例えばAGL（Yoctoを使っています）は、
agl/build/tmp/work-shared/gcc-8.2.0-r0/gcc-8.2.0/
に置かれます。何回見ても覚えられません。

ソースコードの改変はできますが、bitbakeはソースコードの変更を認識しないようです。bitbakeにモジュールを明示的に指定すれば良さそうです。もしくはパッチを作ってレシピに足してbitbakeするのがYocto的には正しいのかな？どちらにせよ面倒です。

新たにモジュールを足す方法は、レシピを足すだけなので簡単だと思いますが、それ以外が辛すぎます。開発用には向いていません。

crosstool-NG

ソースコードは、
crosstool-ng/.build/src/gcc-8.2.0/
にあります。アクセスしやすいです。

ソースコードの改変は反映されますが、差分ビルドはしないようで、./ct-ng buildとすると全てビルドしなおされます。ちょっと微妙です。

新たなモジュールの追加はどうやるのかわかりません。Yoctoなどとは違い、コンパイラなどのツールチェーンをビルドする専用ツールなので、Linuxカーネルやbusyboxはビルドしません。足すものはあまりないんじゃないでしょうか。

buildroot

ソースコードは、
buildroot/output/build/host-gcc-final-7.4.0/
にあります。Yoctoよりわかりやすいです。

ソースコードの改変は認識されていないように見えます。ソースコードを変更してmakeしても何もビルドされません。

新たなモジュールの追加方法は知らないですが、比較的簡単なのかな…？

ツールチェーン単体だとcrosstool-NGですし、将来的に追加するものを考えるとbuildrootが良さそうですけど。変更を反映して差分ビルドする方法ないのかな……？？

クロスビルド用ツールチェーン - その2

目次: GCC

引き続き、超基本的なbinutils + GCC + glibcの組み合わせのクロスビルド環境を作っています。やや苦戦したものの、ARM, AArch64, RISC-V 64でビルドが通りました。良かった良かった。

残念ながらRISC-V 32はglibcが対応しておらず、libcなしのベアメタル向けコンパイラしか作れませんでした。glibc does not yet support 32-bit systemsと怒られます。glibcの代わりにnewlibなどを使えば、libcありのLinux向けコンパイラが作れるかもしれませんが、試していないのでわかりません。

環境

昔作ったクロスコンパイラをビルドするMakefile（GitHubへのリンク）を改造して、作りました。

前回（その1）検討した通り、本格的に運用するなら独自のビルドツールよりcrosstool-NGかbuildrootに切り替えた方が良いと思います。

ビルド方法

詳細はGitHubを見た方が良いですが、configureに指定しているオプションだけ、ざっと列挙しておきます。

CROSS_ARCH = riscv64-unknown-linux-gnu
TOP_DIR    = `pwd`
CROSS_ROOT = $TOP_DIR/buildroot

PREFIX  ?= $(CROSS_ROOT)
SYSROOT ?= $(CROSS_ROOT)/$(CROSS_ARCH)/sysroot

まずbinutilsは、

./configure \
  --target=$(CROSS_ARCH) \
  --prefix=$(CROSS_ROOT) \
  --disable-nls \
  --disable-static \
  --disable-werror \
  --with-lib-path=$(CROSS_ROOT)/lib \
  --with-sysroot=$(CROSS_ROOT)

次にgccは、

./configure \
  --target=$(CROSS_ARCH) \
  --prefix=$(PREFIX) \
  --enable-languages=c \
  --disable-libatomic \
  --disable-libitm \
  --disable-libgomp \
  --disable-libmudflap \
  --disable-libquadmath \
  --disable-libsanitizer \
  --disable-libssp \
  --disable-libstdcxx-pch \
  --enable-long-long \
  --enable-lto \
  --disable-multiarch \
  --disable-multilib \
  --disable-nls \
  --disable-plugin \
  --disable-shared \
  --disable-threads \
  --disable-__cxa_atexit \
  --without-headers \
  --with-local-prefix=$(SYSROOT) \
  --with-sysroot=$(SYSROOT) \
  --with-newlib

難関のglibcはこんな感じ、

./configure \
  --host=$(CROSS_ARCH) \
  --prefix=$(SYSROOT)/usr \
  --disable-profile \
  --disable-multilib \
  --enable-add-ons \
  --enable-kernel=3.0.0 \
  --disable-multi-arch \
  --enable-obsolete-rpc \
  --with-binutils=$(PREFIX)/bin \
  --with-headers=$(SYSROOT)/usr/include \
  --with-sysroot=$(SYSROOT)

最後にglibcを動的リンク可能なgccは、

./configure \
  --target=$(CROSS_ARCH) \
  --prefix=$(PREFIX) \
  --enable-languages=c,c++,fortran \
  --enable-libatomic \
  --disable-libitm \
  --enable-libgomp \
  --enable-libmudflap \
  --enable-libquadmath \
  --disable-libsanitizer \
  --enable-libssp \
  --enable-libstdcxx-pch \
  --enable-long-long \
  --enable-lto \
  --disable-multiarch \
  --disable-multilib \
  --enable-nls \
  --enable-plugin \
  --enable-shared \
  --enable-threads=posix \
  --enable-__cxa_atexit \
  --with-local-prefix=$(SYSROOT)/usr \
  --with-build-sysroot=$(SYSROOT) \
  --with-sysroot=$(SYSROOT) \
  --with-native-system-header-dir=/usr/include

この設定が正しいかどうか確証は持てませんが、printfを呼び出すCソースコードをエラーなくビルド可能なコンパイラが作成できるので、良しとします。

引っかかったポイント

色々引っかかったのですが、覚えている限りのエラーと自分が取った対策を列挙しておきます。

どのバージョンのライブラリを組み合わせれば良いかわからない

私はDebianなどの既存Linuxディストリビューションが採用しているバージョンを参考にしました。ホスト側のコンパイラのバージョンも影響するため、昔ビルドが通っていた組み合わせでもビルドが通らないことはあります。

AArch64に変えるとglibcビルドエラー

エラーの内容はredefinition of 'struct user_regs_structでした。何それ……？？と思いきや、sysrootにインストールしたLinuxカーネルヘッダがRISC-V向けになっていた凡ミスでした。

glibcビルドエラー

エラーの内容はenable-multi-arch support require gcc, assembler and linker indirect-function supportでした。これは解決方法がわからんので、GCCのconfigureに --disable-multi-archを指定し、回避しています。

gccビルドエラー

エラーの内容はPthreads are required to build libgompでした。これはややこしいので、別建てで書きます。

gccビルドエラー（詳細）

エラーメッセージだけ読むとさっぱりですが、config.logに記録されたテストプログラムとテスト結果によれば、pthread.hが見当たらないと言っているようです。

• GCCのconfigureに --enable-libgompを指定したため、libgompがビルドされている
• libgompはpthread.hが見つからないのでPthreads are required to build libgompと文句を言っていた

もちろんGCCの前にglibcのクロスビルドに成功しているので、pthread.hは存在しているものの、

• glibcのヘッダをインストールする場所を間違えていた
• gccの --with-native-system-header-dirに指定したパスが間違っていた

これらの原因によって、pthread.hが見えなくなっていたようです。

感想

ツールチェーン構築って大変です。実際に体験すると、crosstool-NGやbuildrootのありがたさが身に沁みます。

Tinker BoardのHDMIから音を出す

今更ですが、メモしていなかった気がするので、Tinker Board（Rockchip RK3288搭載）でHDMI Audioを有効にする方法です。

方法は簡単でLinuxのCONFIG_DRM_DW_HDMI_I2S_AUDIOを有効にすれば良いです。5/3時点のlinux-nextのツリーでは、make defconfigするとこのコンフィグはnで、ビルド対象外になっています。手動で下記の設定を有効にする必要があります。

$ make menuconfig

  Device Drivers  --->
    Graphics support  --->
      Display Interface Bridges  --->
        [*] Synopsys Designware I2S Audio interface

設定とビルドがうまく行くと、下記のようにi2s-i2s-hifiというちょっと変わった名前のオーディオデバイスが見えるようになるはずです。

# cat /proc/asound/pcm
00-00: USB Audio : USB Audio : playback 1 : capture 1
00-01: USB Audio : USB Audio #1 : playback 1 : capture 1
00-02: USB Audio : USB Audio #2 : playback 1
01-00: ff890000.i2s-i2s-hifi i2s-hifi-0 :  : playback 1

HDMIは画像と音声が一緒に転送されますから、本来は画像側のドライバも合わせて有効にする必要があるはずです。が、画像側のドライバはdefconfigでyないしmになるようで、特殊なカーネルコンフィグを使っている人以外は気にしなくて良いでしょう。

どうして音声系のドライバだけdefconfigからハブられているのか？については謎です。私は画像側のドライバと音声側のドライバ両方ともdefconfigで有効にした方が良いのでは……と思いますが、何か理由があるのでしょう。

CONFIG_DRM_DW_HDMI_I2S_AUDIOはCODEC側なので、CPU側のコンフィグCONFIG_SND_SOC_ROCKCHIP_I2Sも紹介しておきます。とはいえdefconfigで有効になるようなので、これも通常は気にしなくて良いでしょう。

ROCKPro64とPCI Express - 解決編

目次: ROCK64/ROCKPro64

ROCKPro64のPCIeが動かなくて、しばらく放置（2019年3月16日の日記参照）していたのですが、今日久しぶりに見てみたところ、意外とあっさり直せました。

PCIeが動かなかった理由は単純で、PERST# 信号を全く制御しておらず、PCIeカードのリセットを解除していなかったためでした。それは動かないわ。

不思議なことにlinux-nextではROCKPro64以外のRK3399搭載ボードはPCIeが使えるように対応が入っているのに、ROCKPro64だけハブられています。悲しいので、作ったパッチをLKMLにぶん投げておきました。誰かの役に立てば嬉しいですね。

ちなみにROCKPro64のPCIe PERST# 信号は、こんな経路で来ていました。
RK3399 GPIO2_D4 -> PCIE_PERST_L -> PCIE_PERST_3V3_L -> PERST#

実験

我が家にはPCIeのカードが3つあります。あります、というか、わざわざROCKPro64のPCIe接続テストのために買ったという方が正しいです。

• USB 3.0増設カード
• SATA増設カード
• PCIe - PCIブリッジカード

リセットを制御していない場合、基本的にはどのボードも動きません。しかしUSB拡張カードだけはたまに動きます。不思議な挙動です。カードがPERST# を無視しているのか、偶然か、深追いしていないのでわかりません。

PERST# の制御をするように直したところ、USB 3.0カードと、SATAカードはバッチリ認識するようになりました。PCIe - PCIブリッジカードは起動中になぜかROCKPro64にリセットが掛かってしまい、うまくいきませんでした。

ROCKPro64からの給電では足りないのかと疑って、外部からブリッジカードに電源を供給してみましたが、ダメでした。PCでも使えたり使えなかったりする、割と特殊なカードらしいので、ROCKPro64では動かないのかもしれません。

さらに調べるにせよ、何にせよ、また次の機会ですね。

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

GCCを調べる - その1 - ビルド

目次: GCC

最近GCCのコードを書き換えたり、デバッガで追ったり、GCCとお友達になろうとしています。まだ仲良くなれていませんが、入り口に立つまでが色々大変だったのと、間違いなく数カ月後に手順を忘れるので、方法を書き残しておこうと思います。

GCCのコードを書き換えて、結果を反映させるには、何らかの方法でGCCをビルドする必要があります。クロスビルド用ツールチェーンの構築は、昔の日記（2019年4月28日の日記参照）に書いたとおりです。コンパイラを追うだけで、ルートファイルシステムが必要なければ、おそらくcrosstool-NGを使うのが無難です。差分ビルドがうまく行かないので、何か変更した後に再ビルドするのがちょっと面倒ですが、それ以外は簡単で便利です。

私は再ビルドが遅くてイライラしたのと、ビルドの仕組みにも興味があったので、以前の日記（2019年4月29日の日記参照）に書いたとおり、昔作ったクロスコンパイラをビルドするMakefile（GitHubへのリンク）を改造して使っています。ブランチはorigin/develop/separate-makefileです。もうこちらを本線にしても良い気がしてきたな。

オレオレGCCビルド環境

これも使い方を忘れるのでメモしておきます。手動でビルドするのとあまり変わりません。

#### ビルド用ディレクトリ

$ mkdir build_my_toolchain
$ cd build_my_toolchain


#### 環境構築用のリポジトリ

$ git clone https://github.com/katsuster/crosstool-builder
$ cd crosstool-builder
$ git checkout -t origin/develop/separate-makefile
$ cd ../


#### GCCだけリポジトリで取得する（git diffしたいから）

$ git clone https://gcc.gnu.org/git/gcc.git


## GCC-8.3.0を使う、他のバージョンでもある程度ビルドできるはず

$ cd gcc
$ git checkout gcc-8_3_0-release
$ cd ../


#### その他の依存モジュールはtarballを使用する

$ mkdir tmp
$ cd tmp
$ wget https://mirrors.edge.kernel.org/pub/linux/kernel/v4.x/linux-4.19.1.tar.xz
$ wget https://ftp.gnu.org/gnu/binutils/binutils-2.31.1.tar.bz2
$ wget https://ftp.gnu.org/gnu/glibc/glibc-2.28.tar.xz

$ wget https://ftp.gnu.org/gnu/gmp/gmp-6.1.2.tar.lz
$ wget https://ftp.gnu.org/gnu/mpc/mpc-1.1.0.tar.gz
$ wget https://ftp.gnu.org/gnu/mpfr/mpfr-4.0.2.tar.xz
$ cd ../


#### ツールチェーンに必要なモジュール

$ tar xf tmp/linux-4.19.1.tar.xz
$ tar xf tmp/binutils-2.31.1.tar.bz2
$ tar xf tmp/glibc-2.28.tar.xz

$ ln -s linux-4.19.1    linux
$ ln -s binutils-2.31.1 binutils
$ ln -s glibc-2.28      glibc


#### GCCに必要なモジュール

$ tar xf tmp/gmp-6.1.2.tar.lz
$ tar xf tmp/mpc-1.1.0.tar.gz
$ tar xf tmp/mpfr-4.0.2.tar.xz

$ cd gcc
$ ln -s ../gmp-6.1.2  gmp
$ ln -s ../mpc-1.1.0  mpc
$ ln -s ../mpfr-4.0.2 mpfr
$ cd ../

自分で書いていて面倒くさいなあと思いました。スクリプトにしたほうが良かったかもしれない。もしbinutilsも変更したりデバッグしたければ、tarballの代わりにリポジトリをチェックアウトしてくると良いです。

$ source crosstool-builder/env.sh

$ cd crosstool-builder

$ make -j4 install

デフォルトではRISC-V 64bit Linux向けのクロスコンパイラをビルドします。env.shを書き換えればAArch64やARM向けもビルド可能です。RISC-V 32bit向けはgcc-static（ベアメタル用コンパイラとして使用可能）までしかビルドできません。以降はglibcのビルドでエラーになりLinux用のクロスコンパイラはビルドできません。

$ cd crosstool-builder

$ make -f gcc-static.mk -j4 install

GCCに何か修正を入れてビルドし直すときは、ビルドし直したい *.mkファイルを指定してmake します。