ChanServ changed the topic of #asahi-re to: Asahi Linux: porting Linux to Apple Silicon macs | Hardware / boot process / firmware interface reverse engineering | WARNING: this channel (only) may contain binary reverse engineering discussion | RE policy: https://alx.sh/re (MANDATORY READ) | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Logs: https://alx.sh/l/asahi-re
PhilippvK has joined #asahi-re
phiologe has quit [Ping timeout: 480 seconds]
maor26 has joined #asahi-re
the_lanetly_052__ has joined #asahi-re
the_lanetly_052__ has quit [Ping timeout: 480 seconds]
Dcow has joined #asahi-re
Dcow_ has quit [Read error: Connection reset by peer]
riker77 has quit [Quit: Quitting IRC - gone for good...]
the_lanetly_052__ has joined #asahi-re
gwyef has joined #asahi-re
gwyef has quit [Remote host closed the connection]
riker77 has joined #asahi-re
the_lanetly_052___ has joined #asahi-re
<sven>
marcan: so here's something that may be going on: the rtkit reset vector checks some kind of resume flag and if has an unexpected value (0xbaadf1ac) it'll go to a while(1); loop. and i think it'll always have the unexpected value once rtkit is up and running
<sven>
and i think if you send that powerdown message it'll overwrite that value to something else
<sven>
and then a reset will work
<sven>
still need to confirm this though, the code is a bit annoying to follow
the_lanetly_052__ has quit [Ping timeout: 480 seconds]
<sven>
hrm, or maybe not. it changes VBAR at some point
<sven>
but i guess that might also be reset to its original value if the PMGR reset is a true hard reset
the_lanetly_052__ has joined #asahi-re
the_lanetly_052___ has quit [Ping timeout: 480 seconds]
sikkiladho[m] has joined #asahi-re
steve has joined #asahi-re
steve is now known as Guest7639
the_lanetly_052 has joined #asahi-re
the_lanetly_052__ has quit [Ping timeout: 480 seconds]
the_lanetly_052 has quit [Ping timeout: 480 seconds]
the_lanetly_052 has joined #asahi-re
maor26 has quit [Quit: Leaving]
<marcan>
sven: it's weird that sometimes I got it to start the rtkit init and fail later
<marcan>
but I was also playing with sending NMIs; not sure if that's required to cause that to happen (and it's not consistent anyway)
<sven>
the mmi is another while(1); loop in the firmware I think
<sven>
*nmi
<sven>
or, well
<sven>
it'll try to send a crashlog and then spin forever
<marcan>
heh
<marcan>
I haven't seen it try to send a crashlog
<sven>
did you send the nmi after it got a crashlog buffer?
<sven>
hrm, i think it's actually that flag in the data section which we can't access for DCP :(
<sven>
erm
<sven>
*for ANS
<sven>
i'll check tomorrow if i can revive any of the coprocs where we can access that flag
<sven>
(and unless there's something like KTRR this also gives trivial code exec on all coprocs where we can write to the data section by overwriting the stuff it stores in that section during hibernate)