ChanServ 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-offtopic | Keep things on topic | Logs: https://alx.sh/l/asahi
<amw>
sven : More interested to test the exciting new nvme branch :-)
quarkyalice has quit [Quit: Leaving]
quarkyalice has joined #asahi
<chadmed>
following all the interesting development has me REALLY tempted to drop some cash on a mac mini, but at the same time the M1X devices are really just around the corner and i'd also love to wait for those and test whatever quirks exist there vs plain M1
<chadmed>
afaict the only differences should be more Firestorm cores and more pcie/thunderbolt but honestly who knows what else will change
PhilippvK has joined #asahi
phiologe has quit [Ping timeout: 480 seconds]
yuyichao has joined #asahi
quarkyalice_ has joined #asahi
quarkyalice has quit [Ping timeout: 480 seconds]
<alyssa>
🔥⛈
apetresc has quit [Remote host closed the connection]
apetresc has joined #asahi
<sven>
amw: sure. that's much less stable than the usb though. please don't use it for anything productive :)
<sven>
also just pushed a new version that hopefully also compiles without CONFIG_PCI and cleans some minor things up
<sven>
kettenis_: so from what i can tell the linux code has no issues with issuing multiple commands in parallel
thunfisch has quit [Quit: frrrp!]
<sven>
hrm, i also wonder if the remoteproc framework is better suited than the mailbox framework for all these coprocessors
<pipcet[m]>
would that give us a standard way to handle the reserved memory regions the IOPs know about?
<sven>
not sure, but it has e.g. rproc_boot which feels less awkward than requesting a fake mailbox in the nvme driver
<sven>
still trying to wrap my head around how that subsystem works
thunfisch has joined #asahi
<kettenis_>
sven: yeah, pretty sure this is a bug in the OpenBSD code
<pipcet[m]>
"The function can only be called from a process context (for now)." in the documentation for rpmsg_send, though...
<kettenis_>
sven: there still needs to be a way to express that nvme depends on the remoteproc somehow
aleasto has joined #asahi
<sven>
kettenis_: sure, i'm just wondering if all this system endpoint handling really fits into the mailbox framework.
<sven>
pipcet[m]: that just means you can't call it from atomic contexts
<sven>
(i think)
<chadmed>
rproc does seem like a "more correct" way of handling some of this stuff, especially once (if?) we will be getting the kernel to load firmware rather than relying on iboot finding a macos stub and loading fw from that
<sven>
we can't load firmware for any of the coprocessors (except for the SEP) ourselves
<chadmed>
yeah ik at this stage, but ever at all too?
<sven>
very likely, yeah
<sven>
i can't claim i tested this, but from what i've seen so far the firmware is loaded by iboot and locked down
<chadmed>
damn that sucks didnt realise that (though it should have been apparent given how iboot handles things)
<sven>
less work us :)
<chadmed>
that is true, theres no real harm in terms of ux too i guess, only the requirement of having a fairly chunky macos stub partition on the device which doesnt really matter in the grand scheme of things
<sven>
we should be able to eventually shrink that partition down a lot
<chadmed>
yeah im hoping so, only just if that requires us repackaging some of apple's proprietary stuff that might give us some legal troubles. the way i see it, allowing the macos installer to do its thing and "hijacking" it after its done is probably the least legally troublesome route
<chadmed>
i might play around with figuring out what exactly iboot needs to see a valid system and write a post-macos-install script that deletes everything else and sets up the partition just to boot m1n1.... at some point ;-P
<kettenis_>
I believe marcan's thinking about having a script run in the 1TR environment that just creates the APFS container/filesystem and populates it with bits downloaded from Apple's MacOS update server
Andalu30 has joined #asahi
<chadmed>
it may be easier (by which i also mean legally less questionable) to have the user BYO "install macos xxx.app
<chadmed>
and from that we can extract the required files from Base System.dmg
<chadmed>
that is how we did things for hackintosh when we needed specific files for reverting system-breaking updates as it puts the onus onto the user for acquiring those files. its also less likely to be subject to breaking changes. apple could at any time change update urls or encrypt files or whatever, this way we can be sure the user has them (or even a specific version of them)
<chadmed>
its also not exactly a hard thing to acquire if you actually have a mac since the app store will just download it into /Applications
<marcan>
you can get restore images from Apple's server. it's not like the old macs; ever since T2 they have to support the DFU flow and that means having a publicly accessible API for this
<marcan>
idevicerestore already pulls ipsws from Apple, we'll do exactly the same thing
<chadmed>
ohhh right right that makes more sense
<marcan>
in fact I plan to make the installer stream bits of the ipsw, so it doesn't have to download the whole thing
<marcan>
I already have actual professional experience streaming zip files ;)
<marcan>
we only need the recovery image and firmware bundles; we can skip the actual OS image which is most of it
<marcan>
which means no need for any temporary space since this all fits in RAM
<marcan>
I've already tested this, I already did a manual macOS install once, worked fine to the kernel (then exploded due to no sealed OS volume)
<marcan>
I've been designing the installer in my head for a while now :)
<marcan>
I'll probably spend some time on it soon, seeing as alyssa is signing up to do the DCP kernel driver apparently
foxlet has joined #asahi
<foxlet>
Even with old Macs you could get recovery images by polling the Software Update catalog, pretty much a plain plist.
<foxlet>
Good thing that `partialzip` has been done to death by this point :)
<j_ey>
ipsw is an actual zip file?
<foxlet>
Yeah, it decodes fine as a plain ZIP like any other.
<chadmed>
yeah im playing around with one now
<chadmed>
could be easy to manipulate in python using byteio
<chadmed>
the firmwares are near the top of the archive all bundled neatly
Andalu30 has quit [Remote host closed the connection]
Andalu30 has joined #asahi
<pipcet[m]>
what's the status of DCP reverse-engineering? I'm looking at the "wtf" commit of the "dcp-clusterfuck" branch, and those names totally sound like it's production-ready
<j_ey>
marcan just got an image displayed last stream
<j_ey>
and could mess around with the width/height and colours
bradfier_ has quit [Quit: Leaving...]
bradfier has joined #asahi
<chadmed>
yeah so like pipcet says, production ready ;)
<kettenis_>
sven: did you see my message about the USB DARTs not being in bypass mode when m1n1 starts?
<sven>
oh, no, i must've missed that one
<sven>
are they just in translation enabled but without any pagetables configured then?
<sven>
i thought i checked them at one point and they were in bypass mode then :/
<kettenis_>
DART_TCR: 0x00080080
<sven>
hrm, maybe i misremember because i saw that 0x80 (which someone claimed was the bypass offset) and assumed it was in bypass mode then
<kettenis_>
DART_TTBR: 0x0ad7f6bd
<kettenis_>
so translations are enabled but the TTBRs don't have the valid bit set
<sven>
so.. do we still want to set them to bypass mode at the end of m1n1?
<kettenis_>
it would be convenient for u-boot to have them in bypass mode, but for security reasons that may be undesirable
<sven>
hm, not sure how you could exploit anything using the USB darts though
<kettenis_>
true
<sven>
pcie would be another story, but those can't do bypass anyway ;)
<sven>
i think it's fine to still set them to bypass
<kettenis_>
probably by design
<sven>
yeah, that would make sense
<kettenis_>
I didn't notice because I was chainloading m1n1 from m1n1
<kettenis_>
but things stopped working when I used m1n1 with u-boot as a payload
<sven>
oh, right. it never reaches the code path to set them "back" to bypass mode then
<kettenis_>
yup
<sven>
still makes sense to at least set the usb darts to bypass mode then imho
<sven>
i don't really see any security issues and if it helps u-boot :)
<kettenis_>
I could set them into bypass mode in u-boot of course
<kettenis_>
although I haven't figured out yet how to make the dart driver probe without another device driver explicitly referencing it
<sven>
can't you reference them in the usb nodes?
<kettenis_>
that's what the current code does, but it adds (for now) apple-specific code to the generic dwc3 host driver
DarkShadow44 has joined #asahi
<kettenis_>
ah, I think I could put the DART in bypass mode when the driver's bind function is called
Andalu30 has quit [Ping timeout: 480 seconds]
Andalu30 has joined #asahi
Andalu30 has quit [Read error: No route to host]
Andalu30 has joined #asahi
Andalu30 has quit [Ping timeout: 480 seconds]
<marcan>
pipcet[m]: those names were alyssa's suggestion because she can't wait for me to clean up the code apparently :p
<marcan>
it works fine, I got page flipping to work for RGBA surfaces
<pipcet[m]>
marcan: it's awesome, I approve of the names and can't wait to break things with the code :-)
<marcan>
that should be enough functionality for a "real" graphics driver (i.e. proper vsync and hardware cursor)
<marcan>
mode switching probably works too but I didn't get around to trying it because I need to decode the structures that enumerate the modes, but that's a 30 min problem
<marcan>
plane scaling works fine too
<pipcet[m]>
lack of vsync is annoying, I'm not noticing the software cursor much, but my usage is hardly typical :-)
<kettenis_>
sven: using the bind function works so I'll just put the DART in bypass mode in u-boot
<kettenis_>
then it doesn't really matter what m1n1 does
<kettenis_>
so I now have a u-boot that uses the proposed DART DT bindings
<kettenis_>
but for some reason u-boot isn't happy about the "dma-ranges" proprty you added to the "soc" node
<kettenis_>
seems that can be fixed by putting a "dma-ranges" property on the root node
<kettenis_>
but I think it means that u-boot is a bit to strict about this
<sven>
hm, i'm not even sure if that thing is required
<sven>
but sounds good :-)
<sven>
i should also submit v5 of that dart driver
<kettenis_>
I can actually work around it
<sven>
the dt changes are separate from the rest anyway
<kettenis_>
I no longer need the code that checks the dma-ranges properties in u-boot now that I put the USB DARTs in bypass mode
<kettenis_>
I took the dt changes from the asahilinux dev/dart branch
<sven>
yeah, they're in there for convenience :)
<sven>
but i'll just submit the first three patches
<sven>
changes to the dt for the m1 have to go through marcan while the iommu stuff goes through the iommu tree i think
<kettenis_>
that's the idea
kettenis_ is now known as kettenis
<sven>
als, ugh, clocks. we'll need them at some point unless we just turn them all on in m1n1 and keep ignoring them
<kettenis>
might be a viable strategy to get something usable upstreamed
<sven>
yeah
<kettenis>
usb and pcie clocks are already enabled in m1n1 anyway
<pipcet[m]>
sven: ever saw a clock get stuck in 0x...4f state until you write 0xf to it again?
<sven>
no
<pipcet[m]>
0x1400024f
<pipcet[m]>
I suspect I messed up clock initialization order, but probably not relevant, just thought I'd mention it.
<sven>
don't think i ever saw that
<alyssa>
pipcet[m]: thank you for the kind words re: dcp branch/commit naming
<kettenis>
now has a device tree that should be better aligned with sven's dart stuff
<alyssa>
🎯
<alyssa>
I guess I should take a look at dcp-clusterfuck now :3
<alyssa>
marcan: thanks <3
<alyssa>
marcan: +/* swap id */
<alyssa>
+ {swapid.val:02x} 00 00 00
<alyssa>
I would guess that's supposed to be 08x little-end without the 0s
<xerpi[m]>
41 52 47 42 is the FourCC for BGRA if I'm not mistaken
<alyssa>
Yep
<xerpi[m]>
This will make it easier to fuzz for the supported pixel formats/size/stride contraints :)
aleasto has quit [Ping timeout: 480 seconds]
aleasto has joined #asahi
yuyichao has quit [Ping timeout: 480 seconds]
Andalu30 has quit [Quit: Konversation terminated!]
Andalu30 has joined #asahi
Andalu30 has quit []
Andalu30 has joined #asahi
frode_0xa has joined #asahi
<marcan>
alyssa: yes, that was just a quick hack
Andalu30 has quit [Quit: Konversation terminated!]
<marcan>
it's a u32 of course
<marcan>
this is why I said I wanted to clean it up :p
<alyssa>
marcan: you said i couldn't submt PRs, you didn't say nothing about IRC 😉
<marcan>
xerpi[m]: I'm sure I can `strings` that out :p
<marcan>
/kick alyssa
<alyssa>
😇
<alyssa>
marcan: By the way, I assume I need to update macOS on the m1n1/linux/hv partition to sync DCP firmware version with what you have ?
<alyssa>
(I'm admittedly unsure how to do so since my only way of accessing the macOS there is through the hv... I guess I could flash back XNU and then reflash m1n1 after updating)
<marcan>
yes, you need 12.0 beta3
<alyssa>
beta?
<marcan>
yes, it's not out yet
<alyssa>
delightful
<marcan>
I wanted to get ahead of the changes, no point in being behind in versions
<marcan>
you can just bputil back into reduced security mode
<marcan>
that will disable m1n1
<alyssa>
Ah
<alyssa>
thx
<alyssa>
well, i need a test plan in the mean time so there's that.
<alyssa>
Trying to digest the current code
<marcan>
I need to write something to convert the Construct-based type definitions to something like C
<alyssa>
what's special about D101?
<alyssa>
("UNK_get_some_field")
<marcan>
it's inlined
<alyssa>
f.
<marcan>
but dougall already worked it out in #-re
<alyssa>
Nope, I'm not alowed to make suggestions to dcp-clusterfuck 😉
<marcan>
lol
<alyssa>
this is so cursed
<marcan>
I did ask about your masochistic tendencies when signing up for this :p
<alyssa>
😅
<sven>
:D
zopieux has quit [Ping timeout: 480 seconds]
zopieux has joined #asahi
roxfan2 is now known as roxfan
Andalu30 has joined #asahi
aleasto has quit [Ping timeout: 480 seconds]
aleasto has joined #asahi
Andalu30 has quit [Ping timeout: 480 seconds]
<alyssa>
marcan: Spent the morning wrapping my head around dcp-clusterfuck, wrote myself a cheat sheet of how the layers of crap fit together https://rosenzweig.io/DCP-Cheatsheet.md
<alyssa>
Stepping back, I guess the idea is..
<alyssa>
Input structs packed in shared memory, wrapped in a DCP packet structure with the tag name and lengths. The offset of the packet in shared memory is used as a pointer to send a DCPEp_Msg, which is the actual message sent over the ASC mailbox.
<alyssa>
The shared memory itself is just a block mapped to the DCP DART and with the dart VA negotiated with the DCPEp_SetShmem packet
<alyssa>
still not clear to me how pointers work, I guess those are DVAs?
roxfan2 has joined #asahi
roxfan has quit [Ping timeout: 480 seconds]
roxfan has joined #asahi
roxfan2 has quit [Ping timeout: 480 seconds]
LeviLynch[m] has joined #asahi
Andalu30 has joined #asahi
<pipcet[m]>
alyssa: thank you for that, I think it makes sense now. I can make m1n1 turn the display backlight to full brightness even when iBoot leaves it at the "very dim" setting that macOS keeps resetting it to! it's very exciting! now I just need a Linux driver so I can play with it from userland...
Andalu30 has quit [Quit: Konversation terminated!]