marcan changed the topic of #asahi-dev to: Asahi Linux: porting Linux to Apple Silicon macs | General development | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Logs: https://alx.sh/l/asahi-dev
qyousef has quit [Ping timeout: 256 seconds]
riker77_ has joined #asahi-dev
qyousef has joined #asahi-dev
riker77 has quit [Ping timeout: 264 seconds]
riker77_ is now known as riker77
phiologe has quit [Ping timeout: 260 seconds]
phiologe has joined #asahi-dev
VinDuv has joined #asahi-dev
VinDuv has quit [Quit: Leaving.]
maor26 has joined #asahi-dev
amw has joined #asahi-dev
<never_released> modwizcode: There are two IPIs methods
<never_released> the AIC IPIs over IRQs
<never_released> and the fast IPIs over FIQs
M0_osx[m] is now known as osxre
osxre is now known as M0_osx[m]
amw has quit [Ping timeout: 246 seconds]
bisko has quit [Ping timeout: 240 seconds]
redbluescreen[m] has quit [Quit: Idle for 30+ days]
rockinrobstar[m] has quit [Quit: Idle for 30+ days]
crafteck[m] has quit [Quit: Idle for 30+ days]
bisko has joined #asahi-dev
amw has joined #asahi-dev
amw has quit [Ping timeout: 256 seconds]
<marcan> modwizcode: that "defer" doesn't mean what I called "deferred IPIs" for non-AIC
<marcan> that's corellium terminology, and i don't agree with it
<marcan> whoever wrote that QEMU code copied the register defines from the corellium patchset
<marcan> I need to test those extra registers again though
<marcan> also, uh
<marcan> there is hex-rays output in that file
<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> https://github.com/AsahiLinux/m1n1/pull/30/files alright.. that's probably everything I can figure out by poking dart mmios and playing with the framebuffer.
<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> for the DART
<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
<sven> + def writeread32(self, addr, data):
<sven> + return self.request(self.P_WRITEREAD32, addr, data)
<sven> ;)
<sven> great minds think alike and yet fools seldom differ :P
<modwizcode> heh I don't think I've ever heard that one
<modwizcode> Probably unlikely but is there any chance there's even just minor overlap with SMMU concepts?
<sven> oh... I definitely need to take a closer look at that one range I forgot about again
<sven> 0184: 0001000c
<sven> there's 16 values for 16 devices in there that seem to contain more flags
<kettenis> not familliar with SMMU, but in the end it's just a page table of sorts and some registers to poke to flush cached translation entries
<modwizcode> thanks sven
<sven> that's disp0 after a fresh reboot
<sven> 0180 - 01bc looks interesting as well. let's see if I can figure out what they do
<modwizcode> Lots of zeros in the 0x3000 range
<sven> everything after 0x300 seems to be zero.
<sven> 0x200 - 0x300 are the pointers to the pagetables
<sven> 4 per device, bit 31 indicates if they're active
<sven> huh, now I can't reproduce that busy bit anymore.
<kettenis> if there is nothing to flush it will probably clear immediately
<kettenis> anyway, I'll probably get to the point where I can play with bypass mode for the PCIe devices in a few days
odmir has quit []
<sven> well, it used to set the busy bit even when I wrote 0 to it
<sven> but no idea what I've done before that to trigger that :/
<sven> ah... got it. looks like you need to write to that device selection register first
<sven> that kinda makes sense ;)
<sven> actually, no, it just doesn't like you if select a device that is disabled
brandas[m]1 has joined #asahi-dev
rockinrobstar[m] has joined #asahi-dev
odmir has joined #asahi-dev
brandas[m]1 has left #asahi-dev ["User left"]
<modwizcode> sven: any progress on bypass mapping the display?
<sven> no :(
<sven> the whole top_byte<<16 | 0x100 would fit though since I can only set 0xff1bdf and that lines up nicely
<sven> I think I'll need some device to be able to see the virtual address space
<sven> maybe the display is doing something strange that breaks when bypass is enabeld
<modwizcode> sven: Is the dart device for the display #0? It looks like there's multiple entries in that register set
<sven> yes, there are two blocks of registers
<sven> that one that I dumped + another one just before that
<sven> the one just before that contains some kind of pagetable cache starting at 0x2000
<sven> and something else before that, but I haven't looked into that yet
<modwizcode> I meant like there's the #16ish entries or ids or whatever
<sven> oh, yes
<sven> device #0 is the framebuffer
<modwizcode> ah
<sven> there's also #4 which I have no clue about
<modwizcode> I love arbitrary numeric identifiers
<sven> the index is somewhere in the device tree
<modwizcode> I got quite mad when I realized that for all the dynamic stuff of pcie, you still have to know what each BAR represents :p
<sven> mapper-disp0 and mapper-disp0-piodma
<modwizcode> interesting
<modwizcode> what is this?
<sven> the pagetables for disp0 from iboot
<sven> device 04 is this piodma thing
adamcstephens has joined #asahi-dev
<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
adamcstephens has left #asahi-dev ["The Lounge - https://thelounge.chat"]
<sven> the beginning makes sense I think. it's mapping the frame buffer starting from vaddr 0423c000
<sven> but things get weird after the framebuffer ends
<sven> these vaddrs also appear in the "fault address" status register if I disable that mapping
<modwizcode> right but why is your fb from the boot arguments set to what appears to be the physical address?
<sven> FB at: 0x9e0df8000
<sven> page (143): 0423c000 ... 04240000 -> 00000009e0df8000 [0b11]
<modwizcode> Oh are those backwards?
<modwizcode> (i.e. device->host)
<sven> yeah
<modwizcode> backwards from what I was thinking
<modwizcode> wait what type of device are you using sven?
<sven> hm?
<modwizcode> what model of mac
<sven> Mac mini
<modwizcode> ...
<modwizcode> okay
<modwizcode> that doesn't help then :/
<sven> my m1 MacBook Air is just the UART adapter :P
<modwizcode> I'm confused because your address for the framebuffer is very different from what I was seeing in marcan'
<modwizcode> marcan's streams
<modwizcode> and it's not like a nice round number too
<sven> 🤷‍♂️
kubes has quit [Quit: Leaving]
maor26 has quit [Ping timeout: 256 seconds]
zopieux has quit [Ping timeout: 272 seconds]
zopieux has joined #asahi-dev