<marcan>
I'm sorry, I can't trust someone who plasters *decompiler output* all over their repo in a *target repo*
<marcan>
like wtf
<dhewg>
lol
<dhewg>
at least it's just a comment and not actually compiled :P
bisko_ has joined #asahi-dev
bisko has quit [Read error: Connection reset by peer]
w3a has joined #asahi-dev
w3a has quit [Read error: Connection reset by peer]
JTL has quit [Ping timeout: 246 seconds]
JTL has joined #asahi-dev
bisko_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<roxfan>
it's documentation!
odmir has quit [Remote host closed the connection]
bisko has joined #asahi-dev
odmir has joined #asahi-dev
<modwizcode>
Yeah I noticed that it's pretty yikes
<modwizcode>
The point still stands that as far as I know what they call the "deferred" ipis are currently not documented on our AIC page
odmir has quit []
jato_ is now known as jato
<modwizcode>
I think it's fair that someone using a repo as a storage place might keep notes in the comments to explain their code. They make some really weird implementation choices overall though.
<yrlf>
modwizcode: sure, but as I understand it, a public fork of a GPL project most likely counts as distribution, so adding decompiler output _anywhere_ in that repo is questionable at best from a copyright perspective
<yrlf>
(IANAL, of course)
odmir has joined #asahi-dev
<modwizcode>
That's... probably a good point
<modwizcode>
Although I think you could probably use the argument that technically distribution as a public github repo doesn't imply licensing others to actually use the code.
<modwizcode>
But even that is nullified by the fact that they put the GPL license header at the top of the additional files with the copyrighted code decompiled in it
<marcan>
modwizcode: distribution of any kind triggers the GPL rules, and putting something up on github absolutely counts as distribution
vimal has joined #asahi-dev
VinDuv has joined #asahi-dev
vimal has quit [Remote host closed the connection]
arekm has quit [Ping timeout: 264 seconds]
arekm has joined #asahi-dev
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<sven>
now I need to somehow bring up something that lets me see the memory space from the device-side :)
<modwizcode>
Open up the soc and poke some probes in c;
<kettenis>
sven: did you manage to find a way to enable some sort of bypass mode?
Namidairo has quit [Read error: Connection reset by peer]
Namidairo has joined #asahi-dev
<sven>
kettenis: so I assume that there needs to be a "bypass base address" and some "bypass enable" flag. I wasn't able to find them though and doing it just with the frame buffer is a little bit inconvenient because I can't control the device address
<sven>
my best guesses for the bypass enable: 1) the enable/disable flag is in 0xfc, 2) some bit in what I call TCR, 3) somewhere in the 0x140...0x200 range which I haven't spent much time with yet
<sven>
I kinda forgot about 3, so maybe I'll poke around in there some more
<sven>
I haven't looked at what corellium does yet though because I wanted to approach this without any assumptions. maybe they have that bypass flag in their tree.
<kettenis>
They don't
<kettenis>
I poked around a bit within u-boot based on the register names in their code
<sven>
my best bet is the TCR or something in that range I forgot about fwiw.
<never_released>
bypass-only as currently implemented in pongoOS
<kettenis>
ok, thanks
<sven>
hrm. that doesn't seem to work for the frame buffer.
<never_released>
did you convert the pointer?
<never_released>
to the proper base
<sven>
yes
<kettenis>
the problem with the framebuffer is that the graphics hardware will be using a translation
<sven>
I've disabled translations
<kettenis>
so enabling bypass mode without reprogramming the display engine probably won't work
<sven>
set32(0x231304000+0x100, (8<<16)|0x100); <-- that should disable translation (by clearing 0x80) and enable bypass mode with a base at the start of RAM
<sven>
and I know where the display engine expects the frame buffer to be at and I wrote 0xff's to the start of ram plus that address
<sven>
s/set32/write32/, but same result
<kettenis>
is the framebuffer the only thing that's mapped in that particular DART?
<sven>
there are more things mapped, but I just recreated the mapping and only mapped that frame buffer. still works then
vimal has joined #asahi-dev
<sven>
(where "more things" = "one more page")
<sven>
I can set 0xff1bdf in the TCR so that bypass mode kinda agrees with that
<sven>
let me try to poke some bits, maybe it needs something else in there as well
<never_released>
will ask, might be that you'd have to avoid touching the DISP0 DART
<never_released>
for now
<sven>
the flush thing also looks.. strange. just write 0 to two registers?
vimal has quit [Ping timeout: 272 seconds]
<kettenis>
according to the corellium driver you need to write a bitmask of the devices on which to operate in one of those
<kettenis>
and a non-zero code in the other one
<sven>
so I've poked that register before and couldn't really see anything. there's a second block of memory in the device tree (for disp0 0x4000 bytes before) and after 0x2000 there is some kinda of pagetable cache
<sven>
maybe it just doesn't effect that though
<sven>
but all that happened when setting bits in 0x20 was that bits were set and nothing else
vimal has joined #asahi-dev
<sven>
oh... interesting. writing zero to that register does set bit 0x4 for a brief moment though
<modwizcode>
sven: can you post up a full dump of dart space values somewhere?
<sven>
actually, writing anything to that register sets bit 0x4 for a short time
<sven>
I guess invalidate actually is somewhere in there then :-)
<kettenis>
0x4 seems to be a "busy" bit
<sven>
yeah, that makes sense
<sven>
I always did write32(reg, something); read32(reg); from python. kinda obvious that I couldn't see that busy flag :)
<sven>
when I do str directly followed by ldr I do see it though
<modwizcode>
Maybe an op to write and immediately read would be helpful
<modwizcode>
I'm trying to make sense of those mappings
VinDuv has quit [Quit: Leaving.]
<modwizcode>
sven: did you mess with the mappings before that dump was taken?
<sven>
no
<sven>
that was after a clean reboot
<modwizcode>
weird... why is your fb base at such a strange address...?
<modwizcode>
Even the mappings don't make sense to me, assuming that the first dev there is the fb mappings, those are different virtual mappings than I would expect