<jannau>
there is also a dp-crossbar which probably needs to to be configured
<jannau>
I don't think we have documentation besides the code and the tracing implementation
<j`ey>
jannau: whats disp0 "do"?
<marcan>
that's the actual display hardware
<marcan>
dcp is just the CPU
<marcan>
in PMGR it's actually called something like DISP0_CPU or so IIRC
<j`ey>
ah, so dcp pokes mmio in disp0, and the main cpu just enables pmgr stufff for disp0
atsalyuk has joined #asahi-dev
<jannau>
main cpu also maintains the iommu for display processor, dcp and disp0 both have their own dart
the_lanetly_052 has joined #asahi-dev
doggkruse has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<alexsv>
jannau: Thanks a lot! This is already a lot to read!
<alexsv>
One more question: why is everything dependent on m1n1? Is it about FW blobs?
jluthra has joined #asahi-dev
<alexsv>
Ach, m1n1 actually creates the FDT for Linux, as I can see
jluthra has quit []
<_jannau_>
iboot initializes the display (at least partially) and maps some memory in the dcp/disp0 iommu. We have to maintain those iommu mappings otherwise the display processor crashes. m1n1 adds those mappings to the FDT
<_jannau_>
firmware is already loaded by iboot so we do not have to care about that
<chadmed>
more generally, m1n1 handles all the low level init required for linux to see a "normal" arm64 machine in a state it would expect to find one in
atsalyuk has quit [Ping timeout: 480 seconds]
Telvana2 has joined #asahi-dev
MajorBiscuit has joined #asahi-dev
Telvana has quit [Ping timeout: 480 seconds]
<sven>
looks like the nvme irq is just a bit dumb. it'll trigger once when a new completion arrives, and if you send a new command and that command completes before you write the CQ doorbell it won't trigger again :/
<sven>
so that "mystery lock" really just fixes that race and ensures the controller won't see any new commands inbetween the start of the irq handler and the write to the CQ DB
<sven>
and that interrupt sticks until it's actually triggered and handled by the CPU
<sven>
so even if you drive the nvme controller using polling and handle everything, disable interrupts at the nvme level and then shut it down again you'll _still_ get that interrupt
<arnd>
My Mac Ultra (t6002) is going to arrive later today, is there anything I can start trying out on it already, or is it pointless until marcan has done some of the initial work? In the github sources I don't see any reference to the machine or the SoC yet
<maz>
there is also a bunch of m1n1 fixes for that, but I can't find them anymore (must have closed the tab)
<maz>
ah, here you go! :D
jluthra has joined #asahi-dev
MajorBiscuit has quit [Ping timeout: 480 seconds]
<_jannau_>
kernel changes are just the device tree, based on the asahi repo. t600x support in mainline is not yet useful since the iommu support is missing
<arnd>
_jannau_: is it enough to boot into a kernel with display and keyboard,or do I need a serial console?
<_jannau_>
arnd: usb-a ports don't work since the controller needs firmware that is embedded in the macos driver. display over hdmi (preferably at 1920x1080) and usb-c ports work
<arnd>
ok, I think I can find room for one of my old screens on the desk, or use a capture card to view the screen on my current system
<arnd>
using efi-earlycon for debugging does sound easier than serial, as I don't have another mac
MajorBiscuit has joined #asahi-dev
<_jannau_>
running linux under m1n1's hypervisor should work (but not extensively tested) and has serial over usb acm
<shenki>
i can recommend that method
<shenki>
for basic kernel testing at least
<arnd>
right, good idea
<marcan>
arnd: I might poke around in a bit, just need to get a chore taken care of
<marcan>
and yeah, the HV was made for this (also)
<marcan>
_jannau_: I almost *always* run it under the HV while testing, I would call that extensively tested enough
<marcan>
only thing is I think there's still a bug in vUART input, it drops characters if you paste too many at once
Poplar has joined #asahi-dev
atsalyuk has joined #asahi-dev
<j`ey>
same, I always run under m1n1 hv, via normal USB cable
<_jannau_>
not yet extensively tested on t6002, macos HV is definitively busted (probably the second pmgr instance)
<arnd>
I think _jannau_ meant the t6002 specifically isn't extensive tested in hv mode yet, but I guess it's easier for me to get started that way, usb-acm sounds more pleasant than a second monitor with no scrollback
<sven>
okay, i guess I still don't know what that nvme race is. turns out writing to the CQ DB with head < tail will re-enable the interrupt
<sven>
i thought it might be something like "re-issue and complete a command with a tag that's already in the CQ but not yet acked with the DB" but that also works
alcazar has quit [Ping timeout: 480 seconds]
alcazar has joined #asahi-dev
alcazar has quit [Ping timeout: 480 seconds]
alcazar has joined #asahi-dev
atsalyuk has quit [Ping timeout: 480 seconds]
alcazar has quit [Ping timeout: 480 seconds]
alcazar has joined #asahi-dev
alcazar has quit [Ping timeout: 480 seconds]
alcazar has joined #asahi-dev
alcazar has quit [Ping timeout: 480 seconds]
the_lanetly_052 has quit [Ping timeout: 480 seconds]
<arnd>
It took me a while to get macos into a working state with updates and repartitioning, and then I managed to get into u-boot with _jannau_'s m1n1, I can see the output on my hdmi capture, but I have not figured out what I need to do to make the ttyACM devices appear on my host to talk to u-boot without a keyboard
<arnd>
which of the 6 type-c ports is the debug port? Do I need a C-to-C cable or can I plug the other end into a USB-A port on my host?
<j`ey>
you can use a C-A cable
alcazar has quit [Ping timeout: 480 seconds]
<j`ey>
pinging jannau on their other handle
<maz>
arnd: the debug port is the one closer to the Ethernet port.
<jannau>
arnd: debug port is the one next to the ethernet port but that should only matter for the hw uart
<j`ey>
but that's not needed for m1n1 to work over USB
<arnd>
ok, I see, then there must be another problem. Does the ttyACM only work if I boot into m1n1 without the u-boot payload?
<jannau>
arnd: there should be two ttyACM devices when m1n1 is loaded
<kevans91>
it needs to hit the proxy stuff after not detecting an executable payload
<kevans91>
in my experience, at least
<jannau>
ah, yes. m1n1 needs to be standalone on the device without payload
<arnd>
ok, got it. So I reinstall m1n1 with no payload and then pass it u-boot or a kernel from the host, right
<jannau>
then tools/run_guest.py in proxyclient can be used to execute m1n1 + payload from the usb connected computer
<kevans91>
it'd be most convenient if you could drive the proxyclient on the guest, but that seems nontrivial
<nicolas17>
if curl can't connect to the server or resolve DNS or something like that, it will return a non-zero exit code
<nicolas17>
but if the server (or the proxy intercepting it >.>) returns an HTTP error code like 403, it will exit with zero code
<nicolas17>
you may want to add -f to the curl command to make it exit non-zero on HTTP error codes too
<nicolas17>
I don't know if github would ever make raw.githubusercontent.com return 403 (blocking IPs?) or why, but if there is a fallback, we might as well use it in that case too
<alexsv>
jannau: in which component the mentioned uboot boot for dcp is to be fixed?
<rqou_>
nametable[m]: going to guess: are you using the correct "paired" recovery image? you have to make the install you're trying to configure with bputil the default boot option before it will work
alcazar has quit [Ping timeout: 480 seconds]
<nametable[m]>
rqou_: Hmm, I'm not sure if I'm using the "paired" recovery. When I try volume 1 instead of 2, I get a different error "Failed to create local policy"
<j`ey>
is asahi your default startup disk?
<nametable[m]>
Yes, without going to the boot menu, it currently boots to Asahi