コグノスケ

シンタックス・ハイライト

コードのキーワードハイライトに使っているhighlight.js（公式サイトへのリンク）を11.2.0にしました。導入したのは7年も前（2014年9月11日の日記参照）ですが、バージョンアップはスムーズにできました。

APIに変更があってinitHighlightingOnLoad() がdeprecatedになりました。代わりにhighlightAll() を呼べばOKです。ファイル名も微妙に変わっていました。スクリプトはhighlight.pack.jsからhighlight.min.jsに、CSSはvs.cssからvs.min.cssになっていました（Visual StudioスタイルのCSSを使う場合の設定、この他にもスタイルはたくさんあります）。

udevでPCIデバイスのパーミッションを設定する

目次: Linux - まとめリンク

PCIデバイスを使った実験をする際にコンフィグ空間やメモリ空間を読み書きしたいときがあります。メモリ空間の読み書き程度ならば、わざわざPCIデバイスドライバを書かなくても /sys/bus/pci/devices/*/ にあるresourceNファイルにアクセスすれば良いです。

PCIデバイスはコンフィグ空間にBAR (Base Address Register) という32bitレジスタが6個あり、メモリ空間をPC側のアドレスのどこにマッピングするかを指定します。BARがそのままresourceNに対応しています。

最近は64bitアドレスでマッピングするデバイスも多いですが、その際は連続するBARを2つ使ってマッピング先のアドレスを指定します。実際に見たほうが早いと思うので、私の使っているマシンのグラフィックカードNVIDIA GeForce GT 1030を例にしましょう。

# lspci | grep VGA

08:00.0 VGA compatible controller: NVIDIA Corporation GP108 [GeForce GT 1030] (rev a1)

# lspci -s 08:00.0 -v

08:00.0 VGA compatible controller: NVIDIA Corporation GP108 [GeForce GT 1030] (rev a1) (prog-if 00 [VGA controller])
        Subsystem: Micro-Star International Co., Ltd. [MSI] GP108 [GeForce GT 1030]
        Flags: bus master, fast devsel, latency 0, IRQ 84, IOMMU group 14
        Memory at f6000000 (32-bit, non-prefetchable) [size=16M]    ★BAR0: resource0
        Memory at e0000000 (64-bit, prefetchable) [size=256M]       ★BAR1: resource1（64bitアドレス空間なのでBAR2も使われる）
        Memory at f0000000 (64-bit, prefetchable) [size=32M]        ★BAR3: resource3（64bitアドレス空間なのでBAR4も使われる）
        I/O ports at d000 [size=128]                                ★BAR5: resource5
        Expansion ROM at 000c0000 [virtual] [disabled] [size=128K]
        Capabilities: [60] Power Management version 3
        Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+
        Capabilities: [78] Express Legacy Endpoint, MSI 00
        Capabilities: [100] Virtual Channel
        Capabilities: [128] Power Budgeting <?>
        Capabilities: [420] Advanced Error Reporting
        Capabilities: [600] Vendor Specific Information: ID=0001 Rev=1 Len=024 <?>
        Capabilities: [900] Secondary PCI Express
        Kernel driver in use: nvidia
        Kernel modules: nvidia

デバイスの位置（08:00.0）と、マッピングしているアドレスがBAR0, 1, 3, 5の4つ あることがわかります。/sys/bus/pci/devices経由でPCIデバイスのBAR1でマップされているメモリを読み出します。

# cd /sys/bus/pci/devices/0000\:08\:00.0/

# ma -k resource1 dd 0

00000000  ff000020 ff00082c  ff000020 ff00082c
00000010  ff3c0020 ff42082c  ff990020 ffa50027
00000020  ffa10020 ffa10027  ffa50020 ff990027
00000030  ff420020 ff3c0027  ff000020 ff000027
00000040  ff000020 ff000027  ff000020 ff000027
00000050  ff000020 ff000027  ff000020 ff000027
00000060  ff000020 ff000027  ff000020 ff000027
00000070  ff000020 ff000027  ff000020 ff000027
00000080  ff000020 ff000027  ff000020 ff000027
00000090  ff3c0020 ff420027  ffb90020 ffa50027
000000a0  ffa50020 ffb90027  ffa90020 ffa50027
000000b0  ff420020 ff3c0027  ff000020 ff000027
000000c0  ff000020 ff000027  ff000020 ff000027
000000d0  ff000020 ff000027  ff000020 ff000027
000000e0  ff000020 ff000027  ff000020 ff000027
000000f0  ff000020 ff000027  ff000020 ff000027
00000100

読み出しツールは何を使っても構いませんが、サイズがめっちゃでかい（256MB）ので「頭から読む系のツール（hexdumpやテキストエディタ）」は使わないほうが無難です。今回は拙作のmemaccess（GitHubへのリンク）を使いました。

ちなみにresourceNを読みだそうとすると怒られるときは、NVIDIAのドライバをロードしていないかチェックしてみてください。

# ma -k resource0 dd 0

mmap: Invalid argument

# cat /proc/iomem

...
e0000000-fec2ffff : PCI Bus 0000:00
  e0000000-f1ffffff : PCI Bus 0000:08
    e0000000-efffffff : 0000:08:00.0
    f0000000-f1ffffff : 0000:08:00.0
  f6000000-f70fffff : PCI Bus 0000:08
    f6000000-f6ffffff : 0000:08:00.0
      f6000000-f6ffffff : nvidia    ★BAR0をnvidiaドライバが使用中なのでmmapできない
    f7080000-f7083fff : 0000:08:00.1
      f7080000-f7083fff : ICH HD audio
...

# rmmod nvidia_uvm nvidia_drm nvidia_modeset nvidia

# cat /proc/iomem

...
e0000000-fec2ffff : PCI Bus 0000:00
  e0000000-f1ffffff : PCI Bus 0000:08
    e0000000-efffffff : 0000:08:00.0
    f0000000-f1ffffff : 0000:08:00.0
  f6000000-f70fffff : PCI Bus 0000:08
    f6000000-f6ffffff : 0000:08:00.0    ★nvidiaドライバがアンロードされた
    f7080000-f7083fff : 0000:08:00.1
      f7080000-f7083fff : ICH HD audio
...

# ma -k resource0 dd 0

00000000  138000a1 00000000  00000000 bad00200
00000010  bad00200 bad00200  bad00200 bad00200
00000020  bad00200 bad00200  bad00200 bad00200
00000030  bad00200 bad00200  bad00200 bad00200
00000040  bad00200 bad00200  bad00200 bad00200
00000050  bad00200 bad00200  bad00200 bad00200
00000060  bad00200 bad00200  bad00200 bad00200
00000070  bad00200 bad00200  bad00200 bad00200
00000080  0000008f bad00200  bad00200 bad00200
00000090  bad00200 bad00200  bad00200 bad00200
000000a0  bad00200 bad00200  bad00200 bad00200
000000b0  bad00200 bad00200  bad00200 bad00200
000000c0  bad00200 bad00200  bad00200 bad00200
000000d0  bad00200 bad00200  bad00200 bad00200
000000e0  bad00200 bad00200  bad00200 bad00200
000000f0  bad00200 bad00200  bad00200 bad00200
00000100

ドライバが管理しているメモリを横から読み書きされたらたまったもんじゃないですから、この挙動は当然ですね。え？読み出しなら良いのでは？と思われるかもしれませんが、読み出しをトリガーに動作したり、読み出すと値が変化するレジスタなどは珍しくないので、勝手に読み出すのも実はダメなのです。

パーミッション面倒くさい

先ほど /sys/bus/pci/devices以下のファイルをls -lなどで見た方はお気づきかと思いますが、rootしか読めないようなパーミッションになっています。

# cd /sys/bus/pci/devices/0000\:08\:00.0/

# ls -l resource*

-r--r--r-- 1 root root      4096  8月  2 22:08 resource
-rw------- 1 root root  16777216  8月  2 22:10 resource0
-rw------- 1 root root 268435456  8月  2 22:10 resource1
-rw------- 1 root root 268435456  8月  2 22:10 resource1_wc
-rw------- 1 root root  33554432  8月  2 22:10 resource3
-rw------- 1 root root  33554432  8月  2 22:10 resource3_wc
-rw------- 1 root root       128  8月  2 22:10 resource5

誰でもデバイスのメモリにアクセスできるのはマズいですから、セキュリティ上この設定は真っ当です。真っ当ですが、実験に使うときはいちいちsudoするのが面倒なのも事実です。手動でchmodやchownしてパーミッションを変えればsudo不要にできますが、いくつか欠点があります。

• デバイスID 0000:08:00.0が常に同じとは限らない（カードの増設、撤去で変動する）
• PCをリブートすると元に戻ってしまう

どこにいるかわからないデバイスを操作したいときは、udevの出番です。

udevでパーミッションを変える

前置きが長くなりましたが、やっと本題です。/etc/udev/rules.dに99-hogehoge.rulesのようなファイルを作ります。全てのPCIデバイスのパーミッションを全開にする必要はないので、ベンダーIDとデバイスIDでGeForce GT 1030だけ該当するようにフィルタリングしましょう。

# lspci -s 08:00.0

08:00.0 VGA compatible controller: NVIDIA Corporation GP108 [GeForce GT 1030] (rev a1)

# lspci -s 08:00.0 -n

08:00.0 0300: 10de:1d01 (rev a1)
              |    `--- Device ID
              `--- Vendor ID

他の条件をフィルタリングに使いたいときは、udevadm infoを使うと、vendorやdeviceも含んだ全ての属性を見ることができます。

# udevadm info -a -p /sys/bus/pci/devices/0000:08:00.0 | less

...
  looking at device '/devices/pci0000:00/0000:00:03.1/0000:08:00.0':
    KERNEL=="0000:08:00.0"
    SUBSYSTEM=="pci"
    DRIVER==""
    ATTR{ari_enabled}=="0"
...
    ATTR{revision}=="0xa1"
    ATTR{subsystem_device}=="0x8c98"
    ATTR{subsystem_vendor}=="0x1462"
    ATTR{vendor}=="0x10de"    ★ベンダーID
...

IDが判明したらルールファイルを書きます。/sys/bus/pci/devices/* のディレクトリと配下のファイル全てにgroupとotherのRead/Writeパーミッションを付加します。%pは設定中のデバイスのパスが入る変数です。

SUBSYSTEM=="pci", ATTR{vendor}=="0x10de", ATTR{device}=="0x1d01", RUN+="/bin/chmod -R go+rw /sys%p"

注意点は「RUNはシェルじゃない」ことです。パスの補完、ワイルドカード、パイプ、リダイレクトなどは使えません。私は最初resource* と書いて「そんなファイルはない」と言われたり、/bin/chmodなのに /usr/bin/chmodと書いていて、何も実行されなくて悩みました（Ubuntuは /usr/bin/chmodだったりするので、さらにややこしいです）。

# udevadm trigger

# cd /sys/bus/pci/devices/0000\:08\:00.0/

# ls -l resource*

-r--rw-rw- 1 root root      4096  8月  2 23:10 resource
-rw-rw-rw- 1 root root  16777216  8月  2 23:10 resource0
-rw-rw-rw- 1 root root 268435456  8月  2 23:10 resource1
-rw-rw-rw- 1 root root 268435456  8月  2 23:10 resource1_wc
-rw-rw-rw- 1 root root  33554432  8月  2 23:10 resource3
-rw-rw-rw- 1 root root  33554432  8月  2 23:10 resource3_wc
-rw-rw-rw- 1 root root       128  8月  2 23:10 resource5

ルールファイルを書いたら設定を反映させると、resourceNファイルのパーミッションが変わっているはずです。変わっていない場合はおそらくルールの書き方が間違っているので、修正が必要です。

udevルールのデバッグ

むしろこちらが本題かもしれません。udevのRUNルールは「シェルじゃない」ので、普段シェル上で使っているコマンドをコピペしてもまず動かないです。間違っている場合は主に2パターンで、

• フィルタリングのルールが間違っている
• RUNの書き方が間違っている

前者に関してはRUNでログを出すとわかります。例えばRUN+="/usr/bin/logger AAAAAAAA" のようにすると、udevadm triggerを実行した後に /var/log/syslogにメッセージが出ます。

ログが出なければフィルタリングの条件を全部削って試してください。それでもログが出なければおそらくloggerのパスが間違っています。which loggerで出てくるパスとRUNに書いたパスが合っているか確認してください。特に /binと /usr/binは間違えやすいです。

後者に関してはRUNに書いたコマンドが失敗するとsyslogにエラーが記録されるはずですので、間違ってワイルドカードやパイプなどを書いていないかチェックしてみると良いです。

Aug  1 22:56:51 blackbird systemd-udevd[2775846]: 0000:08:00.0: Process '/bin/chmod -R go+rw /sys/devices/pci0000:00/0000:00:03.1/0000:08:00.0*' failed with exit code 1.

ログを見てもすぐにわからないような場合は、地道に「コマンド名だけにして実行されるか？」「引数を1つずつ足していって動くか？」を確認するのが一番良いです。

再び挙動のおかしいKindle Fire HD

目次: Kindle - まとめリンク

第七世代Kindle Fire HDの挙動がどんどんおかしくなってきています。前にも発生した（2018年11月17日の日記参照）、買った本を認識しなくなる病気です。ここのところおかしくなりすぎだぞ？頑張ってくれKindleさん。

前回はスクリーンショットを取り損ねたので、今回はスクリーンショット付きでお届けします。

本を買ったことを認識できていない機能としては、

• ライブラリ
• 「次の作品」機能

ライブラリ「すべて」だと認識できていない

「次の作品」機能も認識できていない

逆に本を買ったことを認識できている機能としては、

• ストア
• ストアのシリーズ買い

ストアは認識できている

ストアのシリーズも認識できている

です。そろそろファクトリリセットの時期なんですかね……？

直せるか？

ファクトリリセットは時間かかって嫌なので、なんとか直せないかなと頑張りましたけど、前回の解決策なども通じずじまいで駄目でした。

• 「購入」を押す→「問題が発生」
• 「今すぐ読む」を押す→永遠にダウンロードされない
• 2018年の解決策1: シリーズページの「今すぐ読む」（緑色）→永遠にダウンロードされない
• 2018年の解決策2: コンテンツ管理サービスアプリのデータを消去→変化なし

購入を試みるとエラー

ダウンロードを試みると永遠に終わらない

となりました。どうやっても「役立たずスキルに……」の3巻を読めません。困ったね。

救世主

TwitterでKindleの文句ばっかり言ってたせいか、最近Amazonのサポートデスクの人からTwitterでリプライをいただけることがあります。

たぶん世界中に私のようなヤツが一杯いるんでしょう。中の人も相当お疲れなようで、かなり機械的というか、マニュアルかなんかありそうな対応（最初にFAQに案内され、それでも駄目だって言うと、サポートデスクチャットを案内される）ですけど……。いやまあ、声掛けていただけるだけありがたいことですよね、うん……。

サポートデスクの人曰く、Amazonのトラブルシューティング（Amazon.co.jpヘルプ - Kindle本がライブラリに表示されない）を参考に試してみてほしいとのことでした。こんな内容です。

• お使いのモバイル端末がインターネットに接続されていることを確認します。
• Kindleアプリを同期します。
• Kindle無料アプリをアップデートします。
• Whispersyncがオンになっていることを確認します。
• 注文履歴でKindleでの購入が正常に行われたかを確認し、支払方法に問題がないことを確認します。
• コンテンツと端末の管理を使用して、ご希望の端末に本を配信します。
• アプリが正しいAmazonアカウントに登録されていることを確認します。複数のアカウントをお持ちの場合は、その本が別のアカウントから購入されている可能性があります。
• アプリを登録解除して再度登録します。
• Kindle無料アプリをアンインストールして再インストールします。この手順では、ライブラリ全体を再度ダウンロードする必要がありますので、最後にお試しください。

上から順に試してみると、6番目の「コンテンツと端末の管理を使用して、ご希望の端末に本を配信します。」が大当たりでした。スゲエ。この手のFAQ系の手順で直ったことって一切ないんで、これが初めてかも？？

本の配信をやり直す方法

未読/既読、どこまで読んだか？情報はキレイさっぱり消えていました。配信したかどうかすら忘れてるんだもん、そりゃそうか。

とまあ、この通りKindleはいつ何が消えるか予想がつかないため、しおり、位置保存、などの機能は一切信用しませんし、使うこともないですね……。

余談

Amazonサポートデスクの人に「なんで勝手に配信解除されたのでしょうか」ってTwitterで聞いたらシカトされました。悲しいよ。

今回に限らないですが、Amazonサポートデスクの人に「どうしたらいいですか？」と聞くと超スピードで答えてくれます（最終奥義は返金です）が、「どうしてこうなるんですか？」って聞くとシカトされる傾向にあります。Amazonは開発部門とサポート部門の距離が遠くて答えを持ってない、機密漏洩等を恐れて意図的に知らせていない、とかかな？

色々事情がありそうなことは察しますが、こちらも人間なのでシカトは辛いよね……。普通に「技術面の質問はわかりませんorお答えできかねます」って言ってくれたら「そうなのか〜」で終わりなんだけど。何か過去にモメごとでもあったのかもね？

Kindle - まとめリンク

目次: Kindle - まとめリンク

一覧が欲しくなったので作りました。

初代Kindle Fire HDの話。

• Kindle Fire HDのカメラ
• Kindle Fire HDとGmail
• Kindle Fire HD絶不調
• Kindle for Androidのバグ
• Kindleで買った本の一覧を見る方法（イマイチ版）

第七世代Kindle Fire HDもしくはKindle for PCの話。

• New Kindle Fire HD
• Kindle Fireの変なフォント
• Kindle Fireの書籍をダウンロードしながら読む機能
• Kindle Fireの変なフォントが直っていた
• Kindle書籍の紹介文
• Kindleの本もダブることがある
• Kindle Fireのシステムアップデート
• 挙動のおかしいKindle Fire HD
• Kindle for PCはダウンロードが遅い？
• Kindle Fireの本が消える病
• Kindle 10,000冊突破（99.9％はマンガ）
• Kindleで買った本の一覧を見る方法（決定版）
• Kindle Fire先生ご乱心
• いまいちなデザインのKindleマンガストア
• 再び挙動のおかしいKindle Fire HD
• そろそろ限界のKindle Fire HD
• 膝を折ったKindle Fire HD
• Kindle Fire HD死す
• Kindle Fire HD死亡の余波

Kindle用のAndroidタブレットの話。

• AndroidタブレットLenovo Tab M10購入

Facebookの内蔵ブラウザを無効にする方法

Facebookは内蔵ブラウザで、Webサイトへのリンクを開きます。私はWebサイトはブラウザで開いてほしい（タブが残せるし、あとで閲覧履歴を確認することもできる）ので、この挙動はぜひとも無効化したいです。

今まで無効化する方法がわからなくて困っていましたが、今日、設定を頭から試していたら、
[設定] - [メディア] - [リンクを外部で開く]
をONにすると外部のブラウザで開いてくれることがわかりました。Webサイトってメディアか……？まあやりたいことはできたから良いか。

LINEはわからずじまい

LINEも内蔵ブラウザでリンクを開きます。無効化したいですが、設定にそのような項目が見当たりません。うーん、嫌な挙動ですね。

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

Debian TestingとZephyr SDKその4 - ローカルパッチの仕組みが0.13で変わった

目次: Zephyr - まとめリンク

Zephyrを最新にしたところSDKのバージョンが古いと怒られてしまいました。

Zephyr SDK 0.13にアップデートしたところ「Debian TestingにはPython 3.8が無くてGDBが動かない」問題が再発しました。Python 3.9を使い、不具合を治すパッチを当てないといけません（その1〜3を参照）が、以前と同様の方法ではダメなようです。

調べてみると少し仕組みが変わっています。バージョン0.12まではUpstreamのtarballを参照し、ローカルでパッチを持っていました。バージョン0.13はnewlib-nano, binutils, gcc, gdb, newlibについてはGitHubのZephyrプロジェクト以下にあるフォークされたソースコード（パッチ適用済み）を参照し、tarballを作成するように変更されました。

今まではローカルでパッチを当てる仕組みが動いていたため、パッチファイルを1つ追加するだけで修正を適用できましたが、0.13からローカルでパッチを当てる仕組み自体を使わなくなったため、パッチファイルを置いても修正が適用されなくなりました。困った。

解決方法その1 - 0.12互換の設定に戻す

バージョン0.12以前の設定と同じようにsdk-ng/patches/gdbの下にあるパッチファイルを見るようにする方法です。まずローカルパッチ機能を有効にするため、コンフィグを追加します。追加する場所はどこでも良い（順序は特にない）です。私はファイルの最後に追加しています。

# sdk-ng/configs/riscv64.config

...

CT_PATCH_BUNDLED_LOCAL=y
CT_LOCAL_PATCH_DIR="${CT_TOP_DIR}/../../patches"

注意点としてはGDBのバージョンは9.2ですが、パッチのディレクトリ名はtarballの名前に準じてgit-xxxxxxxxのようにしなければならないことです。ディレクトリ名を9.2にするとパッチが無視されます。例えば今回試した環境ではgit-76b05e96だったので、sdk-ng/patches/gdb/git-76b05e96/0007-gdb-fix-python3.9.patchのように置けば良いです。

もしgit-xxxxxxxxのバージョンがわからないときは、configs/riscv64.configのCT_GDB_DEVEL_REVISIONを見るとリビジョンが書いてありますが、ぶっちゃけ一旦ビルドしてみてビルドログを見た方が早いです。

解決方法その2 - Crosstool-NGのパッチセットに追加する

動きにややクセがあるもののバージョン0.13だとこちらのほうが変更量が少なくスマートです。0.12でも同じ方法が使えると思いますが、未確認です。

Zephyr SDKの配下にあるCrosstool-NGはパッチセットを持っています。パッチセットに追加しておけば初回ビルド時（sdk-ng/share以下にファイルコピーが行われる）にパッチを持っていってくれます。例えばsdk-ng/crosstool-ng/packages/gdb/git-76b05e96/0007-gdb-fix-python3.9.patchのように置けばよいです。

注意点としては、その1同様の点でディレクトリ名（git-xxxxxxxx）に気をつけること、もう1つあって「コピーのタイミング」にクセがあることです。Crosstool-NGのパッチセットはsdk-ng/share配下にコピーされますが、これはgo.shの初回実行時しかコピーされません。

パッチファイルを追加するなど、再びコピーを実行してほしい場合sdk-ng/binとsdk-ng/shareを消してからgo.shを実行すると初回の処理が再実行されるようです。ただgo.shはヘルプが一切なく、私のやり方が正しいかどうか良くわからないのが欠点です……。

ログを入れたいときの注意点

Crosstool-NGのパッチ当てを行っているスクリプトfunctionsはsdk-ng/crosstool-ng/scripts/functionsが元のスクリプトですが、Zephyr SDKのビルドでは初回ビルド実行時にsdk-ng/share/crosstool-ng/scripts/functionsにコピーされます。ビルド時はコピーしたスクリプトを実行します。

そのためスクリプトにログなどを入れたい場合、コピーの方（sdk-ng/share/crosstool-ng/scripts/functions）を改変しないと効果がないです。ご注意を。

HiFive Unmatchedの動作周波数

目次: RISC-V - まとめリンク

以前HiFive Unleashedの動作周波数を調べました（2019年7月4日の日記参照）。今回はHiFive Unmatchedの動作周波数を調べます。Unmatchedに元々書き込んであるLinuxを起動したあと、PRCIレジスタ領域を見てみました。ダンプすると下記のようになっています。

0x10000000:     0xc0000000      0x820544c2      0x00000000      0x820d1180
0x10000010:     0x80000000      0x00000000      0x00000000      0x8206b982
0x10000020:     0x80000000      0x00000000      0x0000006f      0x00000004
0x10000030:     0x00000000      0x00000000      0x030187c1      0x00000000
0x10000040:     0x00000000      0x00000000      0x00000000      0x00000000
0x10000050:     0x82063bc2      0x80000000      0x00000000      0x00000000
0x10000060:     0x00000000      0x00000000      0x00000000      0x00000000

ビット31がPLL enableですので、オフセット0x4:core_pll, 0xc: ddr_pll, 0x1c: gemgxl_pll, 0x50: hfpclk_pllの設定が有効になっているようです。

いずれのPLL設定もビットフィールドの意味は同じで、[5:0] divr, [14:6] divf, [17:15] divqです。ビットフィールドが4bit境界にないので、PythonなどでPLLの設定値を表示させると楽だと思います。

SiFive U740の仕様書（7. Clocking and Reset）を見ると、PLLの出力周波数foutは
fout = fin / (div_r + 1) * 2 * (div_f + 1) / 2 ^ (div_q)
とのこと。PLLの入力finはいずれのPLLも同じでhfclkという26MHzの外部クロックです。

>> def dump(val):
...     r = val & 0x3f
...     f = (val >> 6) & 0x1ff
...     q = (val >> 15) & 0x7
...     o = 26 / (r + 1) * 2 * (f + 1) / pow(2, q)
...     print("r", r, "f", f, "q", q, "freq", o)

>>> dump(0x820544c2)
r 2 f 275 q 2 freq 1196.0

>>> dump(0x820d1180)
r 0 f 70 q 2 freq 923.0

>>> dump(0x8206b982)
r 2 f 230 q 5 freq 125.12499999999999

>>> dump(0x82063bc2)
r 2 f 239 q 4 freq 260.0

出力結果を見るとcore_pll:1196MHz, ddr_pll:923MHz, gemgxl_pll:125.125MHz, hfpclk_pll: 260MHzという設定です。どうしてこの値なのかはわからないですけど、参考になります。

rangeフィールドの意味

PLL設定に [20:18] rangeというフィールドがあるのですが、SiFiveの仕様書には説明が書かれていません。クロック周りはAnalog Bitsという会社のCLN28HPC Wide Range PLLを使っているようですが、PLLの詳細仕様はNDAを結ばないと知ることができません。うーむ、不親切……。

しかしSiFiveの人たちはLinuxのクロックドライバを作ってくれており、実装からPLLの仕様を窺い知ることができます。ドライバはlinux/drivers/clk/analogbits/wrpll-cln28hpc.cにあります。

/**
 * __wrpll_calc_filter_range() - determine PLL loop filter bandwidth
 * @post_divr_freq: input clock rate after the R divider
 *
 * Select the value to be presented to the PLL RANGE input signals, based
 * on the input clock frequency after the post-R-divider @post_divr_freq.
 * This code follows the recommendations in the PLL datasheet for filter
 * range selection.
 *
 * Return: The RANGE value to be presented to the PLL configuration inputs,
 *         or a negative return code upon error.
 */
