This is nonsense. There is nothing out of reach. This is obviously provable by the fact that macOS itself runs just fine in permissive security mode, which is indistinguishable to the machine to running Linux. We even have it running on a bespoke hypervisor, booting to desktop, which is how we reverse engineer its interactions with the hardware.
> is anyone dealing with the performance modes of the chip, tuning them for performance-vs-dissipation?
Yes, I'll be working on that as soon as the basic GPU kernel driver prototype is done. I already wrote the clock gating driver last week, which was one of the things on my immediate TODO list.
> What about the DRAM interface?
On the M1, unlike typical SoCs from other vendors which are a giant mess in this area, most of these gritty power management details are handled by onboard coprocessors running Apple firmware. This makes porting an OS a lot easier, as you only need to deal with a much higher level interface than you would on other SoCs.
Even CPU sleep modes have an automatic mode. You set it to auto, issue wfi, and some heuristic inside the CPU itself decides if it should do a deep sleep or a shallow sleep. Not sure if we'll use that since Linux is perfectly capable of handling CPU c-state decisions itself (and all we really have to do there is measure the latencies so Linux knows what to expect), but just to give you an idea.
The CPU frequency scaling is abstracted out behind a few simple registers. Poke this register to set the CPU core cluster voltage, poke this other register to set the p-state for a core. No need for thousands of lines of code to deal with calling out to an external I²C PMU to set the vcore voltage or doing a complex PLL frequency switching dance. It's stupid easy. We haven't written a proper driver for that yet, but Corellium wrote a PoC version and it's 390 lines of code.
> each of which require that level of work.
Nope. We already have DART, NVMe, USB, PCIe, I²C, UART, SPI and parts of power management working. Things like I²C and SPI are trivial little blocks. The GPU is by far the biggest thing. I just got DCP display modesetting working last night on our prototype driver; Alyssa is implementing it in Linux soon.
> Apple not only won't be any help, but will be actively hindering these efforts.
I guess they spent a huge amount of development time writing the entire BootPolicy framework that enables other OSes just for fun then, and are planning on throwing it all away? This doesn't make any sense. I keep hearing this FUD and we have seen zero evidence that Apple plan to hinder anyone. The Mac is an open platform and always has been. They are neither helping nor hindering anyone trying to port an OS to this thing. They are tacitly saying "have fun".
I'm not sure why nobody trusts us when we say we're going to make this all work properly. We aren't nobodies; the major team contributors have been reverse engineering hardware for a decade or so. We've been staring at this thing for the past 9 months. We know what to expect. We haven't been putting together a PoC all this time; we've been engineering and reverse engineering things to put together proper, full, upstreamable support. That's why it takes time. But once it comes together you'll see it's far from a mere PoC.
Hey, bravo for replying and all, but your time is valuable. Please don't feel obligated to play whackamole here, unless you enjoy it :)
The skeptic posts will keep appearing (heck I myself wrote one months ago) until people can boot something low-performance with keyboard, unaccelerated framebuffer, network, and internal storage, and trust that it won't corrupt filesystems. We all know you're working on that. It will shut up the skeptics, and it's the only thing that will do that.
That said, at some point a fully 100% comprehensive inventory of all these "onboard coprocessors running Apple firmware" (that we can't reprogram or recompile the firmware for) is going to be needed. And a clear, coherent argument for each of them individually, explaining why it isn't a bugdoor risk. I'm sure most of those answers will be elaborations on "because IOMMU". But for the DRAM controller the story will be much more nuanced.
I'll buy an M1 someday, and it will beat the pants off my RK3399, but I doubt I'll ever trust it to the same degree.
Thanks for the detailed answer! I didn't realize you Apple left firmwares running on a bunch of the peripheral cores, that certainly makes things much more achievable, if only for reverse-engineering what they're doing.
I'm surprised and impressed you got so many peripherals running, including DART! For USB, do you mean USB4?
I hadn't heard of BootPolicy for other OSes, and I can't find anything about that online. Sounds like that gives you a much more solid foundation to work on than I thought.
For USB I mean USB2 on the Type C ports (device/host) and USB3 on the Mac Mini's A ports (which are just a standard discrete PCIe controller). USB3 and Thunderbolt/USB4 require more work to integrate the Type C port management, muxing, and bringing up the associated PCIe controllers; we're working on those things (and Corellium also have a PoC for that, it's not that hard either, but as everything it takes time to do it right). We're also working on making changes to the Linux IOMMU subsystem to enable DART with 16K pages to work with kernels built with a 4K page size, which will solve a lot of use cases (Android apps, x86 apps under FEX emu, and not having to pester distros to ship 16K page size kernels to get TB3/USB4 to work safely). Sven sent out a draft patch series for that to Linux a few days ago, and the first take on DART itself is already upstream. Also, just hours ago Alyssa lit up display modesetting with DCP under Linux with KMS, for the first time outside of macOS and our prototype m1n1 driver. So 4K displays now work with proper page flipping, and we're moving past the bootloader-provided framebuffer.
After taking a crack at the GPU kernel driver, I should probably direct my attention to audio (which nobody has looked at yet); if whenever we demo a fully accelerated 3D desktop I can have that working too it'll avoid a lot of people coming out and saying "they don't even have working audio, nobody's ever going to use it" ;)
For reverse engineering, as I mentioned, one big tool I spent a month writing is a custom thin hypervisor that can run macOS (the native version, not the VM kernel version) with direct access to the hardware. It boots to desktop with all drivers intact, and this allows us to write hypervisor hooks to inspect and log all MMIO traffic. We already have a working tracer for the DCP (display controller coprocessor) that logs all inter-processor calls, which is how I figured out that bit, as well as generic parts of the interface they use for all coprocessors. Next up is the GPU, so I'll just point the base copro tracer at the GFX core and also trace all MMIO registers in those ranges and see what macOS does. It really does make life much easier. It's also great for debugging Linux; it implements a virtual UART over USB-gadget, so you don't need special cables to get a physical UART, and you get low-level debugging features for when your kernel crashes. Our kernel test cycle is on the order of 7-10 seconds, including rebooting the machine and loading a new kernel from a host machine on top of the hypervisor. I made a long video about all the HV stuff, if you're interested:
That's the "official" line why this all exists, being able to run self-built XNU kernels, but it is evident that internally Apple engineers are happy to see efforts to port Linux, and Apple themselves have no reason to oppose that use case. It's all very clearly a "we won't help you, but have fun" kind of understanding. And we intend to have fun :)
Realistically, once this runs well enough and people are actually using it, that does put pressure on Apple not to do anything that gratuitously would seriously make our lives harder, whether they ever officially admit to that or not.
That's what the entire project is about.
> or out-of-reach entirely
This is nonsense. There is nothing out of reach. This is obviously provable by the fact that macOS itself runs just fine in permissive security mode, which is indistinguishable to the machine to running Linux. We even have it running on a bespoke hypervisor, booting to desktop, which is how we reverse engineer its interactions with the hardware.
> is anyone dealing with the performance modes of the chip, tuning them for performance-vs-dissipation?
Yes, I'll be working on that as soon as the basic GPU kernel driver prototype is done. I already wrote the clock gating driver last week, which was one of the things on my immediate TODO list.
> What about the DRAM interface?
On the M1, unlike typical SoCs from other vendors which are a giant mess in this area, most of these gritty power management details are handled by onboard coprocessors running Apple firmware. This makes porting an OS a lot easier, as you only need to deal with a much higher level interface than you would on other SoCs.
Even CPU sleep modes have an automatic mode. You set it to auto, issue wfi, and some heuristic inside the CPU itself decides if it should do a deep sleep or a shallow sleep. Not sure if we'll use that since Linux is perfectly capable of handling CPU c-state decisions itself (and all we really have to do there is measure the latencies so Linux knows what to expect), but just to give you an idea.
The CPU frequency scaling is abstracted out behind a few simple registers. Poke this register to set the CPU core cluster voltage, poke this other register to set the p-state for a core. No need for thousands of lines of code to deal with calling out to an external I²C PMU to set the vcore voltage or doing a complex PLL frequency switching dance. It's stupid easy. We haven't written a proper driver for that yet, but Corellium wrote a PoC version and it's 390 lines of code.
> each of which require that level of work.
Nope. We already have DART, NVMe, USB, PCIe, I²C, UART, SPI and parts of power management working. Things like I²C and SPI are trivial little blocks. The GPU is by far the biggest thing. I just got DCP display modesetting working last night on our prototype driver; Alyssa is implementing it in Linux soon.
> Apple not only won't be any help, but will be actively hindering these efforts.
I guess they spent a huge amount of development time writing the entire BootPolicy framework that enables other OSes just for fun then, and are planning on throwing it all away? This doesn't make any sense. I keep hearing this FUD and we have seen zero evidence that Apple plan to hinder anyone. The Mac is an open platform and always has been. They are neither helping nor hindering anyone trying to port an OS to this thing. They are tacitly saying "have fun".
I'm not sure why nobody trusts us when we say we're going to make this all work properly. We aren't nobodies; the major team contributors have been reverse engineering hardware for a decade or so. We've been staring at this thing for the past 9 months. We know what to expect. We haven't been putting together a PoC all this time; we've been engineering and reverse engineering things to put together proper, full, upstreamable support. That's why it takes time. But once it comes together you'll see it's far from a mere PoC.