コグノスケ

RISC-V 64向けLinux開発環境の構築

目次: GCC

目次: Linux

以前AArch64向けに開発環境を構築しました（その1、その2）。今回は流行りのRISC-Vに対して作成してみます。

全く違うアーキテクチャですが、AArch64向けと同じツール、ほぼ同じ手順が使えます。ツールを整備してくれた開発者の皆様には感謝の極みです。

• クロスコンパイラ: crosstool-NG
• カーネル: linux-next
• ブートローダ: riscv-pk
• ルートファイルシステム: busybox + 手作業
• エミュレータ: qemu

さっと動かしてみたかったので、前回との変化点としてはbuildrootを使わず、busyboxのみの最小環境を作成しています。buildrootは後日チャレンジしたいと思います。

クロスコンパイラ

Crosstool-NGのct-ngのビルド方法は前回と全く同じ（2018年7月15日の日記を参照）なので、割愛します。

$ ./ct-ng menuconfig
- Paths and misc options  --->
    [ ] Try features marked as EXPERIMENTAL
      選択する

- Target options  --->
  Target Architecture (alpha)  --->
    riscvに変更する

  [ ] Use the MMU
    選択する

  Bitness: (32-bit)  --->
    64-bitに変更する

- Operating System  --->
    Target OS (bare-metal)  --->
      linuxに変更する

- C-library  --->
    C library (musl)  --->
      glibcに変更する


$ ./ct-ng build
[00:34] /

設定もAArch64のときと大体同じですが、大きな違いはEXPERIMENTALを有効にする点です。通常はTarget Architectureの選択肢にRISC-Vが存在しません。

また、現時点だと32bit版はビルドエラーになるようなので、64bit版を選択しています。

カーネル

AArch64のビルドとほぼ同じです。

$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
$ cd linux-next

$ export ARCH=riscv
$ export CROSS_COMPILE=riscv64-unknown-linux-gnu-

$ make defconfig

$ make all

ビルドが成功するとソースコードのトップディレクトリにvmlinuxが生成されるはずです。

ブートローダ

AArch64ではqemuの -kernelオプションにImageファイルを渡せば起動しましたが、RISC-VではImageファイルを渡してもエラーになり起動しません。

調べてみると、qemuでRISC-V向けのLinuxを動作させるには、Imageではなくブートローダ付きのvmlinuxを渡してあげる必要があるみたいです。

$ git clone https://github.com/riscv/riscv-pk
$ cd riscv-pk

$ mkdir build
$ cd build

$ ../configure \
  --enable-logo \
  --host=riscv64-unknown-linux-gnu \
  --with-payload=../linux-next-riscv/vmlinux

$ make

成功するとbuildディレクトリの下にbblという名前のファイルができます。これがブートローダ＋カーネルのバイナリです。bblはBerkeley Boot Loaderの略です。

このリポジトリの名前pkはProxy Kernelの略で、RISC-Vのプロセッサ開発を行う際に、周辺のハードウェアを作り込む代わりに、ホストのシステムコールを呼び便利な実行環境を提供するためのソフトウェアのようです。

プロキシカーネルに用事はないんですけど、付属品のブートローダに用事があります。

このriscv-pkはビルドシステムがちょっとイマイチで、buildディレクトリを作らずにconfigureやmakeをすると、ソースコードの入っているpkディレクトリが吹っ飛びます。ご注意ください……。

ルートファイルシステム

以前はbuildrootを使って全自動でinitramfsを生成してもらいましたが、今回は趣向を変えまして、手動でinitramfsを作ります。

$ git clone https://git.busybox.net/busybox

$ cd busybox
$ export CROSS_COMPILE=riscv64-unknown-linux-gnu-

$ make menuconfig

- Settings  --->
  [ ] Build static binary (no shared libs) (NEW)

$ make

ビルドに成功するとbusyboxという実行ファイルが生成されるはずです。

次にinitramfsを作成します。基本的な流れはディレクトリに必要なファイルを配置し、cpioで固めるだけです。

$ mkdir initramfs-work-riscv
$ mkdir initramfs-work-riscv/root
$ cd initramfs-work-riscv/root

