コグノスケ

Linuxを調べる - initrdとカーネル引数

目次: Linux

今どき（？）のinitrdとカーネル引数の渡し方を知らなかったのでメモしておきます。

昔のARM LinuxですとATAGと呼ばれるブートの情報を並べたリストをメモリ領域に置いてカーネル引数やinitrdを渡して（ATAGの仕様はVincentさんのBooting ARM Linuxが詳しいです）いました。ATAGは今も使えます（Booting ARM Linuxの4a. Setup the kernel tagged list）けど主流はデバイスツリーのはずです。たぶん。ARM Linuxの場合レジスタに指定すべき情報はこんな感じだそうです。

• r0: 0
• r1: machine type number discovered in (3) above
• r2: physical address of tagged list in system RAM, or physical address of device tree block (dtb) in system RAM

RISC-V Linuxの場合はカーネルのドキュメント（RISC-V Kernel Boot Requirements and Constraints）によれば、RISC-V Linuxの場合レジスタに指定すべき情報はこんな感じだそうです。

• $a0 to contain the hartid of the current core.
• $a1 to contain the address of the devicetree in memory.

ARM Linuxよりさらに減ってhartidとデバイスツリーのアドレスのたった2つです、シンプルですね。

デバイスツリーの例

仕様からデバイスツリーを書いても良いですが、目の前のQEMUでDebianが動作している（2024年8月2日の日記参照）のですから実際に動作しているものを調べたほうが早いでしょう。

QEMUが内部で生成しているデバイスツリーのダンプ方法は以前（2024年7月23日の日記参照）紹介した通りです。initrdとappend="root=/dev/nfs"を渡してQEMUを起動し、デバイスツリーをダンプして＆dtsに変換します。

$ qemu-system-riscv64 \
  -machine virt \
  -bios none \
  -chardev stdio,id=con,mux=on \
  -serial chardev:con \
  -smp 4 \
  -kernel fw_payload.bin \
  -initrd initramfs.cpio \
  -append "root=/dev/nfs"

(QEMUモニターにて) dumpdtb virt_initrd_cmd.dtb

$ dtc -O dts virt_initrd_cmd.dtb > virt_initrd_cmd.dts

/* virt_initrd_cmd.dts */

/dts-v1/;