static int __wrpll_calc_filter_range(unsigned long post_divr_freq)
{
	if (post_divr_freq < MIN_POST_DIVR_FREQ ||
	    post_divr_freq > MAX_POST_DIVR_FREQ) {
		WARN(1, "%s: post-divider reference freq out of range: %lu",
		     __func__, post_divr_freq);
		return -ERANGE;
	}

	switch (post_divr_freq) {
	case 0 ... 10999999:
		return 1;
	case 11000000 ... 17999999:
		return 2;
	case 18000000 ... 29999999:
		return 3;
	case 30000000 ... 49999999:
		return 4;
	case 50000000 ... 79999999:
		return 5;
	case 80000000 ... 129999999:
		return 6;
	}

	return 7;
}

単純に入力をswitch文で見ているだけです。説明を見るとpost-R-dividerとあるのでfin / (divr + 1) の周波数を見て決めれば良さそうですね。この情報を公開していただけるのは非常にありがたいのですが、NDAは大丈夫なんですかね……？大した情報ではないとはいえ、ちょっと心配になってしまいます。

Zephyr on HiFive Unmatched

目次: Zephyr - まとめリンク

最近ZephyrをHiFive Unmatchedに移植しています。基本的にはUnmatchedとUnleashedは似ています。メモリマップなどの大枠の仕様はほぼ同じですが、クロック周りを初めとして仕様が違う部分もあります。今日気づいたのは、

