<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
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?
<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)