コグノスケ

ROCK64のUSBをデグレさせた

目次: ARM

昔、私が投稿したパッチがLinux 4.20をデグレさせていました。Linux 4.20以降ではROCK64のUSBが動かなくなっています。全然気づきませんでした……。

Arch Linuxの人たちが「動かねーぞ？？」とハマった挙句（リンク）に、指摘してくれたようです。

反省を込めて、ROCK64がデグレした理由をまとめておきます。

当時、私が直したのはピンに出力する信号の割り当て設定です。

GPIO0 A2

• 本来の出力: USB電源供給Enable/Disable信号
• 当時の出力: 何も割り当たっていない（が、なぜか動いていた…）

GPIO0 D3

• 本来の出力: S/PDIF信号
• 当時の出力: USB電源供給Enable/Disable信号

上記のように、本来GPIO0 D3にはS/PDIF信号が割り当てられるはずですが、なぜか全く関係のないUSB電源供給信号が割り当てられており、S/PDIFが全く動作しない状態になっていました。

私のパッチはUSB電源供給信号のピンアサインをGPIO0 A2に直すパッチです。GPIO0 D3ピンからS/PDIFが無事出力できるようになりました。

しかし実装の間違いはこれだけではありませんでした。GPIO0 A2は信号の極性（Active High指定でしたが、本来はActive Lowが正しい）も間違っていたのです。

GPIO0 A2

• 本来: USB電源供給Enable/Disable信号
• 実装: 何も割り当たっていない
• パッチ後: USB電源供給Enable/Disable信号（直った）
• 本来の極性: Active Low
• 実装の極性: Active High
• パッチ後: Active High（変化なし）

私のパッチはピンアサインだけ直して、信号の極性を直さなかったため、USBの電源が常にダウンしてしまい、USBが全く動かなくなってしまったようです。

USB電源周りをいじったのに、USBの動作確認をせずにパッチを投稿してしまったのは、片手落ちだったなあと反省しきりです。

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

誕生日

干支を3周しました。もう完全におじさんの仲間入りです。

若い人に自慢と説教だけはしないように気を付けよう。

TinkerBoardのHDMI出力

せっかくHDMIディスプレイを買った（2019年2月2日の日記参照）ので、以前指摘されたRK3288のI2SとDMAがデグレしていないかどうか（2018年12月14日の日記参照）見るべく、linux-next + TinkerBoardのHDMI出力を確認しました。

映像は映り、音声も鳴りますが、48kHz ←→ 44kHzのLPCMを交互に再生すると、音声にバリバリとノイズが載ります。なぜかノイズが載らないときもあります。

ROCK64のアナログ出力でもこんな問題が起きていたので、同類だろうか？と不安になって、色々いじっていたのですが、どうも違う問題らしく、ディスプレイ側をON/OFFすると問題が発生するように見えます。

他のディスプレイで確認していないため、TinkerBoardが無罪とまでは言い切れませんが、おそらくディスプレイ側の問題でしょう。

ROCKPro64のシリアル文字化け - 結論

目次: ARM

ROCKPro64のシリアルUART2が文字化けする問題に決着がつきました。

LKML（Linux Kernel Mailing List）に生息するナイスガイ達のおかげで、自分が持っているROCKPro64だけが異常値を示していることがわかりました。皆、普通にオシロスコープ持っているみたいですし、アイパターンまで見ていた人もいて、LKMLすげーな……と感心しました。

私のボードは、おそらくどこかにハンダ不良があり、RK3399からUART2ピンまでの抵抗値が異常に高くなっていると推測されます。

テスターで抵抗値を見ればわかるはずですが、ROCKPro64はボードのシルクに部品番号が全く書いておらず、どこにプローブを当てたら良いかさっぱりわかりませんでした。残念。

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

ROCKPro64のシリアル文字化け - LKMLでの議論

目次: ARM

メンテナーのHeikoさんからは「共通部分を変えようとしているから、他のボードの関係者にも聞いてくれ」とのことでした。そりゃそうだなと、RK3399のボードのデバイスツリーを変えていそうな人達にCCでメールしてみたところ、お返事がきました。

Tonyさんは、ROC RK3399 PCとROCKPro64の2つのバージョン（V2.0とV2.1、私が持っているのはV2.1）など、色々なボードでの立ち上がり、立ち下がり時間の測定値を教えてくれました。いずれも私が観測しているような症状はないとのことです。

Robinさんは、アイパターンを見てくれて、やっぱり異常はないと教えてくれました。

念のため、ピンに何か繋いでいる（インピーダンスが低い、立ち上がり時間が遅く計測される）のか、何も繋いでいない（インピーダンスが高い、立ち上がり時間が速く計測される）のかも確認しましたが、UART-USB変換ボードをジャンパケーブルで繋いでいるとのことでした。

うーん。話を総合すると、どうも私のボードの個体不良っぽいです。パッチは取り下げておきました。やりとりは面白かったですが、結果的には皆さんを混乱させてしまっただけでしたね。

ROCKPro64のシリアル文字化け - パッチ投稿

目次: ARM

（主に俺のために）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から転記しておくことにした。加筆した。