> need to be carefully reverse-engineered
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.