目次: ROCK64/ROCKPro64
RK3399のDrive Strength設定をMaxにしたことで、文字化けだらけでポンコツ状態だったROCKPro64のシリアルが割とまともになったので、最近はROCKPro64を触っています。
どうもlinux-nextのROCKPro64のデバイスツリーはHDMI Audioを有効にするのを忘れている?ようで、HDMIから音が出ません。有効にするパッチをLMKLに投げつけておきました……といっても、たった3行のパッチです。
動かしたら一瞬で気づくはずですが、誰も直さなかったのかなあ?
ROCK64もROCKPro64も割と有名な部類のボードですが、Rockchip Linuxじゃなくて、わざわざlinux-nextで動かす人は少ないかもしれませんね。
メモ: 技術系の話はFacebookから転記しておくことにした。
目次: GCC
目次: Linux
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から転記しておくことにした。少し加筆。
目次: ROCK64/ROCKPro64
ROCKPro64のシリアル文字化けの原因は、RK3399の端子ドライブ能力不足が原因である可能性は高そうですが、最大値の12mAに設定しても立ち上がりが遅い(立ち下がり50ns以下に対し、立ち上がり300ns以上かかる)点が気になります。
SoC以外に原因があるとすれば、ボードの回路くらいですが、回路となると門外漢も良いところで、確かめ方がわかりません。
ROCKPro64のSchematicsを素直に信じると、SoCの出力ピンが直接コネクタに接続されていて、抵抗も何もないように読めます。RK3399はSoC裏面がハンダ付けされている(BGA)ため、コネクタ〜SoC端子間に、本当に抵抗や断線がないかどうかは確かめようがありません。
文字化けの頻度はかなり減ったので、今のままでもそれなりに使えますが、なぜ立ち上がりだけが異常に遅いのか、釈然としません。うーん……。
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から転記しておくことにした。追記した。
目次: ROCK64/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は0V → 3Vへの立ち上がりが間に合っていないことが分かるかと思います。
文字化けの原因ですけども、シリアルの転送速度(1.5Mbps、1ビット666ns)に対し、0 → 1の立ち上がりが遅すぎる(650nsくらい)からでしょう。出力側は1を送出しているつもりでも、信号が立ち上がるのが遅いため、受信側は0だと解釈してしまう場合があります。
転送速度を落とせば改善するかもしれません。しかしRockchipのU-Bootはなぜか1.5Mbps固定で転送してくる困った奴で、下手にシリアルの転送速度を変えるとU-Bootが操作できなくなり、非常に使いづらいのです。イマイチですね……。
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から転記しておくことにした。追記、文章の組み換えをした。
目次: Linux
Linuxのクロックフレームワークで実装できるクロック分周器のドライバは2種類あります。
1つはinteger dividerで、入力されたクロック周波数の1/3や1/4など整数比の周波数で出力するハードウェアです。もう1つはfractional dividerで、周波数をx/yにするハードウェアです。
後者のfractional dividerドライバは、標準動作とカスタム動作のドライバが書けます。標準動作の場合、分子と分母に設定できる値に、何ら制約がないものとして動作します。カスタム動作のドライバは、特殊な制約のあるハードウェア向けです。
今のところカスタム動作のfractional dividerドライバを実装しているのはRockchipだけです。Rockchipの場合、分母が分子の20倍以上でなければ出力周波数が不安定になる制約があるようです。
Rockchipが変な仕様であることは間違いないと思いますが、Linuxに対応しているだけ、まだマシとも取れますね。世の中には「どうしてこうなった??」としか思えない、変な仕様のハードウェアがたくさん存在しますし……。
メモ: 技術系の話はFacebookから転記しておくことにした。
目次: ROCK64/ROCKPro64
先日購入したHDMIモニタのおかげで、ROCK64のI2S0つまりHDMI Audioの動作確認ができました。
しかし以前(2018年11月11日の日記参照)悩んでいた通り、単純にI2S0を有効にすることはできません。DMAチャネルが足りない問題が発生するためです。
ROCK64に搭載されているRockchip RK3328のDMACは、16のDMAチャネルを持っていますが、そのうち8chしか同時に使えない仕様になっています。
現在のlinux-nextのROCK64向けデバイスツリーでは、既に7chを使用(I2S1 2ch, SPDIF 1ch, SPI0 2ch, UART2 2ch)していますから、ここに2chを使用するI2S0を追加すると合計9chになって、オーバーしてしまいます。
仕方ないのでUART2のDMA割り当てを解除して、I2S0に割り当てるパッチを投稿しました。
私がパッチに書いた説明が悪かったのだと思いますが、メンテナーのHeikoさんから「どうしてUART2のDMAチャネルをI2S0が使えるのかわからない」という返事がきました。ですよね……私も最初意味不明でしたし。
できる限り説明を加えて返事しましたが、理解してもらえると良いな。
ややこしいことに、RK3328の仕様書を見ると、各DMAチャネルにはIDが(仕様書ではReq number)が振られていて、ぱっと見16チャネルが全て同時に使えそうに見えるんですよ。
この仕様書から「各DMAチャネルは独立しているけど、全てのチャネルが同時に使える訳ではない」という意味を読み取れる人はなかなかいないと思います。
少なくとも私はDMAのReq numberとチャネル数の関係を理解するのは無理だったので、DMACのドライバ(PL330)を追いかけました。
サウンド系からDMAチャネルの割り当てを要求するとき、次のような呼び出し関係になります。
rockchip_pcm_platform_register()
devm_snd_dmaengine_pcm_register()
snd_dmaengine_pcm_register()
dmaengine_pcm_request_chan_of()
dma_request_slave_channel_reason()
of_dma_request_slave_channel()
ofdma->of_dma_xlate() => of_dma_pl330_xlate()
dma_get_slave_channel()
dma_chan_get()
pl330_alloc_chan_resources()
pl330_request_channel()
まず、関数of_dma_pl330_xlate() にはローカル変数chan_idが登場します。これがDMAのIDに相当します。例えばUART2の送信側ならchan_id = 6になります。
元になる数字はどこから来るかというと、of_dma_match_channel() でデバイスツリーから情報を貰っています。RK3328の場合、デバイスツリーでDMAチャネルを指定する際は、Req numberを書くようです。
次に、関数pl330_request_channel() に構造体struct pl330_dmacのメンバーchannelsという配列が登場します。このchannelsの数がDMACのDMAチャネルの数と等しいです。Req numberとは無関係に、DMAチャネルを要求されると先頭から埋まっていきます。
こんな仕様が初見でわかる訳ないじゃない。むり。
メモ: 技術系の話はFacebookから転記しておくことにした。1節加筆。
目次: マンガ紹介
お気に入りのマンガ紹介シリーズ。
最近読んだ、これからも続編が楽しみなマンガ10作品。並びは、あいうえお順です。
1〜5です。
6〜10です。
メモ: 趣味の話はFacebookから転記しておくことにした。
小型のHDMIディスプレイを買いました。ELECROWのLR10FHD01です。Amazonで1万円くらい。
買ったきっかけですけども、ROCK64のHDMI出力を見たかったことと、サーバのVGA出力が壊れたのか、今持っている小型VGAディスプレイが映らなくなってしまったため、代替品が欲しかったからです。
見ての通りスペックはそこそこ良く、価格もお安いです。その分、細かいところはいい加減です。
音量調整がバカでVolume 1でも近所迷惑なデカい音が鳴ります。しかも最大音量は100です。こんなバカでかい音で誰が使うんでしょう?ミュートにできることがせめてもの救いです。
OSDメニューはヘボいです。日本語が選択できますが、漢字は中国語の字体、訳が意味不明、ハングルが混ざるなど、やる気ゼロです。英語に変えた方がマシです。
HDMI入力もバグっていて、HDMI挿抜もしくは電源ON/OFFで画面表示が右にズレて、音が出なくなります。もう一度電源ON/OFFすると直ります……。
本体に型番が書いておらず、箱を捨ててしまうと型番が分からなくなります。
細かいところは手抜き感が漂いますが、映れば全て良しです。
メモ: 技術系の話はFacebookから転記しておくことにした。加筆した。
目次: マンガ紹介
Facebookで教えてもらったマンガ「ハコヅメ」を買ってみました。面白いです。次が楽しみです。
メモ: 趣味の話はFacebookから転記しておくことにした。
弱者を抹殺する。 不謹慎な質問ですが、疑問に… - Yahoo! 知恵袋を読んで。
Twitterで知りました。7年以上前の話題ですが、ベストアンサーに選ばれた回答が素晴らしかったです。
ベストアンサーの中に出てくる「人間の生存戦略は、、、、「社会性」」の一文が非常に興味深かったので、社会性についてちょっと調べてみました。まず、大前提として、生物は生きようとしますし、子孫を増やそうとします。死にたがりや増えない生物は存続不能なので自明だと思います。
生物の行動は利己的、利他的があります(他に相利的行動、いじわる行動もありますが省略)。
利他的行動は一見すると合理的には見えません。しかし、世の中には社会性を持ち、利他的行動を取る生物がいます。人間もそうです。
これらの生物が、あえて利他的行動を取るのはなぜか?言われてみると確かに不思議です。
利他的行動についてはいくつか説があり、
個人的には、人間の社会性に関して言えば、群選択より、互恵的利他の説明が一番しっくりきます。互恵的利他の考えに基づくと、Yahoo! 知恵袋の問いに対しては「将来的に自身の利益になると期待しているから」が答えですかね?
まあ、社会性の仕組みは追々明らかになっていくことでしょう。楽しみですね。
どうでも良いですが、この手の仮説は、立証が大変そうだと思いました。私には利他的行動で得る利益が何かすら定義できないし、どの個体がいくら利益を得ているか示す手段も思いつきません……。
メモ: 技術系の話はFacebookから転記しておくことにした。加筆修正した。
< | 2019 | > | ||||
<< | < | 02 | > | >> | ||
日 | 月 | 火 | 水 | 木 | 金 | 土 |
- | - | - | - | - | 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 | - | - |
合計:
本日: