Ubuntu Weekly Recipe

第753回VisionFive 2でriscv64なUbuntuを動かす

第752回ではStarFiveのRISC-VボードであるVisionFive 2について紹介し、初期ファームウェアのアップグレード方法と、StarFiveが提供するDebianイメージをインストールする方法を紹介しました。今回はこれをUbuntu化してみましょう。

VisionFive 2のカーネルサポート状況

UbuntuはまだVisionFive 2をサポートしていません。これは主にカーネル側の対応をどうするか見極めているという状況です。たとえばVisionFive 2向けのカーネルのパッチやDTB等がすでにLinuxカーネルの新しいバージョンのリポジトリに取り込まれているようなら、修正内容にもよるものの、Ubuntuでそれを採用するのはそこまで難しい話ではありません。また、開発中のブランチで取り込まれているものを暫定的に取り込むということもあります。

ただし、3月頭時点では、Ubuntu用のカーネルパッケージや将来Ubuntuのカーネルの元となる各種リポジトリには、まだVisionFive 2向けのパッチは入っていません。

ちなみにStarFiveのリポジトリはKernel 5.15ベースに独自のパッチを適用している状態です。これが昨年末ぐらいに、Linuxの本流に取り込まれるよう作業を行っていたようです。しかし、次期リリースであるKernel 6.3向けのRISC-V関連開発リポジトリにはまだ入っていない状態で、その元となる開発リポジトリのひとつにはVisionFive 2関連のパッチが取り込まれた状況のようです。

つまり、現在の状態を考えるとUbuntu 23.04のカーネルはもちろん、その先のKernel 6.3でも未対応で、うまくいけばKernel 6.4で対応されるかもしれない、ぐらいのようです。そうするとUbuntu 23.10あたりが現実的な線でしょうか。あとはCanonicalのKernel TeamがRISC-V対応に対してどれくらい注力しているかによって、どれくらい前倒しされるかが変わってくると思われます。

ちなみにVisionFive 2のSoCはJH7110であるため、DTSの名前もjh7110-starfive-visionfive-2-v1.3b.dtsとなっています。これがarch/riscv/boot/dts/starfive/の中に作成されれば、少なくともコードレベルではVisionFive 2の最低限の機能をサポートしていることが期待されます。

というわけで、StarFiveが修正しているカーネル以外は、今のところVisionFive 2では使えなさそうな雰囲気です。そこで今回はカーネルはそのままで、ユーザーランドだけUbuntuに変更してみましょう。

VisionFive 2におけるDebian起動の流れ

VisionFive 2向けのDebianがインストールされたmicroSDカードにUbuntuを上書きインストールすることにします。そこで、何を残して、どこは上書きして良いかを確認するために、まずは既存のシステムの起動の流れを確認しておきましょう。

VisionFive 2はU-BootからLinuxカーネルとDebianを起動する仕組みです。VisionFive 2のU-Bootの場合、次のような流れでシステムが起動します。

  1. QSPI FlashからU-Bootが起動する
  2. U-Bootはハードウェの初期化や認識に合わせて、microSDカードを認識する
  3. microSDカード上の/boot/extlinux/extlinux.confから起動エントリーを作成し・決定する
  4. 上記にエントリー基づいて、microSDカードからカーネル・initramfs・DTB(Device Tree Blob)をメモリにロードする
  5. カーネルの起動オプションを設定する
  6. メモリ上のカーネルを実行する
  7. カーネルはinitramfsを展開し、その内部のスクリプトを実行する
  8. initramfsは必要なカーネルのモジュールをロードする
  9. initramfsはDebianのストレージをマウントし、systemdを起動する

1から6まではU-Bootの仕事です。シリアルコンソールを接続していた場合は、次のようなログが表示されます。

Model: StarFive VisionFive V2
Net:   eth0: ethernet@16030000, eth1: ethernet@16040000
switch to partitions #0, OK
mmc1 is current device
found device 1
bootmode flash device 1

  => microSDカードを認識し、それを起動デバイスとする

