コグノスケ

RockPro64 の HDMI Audio

RK3399 の Drive Strength 設定を Max にしたことで、文字化けだらけでポンコツ状態だった RockPro64 のシリアルが割とまともになったので、最近は RockPro64 を触っています。

どうも linux-next の RockPro64 のデバイスツリーは HDMI Audio を有効にするのを忘れている？ようで、HDMI から音が出ません。有効にするパッチを LMKL に投げつけておきました……といっても、たった 3行のパッチです。

動かしたら一瞬で気づくはずですが、誰も直さなかったのかなあ？

Rock64 も RockPro64 も割と有名な部類のボードですが、Rockchip Linux じゃなくて、わざわざ linux-next で動かす人は少ないかもしれませんね。

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

RISC-V のコンパイラ

Crosstool-NG は RISC-V に対応していないのかと思っていたら、Experimental オプション（CT_EXPERIMENTAL）を Y に設定したら RISC-V が選べるみたいです。

GCC のビルドは ARM 向けに昔チャレンジしましたが、結構面倒くさいので、コンパイラを含むツールチェーンを簡単にビルドできる Crosstool-NG の存在は非常にありがたいです。あとは LLVM にも対応してくれたら最高なんですけどね。

Experimental というだけあって RISC-V 32bit 用のコンパイラはビルドエラーになってしまって作成できません。RISC-V 64bit 用のコンパイラは作成できます。

作成したコンパイラで適当なコードをビルドして逆アセンブルを見ると、命令長が 32bit のものと、16bit のものが混在していました。そういえば ARM も ARM 命令と Thumb 命令の 2種類の命令長があります。最近は RISC でも命令長可変の仕様が流行りなんでしょうか？

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

RockPro64 のシリアル出力

RockPro64 のシリアル文字化けの原因は、RK3399 の端子ドライブ能力不足が原因である可能性は高そうですが、最大値の 12mA に設定しても立ち上がりが遅い（立ち下がり 50ns 以下に対し、立ち上がり 300ns 以上かかる）点が気になります。

SoC 以外に原因があるとすれば、ボードの回路くらいですが、回路となると門外漢も良いところで、確かめ方がわかりません。

RockPro64 の Schematics を素直に信じると、SoC の出力ピンが直接コネクタに接続されていて、抵抗も何もないように読めます。RK3399 は SoC 裏面がハンダ付けされている（BGA）ため、コネクタ〜SoC 端子間に、本当に抵抗や断線がないかどうかは確かめようがありません。

文字化けの頻度はかなり減ったので、今のままでもそれなりに使えますが、なぜ立ち上がりだけが異常に遅いのか、釈然としません。うーん……。

ドライバ観点からの Rock64 や RockPro64 の使いやすさ

Rock64 というか Rockchip RK3328 の HDMI ドライバは drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c です。このドライバは多くの処理を drivers/gpu/drm/bridge/synopsys/dw-hdmi.c つまり Synopsys DesignWare の HDMI IP 用のドライバに頼っています。

Synopsys の HDMI ドライバは映像出力と、音声出力の機能を持っています。映像側の作りは知りませんが、音声側は ASoC フレームワークに合わせて作られています。そのお陰で Rock64 に HDMI 音声出力対応を追加するときは、デバイスツリーに記述を足すだけで良く、非常に楽でした。

Synopsys のドライバは linux-next に Upstream されていますが、コミットログを見る限り Synopsys のメールアドレスの人はあまり出現しません。

社外の人や、会社と関係のない所属の人がわざわざドライバに修正をコミットしてくれるなんて、凄いことだと思います。人気のある IP のドライバを OSS にすると、色々な人が直してくれて、正のスパイラルが構築される、良い例と言えるでしょう。

この辺の根回しの良さは、さすが IP 屋さんの Synopsys って感じがしました。

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

RockPro64 のシリアル文字化け

以前（2018年 12月）に RockPro64 を購入したのですが、シリアルが文字化けして使い物にならず、ずっとお蔵入りになっていました。

最初はケーブルの接続や、接地がおかしいのかと思いましたが、GND 側はきっちり 0V でした。どうも単純な原因ではなさそうだったので、オシロスコープで信号を見ることにしました。テストパターンとして 0 と 1 が交互に出現し、一番転送が難しいパターンと思われる 0x55 'U' の文字を出力しています。

正常に出力できている Rock64 と比較すると、Rock64 は出力が 0 → 1 → 0 と変化する際に 0V → 3V → 0V のように電圧が振れますが、RockPro64 は、0V → 2.48V → 0V のように立ち上がり側が遅く、中途半端な電圧になっています。

下記の画像の青色の線が Rock64 のシリアル出力で、オレンジ色の線が RockPro64 のシリアル出力です。どちらも 1秒ごとに 'U' を出力して、最初の立ち下がり（Start Bit、必ず 0）にトリガを掛けています。

Rock64 のシリアル出力の波形

RockPro64 のシリアル出力の波形

Rock64 は綺麗な波形ですが、RockPro64 は 0V → 3V への立ち上がりが間に合っていないことが分かるかと思います。

文字化けの原因ですけども、シリアルの転送速度（1.5Mbps、1ビット 666ns）に対し、0 → 1 の立ち上がりが遅すぎる（650ns くらい）からでしょう。出力側は 1 を送出しているつもりでも、信号が立ち上がるのが遅いため、受信側は 0 だと解釈してしまう場合があります。

転送速度を落とせば改善するかもしれません。しかし Rockchip の U-Boot はなぜか 1.5Mbps 固定で転送してくる困った奴で、下手にシリアルの転送速度を変えると U-Boot が操作できなくなり、非常に使いづらいのです。イマイチですね……。

RockPro64 のシリアル出力の文字化けを改善する

RockPro64 には Rockchip の RK3399 と言う SoC が搭載されていて、RK3399 は一部のピンの Drive Strength、つまりピンに流せる電流量を調整できます。決して特殊な機能ではなく、大抵の SoC が持つ普通の機能です。

RockPro64 がコネクタに引き出しているシリアルは UART2 です。UART2 は GPIO4_C4（TX）と GPIO4_C3（RX）というピンに割り当てられています。幸運なことに RK3399 ではこれらのピンの Drive Strength が変更できるので、設定値を振って（※）オシロで波形を見てみました。

下記の画像が測定結果です。1枚目はデフォルトかつ最小の 3mA、2枚目は最大の 12mA 設定です。出力している文字は前回同様 0x55 'U' で、トリガも前回同様 Start Bit の立ち下がりに仕掛けています。オシロの Rising, Falling Time 解析を ON にしたので、立ち上がり、立ち下がりに掛かった時間も一緒に表示されています。

Drive Strength = 3mA のときのシリアル出力波形

Drive Strength = 12mA のときのシリアル出力波形

字が若干見づらいので、一応書いておくと、立ち上がりの時間は 650ns → 300ns くらいに改善しました。良い感じですね。

ちなみにスクリーンショットの色が変で、文字が読みづらいのは仕様です。Tektronix さん、スクリーンショット背景の白黒反転処理、バグってますよ……？？

それはさておき Drive Strength の変更で、RockPro64 のシリアル文字化けはかなり改善されました。しかし完全ではなく大量に出力した際に若干文字化けします。

さらなる改善のためには、シリアルの転送速度を落とすくらいしか思いつきません。が、U-Boot の書き換えをするのが面倒くさいので、また今度にします……。

（※）レジスタ名は GRF_GPIO4C_E で、アドレスは 0xff77e138 です。書き込む値は 0x03c00xx0 をお勧めします。xx の部分はドライブ能力を最小にするなら 00 で、最大にするなら 3c です。

メモ: 技術系の話は Facebook から転記しておくことにした。追記、文章の組み換えをした。