16:36 <PaulFertser> anarsoul: so I did same random-ish tests with u-boot today, basically I can take cubieboard2 u-boot config, build it, run it, use cubieboard2 DTB when loading Linux and I get the same error as before. To do that I lower DRAM frequency from 480 MHz to 432 MHz as otherwise Cubietruck can't boot at all. So probably lima has some race condition which is exposed when using such a low DRAM frequency?

16:37 <PaulFertser> anarsoul: I do not have a cubieboard2 or any other mali400 device here so I can't just try lowering the frequency there to see if it is not the case.

16:37 <PaulFertser> I tried lowering it to 384 MHz, with same result.

16:38 <PaulFertser> What are the popular boards Mali400 code is tested on?

16:44 <PaulFertser> If someone could try running A20 with pll-ddr at 432 (I checked via debugfs) and confirm lima works nicely then it's probably not an issue with lima.

17:42 <PaulFertser> OK, with some example from https://linux-sunxi.org/A10_DRAM_Controller_Calibration I managed to run it at 480 MHz, but the result is apparently the same, mmu page fault at Glamour startup.

20:16 <enunes> PaulFertser: I'd say the most popular today is probably any A64 board due to the pinephone

20:17 <anarsoul> PaulFertser: I'm doing development on rock64 which uses rk3328

20:18 <anarsoul> CI used on run on la frite boards with aml-s805x-ac

20:19 <enunes> my main local target has been s905 on odroid-c2 for a while

20:19 <enunes> right... CI needs to go back up

20:19 <anarsoul> :)

20:21 <anarsoul> PaulFertser: it could be GPU not having enough memory bandwidth, it should be configurable with mbus controller, but I'm not expert on this

20:21 <enunes> it is ready to go back up. tomorrow I got some time so I'll go back to that

20:22 <anarsoul> PaulFertser: jernej should have more details on mbus configuration

20:59 <PaulFertser> enunes: I see, thanks. My idea was to check what DRAM frequency is used by other boards in mainline U-boot, and all popular ones seem to be higher.

21:03 <anarsoul> PaulFertser: well, you can lower GPU frequency to see if it helps

21:06 <PaulFertser> anarsoul: that I didn't try yet. Is there a way easier than a custom DTB? What value is good to try?

21:07 <anarsoul> well, start with half you your current gpu frequency, I think dtb is the only way to change it

21:08 <PaulFertser> anarsoul: will try, thank you

21:10 <enunes> I think the last person trying this board mentioned that it somehow worked with some of the armbian patches, have you tried that?

21:10 <enunes> I'm not sure if they identified which particular change it was

21:11 <enunes> PaulFertser: 22:27 https://oftc.irclog.whitequark.org/lima/2021-12-07#30431448;

21:11 <PaulFertser> enunes: no, I haven't. TBH I have some prejudice against armbian.

21:11 <enunes> well I'm not going to comment on that, but it might be worth a try to reduce your debug time

21:12 <enunes> I don't use it either

21:12 <PaulFertser> enunes: thank you for digging up that conversation!

21:17 <anarsoul> enunes: that's for bananapi

21:17 <enunes> I think it's cubietruck, same reporter of https://gitlab.freedesktop.org/mesa/mesa/-/issues/5707

21:18 <anarsoul> enunes: the patch is for bananapi

21:20 <enunes> not a patch, they reported later that the armbian image somehow worked

22:20 <PaulFertser> anarsoul: I checked with amended DT, gpu under pll-video0 is 192000000 , pll-ddr is at 432000000, starting Xorg still gives an mmu page fault, so I guess that's not it.

22:20 <anarsoul> PaulFertser: I'm out of ideas

22:21 <PaulFertser> I see Yann confirmed seeing the desktop but probably armbian just used llvmpipe in that case. If the user isn't member of a render group then it just falls back to software rendering.

22:30 <anarsoul> PaulFertser: you can test it yourself

22:31 <anarsoul> you've got the board and it's easy enough to write armbian image to an sd card

22:31 <PaulFertser> anarsoul: yes, I should try that. I also should have more spare cards...