RPi4版 v1.0系不具合報告スレッド

パパリウス

大変な検証にお付き合いくださりありがとうございます。

検証結果を以下のテーブルにまとめたいと思います。
（モデレータの皆様は直接編集していただいて結構です。）

GPUブートローダ	合否
firm_20191118_16ce612146	NG
firm_20191119_a73aff718f	OK @ジャイアン
firm_20191122_77dcda76ee	OK @ジャイアン
firm_20191129_b9ecbe8d0e
firm_20191205_9300ca948e
firm_20191205_fcf277b30e
firm_20191211_57d3b3ac6e
firm_20200106_06cb898855
firm_20200106_b2b5f9eeb5
firm_20200110_8bb38ef026	@パパリウステスト中
firm_20200114_f0fdb006ab
firm_20200116_e8da15f1ba
firm_20200122_993f47507f
firm_20200130_15261920fa
firm_20200206_0dfefdceed	NG @ジャイアン起動不良
firm_20200207_2c615323f7	NG @ジャイアン温度上昇, Under Voltage
firm_20200210_397abb3c39	△（温度上昇大、ゴンザエモン）
firm_20200212_23acc388b4	OK @ジャイアン
firm_20200220_fd8347b54d	OK @ジャイアン
firm_20200228_e5d33208b7
firm_20200306_9dbd67c91d
firm_20200310_b524f5e7ac	OK（ゴンザエモン）
firm_20200326_0ef99a4e61
firm_20200401_837c2456a7	OK（ゴンザエモン）
firm_20200407_bc987d9297
firm_20200415_10f878d679
firm_20200416_b6e327eae0
firm_20200417_3cd8e820a3
firm_20200417_87fea11838
firm_20200419_62b50c3780
firm_20200420_16484e83df	OK （ゴンザエモン）
firm_20200427_e1050e9482
firm_20200501_8d64ec7016
firm_20200501_f0236cc587
firm_20200512_4e0af7eb74	OK

パパリウス

なお、このGPUブートローダですが、カーネルなどとの連携の要はあるのでしょうか？　全くないのであれば、逆に今まで動いていたもの（V1.0.3ベース?）を継続することで良いようにも思えるのですが。

@ゴンザエモンさん

nzatoさんのご報告によるとv1.0.0正式版で既に発生していた現象のようです。
環境によって発生頻度が異なるだけで、問題は初めから内在していたということになります。

皆さんにご協力いただいた検証結果から、新しいGPUブートローダを採用することで問題が解消することは確実です。
ただ、新しいブートローダには音質低下という別の問題があります。

RPi内部の電圧を各コンポーネントごとに細かく切り詰める方向で調整されていることが原因だと思いますが、、、、この音質の変化を聞いてしまうと、新ブートローダの採用にはどうしても躊躇してしまうものがあります。

ここ数日、新ブートローダを採用した状態でパラメータチューニングを試みています。
性能面だけで言えば、従来のセッティングと同等以上のチューニングができそうだという感触はあります。
ですが、出てくる音の質が違うんですよね。。。新ブートローダを採用すると、軽くて薄っぺらな方向の音になり、満足感は大幅に低下します。
美味しい設定を偶然発見するまで、時間をかけてチューニングを続ける必要があります。

従来のブートローダを継続できるならそうしたいな、、、という思いが湧いてきます。
そこで、どのバージョンで問題が解消するのか特定して、リリースノートからヒントを探し、その問題だけをピンポイントで対策できないかなと期待を抱いているところです。

nzato

@パパリウスさん

nzatoです

今、SabreBerry32からinno-hifi-dac-hatに換えて、v1.05β2マスターモードで聞いています。二時間ぐらいになりますが、ダッシュボードが問題なく表示できます、Rebootも問題なく立ち上がります。

SabreBerry32で頻発していたダッシュボードのトラブルが嘘のようです。

パパリウス

