ChanServ changed the topic of #lima to: Development channel for open source lima driver for ARM Mali4** GPUs - Kernel driver has landed in mainline, userspace driver is part of mesa - Logs at https://oftc.irclog.whitequark.org/lima/
Wizzup has quit [Server closed connection]
Wizzup has joined #lima
adjtm has quit [Remote host closed the connection]
adjtm has joined #lima
mripard_ has joined #lima
mripard has quit [Ping timeout: 480 seconds]
icecream95 has quit [Server closed connection]
icecream95 has joined #lima
icecream95 is now known as Guest283
Guest283 is now known as icecream95
agoldmints[m] has quit [Server closed connection]
agoldmints[m] has joined #lima
Daanct12 has joined #lima
camus has quit [Ping timeout: 480 seconds]
Daaanct12 has joined #lima
Daaanct12 has quit []
Daanct12 has quit [Ping timeout: 480 seconds]
camus has joined #lima
Daanct12 has joined #lima
Daanct12 has quit [Quit: Leaving]
mripard_ has quit []
mripard has joined #lima
adjtm has quit [Remote host closed the connection]
adjtm has joined #lima
PaulFertser has joined #lima
<PaulFertser>
Hi there. I have a https://sunxi.org/Cubietruck here (A20, so Mali-400 MP2) and I seem to be hitting https://gitlab.freedesktop.org/mesa/mesa/-/issues/5707 , so I can't use lima anyhow on it (tested with yesterday's Mesa). I can recompile the needed parts from sources, can do some testing, can provide data from UART. I do not have any display connected to it atm, is that necessary for
<PaulFertser>
troubleshooting?
anarsoul|2 has quit []
anarsoul has joined #lima
<anarsoul>
PaulFertser: it's not really a lima issue since lima works fine on other A20 boards. It's either SoC configuration or PMIC configuration issue
<PaulFertser>
anarsoul: with some hints I guess I could make the right modifications to DTS.
<anarsoul>
PaulFertser: I've no idea what's wrong.
<anarsoul>
GPU misbehaves, so compare working BSP configuration with mainline
<PaulFertser>
A complex SoC like that has plenty of configuration. And also BSP drivers might be handling the same DT values differently or just applying some quirks in random places.
<PaulFertser>
I am very new to mesa, I do not even have an idea how to test it headless. kmscube depends on having something connected to set the right mode etc.
<anarsoul>
PaulFertser: well, as I said I've no idea what could be wrong. You can also compare it to working cubieboard 2 (or whatever it's called) on mainline
uis has quit []
uis has joined #lima
<PaulFertser>
anarsoul: in other words, those mmu page faults and other messages in kernel log are meaning just that mali got upset somehow, and there's no way to do any informed guesses to pinpoint the issue, do I get it right?
<anarsoul>
could be DRAM speed or voltage, CPU voltage, GPU clock, or anything else
<anarsoul>
PaulFertser: yeah, pretty much
<PaulFertser>
anarsoul: and what is the usual way to get headless surfaceless rendering for testing issues like that?
<anarsoul>
however it'll likely fail the same as kmscube
<PaulFertser>
OK, I do not really need rendering, I see it's enough to start Xorg because it tries Glamour and that produces "lima 1c40000.gpu: mmu page fault" nastiness right away.
<PaulFertser>
Then I can kill Xorg and start again and same messages appear.
<anarsoul>
PaulFertser: my guess is that fix will be in the bootloader :)
<anarsoul>
so again, you can compare u-boot for cubieboard 2 and cubietruck
<anarsoul>
it could be unstable DDR, GPU is known to fail early if DDR is unstable
<PaulFertser>
anarsoul: I'm using U-boot as built by Debian atm. I can try just booting cubieboard 2 u-boot I guess with SEL.
<PaulFertser>
Here it's rather consistent in how it reproduces though.
<PaulFertser>
Running it with cb2 DTB produced same "lima 1c40000.gpu: mmu page fault at 0x2484340" (plus non-working ethernet)
drod has joined #lima
<anarsoul>
PaulFertser: try cb2 u-boot?
<PaulFertser>
anarsoul: I will. I see some testpoints on the pcb, there's even voltage silkscreened. Near DRAM chips it's 0.75 V and I measure 0.757 V.
<PaulFertser>
Near upper-right corner of the SoC there's an unmarked TP, it measures at 2.458 V.
<anarsoul>
that's likely VTT
<anarsoul>
*0.75V
<anarsoul>
VDD for DDR3 is 1.5V, for LPDDR3 it's 1.35V
<PaulFertser>
There's a TP marked 1.5 V near lower left, the dot-marked corner (I'm looking at the A20 and other text), I measure 1.516 V there.
<PaulFertser>
Yeah, it's DDR3, not LP.
<PaulFertser>
Another testpoint is marked 5.2 V, I measure 4.97 V (so quite low).
<PaulFertser>
Yet another is marked 3.1 V, I measure 3.095 V.
<PaulFertser>
That 5.2 V is probably actually 6.2 V silkscreened.
<PaulFertser>
1.4 V measures as 1.020 V.
<anarsoul>
I doubt that there's 6.2V on the board :)
<anarsoul>
it's likely powered from 5V source
<PaulFertser>
It is, but probably it has some step-ups for reasons.
<PaulFertser>
Ah, I see it says 5.2 V near the power connector, so I guess that testpoint is at the same voltage.
<PaulFertser>
Yep
<anarsoul>
1.4V is CPU voltage, likely it's scaled down since the CPU runs at lower frequency
<PaulFertser>
anarsoul: cat scaling_max_freq > scaling_min_freq made it change to 1.422 V
<PaulFertser>
However Xorg still doesn't start and lima emits page fault.
<PaulFertser>
I haven't noticed this board to be anyhow unstable running firefox etc.
<PaulFertser>
anarsoul: you're right, bootloader makes a difference. With cb2 loader and ct DT the kernel crashes on boot. Thanks for the pointers!
<anarsoul>
what about cb2 bootloader and cb2 dt?
drod has joined #lima
<PaulFertser>
anarsoul: cubieboard2 u-boot binary can't boot my cubietruck when using cubieboard2 device tree. When I'm trying the same with cubietruck u-boot it kinda works (but no ethernet), trying to use Mesa leads to same error though.
<anarsoul>
compare u-boot sources and config
<anarsoul>
PaulFertser: my point is that lima works fine on cubieboard2 which uses the same A20 as cubietruck
<PaulFertser>
anarsoul: yes, I got it. Was just doing a quick test with binaries just in case the boards are similar enough.
<PaulFertser>
anarsoul: thanks a lot for the pointers