Retrieving file: /boot/extlinux/extlinux.conf
823 bytes read in 4 ms (200.2 KiB/s)
U-Boot menu
1:      Debian GNU/Linux bookworm/sid 5.15.0-starfive
2:      Debian GNU/Linux bookworm/sid 5.15.0-starfive (rescue target)
Enter choice: 1:        Debian GNU/Linux bookworm/sid 5.15.0-starfive

  => メニューエントリーを表示し、自動的に決定する

Retrieving file: /boot/initrd.img-5.15.0-starfive
9684953 bytes read in 412 ms (22.4 MiB/s)
Retrieving file: /boot/vmlinuz-5.15.0-starfive
8015200 bytes read in 341 ms (22.4 MiB/s)
append: root=/dev/mmcblk1p3 rw console=tty0 console=ttyS0,115200 earlycon rootwait stmmaceth=chain_mode:1 selinux=0
Retrieving file: /boot/dtbs/starfive/jh7110-visionfive-v2.dtb
47546 bytes read in 7 ms (6.5 MiB/s)
   Uncompressing Kernel Image
Moving Image from 0x44000000 to 0x40200000, end=41767000
## Flattened Device Tree blob at 48000000
   Booting using the fdt blob at 0x48000000
   Using Device Tree in place at 0000000048000000, end 000000004800e9b9

   => カーネル・initramfs・DTBをロードし、起動オプションを設定する

Starting kernel ...

   => カーネルを実行する

カーネル等は、第752回でmicroSDカードに展開したStarFiveのデータだと、2番目パーティション/dev/mmcblk1p2に保存されています。ちなみに実際のパーティションテーブルは次のような内容になっています。

$ sudo parted /dev/mmcblk1 print
Warning: Not all of the space available to /dev/mmcblk1 appears to be used, you can fix the GPT to use all of the space (an extra 90705920 blocks) or continue with the current setting?
Fix/Ignore? i
Model: SD USDU1 (sd/mmc)
Disk /dev/mmcblk1: 63.2GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system  Name  Flags
 1      1049kB  17.8MB  16.8MB
 2      17.8MB  123MB   105MB   fat16              boot, esp
 3      123MB   16.8GB  16.7GB  ext4               legacy_boot

「fat16」になっているパーティションがカーネルが入っている(U-Bootからアクセスされる)領域です。実際にDebianからも内容を確認できます。

$ ls /boot/boot/
System.map-5.15.0-starfive  extlinux                    vmlinuz-5.15.0-starfive
config-5.15.0-starfive      initrd.img-5.15.0-starfive
dtbs                        uEnv.txt

このうちカーネルはもちろん、initramfsinitrd.imgやDTBもStarFavie/Debianのそれを、Ubuntuでもそのまま流用することにしましょう。また、カーネルの起動パラメーターは次のようになっています。

$ cat /proc/cmdline
root=/dev/mmcblk1p3 rw console=tty0 console=ttyS0,115200 earlycon rootwait stmmaceth=chain_mode:1 selinux=0

root=/dev/mmcblk1p3から、3番目のパーティションにルートファイルシステムが入っていることがわかります。よって/dev/mmcblk1p2はそのままにしておき、/dev/mmcblk1p3をUbuntuのイメージで上書きすれば良さそうです[2]

ただし、注意点としてinitramfsから実際のrootfsに処理が移ったあとのカーネルモジュールは、起動カーネルに合わせたものを用意しなくてはなりません。そこで、今回はDebianのイメージからカーネルモジュールを取り出して利用することにします。

Ubuntuのルートファイルシステムを構築する方法あれこれ

Ubuntuのコアルートファイルシステムを作るにはいくつかの方法が存在します。

  • Ubuntu Baseに必要なパッケージを追加していく
  • Minimal Ubuntuに必要なパッケージを追加していく
  • debootstrapでルートファイルシステムを作る
  • mmdebstrapででルートファイルシステムを作る
  • Chiselでルートファイルシステムを構築する

Ubuntu BaseはUbuntuがインストール済みの最小のイメージという位置づけです。主に組み込み・コンテナ向けに、このイメージをベースに必要なものを追加してインストールして、最終的なルートファイルシステムを構築することを意図しています。このためmanファイルや各種ドキュメントがインストールされないようにパッケージ管理システムを設定しています。

それに対してMinimal Ubuntuはクラウドインスタンス向けのイメージです。Baseに対して5倍以上のサイズですが、サーバー向けに必要なものが一通りインストールされている状態になります。単なるファイルアーカイブだけでなく、ディスクイメージや、squashfs形式でも提供しているのが特徴です。ただしUbuntuのクラウドイメージとしてサポートしているアーキテクチャー(現在だとamd64)だけしか対応していないため、今回の用途には不向きです。

debootstrapは、Debianパッケージのビルド環境を構築するために使われるツールです。ただしこのビルド環境は、aptコマンドが動く小さなDebianとも言える環境であるため、Dockerが登場した頃もベースイメージの作成によく使われていました。メジャーでないCPUアーキテクチャーであってもDebianがサポートしていたら使えるという汎用的なツールでもあります。

mmdebstrapはdebootstrapに対して、ビルド環境よりも「コアイメージの作成」を意識した作りのツールです。比較的シンプルなオプションで高速にベースのルートファイルシステムを構築できるため、最近は広く使われるようになりました。組み込みやコンテナ向けに1からルートファイルシステムを作りたいなら、大変便利なツールでしょう。本連載でも第594回のmmdebstrapで最小のルートファイルシステムを作るで使い方を紹介しています。

最後のChiselはCanonicalが開発している、YAMLの設定ファイルから小さなルートファイルシステムを作る仕組みです。特定のバイナリを動かすために必要なファイルだけを、既にあるルートファイルシステムからピックアップして再アーカイブする作りになっているため、今回の用途には向きません。Chiselに関してはUbuntu Weekly Topicsの2022年8月19日号でも紹介しています。

今回の用途を考えると、Ubuntu Baseから作るかmmdebstrapを使うのが良さそうです。一発ですべて構築してしまうならmmdebstrapのほうが便利ではあるのですが、トライアンドエラーで設定ファイルを変更するならどちらでも手間は変わりません。そこで今回はUbuntu Baseで構築してみましょう。

Ubuntu Baseを元にRISC-V向けのルートファイルシステムを作る

ようやく本題に入れます。Ubuntu BaseはUbuntuのイメージサーバーから取得して、それを展開するだけでOKです。これはVisionFive 2に比べて性能の良い、amd64なマシン上で実行すると良いでしょう。64bitなRISC-V CPU向けのriscv64アーキテクチャーもサポートしているため、次の手順でダウンロード&展開してください。

$ wget http://cdimage.ubuntu.com/ubuntu-base/releases/22.04/release/ubuntu-base-22.04.2-base-riscv64.tar.gz
$ mkdir rootfs
$ sudo tar pxf ubuntu-base-22.04.2-base-riscv64.tar.gz -C rootfs
$ echo 'APT::Sandbox::User "root";' | sudo tee rootfs/etc/apt/apt.conf.d/90run-as-root

最後の行は、Aptシステムにおけるパッケージのダウロードや署名の検証を_aptユーザーではなくrootで行うための対応です。作成した環境に「ログインする」際の方法によっては設定したほうが良いために実施しています。

ここからは作成したrootfs「ログイン/chroot」して作業を行うことになります。これもいろいろな方法がありますが、一番手っ取り早いのはsystemd-nspawnコマンドを使う方法です。systemd-nspawnについては、第491回のいまから『あえて』systemdのコンテナ機能を使ってみるでも詳しく紹介しているので、必要ならそちらも参考にしてください[3]

今回はamd64なマシンの上で、riscv64のルートファイルシステムに入って、バイナリを実行しなくてはなりません。そこで使うのが「qemu-user-static」です。このパッケージが提供するアーキテクチャーごとのバイナリをルートファイルシステムに置いておくと、必要に応じてQEMU経由でコマンドを実行してくれるようになります。そこで、必要なパッケージを一式ダウンロードし、riscv64向けのqemu-user-staticをルートファイルシステムにコピーしておきましょう。

$ sudo apt install systemd-container binfmt-support qemu-user-static
$ sudo cp /usr/bin/qemu-riscv64-static rootfs/usr/bin/

これで準備は完了したので、さっそくsystemd-nspawnでルートファイルシステムの中に入ります。

$ sudo systemd-nspawn -D rootfs
root@rootfs:~# dpkg --print-architecture
riscv64
root@rootfs:~# apt update && apt full-upgrade -y && apt autoremove -y

アーキテクチャーがriscv64になっていること、さらにはネットワーク経由でパッケージをダウンロード・更新できることを確認しておいてください。以降はVisionFive 2向けの設定ファイルの変更に入ります。

ドキュメント類の再インストール

まずはUbuntu Baseが、manページ等のドキュメントをインストールしていないため、これを再有効化します。ちなみにインストールされていなくても、manコマンドが使えない程度であり、Ubuntuとして使う分には問題ありません。もしストレージの使用量を気にするのであれば、この手順はスキップしてもかまいません。

再インストールは/usr/local/sbin/unminimizeを実行するだけです。必要に応じてパッケージを再インストールすることになるため、ネットワークの負荷には注意してください。

root@rootfs:~# /usr/local/sbin/unminimize
This system has been minimized by removing packages and content that are
not required on a system that users do not log into.

This script restores content and packages that are found on a default
Ubuntu server system in order to make this system more suitable for
interactive use.

Reinstallation of packages may fail due to changes to the system
configuration, the presence of third-party packages, or for other
reasons.

This operation may take some time.

Would you like to continue? [y/N] y
(略)
Reinstalling packages with system documentation in /usr/share/doc/ ..
dpkg-query: error: --search needs at least one file name pattern argument
(略)
Restoring system translations...
dpkg-query: error: --search needs at least one file name pattern argument
(略)
Documentation has been restored successfully.
root@rootfs:~# echo $?
0

エラーっぽいメッセージが2箇所で表示されていますが、これらはドキュメント等の未インストールがまだ存在するかをチェックしている部分です。チェックした結果、特に再インストールする必要がなくても、続きのコマンドを実行するためこのようなメッセージが表示されます。最後にDocumentation has been restored successfully.と表示されるのであれば、問題ありません。

各種パッケージのインストール

次にUbuntuとして最低限のパッケージをインストールしましょう。Debianパッケージには「タスク」という概念があり、タスクを指定することでそのタスクに必要なパッケージセットをインストールできます。Ubuntuの場合、⁠minimal」はLinuxシステムとして動かす上で必要か、使う可能性が高いパッケージ(loginやbash/dashなど)が入りますし、⁠standard」だとサーバー・デスクトップ問わずどの環境でもあったほうが良いパッケージ(nftablesやparted、manなど)が入ります。また、サーバー向けには「server-minimal」「server」タスクが存在します。

Ubuntuのサーバーイメージに近づけるならこれらすべてをインストールしておいたほうが良いですが、最低限「minimal」を入れておけば、あとは必要に応じて追加していくことも可能です[4]

aptコマンドでタスクを指定する方法は第331回の「パッケージ管理のハウツー集」にあるパッケージセットをインストールしたいで紹介しているように、末尾に^を付けるだけでOKです。

root@rootfs:~# apt install -y minimal^ standard^ server-minimal^ server^