$ mkdir bin
$ cp ../../busybox/busybox bin/
$ ln -s busybox bin/sh
$ ln -s bin/busybox init

$ mkdir dev
$ sudo cp -a /dev/tty* dev/

$ find . | cpio --format=newc -o > ../initramfs.cpio

本来はinit, sh以外のシンボリックリンクも作った方が良いです。このあと、qemuで動かしてみたらわかりますが、すごく不便です。/dev/ttyも横着してホストマシンのデバイスファイルをコピーするのではなく、mkdevで作るべきです。

が、しかし、美しいinitramfsは次回トライするbuildrootにお任せしましょう。今回は適当なまま行きます。

実行

実行する設定はAArch64とは違います。qemuの引数は多すぎるし難しすぎるので、全く覚えられません。私の場合は、動かすたびにわからなくなるので、調べることが多いです。

$ qemu-system-riscv64 \
  -machine virt \
  -kernel riscv-pk/build/bbl \
  -initrd initramfs-work-riscv/initramfs.cpio \
  -serial stdio

    
bbl loader
              vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
                  vvvvvvvvvvvvvvvvvvvvvvvvvvvv
rrrrrrrrrrrrr       vvvvvvvvvvvvvvvvvvvvvvvvvv
rrrrrrrrrrrrrrrr      vvvvvvvvvvvvvvvvvvvvvvvv
rrrrrrrrrrrrrrrrrr    vvvvvvvvvvvvvvvvvvvvvvvv
rrrrrrrrrrrrrrrrrr    vvvvvvvvvvvvvvvvvvvvvvvv
rrrrrrrrrrrrrrrrrr    vvvvvvvvvvvvvvvvvvvvvvvv
rrrrrrrrrrrrrrrr      vvvvvvvvvvvvvvvvvvvvvv
rrrrrrrrrrrrr       vvvvvvvvvvvvvvvvvvvvvv
rr                vvvvvvvvvvvvvvvvvvvvvv
rr            vvvvvvvvvvvvvvvvvvvvvvvv      rr
rrrr      vvvvvvvvvvvvvvvvvvvvvvvvvv      rrrr
rrrrrr      vvvvvvvvvvvvvvvvvvvvvv      rrrrrr
rrrrrrrr      vvvvvvvvvvvvvvvvvv      rrrrrrrr
rrrrrrrrrr      vvvvvvvvvvvvvv      rrrrrrrrrr
rrrrrrrrrrrr      vvvvvvvvvv      rrrrrrrrrrrr
rrrrrrrrrrrrrr      vvvvvv      rrrrrrrrrrrrrr
rrrrrrrrrrrrrrrr      vv      rrrrrrrrrrrrrrrr
rrrrrrrrrrrrrrrrrr          rrrrrrrrrrrrrrrrrr
rrrrrrrrrrrrrrrrrrrr      rrrrrrrrrrrrrrrrrrrr
rrrrrrrrrrrrrrrrrrrrrr  rrrrrrrrrrrrrrrrrrrrrr

       INSTRUCTION SETS WANT TO BE FREE
[    0.000000] OF: fdt: Ignoring memory range 0x80000000 - 0x80200000
[    0.000000] No DTB passed to the kernel
[    0.000000] Linux version 5.0.0-rc7-next-20190225 (katsuhiro@blackbird) (gcc version 8.2.0 (crosstool-NG 1.23.0.610-db4fdf0)) #2 SMP Tue Feb 26 19:07:38 JST 2019
[    0.000000] Initial ramdisk at: 0x(____ptrval____) (1691648 bytes)
[    0.000000] Zone ranges:
[    0.000000]   DMA32    [mem 0x0000000080200000-0x0000000087ffffff]
[    0.000000]   Normal   empty
[    0.000000] Movable zone start for each node
...

[    0.346331] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
[    0.348500] NET: Registered protocol family 17
[    0.349051] Key type dns_resolver registered
[    0.370752] Freeing unused kernel memory: 192K
[    0.370952] This architecture does not have kernel memory protection.
[    0.371164] Run /init as init process
can't run '/etc/init.d/rcS': No such file or directory

Please press Enter to activate this console.
/ # ls
-/bin/sh: ls: not found
/ # busybox uname -a
Linux (none) 5.0.0-rc7-next-20190225 #2 SMP Tue Feb 26 19:07:38 JST 2019 riscv64 GNU/Linux

無事Linuxの起動画面を拝めました。良かった良かった。

ROCKPro64のHDMI Audioを有効にする

目次: ROCK64/ROCKPro64

RK3399のDrive Strength設定をMaxにしたことで、文字化けだらけでポンコツ状態だったROCKPro64のシリアルが割とまともになったので、最近はROCKPro64を触っています。

どうもlinux-nextのROCKPro64のデバイスツリーはHDMI Audioを有効にするのを忘れている？ようで、HDMIから音が出ません。有効にするパッチをLMKLに投げつけておきました……といっても、たった3行のパッチです。

動かしたら一瞬で気づくはずですが、誰も直さなかったのかなあ？

ROCK64もROCKPro64も割と有名な部類のボードですが、Rockchip Linuxじゃなくて、わざわざlinux-nextで動かす人は少ないかもしれませんね。

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

RISC-V向けクロスコンパイラ

目次: GCC

目次: Linux

Crosstool-NGはRISC-Vに対応していないのかと思っていたら、Experimentalオプション（CT_EXPERIMENTAL）をYに設定したらRISC-Vが選べるみたいです。

GCCのビルドはARM向けに昔チャレンジしましたが、結構面倒くさいので、コンパイラを含むツールチェーンを簡単にビルドできるCrosstool-NGの存在は非常にありがたいです。あとはLLVMにも対応してくれたら最高なんですけどね。

ExperimentalというだけあってRISC-V 32bit用のコンパイラはビルドエラーになってしまって作成できません。RISC-V 64bit用のコンパイラは作成できます。

作成したコンパイラで適当なコードをビルドして逆アセンブルを見ると、命令長が32bitのものと、16bitのものが混在していました。そういえばARMもARM命令とThumb命令の2種類の命令長があります。最近はRISCでも命令長可変の仕様が流行りなんでしょうか？

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

ROCKPro64のシリアル文字化け - 回路図を見る

目次: ROCK64/ROCKPro64

ROCKPro64のシリアル文字化けの原因は、RK3399の端子ドライブ能力不足が原因である可能性は高そうですが、最大値の12mAに設定しても立ち上がりが遅い（立ち下がり50ns以下に対し、立ち上がり300ns以上かかる）点が気になります。

SoC以外に原因があるとすれば、ボードの回路くらいですが、回路となると門外漢も良いところで、確かめ方がわかりません。

ROCKPro64のSchematicsを素直に信じると、SoCの出力ピンが直接コネクタに接続されていて、抵抗も何もないように読めます。RK3399はSoC裏面がハンダ付けされている（BGA）ため、コネクタ〜SoC端子間に、本当に抵抗や断線がないかどうかは確かめようがありません。

文字化けの頻度はかなり減ったので、今のままでもそれなりに使えますが、なぜ立ち上がりだけが異常に遅いのか、釈然としません。うーん……。

ドライバ観点からのROCK64やROCKPro64の使いやすさ

ROCK64というかRockchip RK3328のHDMIドライバはdrivers/gpu/drm/rockchip/dw_hdmi-rockchip.cです。このドライバは多くの処理をdrivers/gpu/drm/bridge/synopsys/dw-hdmi.cつまりSynopsys DesignWareのHDMI IP用のドライバに頼っています。

SynopsysのHDMIドライバは映像出力と、音声出力の機能を持っています。映像側の作りは知りませんが、音声側はASoCフレームワークに合わせて作られています。そのお陰でROCK64にHDMI音声出力対応を追加するときは、デバイスツリーに記述を足すだけで良く、非常に楽でした。

Synopsysのドライバはlinux-nextにUpstreamされていますが、コミットログを見る限りSynopsysのメールアドレスの人はあまり出現しません。

社外の人や、会社と関係のない所属の人がわざわざドライバに修正をコミットしてくれるなんて、凄いことだと思います。人気のあるIPのドライバをOSSにすると、色々な人が直してくれて、正のスパイラルが構築される、良い例と言えるでしょう。

この辺の根回しの良さは、さすがIP屋さんのSynopsysって感じがしました。

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

ROCKPro64のシリアル文字化け - オシロスコープで解析

目次: ROCK64/ROCKPro64

以前（2018年12月）にROCKPro64を購入したのですが、シリアルが文字化けして使い物にならず、ずっとお蔵入りになっていました。

最初はケーブルの接続や、接地がおかしいのかと思いましたが、GND側はきっちり0Vでした。どうも単純な原因ではなさそうだったので、オシロスコープで信号を見ることにしました。テストパターンとして0と1が交互に出現し、一番転送が難しいパターンと思われる0x55 'U' の文字を出力しています。

正常に出力できているROCK64と比較すると、ROCK64は出力が0 → 1 → 0と変化する際に0V → 3V → 0Vのように電圧が振れますが、ROCKPro64は、0V → 2.48V → 0Vのように立ち上がり側が遅く、中途半端な電圧になっています。

下記の画像の青色の線がROCK64のシリアル出力で、オレンジ色の線がROCKPro64のシリアル出力です。どちらも1秒ごとに 'U' を出力して、最初の立ち下がり（Start Bit、必ず0）にトリガを掛けています。

ROCK64のシリアル出力の波形

ROCKPro64のシリアル出力の波形

ROCK64は綺麗な波形ですが、ROCKPro64は0V → 3Vへの立ち上がりが間に合っていないことが分かるかと思います。

文字化けの原因ですけども、シリアルの転送速度（1.5Mbps、1ビット666ns）に対し、0 → 1の立ち上がりが遅すぎる（650nsくらい）からでしょう。出力側は1を送出しているつもりでも、信号が立ち上がるのが遅いため、受信側は0だと解釈してしまう場合があります。

転送速度を落とせば改善するかもしれません。しかしRockchipのU-Bootはなぜか1.5Mbps固定で転送してくる困った奴で、下手にシリアルの転送速度を変えるとU-Bootが操作できなくなり、非常に使いづらいのです。イマイチですね……。

ROCKPro64のシリアル出力の文字化けを改善する

ROCKPro64にはRockchipのRK3399と言うSoCが搭載されていて、RK3399は一部のピンのDrive Strength、つまりピンに流せる電流量を調整できます。決して特殊な機能ではなく、大抵のSoCが持つ普通の機能です。

ROCKPro64がコネクタに引き出しているシリアルはUART2です。UART2はGPIO4_C4（TX）とGPIO4_C3（RX）というピンに割り当てられています。幸運なことにRK3399ではこれらのピンのDrive Strengthが変更できるので、設定値を振って（※）オシロで波形を見てみました。

下記の画像が測定結果です。1枚目はデフォルトかつ最小の3mA、2枚目は最大の12mA設定です。出力している文字は前回同様0x55 'U' で、トリガも前回同様Start Bitの立ち下がりに仕掛けています。オシロのRising, Falling Time解析をONにしたので、立ち上がり、立ち下がりに掛かった時間も一緒に表示されています。

Drive Strength = 3mAのときのシリアル出力波形

Drive Strength = 12mAのときのシリアル出力波形

字が若干見づらいので、一応書いておくと、立ち上がりの時間は650ns → 300nsくらいに改善しました。良い感じですね。

ちなみにスクリーンショットの色が変で、文字が読みづらいのは仕様です。Tektronixさん、スクリーンショット背景の白黒反転処理、バグってますよ……？？

それはさておきDrive Strengthの変更で、ROCKPro64のシリアル文字化けはかなり改善されました。しかし完全ではなく大量に出力した際に若干文字化けします。

さらなる改善のためには、シリアルの転送速度を落とすくらいしか思いつきません。が、U-Bootの書き換えをするのが面倒くさいので、また今度にします……。

（※）レジスタ名はGRF_GPIO4C_Eで、アドレスは0xff77e138です。書き込む値は0x03c00xx0をお勧めします。xxの部分はドライブ能力を最小にするなら00で、最大にするなら3cです。

メモ: 技術系の話はFacebookから転記しておくことにした。追記、文章の組み換えをした。