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]