目次: ROCK64/ROCKPro64
RK3328のI2S1で44.1kHz系を再生するとEINVALエラーになってしまう問題は、I2Sのマスタークロック周波数が11289600ではなく11289599などという変な値が渡されて、マスタークロックとビットクロックが整数比ではなくなることが原因でした。
エラーを無視して処理を流してみると、分周比がおかしくなります。本来11289600 / 2822400 = 4にならなければいけないのですが、11289599 / 2822400 = 3になって、周波数が高めに設定されてしまい、異常に音が高くなります。
Rockchip Linuxはどうやって解決しているのか見るとDIV_ROUND_CLOSESTというマクロで割り算の結果を4側に丸めていました。本当の原因は変な端数の値を返すクロックドライバだと思うので、この対応はちょっとイケてないですね……。
ACODECにも2つほど問題があって、完全には解決できていません。
問題1つ目は、44.1kHz系を再生すると、全く音が出なくなる症状です。これはコアのリセットで直るようです。
リセットを掛けないと、切り替え以降、何をしても全く音が出ません。しかしRockchip Linuxのコードは全くリセットを掛けておらず、なぜこれで動くのか理解できません……。
気になる点としては、リセットすることでdai_set_fmtで設定されたI2Sのマスタースレーブ設定が吹き飛んでしまうことです。しかしACODECはなぜかマスタースレーブ設定が間違っていても動いてしまいます。ハードが設定値を無視しているか、Rockchip Linuxのドライバが間違っているかどちらかでしょう。真相はわかりません。
問題2つ目は、48kHz系 → 44.1kHz系への切り替え時、たまに音が異常に小さくなる症状です。これは直せそうにないです。
これくらいまではわかりましたが、鳴るときor鳴らないときの法則が全くわからないので、これ以上追うのは厳しいです。
体感では、クロック系の切り替えが早すぎると(1秒くらい?)症状が出やすいです。何でだろう??
while :; do aplay -D hw:0,0 48k.wav ; aplay -D hw:0,0 44k.wav ; done
こんなスクリプトをグルグル回すと、44kHz系は全く音が出ません。待ち時間が足りないのかと思いPRECHARGEの後に500msのウェイトを入れましたが、結果は変わらず音が出ません。。。
Raspberry Pi対抗ボードの多くはRaspberry Pi 3のEthernetが遅いこと(USB接続らしい)を引き合いに出し、ネットワークが速いことを宣伝文句にしています。
宣伝文句自体は疑っていませんが、どの程度の差があるかは知らないので、測定してみました。ちょうどTinker Boardも購入しましたし、Rockchip同士の比較もしてみたいと思います。
測定は簡単です。受信側のPCで下記を実行します。
$ iperf3 -s -p 11111
送信側の各種ボードで下記を実行します。
$ iperf3 -c (PCのIPアドレス) -p 11111
受信側のPCのCPUはRyzen 7 2700で、マザーボードはASUS B450-F GAMINGです。OSはDebian GNU/Linux amd64のTesting版です。測定時点でのカーネルは4.18.0-2-amd64というバージョンになっていました。
結果だけ先に言うとTinker Board(RK3288)の方が速いです。ROCK64(RK3328)の方が後発のSoCなのですが、Ethernetは遅いみたいですね。
ちなみにRaspberry Pi 3は94Mbpsでした。そもそもGigabit Etherじゃないので、比べ物になりません。
念のため各ボードのEthernetケーブルを入れ替えてみましたが、結果は変わりませんでした。
参考までにファイルサーバとして使っているPentium Jのマシンから、同様の計測を行ったところ942Mbits/sec でした。
結果はこんな感じでした。
katsuhiro@linaro-alip:~$ iperf3 -c 192.168.1.2 -p 11111 Connecting to host 192.168.1.2, port 11111 [ 4] local 192.168.1.16 port 58608 connected to 192.168.1.2 port 11111 [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 113 MBytes 950 Mbits/sec 0 358 KBytes [ 4] 1.00-2.00 sec 112 MBytes 942 Mbits/sec 0 358 KBytes [ 4] 2.00-3.00 sec 112 MBytes 941 Mbits/sec 0 358 KBytes [ 4] 3.00-4.00 sec 112 MBytes 941 Mbits/sec 0 358 KBytes [ 4] 4.00-5.00 sec 112 MBytes 941 Mbits/sec 0 358 KBytes [ 4] 5.00-6.00 sec 112 MBytes 943 Mbits/sec 0 406 KBytes [ 4] 6.00-7.00 sec 112 MBytes 941 Mbits/sec 0 406 KBytes [ 4] 7.00-8.00 sec 112 MBytes 941 Mbits/sec 0 406 KBytes [ 4] 8.00-9.00 sec 112 MBytes 941 Mbits/sec 0 406 KBytes [ 4] 9.00-10.00 sec 112 MBytes 941 Mbits/sec 0 406 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 1.10 GBytes 942 Mbits/sec 0 sender [ 4] 0.00-10.00 sec 1.10 GBytes 942 Mbits/sec receiver iperf Done.
katsuhiro@rock64:~$ iperf3 -c 192.168.1.2 -p 11111 Connecting to host 192.168.1.2, port 11111 [ 4] local 192.168.1.102 port 54768 connected to 192.168.1.2 port 11111 [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 97.6 MBytes 819 Mbits/sec 0 356 KBytes [ 4] 1.00-2.00 sec 96.4 MBytes 808 Mbits/sec 0 395 KBytes [ 4] 2.00-3.00 sec 95.8 MBytes 804 Mbits/sec 0 395 KBytes [ 4] 3.00-4.00 sec 95.7 MBytes 803 Mbits/sec 0 395 KBytes [ 4] 4.00-5.00 sec 95.8 MBytes 803 Mbits/sec 0 395 KBytes [ 4] 5.00-6.00 sec 95.8 MBytes 804 Mbits/sec 0 395 KBytes [ 4] 6.00-7.00 sec 95.8 MBytes 804 Mbits/sec 0 395 KBytes [ 4] 7.00-8.00 sec 95.7 MBytes 803 Mbits/sec 0 395 KBytes [ 4] 8.00-9.00 sec 95.8 MBytes 804 Mbits/sec 0 395 KBytes [ 4] 9.00-10.00 sec 95.8 MBytes 803 Mbits/sec 0 395 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 960 MBytes 805 Mbits/sec 0 sender [ 4] 0.00-10.00 sec 958 MBytes 804 Mbits/sec receiver iperf Done.
katsuhiro@raspberrypi:~ $ iperf3 -c 192.168.1.2 -p 11111 Connecting to host 192.168.1.2, port 11111 [ 4] local 192.168.1.105 port 46476 connected to 192.168.1.2 port 11111 [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 11.3 MBytes 94.6 Mbits/sec 0 29.7 KBytes [ 4] 1.00-2.00 sec 11.2 MBytes 94.1 Mbits/sec 0 29.7 KBytes [ 4] 2.00-3.00 sec 11.2 MBytes 94.1 Mbits/sec 0 29.7 KBytes [ 4] 3.00-4.00 sec 11.2 MBytes 94.2 Mbits/sec 0 29.7 KBytes [ 4] 4.00-5.00 sec 11.2 MBytes 94.1 Mbits/sec 0 29.7 KBytes [ 4] 5.00-6.00 sec 11.2 MBytes 94.2 Mbits/sec 0 29.7 KBytes [ 4] 6.00-7.00 sec 11.2 MBytes 94.2 Mbits/sec 0 29.7 KBytes [ 4] 7.00-8.00 sec 11.2 MBytes 94.1 Mbits/sec 0 29.7 KBytes [ 4] 8.00-9.00 sec 11.2 MBytes 94.2 Mbits/sec 0 29.7 KBytes [ 4] 9.00-10.00 sec 11.2 MBytes 94.1 Mbits/sec 0 29.7 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 112 MBytes 94.2 Mbits/sec 0 sender [ 4] 0.00-10.00 sec 112 MBytes 94.2 Mbits/sec receiver iperf Done.
目次: ROCK64/ROCKPro64
Tinker Boardでサウンド周りを有効にしてlinux-nextを動かしてみたものの、指摘された不具合(2018年12月5日の日記参照)が出ません。
メールではDMAドライバのどこかでクラッシュした、と言われました。サウンド周りのハードウェアはI2Sとコーデックが居ますが、DMAを使うのはI2Sだけです。コーデックmax98090はSoC外部に居ますから、SoC内部のDMAを使う術がありません。
I2Sが原因ならば、SoC内部のハードウェア起因ですから、Tinker BoardだろうがChromebook C201だろうが、ボードに関わらず現象が再現しても良さそうなのに。
Chromebookで使われているグルードライバrockchip-snd-max98090の影響も疑って、Chromebook C201のデバイスツリー(rk3288-veyron-speedy.dts)からデバイスノードの設定をパクってきて、max98090をspdif-transimtterに差し替えて(Tinker Boardにmax98090は搭載されていない)、無理やり動かしてみましたが、特に何事も無く動いてしまいました。
どうやってもChromebook C201じゃないと再現しないのかな?良くわからないバグだ……。
ROCK64のときはアナログオーディオ出力でもHDMI出力でも、SoC内蔵のI2Sハードが動作しましたが、Tinker Boardはちょっと事情が違います。
Tinker Boardにもアナログオーディオ端子は付いていますが、接続先はRK3288ではなくオンボードのUSB Audio(Realtek ALC4040)です。アナログオーディオのためにわざわざ専用USBデバイスを載せるとは、豪華なボードだなあ〜。
というわけで、Tinker BoardでSoC内蔵のI2Sが動くかどうか試すには、アナログオーディオ端子ではダメで、HDMI出力じゃないと本当に動作しているかどうかわからないです。我が家にはデジタルテレビならありますが、ボードからケーブルが届かないですね。
できればHDMIが映せて、音も出せて、ボードの隣に置いても邪魔にならないくらい小さいモニタがあるとベストですが、我が家にそんなもんは無い……。
メモ: 技術系の話はFacebookから転記しておくことにした。少し加筆した。
先日購入(2018年12月5日の日記参照)したTinker Boardでlinux-nextを動かしてみたら、特に何も引っかかることなく起動しました。素敵。しかし調子に乗ってコンフィグをガチャガチャ弄ってたら起動しなくなってしまいました。
ちょっと焦りましたが、同時にROCK64も起動しなくなっていたので、原因はコンフィグじゃなくて、linux-nextの12月11日版を引っ張ってきたことのようです。先週もなってたなあ。またか〜。
AArch32とAArch64のビルドを往復でやっていて、vmlinuxのリンク速度が全然違うことに気づきました。AArch64の方が桁違いに遅いです。
AArch32だとvmlinuxのサイズは20MBくらいですが、AArch64向けにビルドするとなぜかvmlinuxが300MBとかになります。なぜこんなにデカいんでしょう。リンクが遅くて辛いです。
Tinker BoardはU-bootでsaveenvすると二度と起動しなくなります。linux-nextを起動するコマンドをsaveしたかったのですが、できません。ちょっと不便です。
この症状ROCK64も同じでした。RockchipのU-bootは何かおかしいんだろうか……?
メモ: 技術系の話はFacebookから転記しておくことにした。少し加筆。
私は、比較的PCと出会った時期は遅い(※)ので、パソコン原始時代をほとんど知らないですが、それでも当時のマシンと、今使っているRyzen 7マシンを比べると隔世の感があります。
(※)初めて触ったのは中学校にあったPC9821-Cb2、買ったのはPC9821-V7でCPUはPentium/75MHzだった、はず。
中学生で思い出しましたが、Aboutページの写真(Facebookのアイコンでもある)は中学2年生の時の顔です。現像した写真のスキャンではなく、当時珍しかった「デジカメ」で撮った写真です。機種は覚えていませんが、フロッピーに記録するタイプでした。
当時とそんなに顔は変わっていませんが、髪はかなり白くなりました。何でだろ、体質なのかな……?
メモ: 技術系の話はFacebookから転記しておくことにした。
Ryzen 7は8コア16スレッドCPUですが、5万円もしません。10万円あれば、Ryzen 7 2700, 32GB DDR4, NVMe SSD, マザーボードを買ってもお釣りが来てしまいます。
これほどお安く16並列ビルド(make -j16)に耐えうるCPU, I/O, メモリが購入できる時代が来るとは思いませんでした。一昔前なら、サーバー用の異常に高価なシステムでしか実現できなかったことです。
技術の進歩って素晴らしいですね。
メモ: 技術系の話はFacebookから転記しておくことにした。
目次: ROCK64/ROCKPro64
ASUS Tinker Boardを買いました。RK3288搭載のボードです。RK3288は2014年に登場した32bit CPU(Cortex-A17 x 4)なSoCです。今となっては少し古く感じます。
今あえてTinker Boardを買った理由は、私がlinux-nextに入れた変更(2018年11月10日の日記参照)でRK3288搭載のASUS Chromebook C201がデグレしたらしく、再現環境が欲しかったからです。
パッチに対し、海外の方からの指摘が来ており、症状としてはDMACのコードのどこかでカーネルが吹き飛んでしまうとのことですが、手元のROCK64(RK3328)では再現しません。
Chromebook C201を買うのが一番良いんですが、5万円近くしますし、買っても使う予定がないので、あまり買いたくありませんでした…。
対してTinker Boardなら1万円しませんし、同じRK3288搭載ですし、症状が再現しないかなあ、なんてことを期待しています。
今はDebianを起動しただけで特に何も触っていませんが、週末辺りにでもカーネル入れ替えにトライしてみようと思います。
メモ: 技術系の話はFacebookから転記しておくことにした。
いつものようにlinux-nextを最新版にrebaseしたら、ROCK64が起動しなくなってしまいました。起動時に恐ろしい量のエラーが出てpanicします。エラーメッセージを斜め読みするとDMACとSPIのエラーに見えたので、無効化してみましたが、今度はeMMCが死んでrootfsが読めずやっぱりpanicします。これはダメだ。
調べてみると、DMA関連のパッチ(LKMLへのリンク)が原因でした。MLの議論を見ると、原因も判明しているようですし、そのうちlinux-nextも直るでしょう(後日談: 次の日に直っていました)。
今回初めてまともにlinux-nextをgit bisectしましたが、git bisect goodもしくはbadを打つ度に、ほぼ毎回フルビルドになってしまい、とにかくビルドの時間が掛かって辛かったです。
先日Ryzen 7にCPUを換装していなかったら、間違いなく途中で諦めていたと思います……。
メモ: 技術系の話はFacebookから転記しておくことにした。
普段、家のPCのパワー不足を感じることはないのですが、linux-nextのクロスコンパイルをしていると、vmlinuxのリンクが遅いな〜……と感じることが増えました。
比較対象は前の会社のマシンや、今の会社のマシン(割と最近のCore i5かCore i7が多い)です。1〜2年しか経ってないCore i7(Skylake, Kabylake世代)と4年落ちのAMD A10(Kaveri世代)を比べれば遅いのは当然ですね。
新しいCPUはIntelにしようかとも思ったのですが、ニュースを見ているとRyzen系も大変良さそうだったので、思い切って第2世代Ryzenに買い替えることにしました。
AMD Ryzen 7 2700が届きました。3年ほど頑張ってくれたAMD A10と入れ替えました。今までお疲れさまでした。
メモリは平凡にG.SkillのAMD向けと銘打っているDDR4-2400 2枚差し16GB x 2にしました。ここ数年、メモリはハズレばかりで嫌になったので、4枚差しや極端なオーバークロックメモリは避けました。
マザーボードはASUS B450-F GAMINGにしました。チップセットはミドルエンド向けのB450です。もしハイエンド向けが良ければX470ですが、マルチGPU構成にしたい人以外、ほぼ用事がないと思います。値段の差は5000〜10000円くらいのようです。
マザーボードはGAMINGの名の通りゲーマー仕様(?)で、無駄にLEDが光っていていたり、妙なプレートが付いていたり、変テコなデザインです。まあ、筐体の蓋を閉めれば光はほとんど見えませんから、気にならないでしょう……。
SSDはSamsung 970 EVO M.2にしました。元々Blu-rayドライブ、HDD、SSDしか差さっておらず、スカスカだったSATAポートがさらに寂しくなります。
SSDはかなりややこしいことになっていて、コネクタの物理形状の規格、インタフェース信号の規格、コントローラのプロトコルの規格が、複数種類存在しています。
コネクタ | インタフェース | コントローラ | 特徴 |
---|---|---|---|
SATAコネクタ | SATA | AHCI | HDDのような形、大抵は2.5 inch |
M.2スロット | SATA | AHCI | M.2 SSDのB Key(12-19ピンが欠けている) |
M.2スロット | PCI Express | AHCI | 私は見たことがない、M Keyになっているはず |
M.2スロット | PCI Express | NVMe | M.2 SSDのM Key(59-66ピンが欠けている) |
PCI Expressスロット | PCI Express | NVMe | グラフィックカードのような形 |
今まで私が使っていたOCZ Vertexは1番目、今回購入したSamsung EVO 970 M.2 NVMeは4番目の組み合わせに対応した製品です。2番目、4番目に両対応の製品もあるようです(B & M Keyと呼ばれ、端子に切り欠きが2つある)。
M.2 NVMe SSDは、SATAポートやドライブスロットを占有せず省スペースで、速度も有利(NVMeを使えれば)です。ただ欠点もあって、PCの買い替えなどでデータ移行するとき、やや面倒です。
SATA接続のSSDの場合、古いPCから取り外して新しいPCに繋げばコピーできます。今の時代SATAポートが1つもないマザーボードはないでしょう。SATAからUSBに変換するツールもたくさん売っています。
M.2接続のSSDの場合、マザーボードの仕様によりM.2スロットの有無が異なりますので、もし新しいPCにM.2スロットがない場合、データ移行が難しくなります。
次の買い替えを考えるとM.2 → USB変換機器(特にPCIe NVMe対応のもの)を買っておきたいところです。調べてみるとJMicron JMS583というPCI ExpressとUSB 3.0のブリッジチップを搭載した変換ツールがいくつか発売されていました。買っておこうかなあ。
メモ: 技術系の話はFacebookから転記しておくことにした。大幅に加筆した。
目次: ROCK64/ROCKPro64
先日(2018年11月28日の日記参照)の続きです。linux-nextでROCK64のアナログオーディオ出力から音が出ました。残る問題は1つでした。
3番目の「ACODECはTRMに何も情報が載っていない」を回避しました。
ACODECはI2S信号をアナログオーディオ信号に変換するハードウェアです。仕様を秘密にするようなハードウェアではないと思いますが、TRM(Technical Reference Manual)に記載がありません。無いものは仕方ないので、rockchip-linuxからドライバを移植しました。
残念ながらrockchip-linuxはカーネルバージョンが4.4と古く、ACODECドライバをlinux-nextに持ってきてもビルドできませんので、適当に直しました。ALSA SoCのドライバを作った経験があって良かった。うん。
とりあえずアナログオーディオは動いたのですが、昨日の日記にも書いた通り、44.1kHz系を再生するとACODECがおかしくなる仕組みは謎のままなので、まだ完成とは言えないです。
ROCK64はまだまだおもちゃとして遊べそうです。
目次: ROCK64/ROCKPro64
先日(2018年11月11日の日記参照)の続きです。linux-nextでROCK64のI2S1が動きました。残る問題は2つでした。
1番目の「I2S1はなぜか動かない」の原因が判明しました。
I2S1だけ死んでいた原因は、日記のコメントでT4さんに指摘いただいていた通り、RK3328のクロックゲートの定義がバグっていたことでした。linuxの開発MLに修正パッチをブン投げておきました。先週のどこかで取り込まれたっぽいです。良かった。
RK3328のクロック分周器はかなり対応範囲が広いので、単純にシステムクロック=fs * 256とすれば、44.1kHz系を再生するときシステムクロックが11.2896MHzになり、48kHz系を再生するときシステムクロックが12.288MHzになって、うまく再生されるだろうと考えました。
やってみると48kHz系は正常に動作しますが、44.1kHz系を流すとEINVALを返してきて、なぜかACODECまでおかしくなり、リセットするまで一切音が出なくなります。イケてないです。
クロックのレジスタはGPLL * 147 / 6400 = 11.2896MHzに正しく設定されているのに、なぜかクロックドライバは11.289599MHzだと報告してくるので、サウンドドライバが44.1kHzの整数倍じゃないと判定してEINVALを返しています。
良く見るとGPLLの周波数も491.519999MHzという変な値になっています。なぜ491.52MHzじゃないのか?491.52MHzなら先ほどの割り算は割り切れるはずなんですけどね。
あと44.1kHz系を再生するとACODECがおかしくなる仕組みも謎です。ACODECとクロックに何か関係があるのだろうか?また今度追ってみますか。
メモ: 技術系の話はFacebookから転記しておくことにした。少し加筆。
山手線の新型車両の車内広告は、横並びの3つの液晶ディスプレイを使いますが、各社で広告の見せ方が違って面白いです。
左から並べたとき、
動画、静止画の混在パターンもありました。
静止画のみのパターンもあります。
不思議なもので、3画面全て動画じゃなくても見栄えはします。しかし同じ静止画にされると、映っているものに関わらず、手抜き感を強く感じます。
メモ: 技術系の話はFacebookから転記しておくことにした。
< | 2018 | > | ||||
<< | < | 12 | > | >> | ||
日 | 月 | 火 | 水 | 木 | 金 | 土 |
- | - | - | - | - | - | 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 | - | - | - | - | - |
合計:
本日: