3.5 hours until my talk about #asahilinux which will be recorded and also live streamed at https://streaming.media.ccc.de/39c3/one
Remote
Sven Peter
@sven@social.treehouse.systems
mastodon 4.6.7+glitch-thforward/reverse engineer • porting Linux to Apple Silicon (AsahiLinux) • former console hacker (Homebrew Channel, BootMii, WiiU and PS3) • part of fail0verflow • he/him
header picture by @yawnbox@disobey.net
3758 Followers
188 Following
42 Posts
Joined November 10, 2022
I've finally just submitted the RFC series for USB3 support on Apple Silicon machines. RFC because the entire Type-C machinery spans multiple subsystems and has quite a few quirks which makes the entire thing rather annoying to deal with and I'm not 100% convinced about the current approach.
This also includes some initial work for DisplayPort-altmode and USB4/Thunderbolt but both will require much more work after this is upstream, so don't get your hopes up just yet.
https://lore.kernel.org/asahi/20250821-atcphy-6-17-v1-0-172beda182b8@kernel.org/
Replying to
USB4 allows tunneling of USB3, PCIe and DisplayPort and all that is managed by a Host Router. On Apple Silicon that thing is called acio. The host router contains various protocol adapters which convert the incoming data from e.g. PCIe to the tunneled package format and combines that stream with other tunneled protocols to send it out to the Type-C PHY. The PHY then converts the packets to the on-wire protocol sent over the Type-C port. ACIO also contains an IOMMU and the Native Host Interface (NHI) which controls setting up all these tunnels.
This is reason why supporting that entire thing is so complicated: All the various components have to interact with each other and on x86 machines that's mostly abstracted away by firmware running on the router. Here, we don't get that luxury and have to implement all the management ourselves.
That also means the first Thunderbolt series will be very boring for end-user: It'll just be the Host Router and the NHI such that tunnels can be established. They will be useless though before we then later implement the protocol adapters.
(2/2)
Looks like M4 support for #asahilinux is going be rather painful. We’re still focusing on upstreaming M1/M2 support but other people have been trying to bring up m1n1 on M4 and it looks like a few things changed:
When configuring a macho boot object we now get dropped into an environment where Apple’s SPTM is running in GL2 and we are supposed to talk to it from EL2 with MMU already enabled to setup pagetables. This neither works for Linux nor for running XNU under our hypervisor to reverse engineer the new hardware.
When configuring a raw boot object we’re dropped into EL2 with GL2 and most (all?) Apple specific extensions disabled. This is totally fine for Linux but we can’t run XNU under our hypervisor that we use to reverse engineer the hardware in this state. This also seems to be broken for >=15.2 right now because it probably isn’t very well tested 😕
Looks like I'll be at #FOSDEM this year! I will probably arrive Friday evening and leave Sunday afternoon. Happy to meet and chat about #asahilinux or anything else.
I blame @vbabka@mastodon.social, @ljs@mastodonapp.uk and @neal@social.gompa.me for luring me there :D
Replying to
Looks like it’s mostly ready to be merged, just has to be rebased on usb-next! 🥳
This is another example why sending these patches that we have upstream is so important: The feedback I got from the dwc3 maintainer Thinh made the code much nicer and we don’t have to worry about unrelated changes in dwc3 breaking Apple Silicon support with the new approach he suggested now. It also helped me figure out where SUSPHY is actually required and made the PIPE handler dance much more stable. This will also simplify the atcphy code a little bit.
#asahilinux
Replying to
Like last time this does NOT contain Thunderbolt or DP-AltMode support yet.
It's last big piece of code I wrote that's only been in our downstream trees though. Once this is upstream, I can finally focus on new features :-)
Replying to
Since there’s been some confusion: this does *not* enable DisplayPort over these connectors or Thunderbolt. It only brings up the PHY correctly. For DisplayPort work on DCP is needed and for Thunderbolt the native host interface and finally the PCIe controller need to be brought up.
This series is just the first step required for both.
Replying to
@elly i just don’t understand why these charging stations have to be different that gas stations 😕
They are a mess in .de as well
Replying to
And the (likely) real fixes: https://lore.kernel.org/asahi/20260108-atcphy-coldboot-fix-v1-1-01c41c6e84f2@kernel.org/T/#u and https://lore.kernel.org/asahi/20260108-dwc3-apple-usb2phy-fix-v1-1-5dd7bc642040@kernel.org/T/#u
macOS briefly bringing up dwc3 and tearing it down again with no device connected was just a red herring, no idea why that happens.
I'm considering coming to #GPN24 on saturday or sunday for half a day or so since I live relatively close by. how easy is it to get a day pass? and anyone there who'd like to meet and chat?
Replying to
@shac i see we may have made similar mistakes in the past. Deleting all recipients is the first thing I do when I already feel annoyed before even writing the first word in my reply
Replying to
@shac I could begrudgingly live with stuff like temperature control behind touch buttons but what I really hate is when stuff like cruise control is a stupid touch button on the steering wheel as well like on my current Volkswagen. There’s a 50:50 chance that I change the speed by either 1kph or 10kph because their poor excuse for pressure sensitive touch just doesn’t work at all and I still have to briefly look at the steering wheel instead of feeling the dumb button.
Replying to
@gameshack_ @janne these things don't happen on purpose. what usually happens is that some silicon bug is found very late e.g. during bringup and it's cheaper and easier to just work around it in software than risking another silicon revision trying to fix it
Replying to
@wolf480pl there's a mux inside the type-c PHY that deals with that. usually there would be another line from the display crossbar and from dwc3 to that phy
Replying to
@wolf480pl no, I didn't draw these lines because I only wanted to focus on USB4/TBT for that picture
Replying to
@xsk an alternative would be to hijack XNUs exception handlers and pagetable code and patch the tracing in there. we’ll see.
Replying to
@janne yup, it’s just suspicious that at least this old macOS I looked at goes through a similar sequence even when nothing is connected to the usb port
Replying to
@trollkatt LKML can occasionally be quite abrasive and toxic (and that’s the mails you then see amplified all over the place) but most of the time the feedback is useful
Replying to
@neobrain sure! I haven’t ordered stickers yet and the ones we had are all gone so probably no :(
Replying to
@curious yup, we may know best what quirks are required to make some generic drivers work on Apple hardware but Thinh has a much better understanding of dwc3 and has probably seen half a dozen different variants. Experience like that is incredibly valuable.
Replying to
Replying to
@cperon yeah, I’m aware of it. It should probably be added to our documentation somewhere
Replying to
@edward @AsahiLinux yes, this is the first dependency for external screens. Final support will also require DCP which is still a lot of work to be done.
Replying to
@andrewbriscoe tldr: it’s gonna be possible but take some time, new contributors are making early progress with m3 and we have some rough ideas for how to tackle m4. no promises on timeline ofc :)
Replying to
@Sobex it’s mostly software engineering at this point for both except for some
small details here and there I guess
Replying to
@awws asciiflow.com and then some manual adjustments of the ascii output in some random text editor
Replying to
Replying to
@sebby2k yeah, they also power cycle everything. it's a truly weird design choice and I'd really like to know how this happened and why they haven't fixed it yet.
Replying to
@sebby2k I believe synopsys is mostly to blame for this one. I think the phy can actually be reconfigured without a power cycle but dwc3 really hates that. The Linux driver for that controller already a few dozen quirks so this one maybe isn’t too surprising.
There’s also a stateful eUSB2 (low voltage USB2 for modern SoCs) to USB2 converter on the board that also messes things up.
Replying to
@cperon lol, yeah, we could try a very cursed thing as well: put the m4 kernel onto a m3 with all custom ISA stuff enabled, trap all MMIO and redirect it to the m4 in raw boot mode. Would be very slow if it works at all :D
Replying to
@vbabka@mastodon.social @josefbacik@hachyderm.io I’m sure with the right prompt some LLM is totally going to go from commit id to relevant discussion on lore! No more need for Link: tags!