ChanServ 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
suricato has quit [Ping timeout: 480 seconds]
uralj has joined #asahi-dev
alyssa has joined #asahi-dev
<alyssa> pipcet[m]: ooh, I just got a black screen on boot
<alyssa> 1/3 boots failed tonight .. probably there's a race
riker77_ has joined #asahi-dev
riker77 has quit [Ping timeout: 481 seconds]
riker77_ is now known as riker77
<msmith12[m]> sounds like gstremer
phiologe has joined #asahi-dev
PhilippvK has quit [Ping timeout: 480 seconds]
yuyichao has quit [Quit: Konversation terminated!]
jeffmiw has joined #asahi-dev
bps has quit [Ping timeout: 480 seconds]
aleasto has joined #asahi-dev
bps has joined #asahi-dev
jeffmiw has quit [Ping timeout: 480 seconds]
suricato has joined #asahi-dev
<pipcet[m]> alyssa: do you have timing info on your printks? on my system, the time between enabling the disp dart and switching the FB was perilously close to 1/60 s
phiologe has quit [Ping timeout: 480 seconds]
sirn has quit [Quit: ZNC 1.8.2 - https://znc.in]
sirn has joined #asahi-dev
aleasto has quit [Quit: Konversation terminated!]
al3xtjames0 has joined #asahi-dev
al3xtjames has quit [Ping timeout: 480 seconds]
al3xtjames0 is now known as al3xtjames
chadmed has quit [Remote host closed the connection]
chadmed has joined #asahi-dev
uralj has left #asahi-dev [WeeChat 3.2]
<alyssa> ahhhh
<alyssa> tbh i'm sort of hoping the raciness goes away when i switch to usin the DCP
<alyssa> Otherwise we need to preserve the initial framebuffer and uh
bisko has joined #asahi-dev
yuyichao has joined #asahi-dev
aleasto has joined #asahi-dev
<pipcet[m]> I've beaten up my Digital Crash Processor a bit more and I really don't think we should mix the interfaces if we can avoid it. I also don't like the current page table stealing hacks and am hoping you guys come up with something way better...
gladiac has quit [Read error: Connection reset by peer]
gladiac has joined #asahi-dev
gladiac is now known as Guest5380
Guest5380 has quit [Read error: Connection reset by peer]
gladiac has joined #asahi-dev
<sven> do you want to keep the mappings or start over with a clean pagetable for a locked dart?
<sven> if you want to keep them: in attach_dev first create the io-pgtbl as usual. then walk the Apple pagetable and just ->map everything they mapped. then do a u64-by-u64 copy from the first level io-pgtbl to the first level Apple pagetable. then finally swap the ttbrs in io-pgtbl and set a flag that there are not managed by linux
<alyssa> sven: are you talking to me or to pipcet[m] ?
<sven> then write a custom free function for io-pgtbl that only frees the top-level if that flag isn't set
<sven> alyssa: dunno, both of you i guess? :)
<pipcet[m]> honestly I think sven is Mr DART and both options sound like work :P
<alyssa> sven: 😅
<sven> and you'll also need some changes to ensure to that get_group function to ensure that you can't mix a locked DART with any other DART
<sven> oh, and probably to get_default_domain to force DMA domains for locked DARTs
<sven> alright, finally confirmed how mac os knows about new usb devices connected to usb-c ports: it's the SMC
<pipcet[m]> \o/
<sven> writing 0x1 to NTAP enables notifications, and then you get a message from it
<sven> 0x7020000000000018: 0x18 = notification, 0x70 = "system state" and 0x20... is a bitmask for individual events
<j_ey> sven: writing 1 to NTAP? whats NTAP?
<sven> that 0x20... is event_name-bit41: USB2_plug according to the ADT
<sven> j_ey: your guess is a good as mine. if i write 0x0 it disables notifications, and if i write 0x1 it enables then.
<sven> haven't tested anything else yet
<pipcet[m]> "notify Application Processor"
<pipcet[m]> I would guess
<sven> that would certainly fit
<j_ey> sven: I mean, how do you write to that?
<sven> j_ey: oh, it's a key inside the SMC
<sven> you write 0x1 to that shared memory location
<j_ey> ah
<sven> and then send er... let me find it again
<pipcet[m]> I've been using NTAP for a while and I think it's on the wiki :-)
<sven> ugh. should've taken a look at the wiki then instead of finding that from tracing macOS :D
<pipcet[m]> no, mea culpa, never put it on the wiki :-/
<pipcet[m]> sven: IIRC it's the first thing it does, and tracing macos is good for you! builds moral fibre!
<pipcet[m]> anyway, my fault for not documenting it properly :-(
<j_ey> sven: so the usb phy driver will need to talk to the smc/mailbox too?
<pipcet[m]> oh. there's a file called smc.wiki in my home directory which I never uploaded because my net was down
<alyssa> j_ey: everybody talks to everybody
<alyssa> it's not very socially distanced :'(
<sven> j_ey: it needs to somehow be hooked up to the SMC driver. maybe SMC will be an interrupt-controller as well or something
<sven> no idea yet
<alyssa> sven: SMC really doesn't fit into any one driver class on linux
<j_ey> alyssa: linux is vaxxed
<sven> alyssa: drivers/soc/apple :>
<alyssa> sven: yeah, was going to say
<alyssa> maybe like you did for rtkit
<j_ey> soc = everything else :P
<sven> soc = sven's ugly hacks
<j_ey> soc = sven's odd code
<sven> but yeah, smc is gonna be annoying
<pipcet[m]> sven: I tried the interrupt controller thing and another mailbox controller, didn't like either very much :-/
<sven> j_ey: :D
<pipcet[m]> sven: we need payload data so that's hard to do with interrupts
<sven> what payload data do we need?
<pipcet[m]> power button goes through it, and the battery indicator payloads changed when I upgraded macOS yesterday...
<pipcet[m]> power button, lid switch, charging notifications, usb notifications, who knows what else...
<pipcet[m]> otoh, just do an interrupt for usb and ignore the rest for now?
<alyssa> each of those could be a setup interrupt..?
<sven> we just need to identify individual interrupts, don't we? so something like interrupts = <&smc 0x70 0x20....>; for the usb phy might work
<alyssa> separate
<alyssa> but now you have a virtual interrupt controller and this is getting into sandcastle level hacks
<sven> yeah, i dunno
<sven> gpio usually does chained interrupts fwiw
<sven> pci as well i guess. but this is slightly different
<pipcet[m]> I tihnk I just heard someone volunteer to rewrite the mailbox driver code so it's actually usable and handles stuff like this!
<alyssa> pipcet[m]: I heard sven say that too! 😋
<sven> uh, why mailbox? if this chained/whatever irq controller makes sense this would be aic -> mailbox -> rtkit -> smc -> usb phy. the length of that chain makes me uncomfortable though.
<alyssa> TBF every link there is forced by Apple, not us.
<sven> i'm still annoyed that they didn't consider hooking up the usb connected/disconnected line to dwc3
<alyssa> I do still wonder if "SMC as a library" makes more sense than "SMC as a driver"
<pipcet[m]> sven: you did hear my "the SMC snoops the PD chips' interrupt lines to know when to kick the battery charging circuitry" theory?
<sven> uh... no
<pipcet[m]> I'm pretty sure it does.
<sven> that sounds insane. but at this point it would also only surprise me a little bit
<pipcet[m]> setting the intmask over i2c means no more notifications from the SMC, plus charging doesn't work. You're right it's insane.
<sven> doesn't m1n1 set the intmask by default these days?
<alyssa> supposing that theory is right-- how does charging work if the machine is off?
<sven> https://github.com/AsahiLinux/m1n1/blob/main/src/usb.c#L281 so i think m1n1 should disable all interrupts by default
<sven> and i definitely get notifications after that
<sven> or is it just specific notifications that are missing?
<alyssa> is the SMC always-on? in that case, wouldn't a dead battery brick a macbook?
<pipcet[m]> the SMC does stay on normally, but the tps chip also has a dead-battery mode to recover from that scenario
<pipcet[m]> there's a CL?? property that says how long it's been running :-)
<sven> but that's only called once m1n1 exits
<sven> i get notifications from the SMC inside m1n1 using shell.py
<pipcet[m]> 0x71 notifications or 0x70 ones?
<sven> i think i've seen 0x70, 0x71 and 0x72
<sven> but i can check again
<pipcet[m]> it would be wonderful if the firmware upgrade fixed this and I'll formally call in doubt my theory, then, but until yesterday I needed to enable intmasks for charging to work.
<sven> weird
<pipcet[m]> well, as long as it's getting less weird with every upgrade....
<sven> my firmware is rather old fwiw
<sven> but this is also on a man mini
<pipcet[m]> which version?
<sven> uhh... let's see
<pipcet[m]> oh! I was talking about the macbook, sorry.
<sven> 11.5 20G5033c i think
<pipcet[m]> if you have code I can try in (vanilla, I promise) m1n1 I'll be glad to :-)
<sven> i can clean the mess that i have right now up tomorrow or so
<pipcet[m]> sure, no worries
aleasto has quit [Remote host closed the connection]
<sven> but i think most of what i have should be in m1n1 already
<pipcet[m]> I, uh, may have manually toggled gP0d using read64 and write64 the other day :P
<sven> it's really just the common rtkit bootstrap code + asc.send(0x4e54415000013011, 0x20) and then asc.recv()
<alyssa> gPod? we've come full circle
<pipcet[m]> you're at offset 0x30 in the SMC SRAM?
<sven> this is taken straight from the hv trace
<pipcet[m]> oh, the corellium driver, and my variation on it, always have the second-lowest byte set to 0, which means it always starts at the beginning of the SRAM. macOS advances (I have no idea why because you can't get concurrency anyway)
<pipcet[m]> (maybe it's wear levelling ;-) )
Mary has quit [Quit: The Lounge - https://thelounge.chat]
Mary has joined #asahi-dev
Mary has quit [Quit: The Lounge - https://thelounge.chat]
yuyichao has quit [Quit: Konversation terminated!]
suricato has quit [Ping timeout: 480 seconds]