安易にUnleashedから実装をコピーして楽しようとしたらハマりました……。

ロードする場所

HiFive Unleashedはリセット直後からDDRにアクセスできるかなり変わったボードで、ZephyrはDDRにロードしてしまえば動きました。しかしHiFive UnmatchedのDDRは初期化しないと使えないため、ZephyrをDDRにロードする作戦は使えません。代わりとしては、

• DTIM（Data Tightly-Integrated Memory）
• L2-LIM（Loosely Integrated Memory）

DTIMはアクセスが一定速度かつ高速（1ワード、2クロック）で、リセット直後から使用可能で、RTOSにとって理想的なメモリ領域ですが、サイズが8KiBしかありません。Zephyrはデータ領域は10KB前後、コード領域は50KB超えることもザラで、DTIMにはどうやっても載りません。

ZephyrってRTOSの中では割とデカい部類なのでしょうか？Flash ROMに書き込んでXIP（eXecution In Place）する使い方が前提だから、コード領域のサイズはあまり気にしていないのかもしれませんけど。

L2-LIMはL2キャッシュがRAM代わりになる機能です。試してみるとリセット直後から読めますし、サイズも2MBと十分な大きさです。L2-LIMの弱点はL2キャッシュの動作モードをキャッシュモードに変更すると、二度とL2-LIMとして使えなくなることです。本来の使い方としてはDDRを初期化するまでの「一時的なデータ＆コード置き場」が役目です。

今のところZephyrで高速コアのU74は動かさないでしょうし、L2キャッシュを有効にすることはないでしょう。たぶん。L2-LIMにZephyrのメインメモリ領域として活躍していただくことにしましょう。

インフラの民営化

上水道を売り払う自治体が出ました（下水道はこれまでもあった）。宮城県、水道3事業の運営権を売却へ　国内で初めて - 日経新聞。過疎地は水道維持費が大赤字と思われるので、速攻で廃止され昔ながらの井戸に戻るでしょう。

井戸＝危険ではないですが、井戸の水質は「自己責任」でケチって検査せず使い続ける人達を止められないという点は気になるところです。自治体の基準としても「飲用井戸の衛生確保は、原則として設置者の自己責任」とあります（飲用井戸の衛生管理について - 千葉県より）。

汚染された井戸から疫病が発生、過疎地から都市部に大流行……なんて未来は笑えません。が、昔の日本や今の後進国では起きてた話ですし十分ありえますね。令和は昭和へ回帰する時代かもしれません。国の衰退、生活レベルの低下、衛生面の悪化といった悪い点でね……。

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

ワクチン1回目

自治体の接種会場に行きました。ワクチンはファイザー製でした。

入り口には警備員さんがいましたが、予約システムの予約票は確認されないため「予約してまーす」って言ったら誰でも入れそうでした。が、多少嘘つきが混ざる程度は特に問題ないでしょう。

会場に入れないほど混んだり、1人も来ないなどの事態さえ発生しなければ、別に誰に打ったって良いわけですから。

医療従事者のみなさま

ワクチン接種会場には毎日嫌になるほど人が来ていると思いますが、看護師を始めとした医療従事者の皆様は非常に親切かつ効率的に働いていました。日本の医療は最高だよ、ありがてぇ。

午後だったせいなのか、問診の先生はかなりお疲れモードで、半分目が死んでました。お疲れ様です、無理はしないでください……。

肩が痛い

ワクチンを打った後は、肩こりみたいな痛さ、とか、肩にパンチを食らったような痛さ、と言われてますが、体験したら意味がわかりました。これは痛い……。

ノートPCでゲームは辛いよ

目次: ゲーム - まとめリンク

最近のPCゲームは画面がとてもキレイですね。シミュレーションゲームなど画質とゲーム性があまり関係ないものであっても、こだわりを感じます。海外レーベルのゲームにリアルな画作りが多い印象です。

画面が美しいのはありがたいですけど、我が家のノートPCに積まれてるディスクリートGPU（Radeon RX 550 Mobile）はあまり性能が高い方ではなく、画質をかなり下げないと「コマ送りかな……？？」といわんばかりの描画速度になります。

我が家の重いゲーム、上位三傑

そもそもシミュレーションゲーム好きで、画質や動き重視のゲームは持ってないですが、それでもノートPCには荷が重いゲームたちがいます。

No.1はThe Hunter: Call of the Wildです。画質を上げると景色の描写が非常に美しいです。描画の処理もべらぼうに重いです。我が家のPCでは画質をほぼ最低ランクにしても、草むらなどのオブジェクトの多い場所に突っ込むと、画面がガクガクしてライフルの狙いがつけられません。無駄に難易度が上がる……。

不思議なことに七面鳥だけ、動物の大きさの割に描画が異常に遅くて、描画範囲に入った瞬間に画面がガクガクし始めます。直接見なくても居ることだけはわかるエスパーになれます。

No.2はDyson Sphere Programです。ダイソン球の浮かぶ宇宙、開発中の惑星の景色が素晴らしくキレイです。ゲームの序盤はノートPCでも何ともないんですけど、ゲームの中盤（別の星系に進出する時期）あたりの惑星状に大量の建築物がある状態だと遅くなります。

ジェットで空高く飛び上がったり、惑星間航行で惑星に着陸するときなど、地表の建物が大量に視界に入ってくると、途端に画面がガクガクしてあらぬ方向に飛んでいきます。どこいくんだー。

No.3はAssetto Corsaです。車やコースの描写が非常に美しいです。レースゲームはPlayStation 3あたりで実写と見紛うばかりの画質になりましたが、さらに進化していると思います。ただこのゲーム、最適化を相当頑張っているのか、見た目の綺麗さから想像するより描画の負荷が軽くて驚きます。ロードは遅いけど……。

適当に走るくらいならノートPCでも遊べますが、レースゲームは他のゲームに比較してコマ落ちが致命的ですからね。ノートPCのGPUで遊ぶのは精神衛生上良くないですね。

開発環境としてのHiFive Unmatched

目次: RISC-V - まとめリンク

最近はHiFive Unmatched（HiFive Unleashedも使い勝手はほぼ同じ）を使っていることが多いのですが、このボードは開発環境としてはなかなか魅力的です。素敵なところをいくつか挙げると、

• USBケーブル1本でJTAGとUARTが同時に使える（JTAGの箱が要らない）
• 元々Linux用のボードなので、1GHzクラスのRV64IMAC 1コア＋RV64GC 4コア、USB、PCIe、GPIO、SPIなど重厚なハードが揃っている
• SoCの仕様書が公開されていて、誰でもアクセスできる

他社のボードもいくつか使いましたけど、USB-JTAGチップ搭載のボードはあまり見かけません。通常はJTAGを使いたいと思ったら、JTAGの箱（私はSEGGER J-LINK EDUを使っています）が必要です。が、HiFive系のボードはJTAGの箱が不要です。これは地味に嬉しいです。

製品では切り捨てられがちなJTAG

JTAGはベアメタルやブートローダのようなローレベル開発で重宝しますが、製品のボードにはまず搭載されることはないです。理由は単純。JTAGはデバッグ用の機能で、正常動作しているときには全く使わないからです。ボードのコストアップにしかならず、製品用の設計では真っ先に切られる機能です。以前、メーカーに居た時もデバッグ機能はソフトハード関わらず真っ先に切られていました。

利用者目線から見ると、デバッグ機能を切って安くあげるのは大正義です。利用者はまずデバッグ機能なんて使いませんし、デバッグ機能を悪用して機器に侵入するなどの被害を防ぐ効果もあります。

とはいえ開発者目線から見るとデバッグ機能のないボードやSoCは、トラブったとき解析しづらくて困ります……。なので、SoCレベルではデバッグ機能ON、ボードレベルではOFFにしておいて、不具合解析の際は特殊な治具を繋いでボードレベルのデバッグ機能をONにする設計を良く見かけます。