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/
<anarsoul> yann-kaelig: does kmscube work now?
<yann-kaelig> anarsoul: no
<yann-kaelig> :(
<anarsoul> yann-kaelig: what's in dmesg?
<anarsoul> yann-kaelig: what's screen resolution?
<yann-kaelig> anarsoul: sry I don;t understand what you want
<anarsoul> yann-kaelig: what's your screen resolution? 1920x1080? 1280x720? etc
<yann-kaelig> 1920x1080 is my screen resolution
<anarsoul> yann-kaelig: well, I'm out of ideas. It looks like plbu tries to read something it's not supposed to
<yann-kaelig> it is the right command line for kmscube if I want to test another mode ./kmscube -v 1024x720-60 ?
<yann-kaelig> It's say the the mode is not recognized, maybe I'm writin in the wrong way
<anarsoul> sorry, no idea
<yann-kaelig> well, thank you very much for your help, I learned something wat least about the dtb decompilation, interesting :) Maybe in another life for my cubietruck ^^
<anarsoul> yann-kaelig: try asking #linux-sunxi
<anarsoul> or cubietruck vendor
<anarsoul> personally, I don't have any boards with A20 and I'm not planning to get one
<yann-kaelig> not luck for me when I bought this board, I liked it because of the SATA and that was my first contact with ARM, not really enjoyable :D
<anarsoul> allwinner A20 isn't the most popular SoC
<anarsoul> at least not among lima devs
<yann-kaelig> That was my first contact with ARM board, I was not aware of the most popular SoC at this time, the SATA was why I decided to buy it when no others board was available with this feature years ago and I'm not sure it's still the case
<anarsoul> yann-kaelig: I'd suggest any board with PCIe slot
<anarsoul> you can just use any pcie sata card with it
<anarsoul> e.g. rockpro64
<anarsoul> or rock pi 4 (it'll require an adapter)
<yann-kaelig> I see interesting, but I'm not going to buy any other ARM board I'm not interested by ARM anymore after this experience
<yann-kaelig> Sometimes I'm powering up this board to see if something has changed, but no luck for me today, maybe next days :)
<yann-kaelig> thanks, cu later, have a nice day/night
camus has joined #lima
camus1 has quit [Ping timeout: 480 seconds]
yann-kaelig has left #lima [#lima]
camus1 has joined #lima
camus has quit [Ping timeout: 480 seconds]
chewitt has quit [Read error: Connection reset by peer]
camus has joined #lima
camus1 has quit [Ping timeout: 480 seconds]
camus1 has joined #lima
camus has quit [Read error: Connection reset by peer]
chewitt has joined #lima
daniels has quit [Ping timeout: 480 seconds]
daniels has joined #lima
camus has joined #lima
camus1 has quit [Ping timeout: 480 seconds]
camus1 has joined #lima
camus has quit [Read error: Connection reset by peer]
camus1 has quit [Read error: Connection reset by peer]
camus has joined #lima
adjtm is now known as Guest6596
adjtm has joined #lima
Guest6596 has quit [Ping timeout: 480 seconds]
camus1 has joined #lima
camus has quit [Ping timeout: 480 seconds]
Viciouss has quit [Ping timeout: 480 seconds]
Viciouss has joined #lima
camus has joined #lima
camus1 has quit [Read error: Connection reset by peer]
Viciouss has quit [Quit: The Lounge - https://thelounge.chat]
Viciouss has joined #lima
chewitt has quit [Read error: Connection reset by peer]
chewitt has joined #lima
camus1 has joined #lima
camus has quit [Ping timeout: 480 seconds]
yann-kaelig has joined #lima
<yann-kaelig> hello
<yann-kaelig> well, because Ialso have a cubieboard2 I was curious to test my current archlinuxArm installation with kmscube on this board. Kmscube is working
<yann-kaelig> both of the board use the Mali-400MP2
<yann-kaelig> maybe, that my feeling on cubietruck there could be a mess between the hdmi and the VGA output
camus has joined #lima
camus1 has quit [Ping timeout: 480 seconds]
<yann-kaelig> interesting, I'm comparing the cubietruck dts from armbian and arch, I found that gpu has different phandle on ARMBIAN phandle = <0xbc>; and ARCH phandle = <0xbb>;
<yann-kaelig> is it possible depending on the kernel version ?
<yann-kaelig> hdmi-connector is also different on ARBIAM type = [61 00]; and ARCH type = "a";
<jernej> yann-kaelig: phandle is something that's added automatically by dtc when compiling dts to dtb and it depends on number of nodes, so it would be actually strange if they were the same
<jernej> anyway, how much CMA space you have reserved? For testing purposes, you can set that to 96 MiB
<jernej> [61 00] and "a" is the same
<jernej> character a is 0x61 and 00 is just null terminating character
jstultz has quit [Ping timeout: 480 seconds]
jstultz has joined #lima
<yann-kaelig> jernej: ok, thx for the info. The CMA is set to CONFIG_CMA_SIZE_MBYTES=64
<jernej> that should be enough for basics
<jernej> yann-kaelig: At one point I prepared LibreELEC distro for A20, where GPU was used by Kodi. I had no problems with my board, but users reported that cubietruck image doesn't work
<jernej> so same situation as yours
<yann-kaelig> I found that a patch set has been created https://github.com/wens/linux/commit/962fbf02d41e0e8ed6928a589b4a76cb26a52187 which has never been merged to the mainline kernel. Could it be possible that without this patch something goes wrong without it ?
<jernej> I never found the exact reason (I don't have it and I stopped working on A20 support), but I suspect it has something to do with amount of RAM (2 GiB)
<enunes> I did use A20 for early lima development for a while but that was on... 2018-2019 I think, on a cubieboard2
<jernej> A20 needs CMA in specific memory region
<jernej> and due to different amount of RAM, this could be miscalculated
<jernej> yann-kaelig: no, I don't think that patch changes anything
<yann-kaelig> is it not possible in this case to shrink the amount of RAM to be the same as the cubieboard2 on cubietruck and check if that solved the problem ?
<jernej> I have no idea, it may be that easy but maybe not
<yann-kaelig> ok, thx
<jernej> btw, U-Boot has some display code for A20 and IIRC it does some address calculation...
<jernej> can you enable display support in U-Boot and check if it works?
<yann-kaelig> yes I can
chewitt has quit [Quit: Zzz..]
<jernej> note that driver was changed in v2021.04, so maybe try older than that release
chewitt has joined #lima
<jernej> yann-kaelig: if you don't mind experimenting, you can try to change this line: https://elixir.bootlin.com/linux/latest/source/arch/arm/boot/dts/sun7i-a20.dtsi#L184
camus1 has joined #lima
<jernej> try changing 4 in 0x40000000 in range 8 - b inclusive
<jernej> e.g. 0x80000000, 0x90000000, 0xa0000000, 0xb0000000
camus has quit [Read error: Connection reset by peer]
chewitt has quit [Quit: Zzz..]
drod has joined #lima
<enunes> anarsoul: huh, did you dig any interesting detail from those yet?
<anarsoul> not yet
<anarsoul> most of it should be fixed in mali400 which I expect is newer than mali200 r0p5
<anarsoul> but it describes some hw behavior and introduces some hw terminology
<anarsoul> so it may be useful
<anarsoul> ha
<anarsoul> looks like it explains what is this mysterious texture format for depth reload
<anarsoul> :)
<anarsoul> see "524463: Verbatim32 textures give unexpected results"
<anarsoul> page 41
<enunes> interesting
camus has joined #lima
camus1 has quit [Ping timeout: 480 seconds]
<rellla> anarsoul: h
<rellla> how did you find that?
<anarsoul> google "mali200 errata"
<anarsoul> enunes: do you have any ETA on when lima CI will be back?
<yann-kaelig> jernej: no doesn't change anything, do I need to set an envar ? Also is it a good thing that FB_SIMPLE is fixed as yes to kernel ?
<yann-kaelig> doesn't change anything by enabling display support
<jernej> I didn't mean it will change anything for Linux, but it at least works? do you see U-Boot console?
<yann-kaelig> yes I see U-BOOT console
<jernej> ok, then try my second suggestion
<rellla> RSW early-Z testing, (subword 13, bits 8 and 9)
<anarsoul> rellla: I guess we already knew that, grep for early_z in lima_draw.c
<rellla> oh, i thought we only set bit 9 :)
<rellla> anyway, they call them early-z test and early-z update bit
<anarsoul> I really wonder if some errata for mali200 r0p5 is fixed in mali400 :)
<anarsoul> technically we don't support mali200
<rellla> i just had a quick view, but some things smell still open ;)
<anarsoul> I briefly skimmed it and it doesn't look like it affects us
<rellla> why didn't you google “mali 400 errata“ :P
<anarsoul> rellla: because there's nothing for mali400
<anarsoul> well, I'm wrong. There's something, but not as much as for mali 200
<anarsoul> looks like it would be a good idea to add workaround for 725058
<anarsoul> i.e. add extra attribute if we have less than 16 outputs
<anarsoul> s/outputs/inputs
camus1 has joined #lima
camus has quit [Read error: Connection reset by peer]
drod has quit []
yann-kaelig has left #lima [#lima]