/ {

...

	chosen {
		bootargs = "root=/dev/nfs";           /* ★appendで渡したカーネル引数★ */
		linux,initrd-end = <0x84227600>;      /* ★initrd終端アドレス★ */
		linux,initrd-start = <0x84000000>;    /* ★initrd先頭アドレス★ */
		stdout-path = "/soc/serial@10000000";
		rng-seed = <0x2a0a5693 0x41742b2a 0x49faf2f1 0xaf1d27cc 0x9c06cb87 0x277e3472 0xfdf688c7 0x5029079c>;
	};

...

ルートノード以下のchosenノードにあるbootargs, linux,initrd-なんとかがappendやinitrdオプションと対応しています。

• bootargs: appendオプションに指定したカーネル引数
• linux,initrd-start: initrdオプションに指定したファイルをロード（QEMUがやってくれる）した領域の「先頭」アドレス
• linux,initrd-end: initrdオプションに指定したファイルをロード（QEMUがやってくれる）した領域の「終端」アドレス

以上、今どきのLinuxに対してカーネル引数やinitrdを渡す方法がわかりました。Linuxでデバイスツリーに対応したアーキテクチャは多いですから、一度実装しておけば多数のアーキテクチャでカーネルパラメーター指定ができます。便利ですね。

欠点はブートローダーでデバイスツリーのchosenノードを変更する必要がある、すなわちブートローダーにデバイスツリーを加工する処理を実装しなければならない点です。難しくはないでしょうけど、それなりに手間が掛かるでしょう。

ちなみにlinux,initrd-startのようなlinux,で始まるプロパティの仕様はLinuxカーネルのドキュメント（The chosen node - kernel.org）に記載があります。

QEMUのappend引数なしでカーネル引数を渡す実験

先程まで見てきたbootargsやinitrd-なんとかが正しく生成できれば、QEMUのappendやinitrdオプション無しでもカーネル引数やinitrdをカーネルに渡すことができるはずです。やってみましょう。

/* virt_mod.dts */

/dts-v1/;

/ {

...

	chosen {
		/* ★この行を追加する★ */
		bootargs = "root=/dev/nfs nfsroot=192.168.1.1:/path/to/debian_rootfs,v3 ip=on nfsrootdebug rw";

...

以前作成したGDBスクリプト（2024年7月29日の日記参照）を使ってカーネルとデバイスツリーをロードします。

# load_dtb_opensbi.gdb

restore virt_mod.dtb binary 0x87f00000
thread 1
set $a1=0x87f00000
thread 2
set $a1=0x87f00000
thread 3
set $a1=0x87f00000
thread 4
set $a1=0x87f00000

restore fw_payload.bin binary 0x80000000
thread 1
set $pc=0x80000000
thread 2
set $pc=0x80000000
thread 3
set $pc=0x80000000
thread 4
set $pc=0x80000000

QEMUをkernel, dtb, append引数なし、-Sオプション付き（デバッガーのアタッチ待ち）で起動します。

$ qemu-system-riscv64 \
  -machine virt \
  -bios none \
  -nographic \
  -chardev stdio,id=con,mux=on \
  -serial chardev:con \
  -mon chardev=con,mode=readline \
  -netdev user,id=netdev0 \
  -device virtio-net-device,netdev=netdev0 \
  -m 2g \
  -smp 4 \
  -s \
  -S

$ riscv64-unknown-linux-gnu-gdb

(gdb) target remote :1234

Remote debugging using :1234
warning: No executable has been specified and target does not support
determining executable automatically.  Try using the "file" command.
0x0000000000001000 in ?? ()

(gdb) source load_dtb_opensbi.gdb

Restoring binary file virt_mod.dtb into memory (0x87f00000 to 0x87f01cb5)
[Switching to thread 1 (Thread 1.1)]
#0  0x0000000000001000 in ?? ()
[Switching to thread 2 (Thread 1.2)]
#0  0x0000000000001000 in ?? ()
[Switching to thread 3 (Thread 1.3)]
#0  0x0000000000001000 in ?? ()
[Switching to thread 4 (Thread 1.4)]
#0  0x0000000000001000 in ?? ()

Restoring binary file fw_payload.bin into memory (0x80000000 to 0x81f51608)
[Switching to thread 1 (Thread 1.1)]
#0  0x0000000000001000 in ?? ()
[Switching to thread 2 (Thread 1.2)]
#0  0x0000000000001000 in ?? ()
[Switching to thread 3 (Thread 1.3)]
#0  0x0000000000001000 in ?? ()
[Switching to thread 4 (Thread 1.4)]
#0  0x0000000000001000 in ?? ()

(gdb) continue

Continuing.

最後のcontinueを実行するとQEMU側もログが出ます。例えばこんな感じです。

$ qemu-system-riscv64 \
  -machine virt \
  -bios none \
  -nographic \
  -chardev stdio,id=con,mux=on \
  -serial chardev:con \
  -mon chardev=con,mode=readline \
  -netdev user,id=netdev0 \
  -device virtio-net-device,netdev=netdev0 \
  -m 2g \
  -smp 4 \
  -s \
  -S

OpenSBI v1.5
   ____                    _____ ____ _____
  / __ \                  / ____|  _ \_   _|
 | |  | |_ __   ___ _ __ | (___ | |_) || |
 | |  | | '_ \ / _ \ '_ \ \___ \|  _ < | |
 | |__| | |_) |  __/ | | |____) | |_) || |_
  \____/| .__/ \___|_| |_|_____/|____/_____|
        | |
        |_|

Platform Name             : riscv-virtio,qemo
Platform Features         : medeleg

...

Boot HART MIDELEG         : 0x0000000000001666
Boot HART MEDELEG         : 0x0000000000f0b509
[    0.000000] Linux version 6.9.0 (katsuhiro@blackbird) (riscv64-unknown-linux-gnu-gcc (GCC) 14.1.0, GNU ld (GNU Binutils) 2.42.50.20240622) #9 SMP Thu Aug  1 00:38:49 JST 2024
[    0.000000] random: crng init done
[    0.000000] Machine model: riscv-virtio,qemo

...

[    2.652369] VFS: Mounted root (nfs filesystem) on device 0:20.
[    2.661913] devtmpfs: mounted
[    2.831443] Freeing unused kernel image (initmem) memory: 2260K
[    2.833459] Run /sbin/init as init process
[    4.984017] systemd[1]: systemd 256.4-2 running in system mode (+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBCRYPTSETUP_PLUGINS +LIBFDISK +PCRE2 +PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD +BPF_FRAMEWORK -XKBCOMMON +UTMP +SYSVINIT +LIBARCHIVE)
[    4.988413] systemd[1]: Detected virtualization qemu.
[    4.989856] systemd[1]: Detected architecture riscv64.

Welcome to Debian GNU/Linux trixie/sid!

[    5.048884] systemd[1]: Hostname set to <qemu>.

...

[  OK  ] Reached target graphical.target - Graphical Interface.
         Starting systemd-update-utmp-runle…- Record Runlevel Change in UTMP...
[  OK  ] Finished systemd-update-utmp-runle…e - Record Runlevel Change in UTMP.

Debian GNU/Linux trixie/sid qemu ttyS0

qemu login: 

Debianのログインプロンプトまで表示されれば成功です。カーネル引数を変えたりinitrdのサイズが変わるたびにdtsを書き換えてdtcでコンパイルする……なんて考えると面倒くさいことこの上ないですが、QEMUや気の利いたブートローダーは自動的にデバイスツリーのchosenノードを加工してくれます。ありがたいですね。

Amazonマイリストへの問い合わせの返事がきた

目次: Kindle

先日（2024年8月4日の日記参照）Amazonへ問い合わせた、マイリストの変な挙動についてお返事が来ていました。

お客様からお問い合わせいただいた件につきまして、担当部署へ報告させていただき、
問題が確認された場合には適切に対応させていただきます。

大変お手数ですが、所有数を手動で変更し、購入済に移動していただきますようお願いいたします。

なおほしい物リストの商品登録数について、1つのアカウントで管理できるデータ量には制限があります。
各リストには、登録できる最大数は2500点となりますが、サーバーに負荷をかけずに利用いただく理想の
商品数はおよそ100件となります。それを超えると、データ容量超過でスムーズに作動しない場合や、
エラーメッセージが表示される等の問題が生じる場合がございますので、それぞれのリストの登録商品が
100件以内に収まるようリストを分けて作成いただきますようお願いいたします。

不具合かどうかわからないまま終わりましたけど、本当に不具合ならAmazonのエンジニアが直すでしょう。たぶん。あとマイリストの理想の商品数なんて全く関係ない豆知識を授けてくれたのはなぜでしょうね。「お前はリストに登録し過ぎだ、変なエラーが起きても不思議じゃない」と揶揄したかった？のでしょうか。

Debianのミラーを作ってみる

目次: apt

Debianアーカイブのミラーを試してみた（Debianアーカイブミラーの構築 - Debian）のでメモです。

Debianミラーを作成するにはftpsyncスクリプトを使用します。

$ wget https://ftp-master.debian.org/ftpsync.tar.gz

$ tar xf ftpsync.tar.gz
$ ls

distrib

$ tree distrib/

distrib/
|-- README.md
|-- bin
|   |-- ftpsync
|   |-- ftpsync-cron
|   |-- rsync-ssl-tunnel
|   `-- runmirrors
|-- doc
|   |-- ftpsync-cron.1.md
|   |-- ftpsync.1.md
|   |-- ftpsync.conf.5.md
|   |-- rsync-ssl-tunnel.1.md
|   |-- runmirrors.1.md
|   |-- runmirrors.conf.5.md
|   `-- runmirrors.mirror.5.md
`-- etc
    |-- ftpsync.conf.sample
    |-- runmirrors.conf.sample
    `-- runmirrors.mirror.sample

4 directories, 15 files

