<hexdump0815>
without really understanding that topic it looks to me like the measured amclk on the broken box does not match the expected value - on the working box they seem to match
<xdarklight>
hexdump0815: you seem to understand the topic well :-)
<xdarklight>
hexdump0815: and it seems like the cause is MPLL1 (also called mp1_out)
<xdarklight>
hexdump0815: can you please pastebin "cat /sys/kernel/debug/regmap/dummy-sys-ctrl@*/registers" from both, the working and non-working box?
<xdarklight>
hexdump0815: a full dmesg of the non-working box would also be helpful
<hexdump0815>
besides those audio issues this box is running completely fine and stable with this kernel
naoki has quit [Quit: naoki]
<hexdump0815>
oh - looks like i'm getting the same problem when dumping those regs on my working box ...
<hexdump0815>
i just checked and there should be no changes affecting the kernel on this box vs. a clean v6.1.11 tree and u-boot is v2020.07 with the blobs taken from the origin la boot via glximg, no major patches to that u-boot neither
rockosov has quit [Ping timeout: 245 seconds]
rockosov has joined #linux-amlogic
<xdarklight>
hexdump0815: hmm, now that you're mentioning it: I think some of the sys controller registers are protected (and can only be read from the secure world). we need to dump them differently
<xdarklight>
hexdump0815: from what I've seen in Amlogic's kernel source: S902L2 seems to be a GXLX SoC which *may* be different silicon than GXL (no X at the end)
<xdarklight>
hexdump0815: I'm even finding multiple sources online stating that GXLX has a Mali-450 MP5 (instead of a Mali-450 MP3 on GXL). do you know more about that (e.g. from the vendor kernel boot logs)?
luka177 has quit [Ping timeout: 260 seconds]
luka177 has joined #linux-amlogic
<xdarklight>
hexdump0815: also which .dtb / board model is vendor u-boot loading?
luka177 has quit [Ping timeout: 260 seconds]
luka177 has joined #linux-amlogic
luka177 has quit [Ping timeout: 264 seconds]
<xdarklight>
hexdump0815: http://ix.io/4BLq debug patch (ugly, compile-tested only). please try this on both, working and non-working boxes
<xdarklight>
hexdump0815: then please share dmesg | grep HHI_MPLL
luka177 has joined #linux-amlogic
luka177 has quit [Ping timeout: 246 seconds]
GNUtoo has quit [Remote host closed the connection]
luka177 has joined #linux-amlogic
GNUtoo has joined #linux-amlogic
<hexdump0815>
xdarklight: kernel is compiling right now - native on an amlogic tv box, so it will take a moment :)
<hexdump0815>
i'm not having the android anymore on the box as it does not have an sd slot, so i installed some mainline u-boot to emmc by initially booting it via pyaml and then dd'ning it to emmc
<hexdump0815>
bit i seem to have collected some info beforehand :)
<hexdump0815>
the original android dts has 'interrupt-names = "IRQGP", "IRQGPMMU", "IRQPP", "IRQPMU", "IRQPP0", "IRQPPMMU0", "IRQPP1", "IRQPPMMU1";' which looks like mp2 to me
<hexdump0815>
also the box is the worst i have seen so far (no sd card, very low performance etc.), so i would not expect that anything on it is better than on an older s905w :)
<xdarklight>
hexdump0815: I see, great that you took some notes before wiping android :)
<xdarklight>
off-topic: it even comes with RTL8822BS SDIO wifi. have you tried the mainline rtw88 driver? ;-)
<hexdump0815>
not yet, but i might try at some point - saw you patches ... one of the two boxes has that, the other has mediatek wifi, which i think is not yet supported as sdio
<hexdump0815>
or not even at all
<xdarklight>
some mediatek SDIO wifi chips are supported on mainline
<hexdump0815>
oh - i even have a note about that: it is mtd7668 - it was not supported back then, but maybe it is meanwhile
<hexdump0815>
its actually mt7668 - bt seems to be supported, but not the wifi part
<xdarklight>
yes, that unfortunately seems unsupported
luka177 has quit [Ping timeout: 245 seconds]
luka177 has joined #linux-amlogic
<hexdump0815>
regarding rtw88 i assume v6.4 would be better than v6.1 for testing? would any addition to dts be required for it?
anessen97 has quit [Ping timeout: 244 seconds]
<xdarklight>
hexdump0815: indeed, newer = better for rtw88. I *think* nothing extra is needed but we'll have to see
luka177 has quit [Ping timeout: 260 seconds]
luka177 has joined #linux-amlogic
<hexdump0815>
will be afk for a while, will continue tonight most probably ...
luka177 has quit [Ping timeout: 250 seconds]
luka177 has joined #linux-amlogic
luka177 has quit [Ping timeout: 252 seconds]
luka177 has joined #linux-amlogic
luka177 has quit [Read error: Connection reset by peer]
<hexdump0815>
xdarklight: btw. some off-topic question from me as well - if i build a kernel from your tree, will i get hdmi display support on meson8?
<hexdump0815>
i.e. do you have the hdmi code enabled by default in your tree?
luka177 has quit [Ping timeout: 246 seconds]
luka177 has joined #linux-amlogic
luka177 has quit [Ping timeout: 245 seconds]
luka177 has joined #linux-amlogic
luka177 has quit [Ping timeout: 264 seconds]
luka177 has joined #linux-amlogic
jacobk has joined #linux-amlogic
<minute>
xdarklight: btw thanks for the email followups re: rtw88. i will test the suggestions tomorrow and put in the logging etc.
<minute>
sorry, not tomorrow, but monday
luka177 has quit [Ping timeout: 258 seconds]
luka177 has joined #linux-amlogic
<xdarklight>
minute: thanks! also sorry for the lengthy process: I'm busy with offline things currently and not being able to reproduce this myself (RTL8822CS on my board refuses to come up when I use that SDIO controller DRAM access quirk) are in the way of a quick resolution
<minute>
xdarklight: no problem! i can also send you a bananapi cm4 with io board if that helps
luka177 has quit [Ping timeout: 260 seconds]
<c0rnelius>
if ur referring to `rtw88: sdio: Honor the host max_req_size in the RX path` that patch fixed the issues I was having on the bpi-cm4.
<xdarklight>
hexdump0815: that's surprising, can we try moving the debug stuff to clk-mpll.c: http://ix.io/4BNJ - I'm wondering if some of the registers are read-only (for some reason or another...)
<xdarklight>
c0rnelius: uh, interesting - that's exactly what minute and I are just discussing
<xdarklight>
minute: thanks, I'll get back to that offer if I have more spare time and we haven't resolved the issue by then
<minute>
xdarklight: ok!
<minute>
c0rnelius: are you positive it fixed all issues for you? it seemed to me like that, but then after like half an hour of usage i had skb_panics again, when browsing certain websites etc
<c0rnelius>
minute: I've only been using it headless, but do download a bit on it and haven't had any issues since. I couldn't even run speedtest on it before.
<f_>
Daily driving is the best way to find bugs and solve them quickly.
<minute>
c0rnelius: hmmm if i could convince you to do some more intensive testing (with a browser perhaps) that would be fantastic
luka177 has joined #linux-amlogic
<minute>
i have the bpi cm4 now in my daily driver laptop (mnt reform)
<minute>
to squash any bugs like this before we ship it to people
<f_>
Very nice.
<f_>
I should start using my set-top box as a set-top box at some point.
<f_>
and not as a hacked up SBC
<c0rnelius>
minute: I'll give it a whirl when I have some time and get back to you.
<minute>
c0rnelius: cool, thanks!
<xdarklight>
thanks for further testing and for giving some feedback on my patch c0rnelius! :-)
<c0rnelius>
ur welcome
jacobk has quit [Read error: Connection reset by peer]