RPi4版 v1.0系不具合報告スレッドで@ジャイアンが発言 :

@パパリウスさん

うけたまわりでぇ〜す。
ですが、いまのところ現象再発していません（頭から順番に検証しています）。

この現象、CPU温度が関係している可能性はないでしょうか？
私の環境では、クーリングがうまくいっている個体（41℃ふきん）では発生率が低く、比較的CPU温度が高い個体（50℃後半）では高くなっています。

@ジャイアンさん

仰る通り、温度も関係しているかもしれませんね。
拙宅では、RPi4開発機にバスパワーのSSDを繋ぐと発生しやすくなります。
SSD使用中はRPi本体の温度も上がりやすくなりますし、電源への負荷も大きくなります。その辺りが関係しているのかな〜と思います、、、、

ちなみに、ジャイアンさんのところと同じく、現象を再現したいと思っているときには1日たっても2日たっても発生しません。:kissing:

ゴンザエモン

パパリウスさん

為念、再確認させてください。以下のバージョンでもGPUブートローダは同じ日付のものなのでしょうか？
　V1.0.3
　V1..0.5　（2019年8月版とのこと）
そこそこ発生頻度のある当方環境ですが、少なくともこの二つのバージョンでは差異があると現状認識しています。

もし同じブートローダだとすると、負荷あるいはCPU温度など？の条件によって大きく発生状況が異なる可能性があるため、検証自体をある程度合わせる様な確認方法を取らないといけないのかも、と思量しております。

ジャイアンさん：
当方は日付の真ん中辺りの20200210版から確認スタートしてみます。そこから順次4月、3月、2月、5月と行きつ戻りつ後ろ半分の中で範囲を絞ろうと思いますので適宜情報交換よろしくお願いいたします。

（追記）
なお、ベータ版ドライバーNo３ですが、20200512版のGPUブートローダとの組み合わせでは「プチノイズ再発」いたします。
こちらの確認はV1.0.5オリジナル版のGPUブートローダとセットで行うべきものでしょうか？

パパリウス

@ゴンザエモンさん

v1.0.3とv1.0.5のGPUブートローダは全く同じバージョンです。

先日検証していただいた2020/07/02版では問題発生の報告は1例もありません。
様々な環境の違いがあるにも関わらず、ピタッと現象が解消しているということです。
どのバージョンのブートローダから「ピタッと解消」するようになったのかが分かれば、ゴンザエモンさんの環境でv1.0.3とv1.0.5で発生頻度に違いが生じる理由も明らかにすることができるかもしれません。
いったんは発生頻度の問題には目を瞑り「ピタッと解消バージョン」を探し当てることを優先したいと思います。

β3ドライバーですが、GPUブートローダとの組み合わせはあまり気になさらなくて結構です。

拙宅では、完全にゼロではないものの「ほぼゼロ」と言える程度にはプチ音がしなくなりました。
原因箇所にあたりがついたので、引き続き対策を進めてみます

ゴンザエモン

パパリウスさん、ジャイアンさん

取り急ぎ20200210版ですが、温度が上がり続け非常に危険なので検証を中断しました。（当方は外付けFanによる空冷を行っているにも関わらず、、、です）
なお、vcgencmdのレスポンスはちゃんと返っています。

version : smpd pi4 edition v1.0.5
model : Raspberry Pi 4 Model B Rev 1.2
kernel : Linux 4.19.86-v8 #105 SMP PREEMPT Fri Jun 26 15:21:25 JST 2020
temp : 55.2'C
root [ ~ ]# vcgencmd measure_temp
temp=67.0'C
root [ ~ ]# vcgencmd measure_temp
temp=68.0'C
root [ ~ ]# vcgencmd measure_temp
temp=70.0'C
root [ ~ ]# vcgencmd measure_temp
temp=72.0'C

頻繁に更新されているのは、この辺りが原因かもしれませんね。

パパリウス

