目次: ROCK64/ROCKPro64
ROCKPro64にはPCI Expressスロットが実装されています。せっかくあるので試そうと思い、玄人志向のSATAインタフェース増設カード(SATA3-PCIE-E2)と、USB 3.0インタフェース増設カード(USB3.0R-P2H2-PCIE)を買いました。
結論から先に言うとRK3399のPCI Expressコントローラは有効にできましたが、ROCKPro64の信号品質が良くないのかUSBのカードしか認識しませんでした。残念です。
唯一認識されるUSBのカードもPCI Expressのライザーカードで延長すると認識しなくなります。認識できるギリギリの信号なんですかね。
rockchip-pcie f8000000.pcie: PCIe link training gen1 timeout!
認識されないときはこんなエラーログが出ています。うーん。
RK3399のPCIeコントローラもちょっと癖があって、ep-gpiosプロパティを指定しないとprobe時にエラーで落ちます。このドライバはGPIOを使ってレギュレータを操作し、PCI Expressへの電源供給を制御したいようです。
通常、デバイスドライバで電源制御を実装したい場合vpcie12v-supplyのようなレギュレータを指定するプロパティを使いますが、なぜGPIOを使っているのでしょうね……?
しかもうまくないことにROCKPro64の場合、既にPCI Express用レギュレータのデバイスノードが定義されており、常にPCI Expressの電源をONにしています。そのためPCI ExpressのデバイスノードにGPIOを追加すると「もう使われているよ!」と怒られてしまいます。
どう直すのが正しいのかわかりませんが、とりあえずPCI Expressのドライバを改造し、GPIOのエラー処理を削ったら先に進みました。しかし良くハングするようにもなりました。イマイチだ……。
後日、直すことができました(2019年5月9日の日記参照)。
メモ: 技術系の話はFacebookから転記しておくことにした。追記した。
目次: ROCK64/ROCKPro64
昔、私が投稿したパッチがLinux 4.20をデグレさせていました。Linux 4.20以降ではROCK64のUSBが動かなくなっています。全然気づきませんでした……。
Arch Linuxの人たちが「動かねーぞ??」とハマった挙句(リンク)に、指摘してくれたようです。
反省を込めて、ROCK64がデグレした理由をまとめておきます。
当時、私が直したのはピンに出力する信号の割り当て設定です。
GPIO0 A2
GPIO0 D3
上記のように、本来GPIO0 D3にはS/PDIF信号が割り当てられるはずですが、なぜか全く関係のないUSB電源供給信号が割り当てられており、S/PDIFが全く動作しない状態になっていました。
私のパッチはUSB電源供給信号のピンアサインをGPIO0 A2に直すパッチです。GPIO0 D3ピンからS/PDIFが無事出力できるようになりました。
しかし実装の間違いはこれだけではありませんでした。GPIO0 A2は信号の極性(Active High指定でしたが、本来はActive Lowが正しい)も間違っていたのです。
GPIO0 A2
私のパッチはピンアサインだけ直して、信号の極性を直さなかったため、USBの電源が常にダウンしてしまい、USBが全く動かなくなってしまったようです。
USB電源周りをいじったのに、USBの動作確認をせずにパッチを投稿してしまったのは、片手落ちだったなあと反省しきりです。
メモ: 技術系の話はFacebookから転記しておくことにした。
干支を3周しました。もう完全におじさんの仲間入りです。
若い人に自慢と説教だけはしないように気を付けよう。
せっかくHDMIディスプレイを買った(2019年2月2日の日記参照)ので、以前指摘されたRK3288のI2SとDMAがデグレしていないかどうか(2018年12月14日の日記参照)見るべく、linux-next + TinkerBoardのHDMI出力を確認しました。
映像は映り、音声も鳴りますが、48kHz ←→ 44kHzのLPCMを交互に再生すると、音声にバリバリとノイズが載ります。なぜかノイズが載らないときもあります。
ROCK64のアナログ出力でもこんな問題が起きていたので、同類だろうか?と不安になって、色々いじっていたのですが、どうも違う問題らしく、ディスプレイ側をON/OFFすると問題が発生するように見えます。
他のディスプレイで確認していないため、TinkerBoardが無罪とまでは言い切れませんが、おそらくディスプレイ側の問題でしょう。
目次: ROCK64/ROCKPro64
ROCKPro64のシリアルUART2が文字化けする問題に決着がつきました。
LKML(Linux Kernel Mailing List)に生息するナイスガイ達のおかげで、自分が持っているROCKPro64だけが異常値を示していることがわかりました。皆、普通にオシロスコープ持っているみたいですし、アイパターンまで見ていた人もいて、LKMLすげーな……と感心しました。
私のボードは、おそらくどこかにハンダ不良があり、RK3399からUART2ピンまでの抵抗値が異常に高くなっていると推測されます。
テスターで抵抗値を見ればわかるはずですが、ROCKPro64はボードのシルクに部品番号が全く書いておらず、どこにプローブを当てたら良いかさっぱりわかりませんでした。残念。
メモ: 技術系の話はFacebookから転記しておくことにした。
目次: ROCK64/ROCKPro64
メンテナーのHeikoさんからは「共通部分を変えようとしているから、他のボードの関係者にも聞いてくれ」とのことでした。そりゃそうだなと、RK3399のボードのデバイスツリーを変えていそうな人達にCCでメールしてみたところ、お返事がきました。
Tonyさんは、ROC RK3399 PCとROCKPro64の2つのバージョン(V2.0とV2.1、私が持っているのはV2.1)など、色々なボードでの立ち上がり、立ち下がり時間の測定値を教えてくれました。いずれも私が観測しているような症状はないとのことです。
Robinさんは、アイパターンを見てくれて、やっぱり異常はないと教えてくれました。
念のため、ピンに何か繋いでいる(インピーダンスが低い、立ち上がり時間が遅く計測される)のか、何も繋いでいない(インピーダンスが高い、立ち上がり時間が速く計測される)のかも確認しましたが、UART-USB変換ボードをジャンパケーブルで繋いでいるとのことでした。
うーん。話を総合すると、どうも私のボードの個体不良っぽいです。パッチは取り下げておきました。やりとりは面白かったですが、結果的には皆さんを混乱させてしまっただけでしたね。
目次: ROCK64/ROCKPro64
(主に俺のために)ROCKPro64のシリアル文字化けを直すべく、Rockchip RK3399のシリアルUART2のdrive strengthを3mAから12mAにするパッチをLKML(Linux Kernel Mailing List)に送ってみました。ま、ダメ元です。
ROCKPro64だけ何でこんなにRising timeが長くなるのでしょう?
Rockchip RK3328搭載のROCK64は、特に問題がないように見えます。ROCKPro64同様にROCK64もRK3328からPi-2コネクタに直で信号を出しているはずなのに。
RK3399の方がプロセス進んでるから、I/Oドライブ性能が低いのでしょうか。結局、問題の原因は良くわからないままです。
パッチを送ってから気づいたのですが、タイトルにRK3399向けのパッチと説明を忘れていたり、ROCKPro64しか確認できていない症状なのに、共通ファイルrk3399.dtsiに変更入れていたり、色々マズいです。そんなもんROCKPro64のデバイスツリーに入れてよ……、ってリジェクトされる気がします。
おそらく他のRK3399のボードもRK3399とUARTのピンを直結していれば、同じ症状が起きると思うんですが、私は他のボード持っていないからわかりません。
メモ: 技術系の話はFacebookから転記しておくことにした。加筆した。
< | 2019 | > | ||||
<< | < | 03 | > | >> | ||
日 | 月 | 火 | 水 | 木 | 金 | 土 |
- | - | - | - | - | 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 | - | - | - | - | - | - |
合計:
本日: