コグノスケ

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は大丈夫なんですかね……？大した情報ではないとはいえ、ちょっと心配になってしまいます。

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）を改変しないと効果がないです。ご注意を。

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

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

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

LINEはわからずじまい

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

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

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購入

Amazonそのものの話。

• Amazonの不思議な注文確認メール
• ありがとうAmazonさん
• Amazonでよくあること
• Amazonの荷物消滅
• Amazonのマイリストの不思議な挙動
• Amazonマイリストへの問い合わせの返事がきた

再び挙動のおかしい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お答えできかねます」って言ってくれたら「そうなのか〜」で終わりなんだけど。何か過去にモメごとでもあったのかもね？