アーカイブにはdistribディレクトリだけ存在しています。設定する際はdistrib/etcの下にftpsync.confファイルを置きます。distrib/etcディレクトリにあるftpsync.con.sampleが設定ファイルのサンプルです。

# distrib/etc/ftpsync.conf

TO=/path/to/debian

RSYNC_HOST=ftp.jp.debian.org
RSYNC_PATH="debian"

ARCH_INCLUDE="riscv64"

RISC-V用のDebianアーカイブを日本のサーバーからミラーする設定は上記の通りです。実行はdistrib/bin/ftpsyncを実行するだけです。数時間かかりますが、進捗やステータスの類が何も表示されないので不安になります……。

レガシィの7回目の車検完了

目次: 車

ディーラーまで車検の車を取りに行きました。外は非常に暑くて辛いです……。今後、新しく車を買うときは車検が冬になるようにしたいですね。夏の車検はもう嫌だ。

追加の修理費は特にありませんが、タイヤがもうダメそうだったのでFALKEN AZENIS FK520Lに交換しました。FALKENのプレミアムグレードですが、割と安かった気がします。ブリヂストンやヨコハマは結構高くて1.5〜2倍くらいしますね。

今回FALKENのタイヤを調べていて初めて知ったのですが、DUNLOP（アジア地域など）とFALKENはどちらも住友ゴム工業が製造しているんですね。しかもDUNLOPブランドは非常に複雑でグッドイヤー、住友ゴム工業、コンチネンタルなど複数社が地域ごとにDUNLOPブランドを分け合っているようです。何でそんなことに？ややこしいなあ？

前回の車検からの懸念事項だったパワステギアボックスだかのオイル滲みはまだ耐えてくれているようです。駆動系のブーツ類も硬くなっているそうですが、ブーツ類は消耗品だからしかたないですね。半年後の点検まで様子見します。

Milk-V Jupiterが届いた

目次: RISC-V

Milk-V Jupiterが届きました。お値段が非常に安かったのもあってM1/K1両方購入しました。注文したのは2か月くらい前で、何も音沙汰がなかったので忘れかけていましたが無事に届いて良かったです。

Jupiterの見た目はPCのMini-ITX規格マザーボードとほぼ一緒です。動かすためにはATX電源が必要なので別途用意してください。SoCはSpacemiT Key Stone M1/K1で、CPUはX60という独自コアが8コア搭載、RVA22のほかRVV 1.0にも対応しています。いいですね〜。

Milk-V Jupiter (Key Stone M1)

Milk-V Jupiter (Key Stone K1)

Key Stone M1とKey Stone K1の違いがよくわかりませんが、とりあえずM1はCPU 1.8GHz駆動でK1は CPU 1.6GHz駆動の違いがあるらしいです（Jupiter - Milk-V）。わかりやすい違いは見た目ですね。M1はヒートスプレッダが付いていて銀色のパッケージ、K1は樹脂のみで黒色のパッケージです。

SpacemiTのドキュメントは一応ある（Documentation - SpacemiT）のですが、ダウンロードできない形式になっていて不親切ですね……。イケてない。

Ubuntuのインストール

起動方法はSDカード、SSD、eMMCと複数ありますが簡単な方法はSDカードからの起動です。Milk-Vの公式サイトにある通りにインストールすれば良いです（Milk-V Jupiter Install OS Image - Milk-V）。OSイメージはUbuntuとFedoraとSpecemiT独自（？）のBianbu OSが用意されていますので、お好みで使うと良いと思います。私は使い慣れているUbuntuにしました。

SDカードに書き込むツールもRaspberry Piのときにお世話になったBalena Etcherを使います。なぜかUbuntuのバージョンは23.10（Mantic Minotaur）です。LTSではないUbuntuはサポート期限が短い（24.04リリースまでの9か月程度）ので、長期間の運用には向いていません。普通の人はしないと思いますけども。

CoreMarkを実行

新しいボード購入時の恒例、CoreMarkを実行します。まずはCPUの動作周波数を確認します。

katsuhiro@milkv-jupiter:~$ sudo cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq

1800000

