4 ms·
We actually know very little about the clock tree; we know where the clock mux registers are but not how they connect to each other, and that's mostly about per
by marcan_42 5y ago
We actually know very little about the clock tree; we know where the clock mux registers are but not how they connect to each other, and that's mostly about peripherals, not the CPUs. Also, the PLL registers are locked out and read only. The CPU DVFS stuff is all done automatically (you just select a performance level in one register), and I wouldn't be surprised if the underlying tables and configs for that are also locked post boot. The PMIC is accessible to some extent, but runs its own firmware anyway which might lock things out, and I don't think CLVRs (final voltage regulator stage, the one you care about) are directly accessible (on the Pro/Max) and that should all be controlled by the SMC or hardware logic, which again has a good chance of being locked off.
Basically, all of this is configured at boot and much of it locked off. Apple have done a good job making it difficult to nuke these things from the OS level, for better or for worse :). I once overwrote all the GPIO registers and didn't even break anything (though the Type C controllers did crash, but a hard shutdown and boot fixed it - this was on an M1 Pro MacBook). It's in one of my streams somewhere...
- monocasa 5y agoOh, word. Thanks for the correction. I guess I extrapolated too much from the combo of you knowing enough of the clock inputs to the peripherals to make them work and a statement of yours about finding a pll bypass signal. I want to say your main point your statements on the pll bypass was that the cores must be mainly static logic because they ran stable at whatever rate the crystal is, but I'm half remembering and could conflating that with something else.
- marcan_42 5y agoAh, the PLL bypass was just p-state 0, but that was still using the high level interface. macOS never uses that mode, but it's there.