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
dcowich[m] has joined #asahi-dev
dcowich[m] is now known as Dcow[m]
FireFox317 has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
FireFox317 has joined #asahi-dev
yuyichao has quit [Ping timeout: 480 seconds]
yuyichao has joined #asahi-dev
kov has quit [Quit: Coyote finally caught me]
kov has joined #asahi-dev
PhilippvK has joined #asahi-dev
phiologe has quit [Ping timeout: 480 seconds]
aleasto has joined #asahi-dev
chadmed has joined #asahi-dev
chadmed has quit [Remote host closed the connection]
chadmed has joined #asahi-dev
matthewayers[m] has joined #asahi-dev
yuyichao has quit [Ping timeout: 480 seconds]
Gaspare has joined #asahi-dev
yuyichao has joined #asahi-dev
casperes1996[m] has joined #asahi-dev
<sven> fwiw, all the DCP DART entries that are left over from iBoot are present in the "segment-ranges" property in the ADT
yuyichao_ has joined #asahi-dev
<marcan> I like the kernel test robot, it catches a lot of silly stuff in the asahi tree
<marcan> thank you to whoever added us to that :)
<sven> yup, that thing is great :D
yuyichao has quit [Ping timeout: 480 seconds]
<sven> it runs on all branches of that repo as well
the_lanetly_052 has joined #asahi-dev
<marcan> yup
yuyichao has joined #asahi-dev
yuyichao_ has quit [Ping timeout: 480 seconds]
yuyichao_ has joined #asahi-dev
yuyichao has quit [Ping timeout: 480 seconds]
<_jannau_> it might have pick the repository up from MAINTAINERS
Gaspare has quit [Quit: Gaspare]
<povik> how does it decide who to send emails to? MAINTAINERS again?
<j_ey> sven wasnt emailed, but hes a MAINTAINER
<sven> pretty sure someone added the github repo manually
<sven> and it takes the email from the commit author (+ tags if available)
<sven> [ 1.023592] apple-pmgr-pwrstate 23b700000.power-management:power-controller@3f0: PS 0x3f0: assert reset
<sven> [ 1.027570] apple-pmgr-pwrstate 23b700000.power-management:power-controller@3f0: PS 0x3f0: deassert reset
<sven> marcan: ^-- that should mean the reset was successful, right?
<sven> because afterwards ANS2 still has the CPU_RUN flag in that register set and i can't restart it
<marcan> sven: can you hvtrace it to make sure I don't fail it with the regmap stuff?
<sven> sure
<sven> hrm, trace_range(range(0x23b700000, 0x23b700000+0x4000)) should work, right?
<sven> ah yes, it does
<sven> marcan: ^-- that should be the relevant part
<sven> (that also includes some additional debug reads)
<marcan> sven: hm, I'll have to look into that
<marcan> it did work with PMP IIRC
<sven> hm, strange
<sven> doing it manually from shell.py doesn't seem to clear the running flag either
<sven> it's a pity we can't see what iBoot does to reset ANS completely
<marcan> sven: it does work for me, found the old code
<sven> okay, wtf
<sven> let me try that code
<sven> hrm, it hangs
<sven> oh.. SART probably
<sven> okay, why the hell does that work
<marcan> yeah, it's not doing SART
<marcan> but the reset works
<marcan> I need to get some sleep, but I hope that leads you somewhere :)
<sven> i'm just more confused WTF is going on :D
<marcan> :D
<sven> i can run that thing twice and it seems to work
<sven> but i manually poke that PMGR reg from shell it doesn't?!
<sven> this is clearly something very dumb
<marcan> sven: oh, the reset doesn't clear the bit
<marcan> but it still works
<marcan> note that the m1n1 asc code does 0->1->0 on that cpu run bit
<sven> oh, urgh.
<marcan> but even if you just make it a set32 to only write 1, it still works
<sven> let's see
<marcan> even if it's already 1 (as long as you reset)
<sven> hrm, so i do that in linux and that apparently didn't work
<marcan> well, to be specific, just this is enough: self.asc.CPU_CONTROL.set(RUN=1)
<sven> see [cpu5][0xffff80001054cee4] MMIO: W.4 0x277400044 (ans[0], offset 0x44) = 0x10 in the HV trace :/
<kettenis> so RUN is really RESET?
<marcan> actually, as long as the bit is 1 and left at 1 it works :D
<marcan> if it's 0 it doesn't boot after a pmgr reset
<marcan> if 1 it does
<marcan> so it looks like it's a cpu_run flag or whatever
<marcan> sven: I have an idea
<marcan> if it's left at 1, the thing will boot on its own
<marcan> maybe you're dropping the mailbox message in that case?
<marcan> so, make sure that bit is 0, *then* reset, *then* set it to 1
<marcan> and that way you know when it's booting
<marcan> maybe trace the mailbox too
<marcan> (well, the whole asc)
<sven> setting it to 0 before the reset doesn't seem to help. let me try tracing everything
<marcan> also, if the mailbox driver relies on IRQs and it's already initialized by now, maybe that config is lost
<marcan> maybe check the mailbox status manually
<marcan> m1n1 polls of course
<marcan> I gotta sleep, have fun :)
<sven> the ans mailbox shouldn't need any irq configuration
<sven> that's just the thunderbolt ones which have that slightly braindead secondary irq configuration. but let's see
<sven> 'night
<sven> marcan: it doesn't work anymore if ANS has been fully booted once apparently
<marcan> ha
<marcan> maybe something else needs resetting
<marcan> apcie?
<marcan> apcie_st specifically
<sven> let's see
<sven> so i added this to the ans script and then i can only run it once as well
<sven> sart_base = 0x27bc50000
<sven> p.write32(sart_base+6*4, 0xffffffff)
<sven> p.write32(sart_base+0x40+6*4, 0x800000000>>12)
<marcan> hmm, yeah...
<marcan> I'll have to look into this
<marcan> wonder if we can get any debug as to what these ASCs are doing
<marcan> also, this could be something dumb
<marcan> I've always wondered how the .data section is reset when you reboot an ASC
<marcan> maybe it isn't
<marcan> maybe iBoot loads it and that's all you get
<marcan> that would mean we can't actually do clean resets
<sven> hmmm..
<sven> that would be annoying
<marcan> I tried PMP earlier and it didn't work; might try manually resetting .data since that one is not locked later
<marcan> anyway, 'night :)
<marcan> (unfortunately NVMe is...)
<sven> yeah :/
<sven> goodnight!
<sven> resetting APCIE_ST doesn't seem to do anything
the_lanetly_052__ has joined #asahi-dev
the_lanetly_052 has quit [Ping timeout: 480 seconds]
Gaspare has joined #asahi-dev
<sven> nope, can't get it to reset after it was fully booted once :/
<kettenis> so that means I wouldn't be able to do so from u-boot either isn't it?
<sven> you can still send 0x60000000000010 (and possibly even 0x60000000000002 for an even lower power state)
<sven> then the next stage needs to wake it up again with 0x60000000000020 or so
<kettenis> does it renegotiate the syslog/crashlog memory addresses in that case?
<sven> yes
<landscape15[m]> kettenis: I know it’s a simple question but, do you really need u-boot to run Linux? You can directly run the Linux kernel right?
<j_ey> landscape15[m]: yes if you want to be able to update kernels
<landscape15[m]> j_ey: ok, so for debugging purposes it seems better, but the end user will still prefer a friendly EFI boot menu.
<j_ey> landscape15[m]: u-boot will likely load GRUB on most distros
<landscape15[m]> Ok fine. How long does it take to complete the boot chain (before loading the kernel)?
<j_ey> im sure u-boot won't add much time
<sven> hah, got it to reset successfully i think
<sven> so it looks like we need to send 0xb0000000000010 followed by 0x60000000000001 to shut it down cleanly
<sven> and only then does the reset work :/
<landscape15[m]> j_ey: ok thanks
the_lanetly_052__ has quit [Ping timeout: 480 seconds]
Gaspare has quit [Ping timeout: 480 seconds]
maor26 has joined #asahi-dev
aleasto has quit [Remote host closed the connection]
Gaspare has joined #asahi-dev
Gaspare has quit [Quit: Gaspare]
Gaspare has joined #asahi-dev
mini has quit [Quit: ZNC closing...]
VinDuv has quit [Ping timeout: 480 seconds]
Gaspare has quit [Quit: Gaspare]
maor26 has quit [Ping timeout: 480 seconds]