katsuhiro@milkv-jupiter:~$ sudo cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq

614400

katsuhiro@milkv-jupiter:~$ sudo cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq

1800000

CPUの動作周波数は0.614GHz〜1.8GHzのようですが、curは1.8GHz固定で変動している様子はありません。バグってる？固定？まあいいや、とりあえずこの値を信じましょう。

最初はシンプルにオプションOfastを試します。

2K performance run parameters for coremark.
CoreMark Size    : 666
Total ticks      : 17322
Total time (secs): 17.322000
Iterations/Sec   : 6350.305969
Iterations       : 110000
Compiler version : GCC13.2.0
Compiler flags   : -Ofast -g
Memory location  : Please put data memory location here
                        (e.g. code in flash, data on heap etc)
seedcrc          : 0xe9f5
[0]crclist       : 0xe714
[0]crcmatrix     : 0x1fd7
[0]crcstate      : 0x8e3a
[0]crcfinal      : 0x33ff
Correct operation validated. See README.md for run and reporting rules.
CoreMark 1.0 : 6350.305969 / GCC13.2.0 -Ofast -g / Heap

6350.305969 / 1800 = 3.52CM/MHzですね、正直言ってあまり速くないです。Cortex-A53より上、Cortex-A55より下といったところです。

RISC-Vは標準的な命令以外にも拡張命令が多数定義されています。なかでもbit manipulation命令はこの手のベンチマークには結構効き目がありますので、有効にして測ってみます。Zbc拡張は有効にしたら逆に遅くなったので外しています。

2K performance run parameters for coremark.
CoreMark Size    : 666
Total ticks      : 16201
Total time (secs): 16.201000
Iterations/Sec   : 6789.704339
Iterations       : 110000
Compiler version : GCC13.2.0
Compiler flags   : -Ofast -g -march=rv64gc_zicsr_zifencei_zmmul_zba_zbb_zbs
Memory location  : Please put data memory location here
                        (e.g. code in flash, data on heap etc)
seedcrc          : 0xe9f5
[0]crclist       : 0xe714
[0]crcmatrix     : 0x1fd7
[0]crcstate      : 0x8e3a
[0]crcfinal      : 0x33ff
Correct operation validated. See README.md for run and reporting rules.
CoreMark 1.0 : 6789.704339 / GCC13.2.0 -Ofast -g -march=rv64gc_zicsr_zifencei_zmmul_zba_zbb_zbs / Heap

6789.704339 / 1800 = 3.77CM/MHzです、だいぶ改善されてCortex-A55と同程度になりました。それでも速いとは言い難いですけど……。X60コア用にコンパイルするときはbit manipulation系の拡張命令は必須ですね。

Microsoftマウスが壊れた

3年前くらいに購入した（2021年3月6日の日記参照）Microsoft Basic Optical Mouseが壊れました。今までのマウスは左ボタンが壊れて勝手にダブルクリック病になっていましたが、今回はセンターホイールが壊れて下に回しているのに上にスクロールされたり、上に回しているのに下にスクロールされたりする症状が出ています。初めて出会う症状ですが、ダブルクリック病と同じくらいイライラします。

Microsoft Basic Optical Mouse分解

3年使ったものなので内部は埃だらけで若干お見苦しいですが、捨てる前に分解して内部の写真を撮りました。ボタンと逆側にあるねじ1本で留まっているだけで、分解はとても簡単です。内部の基板は極めてシンプルです。片面が茶色（レジストなし）、逆側が緑色（レジストあり）のちょっと変わった基板でした。両面レジストが普通だと思っていましたが、コストカットのためですかね？

さて次のマウスは何にしようかな〜と言いたいところですが、実は同じマウスがもう1つあるので引き続き2個目のMicrosoft Basic Optical Mouseを使います。

間違って2個買ったのではなく、あまりに安かったのですぐ壊れるかと思い2個買いました。でも蓋を開けてみれば3年も使えたし杞憂でしたね。1年あたりにすれば300円くらいで驚異のコストパフォーマンス、素晴らしい製品だと思います。Microsoftはこの価格で儲かっているのでしょうか……？