@ジャイアンさん @ゴンザエモンさん

検証にご協力いただきありがとうございます。
2019-11-19版が「ピタッと解消バージョン」のようですね。
こちらでも追試を開始したいと思います。

解消前後のバージョンである2019-11-18版と2019-11-19版のリリースノートを転記します。

2019-11-19版

firmware: arm_loader: Respect all required frequencies when throttling

firmware: Fixup vcgencmd display_power return values

2019-11-18版

firmware: Reduce voltage as part of DVFS

firmware: arm-loader: Inherit 2711 mac-address from the bootloader
See: http://git/vc4/vc4/merge_requests/687

ゴンザエモン

パパリウスさん

おはようございます。

現在2020-03-10版のテスト実施しておりますが、これが完了次第、

「2019-11-19版」

の追確認に入ります。こちらはかなり長めにテストを実施いたします。

パパリウス

2019-11-19版のリリースノートで気になったのはこれです。

firmware: arm_loader: Respect all required frequencies when throttling

2019-11-19版よりも古いバージョンでは、温度超過のスロットリングが発生したときに、何か良からぬ動作をしてしまっているのかもしれません。

smpdのデフォルト設定では、temp_limit=70と設定しています。

この設定では65℃からスロットリングが開始されarm_freqが強制的に引き下げられます。

そして70℃に達するとarm_freqとcore_freqの両方が引き下げられます。

RPi4で放熱が甘いと、瞬間的とは言え65℃に達することは珍しくないと思います。
特にDSDのPCM変換再生のようにCPUに負荷がかかるケースでは、たとえ十分な放熱対策があったとしても65℃を超えることは十分にありえます。

もう1パターン、検証にご協力ください。

温度超過時のスロットリングが引き金になっているのかどうかを確かめたいと思います。

v1.0.5のデフォルトのGPUブートローダに戻して、config.txtのtemp_limitをコメントアウトした状態で動作検証をお願いします。

これでRPi4のデフォルト設定であるtemp_limit=85で動作するようになり、80℃に達するまで温度超過によるスロットリングが発生しなくなります。
RPi4だと瞬間的に65℃を超えることはあるかもしれませんが、80℃超えはまずないでしょうから。

もしこれで現象が発生しなくなれば、すべて丸く収まります。:ok_hand:

パパリウス

temp_limitをあえて低く設定すれば、いつでも温度超過を再現することができます。

デフォルトのGPUブートローダに戻し、temp_limit=40で温度超過を発生させてみました。

実際にスロットリングが開始され、クロックが抑えられていることまでは確認できたのですが、vcgencmdの問題は再現しません。

スロットリングは無関係・・・？？

リリースノートに記載のあるもう一つの変更点、こちらが本命なのでしょうか？？

firmware: Fixup vcgencmd display_power return values

ゴンザエモン

パパリウスさん

2019-11-19版のリリースノートの記載事項と事象を突き合せますと、これがポイントのような気もします。

firmware: Fixup vcgencmd display_power return values

まずはDashboard表示不可、vcgencmdのノーレスポンス、shutdown未完という観点から、このバージョンの重点テスト開始しています。（音へのインパクトが少ないものだと良いのですが）

ただ、ここまで頻繁にファーム更新が行われていると、どこまでそれに追随すべきかかなり悩ましい状況ですね、、、、

nzato

@パパリウスさん

nzatoです

症状が出やすいSabreBerry32とSMPDv1.05の組み合わせに、2020-11-19版を入れて確認をしています。30分がたちましたが、ダッシュボードのLatencyが問題なく表示されます。

気になったのが、ARM1188、CORE198で、COREの値はこれで良いのでしょうか?

flyingace

@パパリウスさん

β3ドライバーの報告です。
β3ドライバー適用前は曲ごとに頭の部分にプチノイズが３~４回発生していました。
適用後は３~４曲ごとに１~２回発生と大きく減少しました。

使用環境
Rpi-4B Ver.1.2(2GB)
SB32+PRO DoP:Master mode
Spotify

もう原因のあたりを付けられた言うことであまり意味のない報告窯しれませんが、私の環境での状況ということで、、

パパリウス

RPi4版 v1.0系不具合報告スレッドで@nzatoが発言 :

@パパリウスさん

nzatoです

症状が出やすいSabreBerry32とSMPDv1.05の組み合わせに、2020-11-19版を入れて確認をしています。30分がたちましたが、ダッシュボードのLatencyが問題なく表示されます。

気になったのが、ARM1188、CORE198で、COREの値はこれで良いのでしょうか?

@nzato さん

ご報告ありがとうございます。
2019-11-19版から解消している可能性は高いですね。

COREの値は2019-11-18版以降の正しい動きです。PLLやCOREの算出方法が大きく変わっため、従来とは異なる周波数が設定されます。
これはsmpdとしては大問題なので、なんとか回避しようともがいているところです。

@flyingace さん

情報ありがとうございます。
β3でどの程度解消されているか気になっているところでした。
皆さんの環境でも発生頻度が低減されたのであれば、β3で見直した箇所がビンゴ:dart: ということがはっきりしました。
場所が分かれば気が楽なものです。あとは性能を落とさずにどこまで対処するかですね。

ジャイアン

RPi4版 v1.0系不具合報告スレッドで@パパリウスが発言 :

v1.0.5のデフォルトのGPUブートローダに戻して、config.txtのtemp_limitをコメントアウトした状態で動作検証をお願いします。

@パパリウスさん

六時間近くこの設定で二台とも走らせていますが、今のところ問題は生じません。

ゴンザエモン

パパリウスさん

2019-11-19版のテスト結果ですが、いずれの現象も発生せず、でした。（Dashboard表示不可、vcgencmdのノーレスポンス、shutdown未完）

以下の２ケースで確認いたしました。
１．標準ドライバー
２．ベータ３ドライバー　＋　マスターHAT用dt-blob.bin
　（ベータ版でのノイズ状況ですが、3では頻度が低下しているように思われます。正確にはカウントできていませんが、、、）

ジャイアン

@パパリウスさん

先ほど報告した検証ですが、一台で問題発生です。

パパリウス

@ジャイアンさん

ご報告ありがとうございます。
temp_limitをデフォルト(85℃)に戻すのは確実な方法ではないようですね。
（多少、発生頻度が良化しているようにも見えますが）

次は、「vcgencmdを利用しない」という対策を試してみたいと思います。

smpdでvcgencmdを利用しているのは3箇所です。

.bashrc (sshログイン時の温度表示)
/usr/local/bin/pipe_event.sh (extreme設定時、アラート無しなら監視系のモジュールを停止)
/usr/local/bin/util-dashboard.sh (ダッシュボード表示時にarmクロック、coreクロック、温度、アラートを取得)

vcgencmdで情報を取得する代わりに、以下から値を読み取る方式にしてみたいと思います。

温度取得
/sys/class/thermal/thermal_zone0/temp

アラート取得
/sys/devices/platform/soc/soc:firmware/get_throttled

ARMクロック取得(実装中)
/sys/devices/platform/soc/soc:firmware/arm_freq

COREクロック取得(実装中)
/sys/devices/platform/soc/soc:firmware/core_freq

nzato

@パパリウスさん

nzatoです

症状が出やすいSabreBerry32とSMPDv1.05の組み合わせに、2020-11-19版を入れて確認をしています。10時間近く経ちますが、ダッシュボードのLatencyが問題なく表示され、Rebootもすぐに立ち上がります。

　温度は、裸状態で使っているので、自然空冷で48℃(室温30℃)ほぼ一定です。

RPi4版 v1.0系 不具合報告スレッド

2019-11-19版

2019-11-18版

RPi4版 v1.0系不具合報告スレッド