すべてインストールするとなるとそれなりの時間がかかるので注意してください。さらにインストールの途中でいくつかの質問が行われます。

たとえばkeyboard-configurationの設定は、特にベストマッチするものがなければ「Generic 105-key PC」を選びましょう。日本語キーボード向けのjp106はここには登場しません。日本語キーボードの場合は、そのあとの項目で「Japanese」を選べば問題ありません。console-setupは最初から選択されている項目(UTF-8等)をそのまま選択します。

他にも必要なパッケージがあれば、このタイミングでインストールしましょう。たとえばstarfive.localのようにアクセスできるようにしたければavahi-daemonをインストールすると良いですし、日本語のファイルを編集するなら、日本語のロケール設定も必要です。後者は手動で設定しても良いですが、language-pack-jaをインストールしておくと一通り設定してくれて便利です。

root@rootfs:~# apt install language-pack-ja avahi-daemon

ただしメッセージ類も日本語化されてしまうので、使い方によっては再度ロケールを変更したくなるかもしれません。

fstabの作成

/etc/fstabはDebianのそれをそのまま持ってくると良いでしょう。

root@rootfs:~# cat <<EOF > /etc/fstab
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/dev/mmcblk1p2       /boot       vfat    defaults       0 2
/dev/mmcblk1p3       /       ext4    errors=remount-ro       0 1
EOF

ユーザーの追加

Ubutnu Baseにはパスワードが無効化されたrootしかいません。そこでユーザーを作成しましょう。Ubuntuにはコマンドオプションをシンプルにできるadduserと、細かく設定できるuseraddが存在します。Ubuntuの流儀に合わせるなら、adduserで作るのがおすすめです。--gecosオプションにフルネームを指定してやれば、あとはパスワードを入力するだけです。

root@rootfs:~# adduser --gecos "フルネーム" ユーザー名
Adding user `ユーザー名' ...
Adding new group `ユーザー名' (1000) ...
Adding new user `ユーザー名' (1000) with group `ユーザー名' ...
Creating home directory `/home/ユーザー名' ...
Copying files from `/etc/skel' ...
New password:(パスワードの入力)
Retype new password:(同じパスワードを再入力)
passwd: password updated successfully

もしパスワード入力も含めて自動化したいなら、useraddを利用してください。作成したユーザーは、管理者として使いたいのでsudoグループに所属させます。他にもインストール時に作ったユーザーが所属するグループにも一通り所属させたければ、次のように実行します。

root@rootfs:~# usermod -aG adm,cdrom,sudo,dip,plugdev ユーザー名
root@rootfs:~# id ユーザー名
uid=1000(ユーザー名) gid=1000(ユーザー名) groups=1000(ユーザー名),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev)

ネットワーク関連の設定

ネットワーク関連の設定を行いましょう。Ubuntuはnetplanという仕組みを使って、ネットワークの設定を管理しています。今回は管理ポートにDHCPv4でアドレスを割り触れればいいので、次のように設定できます。

root@rootfs:~# cat <<EOF > /etc/netplan/01-base.yaml
network:
  ethernets:
    eth0:
      dhcp4: true
  version: 2
EOF
root@rootfs:~# netplan generate

ただし上記のようにserver-minimalタスクをインストール済みなら、cloud-initが初回起動時に勝手に設定してくれるようです。設定がバッティングしてしまうため、その場合はファイルを作らずにおきましょう。作ってしまった場合は/etc/netplan/01-base.yamlを削除するだけでOKです。

/etc/hosts/etc/hostnameも作っておきます。どちらも「starfive」のところは任意の名前でOKです。

root@rootfs:~# echo "starfive" > /etc/hostname

root@rootfs:~# cat <<EOF >/etc/hosts
127.0.0.1       localhost
127.0.1.1       starfive

# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
EOF

もしSSHにパスワードログインしたいなら、次のように設定しておきましょう。

root@rootfs:~# sed -i 's/^#\(PasswordAuthentication\) .*$/\1 yes/' /etc/ssh/sshd_config

カーネルモジュールのブラックリストの設定

StarFiveのDebianには、カーネルモジュールのブラックリストが追加されていました。理由はわかりませんが、Ubuntuでも設定しておきます。

root@rootfs:~# cat <<EOF > /etc/modprobe.d/blacklist-starfive.conf
blacklist starfive_mailbox_test
blacklist e24
blacklist xrp
blacklist starfive_mailbox
EOF

ルートファイルシステムからのログアウト

これでルートファイルシステムの中で実行するコマンドは一通り完了です。ログアウトする際に不要なファイルを削除しておきます。

root@rootfs:~# rm /etc/apt/apt.conf.d/90run-as-root
root@rootfs:~# exit
logout
Container rootfs exited successfully.
$ sudo rm rootfs//usr/bin/qemu-riscv64-static

カーネルモジュール等のインストール

カーネルモジュールは、StarFiveのDebianにあるものをそのまま持ってきます。Debianが動いているVisionFive 2が残っているようなら、次のようにSSH経由で一通りコピーしてください。rsyncコマンドなので末尾のスラッシュのあるなしが重要な点に注意してください。

$ sudo rsync -a user@starfive.local:/usr/src/linux-headers-5.15.0-starfive rootfs/usr/src/
$ sudo rsync -a user@starfive.local:/usr/lib/linux-image-5.15.0-starfive rootfs/usr/lib/
$ sudo rsync -a user@starfive.local:/lib/modules/5.15.0-starfive rootfs/lib/modules/

ルートファイルシステムのアーカイブ

再利用しやすいように、ルートファイルシステムをアーカイブしてしまっても良いでしょう。この際ファイルのオーナーやパーミッションが保持されるようにオプションには注意してください。

$ (cd rootfs; sudo tar --same-owner -capf ../visionfive.base.tar.gz *)

VisionFive 2向けのmicroSDカードの作成

ルートファイルシステムができたので、VisionFive 2向けにmicroSDカードを構築します。空のカードからパーティションを切って作っても良いのですが、もしDebianインストール済みのカードの中身を消していいなら、それをそのまま流用するほうが簡単です。ここではその方法を紹介しましょう。

まずはVisionFive 2の電源を切って、microSDカードをPCに接続します。Ubuntuなら/media/shibata/rootにDebianのルートファイルシステムがマウントされるはずなので、それを削除してしまいます。

$ sudo rm -rf /media/shibata/root/*

先ほど作成したルートファイルシステムのアーカイブを、/media/shibata/rootに展開しましょう。

$ sudo tar pxf visionfive.base.tar.gz -C /media/shibata/root/
$ sudo sync
$ sudo umount /media/shibata/root/

これで準備は完了です。microSDカードをVisionFive 2に接続し直して電源を入れます。シリアルコンソールを繋いでおくと何か問題があってもすぐにわかるのでおすすめです。ただし、なくてもおそらく起動すると思うので、ネットワークポートのアクティビティLEDや、緑色のLEDによるストレージのアクセスから、起動の程度を把握しstarfive.localへのSSHログインを試してみると良いでしょう。starfiveの部分は/etc/hostnameに設定した名前になります。うまくログインできたら完成です。

shibata@starfive:~$ uname -a
Linux starfive 5.15.0-starfive #1 SMP Mon Dec 19 07:56:37 EST 2022 riscv64 riscv64 riscv64 GNU/Linux
shibata@starfive:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 22.04.2 LTS
Release:        22.04
Codename:       jammy

無事にUbuntu 22.04 LTSになりました。

Ubuntuでのパフォーマンス

試しに第752回と同じように性能を評価してみましょう。まずはfioによるストレージアクセスの結果です。

$ jq -r '.jobs[] | [.jobname, if .read.bw > 0 then .read.bw, .read.iops | round
    else .write.bw, .write.iops | round end] | @tsv' \
    results.json | column -t --table-columns JOB,KB/s,IOPS --table-right KB/s,IOPS
JOB                  KB/s  IOPS
SEQ1MQ8T1-Read      22993    22
SEQ1MQ8T1-Write     12097    12
SEQ128KQ32T1-Read   23011   180
SEQ128KQ32T1-Write  12041    94
RND4KQ32T16-Read     8298  2075
RND4KQ32T16-Write    2408   602
RND4KQ1T11-Read      6382  1596
RND4KQ1T1-Write      2150   538

Debianのときと結果は同じになりました。カーネルが一緒なので当然といえば当然ですね。

次にsbc-bench.shの結果です。

$ sudo ./sbc-bench.sh -c
(略)

Results validation:

  * No mismatch between advertised and measured max CPU clockspeed
  * Background activity (%system) OK
  * No throttling

Memory performance
memcpy: 861.3 MB/s
memset: 758.3 MB/s

7-zip total scores (3 consecutive runs): 4028,4127,4016, single-threaded: 1179

OpenSSL results:
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-128-cbc      23357.03k    29324.50k    31249.32k    31819.78k    31976.11k    31943.34k
aes-128-cbc      23628.61k    29400.47k    31308.12k    31830.70k    31973.38k    31954.26k
aes-192-cbc      20945.81k    25931.18k    27408.04k    27808.43k    27915.61k    27885.57k
aes-192-cbc      21130.03k    25807.42k    27401.56k    27799.55k    27918.34k    27891.03k
aes-256-cbc      19514.63k    23093.23k    24370.09k    24687.62k    24775.34k    24767.15k
aes-256-cbc      19514.07k    23201.19k    24367.02k    24687.96k    24775.34k    24767.15k

Full results uploaded to http://ix.io/4q00

前回の比較表にUbuntuを加えると次のようになります。こちらもほぼ一緒です。

Device Clock Kernel 7-zip multi/single AES memcpy memset
RasPi 3B+ 1.4GHz 4.14 3240/914 36600 1130 1530
RasPi 4 1.8GHz 5.10 5790/1769 36260 2330 3120
VF2 Debian 1.5GHz 5.15 4090/1194 6820 860 760
VF2 Ubuntu 1.5GHz 5.15 4060/1179 24770 860 760

Debianの結果に比べるとUbuntuの結果のAESが劇的に改善しています。実施ログを確認してみたところ、どうやら利用しているOpenSSLのバージョンが違うようです。

  • OpenSSL 1.1.1f, built on 31 Mar 2020
  • OpenSSL 3.0.2, built on 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022)

理由までは調べていないのですが、おそらくこのバージョンの違いが影響したのだと思われます。ただし、そもそもDebianもbookworm/sidはだいぶ前にOpenSSL 3.0.xになっているはずなので、テスト時に1.1.1fになっているのが少し不思議ですね。

さらにカスタマイズするなら

もしデスクトップを使ってみたいなら「ubuntu-desktop」パッケージをインストールしてください。ただしXfceであのような結果になっていたので、GNOMEはさらに厳しいと思います。将来GPUアクセラレーションが使えるようになれば、もう少し変わってくるかもしれません。

microSDをストレージに使っている以上、ストレージのI/O頻度は気になるかもしれません。たとえばjournaldの記録先は揮発しても良いのなら、tmpfs上に書くなどの対応を行っても良いでしょう。そもそもルートファイルシステムを読み込み専用のsquashfsにしてしまって、overlayfsで書き込み領域をtmpfsに載せてしまう(再起動する度にデータをリセットする)という作りにしてしまう方法もあります。

UbuntuなのでsnapパッケージやLXDを使えるか確認してみるのも良いでしょう。PCのQEMUで動かすRISC-V環境と比較して、RISC-Vのビルド環境としてどちらが高速化を比較してみるのも良いかもしれません。

おすすめ記事

記事・ニュース一覧