目次: RISC-V
最近はHiFive Unmatched(HiFive Unleashedも使い勝手はほぼ同じ)を使っていることが多いのですが、このボードは開発環境としてはなかなか魅力的です。素敵なところをいくつか挙げると、
他社のボードもいくつか使いましたけど、USB-JTAGチップ搭載のボードはあまり見かけません。通常はJTAGを使いたいと思ったら、JTAGの箱(私はSEGGER J-LINK EDUを使っています)が必要です。が、HiFive系のボードはJTAGの箱が不要です。これは地味に嬉しいです。
JTAGはベアメタルやブートローダのようなローレベル開発で重宝しますが、製品のボードにはまず搭載されることはないです。理由は単純。JTAGはデバッグ用の機能で、正常動作しているときには全く使わないからです。ボードのコストアップにしかならず、製品用の設計では真っ先に切られる機能です。以前、メーカーに居た時もデバッグ機能はソフトハード関わらず真っ先に切られていました。
利用者目線から見ると、デバッグ機能を切って安くあげるのは大正義です。利用者はまずデバッグ機能なんて使いませんし、デバッグ機能を悪用して機器に侵入するなどの被害を防ぐ効果もあります。
とはいえ開発者目線から見るとデバッグ機能のないボードやSoCは、トラブったとき解析しづらくて困ります……。なので、SoCレベルではデバッグ機能ON、ボードレベルではOFFにしておいて、不具合解析の際は特殊な治具を繋いでボードレベルのデバッグ機能をONにする設計を良く見かけます。
この記事にコメントする
目次: ゲーム
最近の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で遊ぶのは精神衛生上良くないですね。
この記事にコメントする
自治体の接種会場に行きました。ワクチンはファイザー製でした。
入り口には警備員さんがいましたが、予約システムの予約票は確認されないため「予約してまーす」って言ったら誰でも入れそうでした。が、多少嘘つきが混ざる程度は特に問題ないでしょう。
会場に入れないほど混んだり、1人も来ないなどの事態さえ発生しなければ、別に誰に打ったって良いわけですから。
ワクチン接種会場には毎日嫌になるほど人が来ていると思いますが、看護師を始めとした医療従事者の皆様は非常に親切かつ効率的に働いていました。日本の医療は最高だよ、ありがてぇ。
午後だったせいなのか、問診の先生はかなりお疲れモードで、半分目が死んでました。お疲れ様です、無理はしないでください……。
ワクチンを打った後は、肩こりみたいな痛さ、とか、肩にパンチを食らったような痛さ、と言われてますが、体験したら意味がわかりました。これは痛い……。
この記事にコメントする
上水道を売り払う自治体が出ました(下水道はこれまでもあった)。宮城県、水道3事業の運営権を売却へ 国内で初めて - 日経新聞。過疎地は水道維持費が大赤字と思われるので、速攻で廃止され昔ながらの井戸に戻るでしょう。
井戸=危険ではないですが、井戸の水質は「自己責任」でケチって検査せず使い続ける人達を止められないという点は気になるところです。自治体の基準としても「飲用井戸の衛生確保は、原則として設置者の自己責任」とあります(飲用井戸の衛生管理について - 千葉県より)。
汚染された井戸から疫病が発生、過疎地から都市部に大流行……なんて未来は笑えません。が、昔の日本や今の後進国では起きてた話ですし十分ありえますね。令和は昭和へ回帰する時代かもしれません。国の衰退、生活レベルの低下、衛生面の悪化といった悪い点でね……。
メモ: 技術系?の話はFacebookから転記しておくことにした。
この記事にコメントする
目次: Zephyr
最近ZephyrをHiFive Unmatchedに移植しています。基本的にはUnmatchedとUnleashedは似ています。メモリマップなどの大枠の仕様はほぼ同じですが、クロック周りを初めとして仕様が違う部分もあります。今日気づいたのは、
| 違うところ | Unmatched | Unleashed |
|---|---|---|
| 外付けの水晶発振器の周波数 | 26MHz | 33MHz |
| ペリフェラルクロック | hfpclk_pll | core_pllの1/2 |
| DDR領域 | リセット直後は使えない | リセット直後から使える |
安易にUnleashedから実装をコピーして楽しようとしたらハマりました……。
HiFive Unleashedはリセット直後からDDRにアクセスできるかなり変わったボードで、ZephyrはDDRにロードしてしまえば動きました。しかしHiFive UnmatchedのDDRは初期化しないと使えないため、ZephyrをDDRにロードする作戦は使えません。代わりとしては、
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のメインメモリ領域として活躍していただくことにしましょう。
この記事にコメントする
目次: 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という設定です。どうしてこの値なのかはわからないですけど、参考になります。
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は大丈夫なんですかね……?大した情報ではないとはいえ、ちょっと心配になってしまいます。
この記事にコメントする
| < | 2021 | > | ||||
| << | < | 08 | > | >> | ||
| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
| 29 | 30 | 31 | - | - | - | - |
25年10月15日
25年10月18日
22年5月5日
25年10月19日
23年4月11日
06年4月22日
25年10月17日
25年10月6日
25年10月13日
20年10月23日
25年10月12日
20年8月29日
19年1月13日
18年10月13日
18年9月3日
18年8月20日
18年7月23日
18年7月22日
18年10月14日
18年11月10日
wiki
Linux JM
Java API
2002年
2003年
2004年
2005年
2006年
2007年
2008年
2009年
2010年
2011年
2012年
2013年
2014年
2015年
2016年
2017年
2018年
2019年
2020年
2021年
2022年
2023年
2024年
2025年
過去日記について
アクセス統計
サーバ一覧
サイトの情報合計:
本日: