marcan changed the topic of #asahi to: Asahi Linux: porting Linux to Apple Silicon macs | General project discussion | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Topics: #asahi-dev #asahi-re #asahi-gpu #asahi-stream #asahi-offtopic | Keep things on topic | Logs: https://alx.sh/l/asahi
zigmars has quit [Ping timeout: 480 seconds]
zigmars has joined #asahi
yuyichao has joined #asahi
zigmars has quit [Ping timeout: 480 seconds]
zigmars has joined #asahi
zigmars has quit [Ping timeout: 480 seconds]
zigmars_ has joined #asahi
zigmars_ has quit [Ping timeout: 480 seconds]
zigmars has joined #asahi
zigmars_ has joined #asahi
zigmars has quit [Remote host closed the connection]
zigmars_ has quit [Ping timeout: 480 seconds]
dfip^ has quit [Ping timeout: 480 seconds]
dfip^ has joined #asahi
zigmars has joined #asahi
zigmars_ has joined #asahi
zigmars has quit [Read error: Connection reset by peer]
<sven>
the other two irqs are also symmetric fwiw. i think they literally just hooked up the same HW block to both processors
<kettenis>
sven: it is a bit difficult for me to review the mailbox DT binding from a OpenBSD/U-Boot standpoint since it isn't clear how the upper layers are going to look
<kettenis>
currently the U-Boot mailbox driver handles the rtkit protocol as well
<kettenis>
so the NVMe node can simply reference the mailbox
<kettenis>
but it looks as if your Linux mailbox driver only deals with the hardware mailbox
<sven>
yeah, i'm not really sure how those will look like yet either. two two alternative i see is to have a separate rtkit node (like https://lore.kernel.org/all/550C7534.8070100@wwwdotorg.org/ suggested for the raspberry pi case) or to have the rtkit handling be part of the nvme driver (shared as some library)
<alyssa>
jmcneill: new brunswick! 😁
vmcs has joined #asahi
<alyssa>
kettenis: sven and I had discussed a mailbox driver that only deals with the hardware, and then a soft RTKit library which implements all the firmware stuff on top of a generic mailbox
<alyssa>
with the DT describing only the physical hw mailbox
<sven>
that's one alternative, yes
<sven>
there is at least the SEP which will also use the mailbox HW but doesn't speak rtkit at all
<alyssa>
and then the NVMe driver (or whatever) calling into the RTKit library for pacakging
<alyssa>
my DCP tree has that setup with some version of sven's mbox and sven's RTKit .. should probably rebase on what's on the list
<sven>
the other alternative is that separate rtkit node that would handle the rtkit stuff and that the nvme driver could reference
<sven>
not really sure which of those i prefer
<alyssa>
sven: I really dislike that on principle -- device trees are supposed to model the hardware.
<alyssa>
the mbox is physical hardware, rtkit is just a protocol.
<sven>
"I expect you'd end up representing the low-level mbox HW and the remote
<sven>
firmware as separate nodes in DT. There's certainly precedent for
<sven>
representing firmware in DT as a separate node. Perhaps something like:"
<kettenis>
I think what matters here is we end up with multiple device trees node that need to reference specific channels exposes by the RTKit firmware
<kettenis>
if that's the case, I think we need a separate node for the RTKit firmware
<sven>
yes. so if we have multiple nodes that need to talk to difference rtkit channels we need that node
<sven>
yup
<alyssa>
right, true
<alyssa>
SMC is the obvious block that needs that sort of stupid
<sven>
uh, no
<sven>
SMC is a single rtkit channel
<alyssa>
oh I misread that
<alyssa>
SMC needs other stupid, my bad 😉
<sven>
yup :D
<j_ey>
alyssa: (btw there's asahi/mailbox/v2 now, so dont use whats on the list)
<alyssa>
j_ey: Ack
<sven>
which is what's on the list + alyssa's review comments :-)
<alyssa>
sven: For DCP at least, there are lots of rtkit channels but I see no reason not to stick it all in dcp.ko ... the rtkit library api is 💯 natural to me
<j_ey>
and jassi's!
<alyssa>
SMC is a single channel so irrelevant as discussed
<j_ey>
alyssa: youre so hip n cool with your 💯
<alyssa>
j_ey: 😎
<sven>
j_ey: oh, yep. ofc!
<alyssa>
sven: so ... which block are we worried about?
<alyssa>
SEP isn't even RTKit ... NVMe maybe?
<alyssa>
AGX i don't know how it looks but I can't possibly fathom a reason not to do it all in agx.ko
<sven>
i dunno
<j_ey>
NVMe doesnt use the mailbox, just has to start it
<alyssa>
sven: right... it seems like this is future proofing for the sake of future proofing, not because of a particular engineering objective ...
<alyssa>
admittedly it's a thin tightrope since we don't have docs on current or future apples
<sven>
i don't even know about all blocks that _currently_ use rtkit
<kettenis>
yes, apple should hurry up with their next-gen hardware such that we can compare ;)
<sven>
:>
<marcan>
< sven> the other two irqs are also symmetric fwiw. i think they literally just hooked up the same HW block to both processors <- just like the wii :p
<kettenis>
anyway, I think either design could work for U-Boot and OpenBSD, so I think the DT binding for the mailbox should be fine
<sven>
thanks, that's good to know.
<sven>
i don't have a strong opinion regarding that separate rtkit node fwiw
<alyssa>
kettenis: I'm waiting for M2 Macbooks to be released so I can get a used M1 air for cheap 😋
<marcan>
separate rtkit node is basically what macos does, fwiw
<marcan>
I don't have a strong opinion there, I guess it comes down to what that buys us
vmcs has quit [Quit: leaving]
<kettenis>
it looks like both iop,ascwrap-v4 and iop,m3wrap-v2-acio were first introduced on the M1, so even the compatible names make sense to me ;)
<marcan>
the library solution seems reasonable, especially considering all the display related sub-drivers in DCP are the kind of thing that ends up in one big module on linux anyway, for other hardware
<sven>
hah :D
<kettenis>
marcan, the iop-nub,rtbuddy-v2 nodes?
<marcan>
yeah
<alyssa>
ADT uses a lot of software nodes
<alyssa>
gfx-mapper is such an ugly one..
<sven>
the fake-iommu that really just calls back into the main kext? :D
<alyssa>
ye
<alyssa>
described in the ADT
<kettenis>
I don't think it would be too horrible if we skip the rtkit firmware node for now and add it later if it turns out we need it
<kettenis>
btw, maz and alyssa, I pushed a small change to U-Boot to update the msi-ranges property for the PCIe node to match the proposed binding
<j_ey>
kettenis: do you have any patches to m1n1? I have issues running m1n1+clang
<j_ey>
(with run_guest.py, I dont think youre using that..)
yuyichao has joined #asahi
<jmcneill>
alyssa: yep! born here, moved away, and eventually returned
<kettenis>
j_ey: no (but I'm using gcc as a cross-compiler to build m1n1 and u-boot)
<j_ey>
kettenis: oh
<kettenis>
well, I have a diff to set the baudrate to 115200 but I doubt that will help you
<j_ey>
it seems to get into some kinda exception loop
<j_ey>
I'll probably just stick to gcc for now, at least my linux+clang works
<j_ey>
what format should the initrd to u-boot be? I get 'Wrong Ramdisk Image Format' with a .cpio.gz
<kettenis>
there should be no initrd
<j_ey>
I mean when running: booti kerneladdr initrd dtbaddr
<kettenis>
I don't know; I don't do Linux ;)
<kettenis>
I would expect u-boot to support most formats in common use
<j_ey>
there's IMAGE_FORMAT_LEGACY IMAGE_FORMAT_FIT and CONFIG_SUPPORT_RAW_INITRD, problem is that m1n1 doesnt support uncompressed cpio which is what I assume CONFIG_SUPPORT_RAW_INITRD is (maybe)
<roxfan>
well, it' just a little matter of programming :)
<kettenis>
my main goal with u-boot is to enable the UEFI interface
<j_ey>
makes sense
<kettenis>
so booting Linux directly from u-boot is (largely) untested
<kettenis>
I believe that with the UEFI boot path folks typically use grub and grub does the initrd loading
<roxfan>
maybe adding tianocore to m1n1 is an easier task?
<kettenis>
although there is EFISTUB as well which allows you to directly load a kernel if I understand things correctly
<j_ey>
kettenis: yup
<kettenis>
not sure how initrd gets loaded in that scenario, although I have seen people mention that this relies on the EFI LoadFile2 protocol
<kettenis>
that's a fairly recent thing in u-boot, but the code seems to be there in my fork
<j_ey>
well I finally got uboot with an initrd working, cool!
<kettenis>
yay!
<sven>
huh, does anyone know where the SMC firmware is stored? can't find it in the ipsw or in the preboot volume
<kettenis>
maybe it is in a ROM?
<sven>
hm, good point
<sven>
could also be some internal flash i guess if it has to come up before SecureROM
zigmars has quit [Remote host closed the connection]
<alyssa>
sven: i assume iBoot needs to talk to SMC very early on in the boot
<kettenis>
the SMC might be what is starting the CPU that runs iBoot
<sven>
yeah
zigmars has joined #asahi
zigmars_ has joined #asahi
zigmars has quit [Read error: Connection reset by peer]
zigmars_ has quit [Remote host closed the connection]
zigmars has joined #asahi
<sven>
pipcet[m]: so it looks like this tps USB PD chip has _two_ i2c buses and with that also two independent interrupt controllers. i suspect one of them is connected to the main CPU while the other is connected to the SMC
<sven>
can you try to see if you can break charging when you only disable interrupts in one of those two?
PeterB[m] has joined #asahi
zigmars has quit [Remote host closed the connection]
<krbtgt>
jmcneill: oh hey, someone else from here
zigmars has joined #asahi
jnoxon has quit [Ping timeout: 480 seconds]
zigmars has quit [Remote host closed the connection]
<jmcneill>
ah never mind, answered by your hostname :)
<jmcneill>
always surprised to see someone from around here on any irc server
<krbtgt>
sme
<alyssa>
<--- boring ontarian
<alyssa>
we've got... uh... cheap beer!
<jmcneill>
again?
<jmcneill>
i lived there when buck a beers were $1, and then the prices went up
<alyssa>
🤷
<alyssa>
I wouldn't know, my coding schedule relies on sobriety 😅
<jmcneill>
anyway, don't be ashamed of being from ontario, it's a beautiful province and in another life i would probably have stayed there
<alyssa>
sorry, *Toronto, and nobody is from here. nobody 😉
<jmcneill>
I have great memories of visiting Toronto when I was a kid!
<alyssa>
(also, errr, hello from m1 linux. It really bugs me how much more usable this is already than my Chromebook)
<alyssa>
(GNOME/X11/4K@60 in this case. Was testing HDMI hotplug... works fine now ☺)
<jmcneill>
nice!
<alyssa>
I wonder, do I dare experiment with type-C display out?
<jmcneill>
I'm hoping that driver gets ported to NetBSD some day :)
<alyssa>
Maybe downstream?
<j_ey>
alyssa: how 'quick' does it come up when you plug it in?
<alyssa>
j_ey: brb finding out :-p
<jmcneill>
It will happen eventually, as long as the driver is not GPL only
<alyssa>
j_ey: about 3 seconds. but that could easily just be the monitor, nothing to do with the driver stack
<alyssa>
(switching from 1080p to 4K is also a few seconds of black...)
<j_ey>
aw, i was hoping it might just be magical and be instant :P but 3s is fine anyway
<alyssa>
where does this "m1 display stack is magic" meme even come form
<alyssa>
*from
<alyssa>
Is it just a mix of System Preferences' Displays tab changing scaling instantly, together with the "m1 go brrr magic" that my twitter follower count relies on?
<alyssa>
on the former charge -- by default macOS on M1 doesn't change physical resolution at all, just reconfigures software scaling. of course that'll be instant..
<alyssa>
I imagine that's a smoke and mirrors trick for the MacBooks... just boot at maximum resolution and *never change it* ... Wow, so fast!
<alyssa>
it's cute but doesn't have much to do with the M1 👅
<alyssa>
* 😋
<j_ey>
ive never changed resolution or used a 2nd screen with my m1 D:
<krbtgt>
alyssa: i've seen them react quickly to external monitors on mac os
<krbtgt>
which is where the meme comes from
<alyssa>
krbtgt: I see.. maybe I have bad luck with external monitors then
<Bastian[m]>
https://youtu.be/KfbiX7JFKsE?t=368 looks fairly normal here, maybe it's really fast if the screen is still on? closing the lid and switching to monitor only seems somewhat fast
<alyssa>
I also wonder, is it possible to have dual type-c monitors on the mac mini, if no hdmi is plugged in?
<alyssa>
If I understand the cable topology correctly, it's not
<alyssa>
> While the M1 MacBooks natively support just one monitor, the M1 Mac Mini does natively support up to two external monitors - one via the HDMI port and a second via USB-C. But the latest models of the MacBook Air and MacBook Pro support only one external display.