コグノスケ

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 します。

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から転記しておくことにした。多少修正。

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で有効になるようなので、これも通常は気にしなくて良いでしょう。