<tpw_rules>
hm, that sure seems to be the case. bizarre
bpye has joined #asahi-dev
skipwich has quit [Quit: DISCONNECT]
skipwich has joined #asahi-dev
bpye4 has joined #asahi-dev
skipwich has quit []
<marcan>
sven: that would be a cute hack, if we can just have the kmutil m1n1 chainload something from AuxKC :D
<tpw_rules>
marcan: btw i fixed the issues with the device tree. u-boot has a hook to essentially do a merge of the device tree it loads with its own device tree
<marcan>
tpw_rules: it works if you haven't fully initialized rtkit yet
<marcan>
it's weird
<marcan>
we don't know why it doesn't work if you do a full init
<tpw_rules>
"it"?
rwhitby has joined #asahi-dev
<marcan>
the reset thing
bpye has quit [Ping timeout: 480 seconds]
<tpw_rules>
oh. well i'm not sure if what u-boot is doing a full init. do you remember exactly how you tested that function?
<tpw_rules>
i mean my whole problem is it's not initialized enough i can get it to shut back down
<tpw_rules>
so maybe i'm just not testing the reset properly
Dcow_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Dcow has quit [Ping timeout: 480 seconds]
Dcow has joined #asahi-dev
amarioguy has quit [Ping timeout: 480 seconds]
Dcow_ has joined #asahi-dev
Dcow has quit [Ping timeout: 480 seconds]
<Jamie[m]1>
does anyone have a convenient method for syncing up events in MMIO traces to the thing that caused it (i.e. a way to get a marker to show up in the trace from macOS userland?)
<marcan>
Jamie[m]1: you could use the m1racles register :D
<marcan>
hv_exc.c has a handler for it, you could have that emit an event
<marcan>
and then read/write that register to trigger events; you get a whole two bits for writes (though macOS writes zeroes to it all the time, so you need to filter that out either by value or EL1)
<marcan>
though since this is trapped, you can use the full 64 bits of data
<marcan>
or indeed as many registers as you want, treating it as a weirdo hypercal
<marcan>
I'd actually been meaning to implement this for this use case, especially for the GPU stuff, just haven't gotten there yet
<marcan>
another option would be a debug break; I think we trap brks unconditionally right now (and lower them automatically since a patch I sent some time ago), at least from EL1 but presumably EL0 too
Glanzmann has joined #asahi-dev
<Glanzmann>
tpw_rules: I'm your beta tester.
<Jamie[m]1>
haha sounds good
skipwich has joined #asahi-dev
<tpw_rules>
kettenis: i fixed u-boot. my shower thought is that the addresses you give to rtkit should probably be 16k aligned
<tpw_rules>
and doing that fixed it it seems. i'll actually like clean up and test it tomorrow
<tpw_rules>
anyway night
skipwich has quit [Quit: DISCONNECT]
amarioguy has joined #asahi-dev
amarioguy has quit [Ping timeout: 480 seconds]
the_lanetly_052 has joined #asahi-dev
ChaosPrincess has quit [Quit: WeeChat 3.3]
thunfisch has quit [Remote host closed the connection]
thunfisch has joined #asahi-dev
l3k[m] has joined #asahi-dev
Sebhl[m] has joined #asahi-dev
thunfisch has quit [Ping timeout: 480 seconds]
<sven>
Hmmm… iirc SART should allow anything aligned to 4K
<sven>
im still baffled SART can be skipped and nvme then still works :/
yuyichao has quit [Quit: Konversation terminated!]
yuyichao has joined #asahi-dev
aeadio has joined #asahi-dev
aead has quit [Remote host closed the connection]
MajorBiscuit has joined #asahi-dev
MajorBiscuit has quit [Quit: WeeChat 3.3]
MajorBiscuit has joined #asahi-dev
Dcow has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
VinDuv has joined #asahi-dev
m42uko has quit [Ping timeout: 480 seconds]
MajorBiscuit has quit [Ping timeout: 480 seconds]
Dcow has joined #asahi-dev
m42uko has joined #asahi-dev
Dcow has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Dcow has joined #asahi-dev
amarioguy has joined #asahi-dev
Dcow has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
tdmm has joined #asahi-dev
<tpw_rules>
sven: the problem is specifically giving rtkit non 16k aligned addresses. sart doesn't seem to care
<sven>
yes, I just refer to them as SART buffers as opposed to NVMMU buffers used for most nvme data
<tpw_rules>
ah ok
<sven>
I guess rtkit runs with 16k pages as well and just doesn’t want to map non aligned buffers for those
<sven>
SART should only require 4K alignment or so
Dcow has joined #asahi-dev
tdmm has left #asahi-dev [#asahi-dev]
aleasto has quit [Ping timeout: 480 seconds]
the_lanetly_052 has quit [Ping timeout: 480 seconds]
amarioguy has quit [Ping timeout: 480 seconds]
amarioguy has joined #asahi-dev
<kettenis>
sven: so if I don't start the syslog endpoint nvme works in u-boot and in OpenBSD
<sven>
hrm, so that one isn't mandatory after all then
<sven>
let me try that with the firmware i have
<tpw_rules>
are you able to shut the processor down?
<kettenis>
no, because I have no way to verify that I can start it back up again
<kettenis>
and if I start the syslog endpoint I run into isses
<kettenis>
I can make u-boot work if I poll the mailbox
<kettenis>
and afterwards I can use nvme on the mini which boots from usb
<kettenis>
but on the macbook pro (which boots from nvme) OpenBSD hangs
<tpw_rules>
well let me see if i can shut it down then. for whatever reason i don't actually get any syslog messages besides that 0xb type response
<sven>
you'll only get syslog messages once you start bringing up nvme
<kettenis>
I see the syslog messages if I start the endpoint now
<sven>
feels like we have different firmware then :D
<tpw_rules>
maybe i am not checking for them in the right place then
<sven>
iirc the first message for me comes when the admin queue is set up
<kettenis>
the messages start appearing when I start initializing the nvme stuff
<sven>
ah ok, i just misunderstood then
<kettenis>
not sure if that is when the admin queue is set up
<tpw_rules>
no, it seems if i never initialize syslog, then the management interface doesn't respond to anything
<tpw_rules>
endpoint*
<sven>
that sounds like what happened when i tried to boot without syslog originally
<sven>
maybe we should define what we mean by "enable syslog". could be "send start ep for the syslog endpoint" but could also be "send this 0xb command which we thought was syslog_init"
<kettenis>
that is what happens if I don't enable syslog
<tpw_rules>
and trying that second thing, the management interface still does respond to the shutdown messages. and uboot is able to reinitialize rtkit, but hangs trying to reinitialize the nvme itself
<sven>
hm... so i know that the syslog thread in the rtkit firmware registers a callback for "power state changes" (i.e. that 0xb) command. so maybe that just gets stuck if the endpoint isn't initialized?
<tpw_rules>
although now that i think about it, my shutdown code does not try to shut down the nvme. so maybe i need to do that better
wCPO has joined #asahi-dev
<tpw_rules>
well, maybe linux knows how to do that
<tpw_rules>
hm, it sure seems to... let me garbage collect my setup and make sure this works for real
<tpw_rules>
sven: good call on not sending that 0xb command
<sven>
so the thing is if you send 0xb ("set AP power state") twice with the same power state RTKit panics
<sven>
if you never send 0xb with 0x20 as the argument the power state remains at 0x10
<sven>
and that's also the thing you have to send to shut it down
<tpw_rules>
i'm sending 0x01 to shut it down
<tpw_rules>
but 0x10 with message type 6 ("set IOP power state")
<sven>
hrm, i might've confused those two
<sven>
but they are modeled after what iBoot does anyway
<sven>
so if RTKit thinks the AP power state is 0x01 and you send it 0xb with 0x01 again it'll just panic
<tpw_rules>
that's rude of it
<sven>
yup. and what's even worse is that flipping that reset bit can't revive the co-processor after a panic
<tpw_rules>
but probably explains why earlier experiments were having linux tell me it crashed
<sven>
the code in nvme/dev parses the crashlog it sends fwiw
<sven>
it would've complained about something like "Invalid AP Power" there
<tpw_rules>
i never quite figured out how to actually dump them for that to pars
<sven>
hm?
<sven>
the crashlog is just written to the buffer it requested originally
<tpw_rules>
oh, you mean the linux branch
<tpw_rules>
i thought you were talking about m1n1
<sven>
:D
<sven>
m1n1 also has a crashlog parser somewhere
<tpw_rules>
yeah but it just accepts a file on the hard disk, which i'm not sure how to get
<sven>
ah
<sven>
just open("crashlog.b", "w").write(iface.readmem(crashlog_addr, 0x8000)) or something like that
MajorBiscuit has joined #asahi-dev
MajorBiscuit has quit []
<tpw_rules>
hm, i think i made a mistake when testing because i can't get it to work now. it just crashes in linux again. but i will try the parser out
<kettenis>
fwiw, i pushed some fixes to the u-boot branch
<kettenis>
including the hack to not start the syslog endpoint
aleasto has joined #asahi-dev
<tpw_rules>
ah, simply not sending the 0xb command to shut it down seems to solve the problem for good
<tpw_rules>
but kettenis i assume you are not interested in having uboot shut nvme down yet because that will break openbsd
nabaiste^ has joined #asahi-dev
<kettenis>
right
<kettenis>
I need to add the code to start things back up to OpenBSD first
MajorBiscuit has joined #asahi-dev
Glanzmann has quit [Quit: EOF]
Major_Biscuit has joined #asahi-dev
MajorBiscuit has quit [Ping timeout: 480 seconds]
yamii has quit [Quit: WeeChat 3.3]
yamii has joined #asahi-dev
Dcow has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<povik>
that strikes me as ironic given what we suspect the sio coprocesor does/is :-p
<sven>
its firmware is ~1MB or so. assuming that most of that is rtkit it shouldn't be too hard to confirm how smart it actually is :)
<sven>
huh. i just shutdown nvme after writing a lot of data and it seems that remove_sq/cq actually flushed some more data because it took a few seconds to complete. and that was after a flush already