ChanServ changed the topic of #etnaviv to: #etnaviv - the home of the reverse-engineered Vivante GPU driver - Logs https://oftc.irclog.whitequark.org/etnaviv
mvlad has quit [Remote host closed the connection]
cphealy has joined #etnaviv
<MoeIcenowy> BTW is Vivante MMUv1 layered on MMUv2 ?
<MoeIcenowy> when I switched to MMUv1 on GC620, I finally get my first interrupt fired
<MoeIcenowy> although the thing seems to be not still rendered yet
<MoeIcenowy> well MMUv1 is not performed too
<MoeIcenowy> the image is rendered to physical 0x80000000
cphealy_ has joined #etnaviv
cphealy has quit [Ping timeout: 480 seconds]
<austriancoder> MoeIcenowy: great.. you got mmuv1 working.. the 2d demo could work now.
<austriancoder> mmuv1 is quite simple.. has a fixed page size of 4k each PTE is 4byte long and the page table has a maximum size of 256k. Index 0 of the big page table array maps directly to GPU address 0x80000000 and index 1 maps directly to 0x80001000.
<MoeIcenowy> austriancoder: ah I didn't get MMUv1 working...
<MoeIcenowy> it's bypassed ...
<MoeIcenowy> "the image is rendered to physical 0x80000000"
<MoeIcenowy> how does mmuv1 handle the command buffer?
<MoeIcenowy> in the case of force mmuv1, the PE seems to be off but the command seems to be executed correcly by FE
<austriancoder> Ahh.. it is still bypassed. Too early in the morning here ;)
JohnnyonFlame has quit [Read error: Connection reset by peer]
<MoeIcenowy> the PE seems to be working, corrupting physical memory with the expected data ;-)
<MoeIcenowy> it's just the MMU is behaving strangely
<austriancoder> MoeIcenowy: do you have binary blob running successfully running too?
<austriancoder> Maybe you can figure out the missing bits to enable mmuv1 on a working setup.
<MoeIcenowy> austriancoder: sorry, but not ...
<MoeIcenowy> I don't know how to program with libGAL...
<MoeIcenowy> I hacked the downstream driver to allow it to run with vivante,gc compatible, so I can load it with the same DT
<austriancoder> The mmu init should be part of the vivantes kernel driver.
<MoeIcenowy> yes
Peng_Fan___ has joined #etnaviv
<austriancoder> MoeIcenowy: I had a quick look at the galcore sources from thead-kernel repo and it should use mmuv2 as gcFEATURE_BIT_REG_MMU is 1.
<MoeIcenowy> austriancoder: yes I agree
chewitt has joined #etnaviv
frieder has joined #etnaviv
mvlad has joined #etnaviv
pcercuei has joined #etnaviv
<MoeIcenowy> oh on mmu v1 cmdbufs are just not accessed via mmu.
<MoeIcenowy> so it's why commands are executing there
<MoeIcenowy> but I still don't know why the MMUv2 does not want to work...
JohnnyonFlame has joined #etnaviv
<MoeIcenowy> strange, a register at 0x800 seems to be playing something
<MoeIcenowy> oh this could be a misread
<MoeIcenowy> oops in the specific situation the 0x55758082 0x1141B7FD is placed to 0x1008 instead of 0x1010, thus not hanging FE
<MoeIcenowy> okay it's always there
<MoeIcenowy> always 0x1008
<MoeIcenowy> it seems a write of 0x0 to 0x800 really made the FE fetch correct command stream via MMU
<MoeIcenowy> although this time the FE works strangely ...
<MoeIcenowy> s/FE/PE/
<MoeIcenowy> writing 0x0 to 0x800 can prevent the GPU hang is now proven
<MoeIcenowy> the BSP is writing a 0x10 to it, but writing 0x10 to it seems to do nothing ...
<MoeIcenowy> (or the value is messed up previously)
<MoeIcenowy> well the PE looks to have really written the image to the expected location
<MoeIcenowy> now to inspect the CPU
<MoeIcenowy> s/CPU/&'s cache/
<MoeIcenowy> okay the problem is that I printed too much debug info with printk, make etnaviv_2d_test confused
<MoeIcenowy> well etnaviv_2d_test only work for its first run
<MoeIcenowy> in the second run MMU fault happens
<MoeIcenowy> the third run leads to `Unable to handle kernel NULL pointer dereference at virtual address 0000000000000224` (maybe a 5.10.113 kernel issue)
chewitt has quit [Quit: Zzz..]
frieder has quit [Remote host closed the connection]
sravn has quit [Quit: WeeChat 3.5]
DavidHeidelberg has quit [Remote host closed the connection]
DavidHeidelberg has joined #etnaviv