Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Overclocking the G5 CPU
- Thread starter simie
- Start date
- Sort by reaction score
I saw an posting on a forum, where the user claimed to have overclocked a couple of G5's some years before 2014, the user claimed the resistors were moved on the daughter card. When asked to post the config of the resistors the user name ever replied.
Here is the datasheet for the memory controller for the Power PC CPU.
6.2 Initializing HyperTransport Core in the CPC945 The initialization sequence of the HyperTransport unit is dependent on the detection of the ‘sync’ state. Figure 6-1 illustrates a HyperTransport initialization sequence, followed by an HT_LDTSTOP_L. The first half of the link initialization is automatically attempt by the core when the link powers up. The core begins this sequence by asserting the HT_RESET_L. In the initialization sequence, the link width is based on the maximum width of the smallest transmitter or receiver, but limited to 8. The default clock frequency is 200 MHz for all devices. Figure 6-1 demonstrates that first half of the initialization. While HT_RESET_L is asserted during a cold reset, each device drives its CTL signal to a logical 0, and drives its output CAD signals to a value that is based on the width of its receiver. At the deasserting edge of HT_RESET_L, each device samples its input CAD signals and uses this sampled value to determine its transmitter and receiver widths then updates the LinkWidthIn and LinkWidthOut Registers. After the deassertion of HT_RESET_L, each device asserts its CTL signal across a rising CLK edge, initiating a sync sequence. The assertion of the CTL signal serves to indicate to the device at the other side of the link that this device is ready to complete initialization of the link. At this time, the HyperTransport is active. However, the second stage of the initialization is driven by the system firmware. This stage is used to operate at the maximum clock frequency and link width.The firmware reads the LinkWidthIn and LinkWidthOut Registers to determine the link’s maximum width. The firmware also determines the links frequency cababilites. It then updates the corresponding control registers for link width and frequency in both upstream and downstream traffic. Lastly, the firmware asserts the HT_LDTSTOP_L to force the updated values to take effect.
6.9.2 Updating the PLL The HyperTransport Specification describes the HT PLL as capable of being changed without placing the PLL in reset. However, the CPC945 HT PLL can only be changed when the PLL is in reset or by using the ForcePLLReset. Use of the ForcePLLReset bit is not recommended as data present on the HyperTransport bus can be lost. The HyperTransport Specification mandates the HT clocks continue running while the clocks are changed. However, the CPC945 power manager design requires stopping the clocks while the PLL is changed.
Our solution may well be a firmware mod.
6.2 Initializing HyperTransport Core in the CPC945 The initialization sequence of the HyperTransport unit is dependent on the detection of the ‘sync’ state. Figure 6-1 illustrates a HyperTransport initialization sequence, followed by an HT_LDTSTOP_L. The first half of the link initialization is automatically attempt by the core when the link powers up. The core begins this sequence by asserting the HT_RESET_L. In the initialization sequence, the link width is based on the maximum width of the smallest transmitter or receiver, but limited to 8. The default clock frequency is 200 MHz for all devices. Figure 6-1 demonstrates that first half of the initialization. While HT_RESET_L is asserted during a cold reset, each device drives its CTL signal to a logical 0, and drives its output CAD signals to a value that is based on the width of its receiver. At the deasserting edge of HT_RESET_L, each device samples its input CAD signals and uses this sampled value to determine its transmitter and receiver widths then updates the LinkWidthIn and LinkWidthOut Registers. After the deassertion of HT_RESET_L, each device asserts its CTL signal across a rising CLK edge, initiating a sync sequence. The assertion of the CTL signal serves to indicate to the device at the other side of the link that this device is ready to complete initialization of the link. At this time, the HyperTransport is active. However, the second stage of the initialization is driven by the system firmware. This stage is used to operate at the maximum clock frequency and link width.The firmware reads the LinkWidthIn and LinkWidthOut Registers to determine the link’s maximum width. The firmware also determines the links frequency cababilites. It then updates the corresponding control registers for link width and frequency in both upstream and downstream traffic. Lastly, the firmware asserts the HT_LDTSTOP_L to force the updated values to take effect.
6.9.2 Updating the PLL The HyperTransport Specification describes the HT PLL as capable of being changed without placing the PLL in reset. However, the CPC945 HT PLL can only be changed when the PLL is in reset or by using the ForcePLLReset. Use of the ForcePLLReset bit is not recommended as data present on the HyperTransport bus can be lost. The HyperTransport Specification mandates the HT clocks continue running while the clocks are changed. However, the CPC945 power manager design requires stopping the clocks while the PLL is changed.
Our solution may well be a firmware mod.
Last edited:
well after talking to chat GPT about all of this and specifying this spec sheet on the G5:
chatGPT had this to say after reading it:
Modifying firmware, especially for a processor, is an extremely advanced and risky task that requires specialized knowledge in embedded systems programming, hardware architecture, and potentially reverse engineering. It is generally not recommended due to the high risk of causing irreversible damage to the hardware, rendering the system inoperable, and voiding warranties. Additionally, modifying firmware can have legal and ethical implications, as firmware is proprietary software protected by intellectual property laws.
### Theoretical Steps for Firmware Modification:
1. **Firmware Extraction**:
- The first step would be to extract the existing firmware from the hardware, which might require specialized tools and knowledge.
2. **Reverse Engineering**:
- Once extracted, the firmware would likely need to be reverse-engineered to understand its structure, functionality, and to identify the portions responsible for setting the clock multiplier.
3. **Modification**:
- After understanding the firmware's workings, you would need to modify the relevant portions to change the clock multiplier, which would likely require advanced programming and debugging skills.
4. **Reflashing**:
- The modified firmware would then need to be reflashed onto the hardware, which carries the risk of bricking the hardware if anything goes wrong.
5. **Testing and Monitoring**:
- If the hardware survives the reflash, extensive testing and monitoring would be necessary to assess the impact of the modifications on stability, performance, and temperatures.
### Legal and Ethical Considerations:
- **Intellectual Property**: Firmware is typically protected by copyright, and unauthorized modification or distribution can have legal repercussions.
- **Integrity and Security**: Modifying firmware can compromise the integrity and security of the hardware and can introduce vulnerabilities.
### Conclusion:
While modifying firmware to change the clock multiplier is theoretically possible, it is fraught with technical, legal, and ethical challenges and is generally not feasible or advisable for most users. The risks of hardware damage, legal consequences, and unintended side effects far outweigh the potential benefits of such modifications. Always consider the legality, ethics, and risks involved in modifying proprietary software and hardware, and explore safer and more responsible ways to achieve your performance goals.
chatGPT had this to say after reading it:
Modifying firmware, especially for a processor, is an extremely advanced and risky task that requires specialized knowledge in embedded systems programming, hardware architecture, and potentially reverse engineering. It is generally not recommended due to the high risk of causing irreversible damage to the hardware, rendering the system inoperable, and voiding warranties. Additionally, modifying firmware can have legal and ethical implications, as firmware is proprietary software protected by intellectual property laws.
### Theoretical Steps for Firmware Modification:
1. **Firmware Extraction**:
- The first step would be to extract the existing firmware from the hardware, which might require specialized tools and knowledge.
2. **Reverse Engineering**:
- Once extracted, the firmware would likely need to be reverse-engineered to understand its structure, functionality, and to identify the portions responsible for setting the clock multiplier.
3. **Modification**:
- After understanding the firmware's workings, you would need to modify the relevant portions to change the clock multiplier, which would likely require advanced programming and debugging skills.
4. **Reflashing**:
- The modified firmware would then need to be reflashed onto the hardware, which carries the risk of bricking the hardware if anything goes wrong.
5. **Testing and Monitoring**:
- If the hardware survives the reflash, extensive testing and monitoring would be necessary to assess the impact of the modifications on stability, performance, and temperatures.
### Legal and Ethical Considerations:
- **Intellectual Property**: Firmware is typically protected by copyright, and unauthorized modification or distribution can have legal repercussions.
- **Integrity and Security**: Modifying firmware can compromise the integrity and security of the hardware and can introduce vulnerabilities.
### Conclusion:
While modifying firmware to change the clock multiplier is theoretically possible, it is fraught with technical, legal, and ethical challenges and is generally not feasible or advisable for most users. The risks of hardware damage, legal consequences, and unintended side effects far outweigh the potential benefits of such modifications. Always consider the legality, ethics, and risks involved in modifying proprietary software and hardware, and explore safer and more responsible ways to achieve your performance goals.
I quite agree but that is not stopping other members on this forum from modifying firmware to inject CPU codes etc.. From reading the datasheet it looks like it is possible to change the state of the CPU without resetting. It states that everything has to lock into place ( this will be the Phase Locked Loop), meaning the operating frequencies and this seems to be software controlled. The datasheet states that you can monitor the frequencies selected.
I shall read through the datasheet and see what is possible and post any finding here.
Last edited:
Tell that lawnmower man to go back to his shed! If he isn't part of the solution...
Thanks a lot for that! I had installed it under Debian ppc and used it a couple of times for some large datasets (>10,000 cells) and 26.5Gb RAM was definitely needed! Will give it a try under leopard as soon as I replace one of my CPUs (I get the CPU halt red light after a while using it, disabling it the Quad runs fine)
On this note, given that you seem to be into bioinformatics too, did you by any chance ever get bowtie2 to compile under Leopard ppc64 and/or know if the bowtie2 macport could be modified to compile under ppc64? I had got close by modifying "arch" to ppc64 in my macports config but even by installing sidme via macports, compilation always fails - I don't know if simde will translate all sse2 instructions on the G5's implementation of altivec (could be that it requires vsx) . No such issue for bowtie1 under Leopard (recently published a Nat Commun paper for which I used my quad to align some ChIP-Seq data I had generated using a leopard-compiled version of bowtie when available computing resources were low as used for other projects, and I won't ever be thankful enough to my Quad
) or bowtie2 under Linux ppc64 - the latter of which does make me believe that this is possible.I do have that version of bowtie1 I had compiled under leopard handy (ppc32 version) if you by any chance need it to e.g. put the binary on ppc macports btw, let me know!Thanks a lot for that! I had installed it under Debian ppc and used it a couple of times for some large datasets (>10,000 cells) and 26.5Gb RAM was definitely needed! Will give it a try under leopard as soon as I replace one of my CPUs (I get the CPU halt red light after a while using it, disabling it the Quad runs fine)
On this note, given that you seem to be into bioinformatics too, did you by any chance ever get bowtie2 to compile under Leopard ppc64 and/or know if the bowtie2 macport could be modified to compile under ppc64? I had got close by modifying "arch" to ppc64 in my macports config but even by installing sidme via macports, compilation always fails - I don't know if simde will translate all sse2 instructions on the G5's implementation of altivec (could be that it requires vsx) . No such issue for bowtie1 under Leopard (recently published a Nat Commun paper for which I used my quad to align some ChIP-Seq data I had generated using a leopard-compiled version of bowtie when available computing resources were low as used for other projects, and I won't ever be thankful enough to my Quad
Thanks a lot for that! I had installed it under Debian ppc and used it a couple of times for some large datasets (>10,000 cells) and 26.5Gb RAM was definitely needed! Will give it a try under leopard as soon as I replace one of my CPUs (I get the CPU halt red light after a while using it, disabling it the Quad runs fine)
On this note, given that you seem to be into bioinformatics too, did you by any chance ever get bowtie2 to compile under Leopard ppc64 and/or know if the bowtie2 macport could be modified to compile under ppc64? I had got close by modifying "arch" to ppc64 in my macports config but even by installing sidme via macports, compilation always fails - I don't know if simde will translate all sse2 instructions on the G5's implementation of altivec (could be that it requires vsx) . No such issue for bowtie1 under Leopard (recently published a Nat Commun paper for which I used my quad to align some ChIP-Seq data I had generated using a leopard-compiled version of bowtie when available computing resources were low as used for other projects, and I won't ever be thankful enough to my Quad
1. Feedback will be appreciated. Hopefully it is usable
2. This is not my field at all, I just wanted to make R in MacPorts more usable for other people with different interests. I have seen you mentioned Seurat earlier, and then one of existing ports added it as a required dependency, which prevented updating it. So eventually I added it too.
3. simde is broken at the moment, I think, though I need to review it. Ticket: https://trac.macports.org/ticket/66634
4. ppc64 is a pain, and the stopper is that ld64 does not work when built for ppc64, ironically. So we need some ugly hacks to use ppc linker for ppc64, but even that failed for me last few times I tried.
I would like to have it working, but since I do not really know what exactly causes failures, I have no idea how to fix that.
You strictly need ppc64?
If it is a single port that is needed, then you may have luck forcing usage of gcc10-bootstrap, which does build as ppc+ppc64. It will need to be done for every C++11-requiring dependency, as long as a regular gcc does not build for ppc64. Alternatively, you could build gcc outside of Macports, which should work on 10.5.8, and try using that.
You could ask bowtie2 upstream if there is an alternative solution which avoids simde. By default bowtie2 depends only on python311 and zlib, which would be rather easy to sort for ppc64. But simde, perhaps, even if hacked to build, will not be of a great utility.
Does it work? If yes, let’s fix it in MacPorts. I have no idea why it is restricted to 64-bit archs now.
UPD. This should fix bowtie v. 1: https://github.com/macports/macports-ports/pull/23894
Last edited:
On this note, given that you seem to be into bioinformatics too, did you by any chance ever get bowtie2 to compile under Leopard ppc64 and/or know if the bowtie2 macport could be modified to compile under ppc64? I had got close by modifying "arch" to ppc64 in my macports config but even by installing sidme via macports, compilation always fails - I don't know if simde will translate all sse2 instructions on the G5's implementation of altivec (could be that it requires vsx) . No such issue for bowtie1 under Leopard (recently published a Nat Commun paper for which I used my quad to align some ChIP-Seq data I had generated using a leopard-compiled version of bowtie when available computing resources were low as used for other projects, and I won't ever be thankful enough to my Quad
The wording seems to suggest that SIMD are optional in bowtie2: https://github.com/BenLangmead/bowtie2/commit/cad6a7ed8c18a5788445e7e56d5f7579a314ac74
If so, then just removing ppc/ppc64 from the macro should do. It will work slower than otherwise, but otherwise it is just broken LOL
I'm sorry for resurrecting this old thread, but I think I have some thoughts on the topic which you'll potentially find interesting.
First, however, I find myself in need of clearing up some things.
Thank you! This schematic is useful for the non-2005 G5s, but it is, as is always the case, from an iMac G5. The system block diagram displays the U3lite SoC, not U3. There's also an integrated GPU die on the diagram, which wouldn't have been the case for the Power Mac G5. There are two SATA connectors, but one of them is marked as 'development only'. And, crucially, the schematic has 'IMG5' written all over it in various places, including the name of the file. Wonder what that stands for.
(U3, as seen on the non-2005 Power Mac G5 board)
I've found an equivalent schematic for the 2005-style architecture iMac G5 here (although if anyone has an actual pdf version I would be very grateful if you linked it here, as the site it's on seems to only really allow zoom on mobile platforms and doesn't allow you to actually download the schematic), and it will no doubt reflect the internals of the Dual Core and the Quad Power Macs much better than the one linked earlier.
You can tell that the architecture is fundamentally similar to the architecture of the Late 2005 Power Mac G5 because it has the giant 'KODIAK' label across the northbridge chip in the block diagram, and not 'U3lite'. Kodiak is, in fact, the codename for the U4/CPC945 IBM chip used in the last Power Mac G5 models. And I know this because I removed a Power Mac G5 logic board from its case, detached all of the heatsinks, and found an IBM-produced package with a clear 'KODIAK' label under the largest of the heatsinks on the back of the board:
(You can see the faint 'KODIAK' lettering along the right side on the bottom, which is kinda brighter in person)
(The post in question includes the datasheet and the user manual for the 970MP processor)
This does indeed help. Thank you!
Well, yes, but actually no, except yes. Let me explain.
First things first, if you look at the system block diagram for the 2005 iMac G5, which I conveniently hung up on the metaphorical wall of our investigation all Chekhov's-gun-like about a minute ago, HyperTransport has little to nothing to do with processor speed or even processors themselves. It simply connects the Kodiak/U4 chip with the Shasta chip, or the U3 chip with the same Shasta chip, on the older non-2005-style iMacs and PowerMacs. The Shasta chip is responsible for most of the IO, including SATA and the BootRom, which is chillin' on Shasta's little dedicated PCI bus, along with some other stuff and the AirPort card, if you have it.
(Shasta, with its heatsink and with the heatsink removed, on Late 2005 and non-2005 Power Mac G5 boards, respectively; NOTE: it's on the back side of the board in both versions, and is the only chip on the back of the board with that kind of heatsink)
"BootRom!?" you might exclaim. "But that's where the firmware sits! It must be responsible for setting clocks and stuff!" you might add.
I believe that that is, in fact, not the case.
Attached below is the 'IBM PowerPC 970MP Power On Reset Application Note', which goes into the entirety of the power-on sequence in excrutiating detail. If you scroll to page 15 of the aforementioned note, you will see an overview drawing of the Kodiak and 970MP initialization sequence, which I duplicate here for your convenience:
Initialization is started and managed by a dark and mysterious entity which the note calls the 'SPU'. You might already suspect what this is all about, if you concentrate on the letters 'SPU', activate your innate pattern recognition abilities and let repressed memories enter your mind.
If you scroll back to the first section of the application note and read some more, you'll gain confirmation: the entirety of the system is initialized by a so-called 'service processor unit', or the SPU. Which, in the words of the note, is usually a low-cost microcontroller, which may also be responsible for some other functions, like fans (which I feel like a terrible writer by explicitly saying that this will be relevant later):
The only question is, where is this microcontroller on the G5? The iMac G5 schematic doesn't contain anything called an 'SPU'. But what it does contain, is something called the 'system management unit' or the SMU.
Yes, yes, yes. That magic thing you've been resetting with the 'SMU reset' button? Well, turns out it isn't magic after all.
If you find the thing on the 2005 iMac G5 schematic, it's labeled 'M30280F8', which is indeed a low-cost 16-bit microcontroller seemingly made by Renesas Electronics. Same for the non-2005 iMac G5. The power button and the power LED are connected to it, and it is connected to Kodiak/U4 in turn using I2C. Moreover, it seems to have lots of fans connected to it. Wonder what this is all about...
In my eye, if it walks like an SPU, manages fans like an SPU, and talks to Kodiak like an SPU, it is an SPU.
The non-2005 Power Mac G5 board that I have seems to be using an M3062MF8NGP IC as its SMU- sorry, I mean, PMU, of course. Non-2005 Power Macs have a different terminology. It's sitting on the back of the board, next to U3 and below Shasta, close to the edge of the board. It also has a pill-shaped oscillator right next to it, which is seemingly the only oscillator on the board.
(seems to be the SMU on non-2005 Power Macs)
The 2005 Power Mac G5 board that I have seems to be using an IC labeled 'M30280FAHP' as its SMU. It's roughly in the same place, but on the front side of the board rather than on the back, and has been moved upwards seemingly to make space for the bus bar connector thingamajigs Apple used in the 2005 Power Macs. It even has the same component designator as it does on the iMac G5 schematic, 'U2800' (which my marketing departmen tells me is at least 930 times better of a name than U3). Keep this designator in mind, because it will be relevant later.
(seems to be the SMU on Late 2005 Power Macs)
Now, why am I talking about the SPU? Weren't we supposed to be overclocking the G5? This is interesting and all, but what does any of this have to do with overclocking?
Well...
The CPC945 user manual contains a fair bit of references to the SPU in the "System Initialization Sequence" section, and it even has kind of the same-ish initialization sequence diagram as the note. But most interesting of all, it contains some info about processor speeds:
Well well well... So the SPU/SMU seems to be somewhat in control of processor speed, at least during initialization. Because PLL1 is all about processor interconnect (also known as PI, advanced processor interconnect/API, elastic interface/EI, or simply backside bus) interface speed, which is a ratio of processor speed. Take a look at this section of the CPC945 user manual:
Well, ladies, gentlemen, and all in between, we seem to have found the 'bus slewing' thing. I always wondered how they did that. This whole table seems weird in terms of numbers, however. It seems like they would be changing CPU-to-Bus ratio by setting the PLL1 Control Register, but then it seemingly doesn't do anything, unless you're also changing the reference clock, but then also what's the point of it all, really?
Philosophical questions aside, though, it seems that processor interconnect reference clock is what really sets the processor speed.
"Then why the whole SPU-related detour?" you might be wondering calmly at this point.
Well...
Let's look at the datasheet (not the user manual this time) for CPC945, which is attached below. In section 3.5 'Clocks', it says that the processor interface reference clock is called 'PI_REFCLK' in the real world of schematics.
If we now go to the 2005 iMac G5 schematic and look up 'PI_REFCLK', we find four matches, all on the page titled 'KODIAK EI A', where 'EI' obviously stands for 'elastic interface', which is the same as 'processor interface' as discussed before. The pins in question are called 'API_REFCLK_P', 'API_REFCLK_N', 'API_REFCLK_AVDD' and 'API_REFCLK_AGND', where 'API' presumably means 'advanced processor interconnect', which is yet another name for the advanced elastic processor interface interconnect, because of course it is.
While ...VDD is obviously power and ...GND is obviously ground (duh), API_REFCLK_P and API_REFCLK_N are actual signal pins which we were looking for. They're connected to singals called 'EI_NB_SYSCLK_P' and 'EI_NB_SYSCLK_N', respectively, which are generated directly by an IC with a 'U2500' component designator. That is to say, two of U2500's pins (HCLKP_2 and HCLKN_2, respectively) are connected directly to Kodiak and nothing else (except test points), and all of this is called 'EI_NB_SYSCLK_P' and 'EI_NB_SYSCLK_N', respectively.
Unlike pretty much all other components, the U2500 doesn't seem to have a regular part number label above it. It does have a part number label, but the label reads 'PULSAR2'. I belive this is an in-house name for an Apple-specific IC, much like 'Shasta'. I'm gonna give it to Apple, calling an IC that generates regular electric pulses 'Pulsar'... I must say, we had no chance of knowing what it does, until we looked through all the datasheets. Why is it specifically the second version? Well, that's because the non-2005 iMacs (and probably Power Macs) have a completely different 'U2600' IC, called 'Pulsar'. I'm yet to figure out what this one does, but I think it might have something to do with pulses.
The Pulsar 2 IC itself is hard to locate on the board because I don't know the actual part number, but I think it's the Apple-branded one between the CPU sockets under the black plastic sheet, at least on the 2005 Power Macs.
Remember I said about *checks watch* ten minutes ago that the SMU being 'U2800' on the iMac G5 schematic will be relevant later? Well, time has passed, and now later is now. Because the chip that I suspected of being an SMU on the Late 2005 Power Mac G5, was also labeled 'U2800' on the actual Power Mac G5 board. Which means that, at least between the Power Mac G5 and iMac G5, component designators seem to match to some extent. And the Apple-branded IC between the CPU sockets? U2500, just like the iMac G5 schematic.
(The Apple-branded IC, which I think is the Pulsar 2 IC; the circuit seems similar-ish to iMac G5 schematic)
All of this is important for one reason and one reason only: there seem to be no strap resistors next to it, neither on the Power Mac G5 board, nor in the iMac G5 schematic.
But not all hope is lost yet.
Now, the Pulsar 2 IC seems to be in charge of generating virtually all of the clocks for the system, except, I assume, for the SMU clock. But apart from the myriads of clock signal output pins, it has two pins that are of great interest to us. SCLK and SDATA, which are the two pins that might allow us to control the Pulsar 2 IC, and thus set PI reference clocks. But where do they lead? What's connected to them? Who's been pulling the strings behind the curtain this entire t-
It's the SPU.
It's always the SPU.
SCLK of Pulsar 2 is conencted to 'I2C_CLOCK_B_SCL', SDATA is connected to 'I2C_CLOCK_B_SDA', and these are both connected to SMU I2C 'B' bus, on which the SMU is the master.
And all of this is well and good, but what do we do now? I mean, it would obviously be extremely hard to gain access to the SMU. You'd probably need to solder tiny wires to the pins of the microcontroller just to gain any access to it. I mean... It's not like the SMU would just conveniently support communicating over UART... And surely, surely there would be no convenient debug connector right there on the board, that's been there this entire time, labeled 'SMU' right on the board and called J2904 in the 2005 iMac G5 schematic and J2900 on the Late 2005 Power Mac G5 board?
I mean, we can check...
Fingers crossed......
HOLY **** IT'S ****ING THERE
I haven't yet attempted to connect to the SMU via UART. Partly because the connector is different and I don't know the pinout. There's a procedure for distinguishing UART pins when you know that something's UART, but I haven't ever done that, and I'd like to make sure I know the theory first. But also partly because this is probably just the beggining, not the end:
There's also the problem of the non-2005 Power Mac G5, which does not, in fact, have a convenient connector like the Late 2005 Power Mac G5. I can see no 'SMU' label anywhere on the board.
Although the non-2005 G5 board might simply not have it soldered on or labeled. There are holes for a 20-pin header next to the IO. There are pads for what I assume is an FPC-style connector next to the big ATX-style power connector on the bottom of the board. And most interestingly, there are also pads like that next to the what seems to be the SMU itself, labeled 'J7'.
All in all, here's the main takeaway: it doesn't seem to me like OpenFirmware has anything to do with processor speed. It might do bus slewing or something, but it doesn't set reference clocks, which instead seem to be set by the SMU/PMU using the Apple-specific 'Pulsar' family chips.
It may be the case that OpenFirmware can set the desired processor frequency after the fact. But this design option seems kinda dumb compared to just flashing it into the SMU. You'd seemingly have to bring up the whole system just to know your clocks when you absolutely don't have to do it that way. It's far easier and far more sane to keep system-specific stuff in the SMU, and then OpenFirmware is just the same for all models in a given year/period.
And with that, my work is done here.
Shasta la vesta, kodiak
(I've been keeping this joke in this whole time, I earned it)
First, however, I find myself in need of clearing up some things.
Datasheets and Misconceptions
Thank you! This schematic is useful for the non-2005 G5s, but it is, as is always the case, from an iMac G5. The system block diagram displays the U3lite SoC, not U3. There's also an integrated GPU die on the diagram, which wouldn't have been the case for the Power Mac G5. There are two SATA connectors, but one of them is marked as 'development only'. And, crucially, the schematic has 'IMG5' written all over it in various places, including the name of the file. Wonder what that stands for.
(U3, as seen on the non-2005 Power Mac G5 board)
I've found an equivalent schematic for the 2005-style architecture iMac G5 here (although if anyone has an actual pdf version I would be very grateful if you linked it here, as the site it's on seems to only really allow zoom on mobile platforms and doesn't allow you to actually download the schematic), and it will no doubt reflect the internals of the Dual Core and the Quad Power Macs much better than the one linked earlier.
You can tell that the architecture is fundamentally similar to the architecture of the Late 2005 Power Mac G5 because it has the giant 'KODIAK' label across the northbridge chip in the block diagram, and not 'U3lite'. Kodiak is, in fact, the codename for the U4/CPC945 IBM chip used in the last Power Mac G5 models. And I know this because I removed a Power Mac G5 logic board from its case, detached all of the heatsinks, and found an IBM-produced package with a clear 'KODIAK' label under the largest of the heatsinks on the back of the board:
(You can see the faint 'KODIAK' lettering along the right side on the bottom, which is kinda brighter in person)
(The post in question includes the datasheet and the user manual for the 970MP processor)
This does indeed help. Thank you!
Well, yes, but actually no, except yes. Let me explain.
The SPU, PLL1 and bus slewing
First things first, if you look at the system block diagram for the 2005 iMac G5, which I conveniently hung up on the metaphorical wall of our investigation all Chekhov's-gun-like about a minute ago, HyperTransport has little to nothing to do with processor speed or even processors themselves. It simply connects the Kodiak/U4 chip with the Shasta chip, or the U3 chip with the same Shasta chip, on the older non-2005-style iMacs and PowerMacs. The Shasta chip is responsible for most of the IO, including SATA and the BootRom, which is chillin' on Shasta's little dedicated PCI bus, along with some other stuff and the AirPort card, if you have it.
(Shasta, with its heatsink and with the heatsink removed, on Late 2005 and non-2005 Power Mac G5 boards, respectively; NOTE: it's on the back side of the board in both versions, and is the only chip on the back of the board with that kind of heatsink)
"BootRom!?" you might exclaim. "But that's where the firmware sits! It must be responsible for setting clocks and stuff!" you might add.
I believe that that is, in fact, not the case.
Attached below is the 'IBM PowerPC 970MP Power On Reset Application Note', which goes into the entirety of the power-on sequence in excrutiating detail. If you scroll to page 15 of the aforementioned note, you will see an overview drawing of the Kodiak and 970MP initialization sequence, which I duplicate here for your convenience:
Initialization is started and managed by a dark and mysterious entity which the note calls the 'SPU'. You might already suspect what this is all about, if you concentrate on the letters 'SPU', activate your innate pattern recognition abilities and let repressed memories enter your mind.
If you scroll back to the first section of the application note and read some more, you'll gain confirmation: the entirety of the system is initialized by a so-called 'service processor unit', or the SPU. Which, in the words of the note, is usually a low-cost microcontroller, which may also be responsible for some other functions, like fans (which I feel like a terrible writer by explicitly saying that this will be relevant later):
The only question is, where is this microcontroller on the G5? The iMac G5 schematic doesn't contain anything called an 'SPU'. But what it does contain, is something called the 'system management unit' or the SMU.
Yes, yes, yes. That magic thing you've been resetting with the 'SMU reset' button? Well, turns out it isn't magic after all.
If you find the thing on the 2005 iMac G5 schematic, it's labeled 'M30280F8', which is indeed a low-cost 16-bit microcontroller seemingly made by Renesas Electronics. Same for the non-2005 iMac G5. The power button and the power LED are connected to it, and it is connected to Kodiak/U4 in turn using I2C. Moreover, it seems to have lots of fans connected to it. Wonder what this is all about...
In my eye, if it walks like an SPU, manages fans like an SPU, and talks to Kodiak like an SPU, it is an SPU.
The non-2005 Power Mac G5 board that I have seems to be using an M3062MF8NGP IC as its SMU- sorry, I mean, PMU, of course. Non-2005 Power Macs have a different terminology. It's sitting on the back of the board, next to U3 and below Shasta, close to the edge of the board. It also has a pill-shaped oscillator right next to it, which is seemingly the only oscillator on the board.
(seems to be the SMU on non-2005 Power Macs)
The 2005 Power Mac G5 board that I have seems to be using an IC labeled 'M30280FAHP' as its SMU. It's roughly in the same place, but on the front side of the board rather than on the back, and has been moved upwards seemingly to make space for the bus bar connector thingamajigs Apple used in the 2005 Power Macs. It even has the same component designator as it does on the iMac G5 schematic, 'U2800' (which my marketing departmen tells me is at least 930 times better of a name than U3). Keep this designator in mind, because it will be relevant later.
(seems to be the SMU on Late 2005 Power Macs)
Now, why am I talking about the SPU? Weren't we supposed to be overclocking the G5? This is interesting and all, but what does any of this have to do with overclocking?
Well...
The CPC945 user manual contains a fair bit of references to the SPU in the "System Initialization Sequence" section, and it even has kind of the same-ish initialization sequence diagram as the note. But most interesting of all, it contains some info about processor speeds:
Well well well... So the SPU/SMU seems to be somewhat in control of processor speed, at least during initialization. Because PLL1 is all about processor interconnect (also known as PI, advanced processor interconnect/API, elastic interface/EI, or simply backside bus) interface speed, which is a ratio of processor speed. Take a look at this section of the CPC945 user manual:
12.5.6 PLL1 Control Register
The PLL1 Control Register configures the PI PLL. It is set at reset to support a CPU running a 3:1 ratio between its core clock and the PI bit rate. The CPU core runs between 2400 MHz and 2664 MHz. The PLL1 Control Register is reloaded during processor reset by the SPU. Its value is initialized at that point to reflect the proper configuration for the CPUs attached to CPC945. <...>
When performing dynamic speed control of the processors, it might be necessary for system software to change the configuration of PLL1. This procedure guarantees a stable PLL1 transition:
1. Software naps or sleeps all but one processor.
2. The last processor loads a new value into PLL1Control, clearing PLLLoaded.
<...>
5. The last processor naps.
<...>
8. CPC945 sees the PI clocks stopped and EnablePLL1Shutdown set, so it stops PLL1 and loads the new configuration from PLL1Control.
<...>
11. When PLL1 is re-locked, CPC945 restarts clocks to the PI interface.
<...>
14. Last processor wakes other processors, if desired.
The values which go into the PLL1 Control Register depend upon the speed of the PI interface and the ratio between the reference clock input and the PI interface. The range of frequencies available for different processor and PI bus ratios are shown in Table 12-5 PLL1 Clock Settings. Table 12-5 documents the PLL settings for CPUs running between 600 MHz and 2700 MHz at all three ratios: 2:1, 3:1, and 4:1.
Table 12-5. PLL1 Clock Settings.
Well, ladies, gentlemen, and all in between, we seem to have found the 'bus slewing' thing. I always wondered how they did that. This whole table seems weird in terms of numbers, however. It seems like they would be changing CPU-to-Bus ratio by setting the PLL1 Control Register, but then it seemingly doesn't do anything, unless you're also changing the reference clock, but then also what's the point of it all, really?
Philosophical questions aside, though, it seems that processor interconnect reference clock is what really sets the processor speed.
"Then why the whole SPU-related detour?" you might be wondering calmly at this point.
Well...
The SPU Again, Pulsars and Headers
Let's look at the datasheet (not the user manual this time) for CPC945, which is attached below. In section 3.5 'Clocks', it says that the processor interface reference clock is called 'PI_REFCLK' in the real world of schematics.
If we now go to the 2005 iMac G5 schematic and look up 'PI_REFCLK', we find four matches, all on the page titled 'KODIAK EI A', where 'EI' obviously stands for 'elastic interface', which is the same as 'processor interface' as discussed before. The pins in question are called 'API_REFCLK_P', 'API_REFCLK_N', 'API_REFCLK_AVDD' and 'API_REFCLK_AGND', where 'API' presumably means 'advanced processor interconnect', which is yet another name for the advanced elastic processor interface interconnect, because of course it is.
While ...VDD is obviously power and ...GND is obviously ground (duh), API_REFCLK_P and API_REFCLK_N are actual signal pins which we were looking for. They're connected to singals called 'EI_NB_SYSCLK_P' and 'EI_NB_SYSCLK_N', respectively, which are generated directly by an IC with a 'U2500' component designator. That is to say, two of U2500's pins (HCLKP_2 and HCLKN_2, respectively) are connected directly to Kodiak and nothing else (except test points), and all of this is called 'EI_NB_SYSCLK_P' and 'EI_NB_SYSCLK_N', respectively.
Unlike pretty much all other components, the U2500 doesn't seem to have a regular part number label above it. It does have a part number label, but the label reads 'PULSAR2'. I belive this is an in-house name for an Apple-specific IC, much like 'Shasta'. I'm gonna give it to Apple, calling an IC that generates regular electric pulses 'Pulsar'... I must say, we had no chance of knowing what it does, until we looked through all the datasheets. Why is it specifically the second version? Well, that's because the non-2005 iMacs (and probably Power Macs) have a completely different 'U2600' IC, called 'Pulsar'. I'm yet to figure out what this one does, but I think it might have something to do with pulses.
The Pulsar 2 IC itself is hard to locate on the board because I don't know the actual part number, but I think it's the Apple-branded one between the CPU sockets under the black plastic sheet, at least on the 2005 Power Macs.
Remember I said about *checks watch* ten minutes ago that the SMU being 'U2800' on the iMac G5 schematic will be relevant later? Well, time has passed, and now later is now. Because the chip that I suspected of being an SMU on the Late 2005 Power Mac G5, was also labeled 'U2800' on the actual Power Mac G5 board. Which means that, at least between the Power Mac G5 and iMac G5, component designators seem to match to some extent. And the Apple-branded IC between the CPU sockets? U2500, just like the iMac G5 schematic.
(The Apple-branded IC, which I think is the Pulsar 2 IC; the circuit seems similar-ish to iMac G5 schematic)
All of this is important for one reason and one reason only: there seem to be no strap resistors next to it, neither on the Power Mac G5 board, nor in the iMac G5 schematic.
But not all hope is lost yet.
Now, the Pulsar 2 IC seems to be in charge of generating virtually all of the clocks for the system, except, I assume, for the SMU clock. But apart from the myriads of clock signal output pins, it has two pins that are of great interest to us. SCLK and SDATA, which are the two pins that might allow us to control the Pulsar 2 IC, and thus set PI reference clocks. But where do they lead? What's connected to them? Who's been pulling the strings behind the curtain this entire t-
It's the SPU.
It's always the SPU.
SCLK of Pulsar 2 is conencted to 'I2C_CLOCK_B_SCL', SDATA is connected to 'I2C_CLOCK_B_SDA', and these are both connected to SMU I2C 'B' bus, on which the SMU is the master.
And all of this is well and good, but what do we do now? I mean, it would obviously be extremely hard to gain access to the SMU. You'd probably need to solder tiny wires to the pins of the microcontroller just to gain any access to it. I mean... It's not like the SMU would just conveniently support communicating over UART... And surely, surely there would be no convenient debug connector right there on the board, that's been there this entire time, labeled 'SMU' right on the board and called J2904 in the 2005 iMac G5 schematic and J2900 on the Late 2005 Power Mac G5 board?
I mean, we can check...
Fingers crossed......
HOLY **** IT'S ****ING THERE
Not Out of the Woods Yet
I haven't yet attempted to connect to the SMU via UART. Partly because the connector is different and I don't know the pinout. There's a procedure for distinguishing UART pins when you know that something's UART, but I haven't ever done that, and I'd like to make sure I know the theory first. But also partly because this is probably just the beggining, not the end:
- I'm not sure the thing will talk to me in plain English, so protocol reverse engineering might be in order.
- These microcontrollers apparently have some sort of flash protection, so I might need to brute-force that in order to access anything, and god knows how long that will take.
- Even assuming I can access the flash, right now I've no clue what to do with the resulting binary file, except try and find patterns and checksums, and hope something works.
There's also the problem of the non-2005 Power Mac G5, which does not, in fact, have a convenient connector like the Late 2005 Power Mac G5. I can see no 'SMU' label anywhere on the board.
Although the non-2005 G5 board might simply not have it soldered on or labeled. There are holes for a 20-pin header next to the IO. There are pads for what I assume is an FPC-style connector next to the big ATX-style power connector on the bottom of the board. And most interestingly, there are also pads like that next to the what seems to be the SMU itself, labeled 'J7'.
All in all, here's the main takeaway: it doesn't seem to me like OpenFirmware has anything to do with processor speed. It might do bus slewing or something, but it doesn't set reference clocks, which instead seem to be set by the SMU/PMU using the Apple-specific 'Pulsar' family chips.
It may be the case that OpenFirmware can set the desired processor frequency after the fact. But this design option seems kinda dumb compared to just flashing it into the SMU. You'd seemingly have to bring up the whole system just to know your clocks when you absolutely don't have to do it that way. It's far easier and far more sane to keep system-specific stuff in the SMU, and then OpenFirmware is just the same for all models in a given year/period.
And with that, my work is done here.
Shasta la vesta, kodiak
(I've been keeping this joke in this whole time, I earned it)
Last edited:
Oh, also also actually actually, I have unwittingly concealed crucial guesstimations when I was writing the post, 'cause it was late at night. I felt like I was forgetting something, and here I am, making an addition.
I think the right way to go about this might be by studying with great care the contents of the Apple Service Diagnostic CDs. I'm not sure, though.
My guess is that the fan calibration data is stored on the SMU. It would make sense, not only because the SMU is the thing which is actually controlling the fans, but also because it sort of needs to know all of this data all of the time, preferably even before POST. (Desoldering the OF flash from the board and giving the startup button a go would be one way to prove/disprove this. There's always a chance the system won't work after that, though)
My second guess, which is even more unfounded, is that the SMU ROM gets partially rewritten by the ASD during fan calibration.
I think this guess has a 50/50 chance of being correct.
On the one hand, the proper way to go about this would be to have the SMU user-space code flash the ROM, not the ASD. This would entail ASD contacting the SMU, possibly identifying itself with a separate ID code, and then passing calibration data, so that the SMU could write the calibration data to itself and send back an 'OK' status. This way, the actual ID code for the flash doesn't have to be embedded into the ASD.
However, this is also the non-lazy way. For 2005... I wouldn't be surprised if they went the lazy way instead, said "You know what, screw it, the ASD will only be available to AASPs, and they're both (1) not smart enough to reverse engineer it and (2) are contractually obligated not to", and just effectively granted the ASD complete access to the SMU.
These are just my speculations, though. But I'd still give them, like, at least a 25% chance of being true. Which, coincidentally, is bigger than the chance of brute-forcing the 7-byte flash protection id code during any of our lifetimes. I mean, unless it's just ASCII for "AAPL$$$" or something like that.
I think the right way to go about this might be by studying with great care the contents of the Apple Service Diagnostic CDs. I'm not sure, though.
My guess is that the fan calibration data is stored on the SMU. It would make sense, not only because the SMU is the thing which is actually controlling the fans, but also because it sort of needs to know all of this data all of the time, preferably even before POST. (Desoldering the OF flash from the board and giving the startup button a go would be one way to prove/disprove this. There's always a chance the system won't work after that, though)
My second guess, which is even more unfounded, is that the SMU ROM gets partially rewritten by the ASD during fan calibration.
I think this guess has a 50/50 chance of being correct.
On the one hand, the proper way to go about this would be to have the SMU user-space code flash the ROM, not the ASD. This would entail ASD contacting the SMU, possibly identifying itself with a separate ID code, and then passing calibration data, so that the SMU could write the calibration data to itself and send back an 'OK' status. This way, the actual ID code for the flash doesn't have to be embedded into the ASD.
However, this is also the non-lazy way. For 2005... I wouldn't be surprised if they went the lazy way instead, said "You know what, screw it, the ASD will only be available to AASPs, and they're both (1) not smart enough to reverse engineer it and (2) are contractually obligated not to", and just effectively granted the ASD complete access to the SMU.
These are just my speculations, though. But I'd still give them, like, at least a 25% chance of being true. Which, coincidentally, is bigger than the chance of brute-forcing the 7-byte flash protection id code during any of our lifetimes. I mean, unless it's just ASCII for "AAPL$$$" or something like that.
Last edited:
Also the fact that past this point the Intel transition was announced and then apparently Apple is shipping two *very* substantial updates to their existing product lines (the DLSD PBG4s and what I'm gonna dub as the Kodiak G5s)... these were probably rushed products to some extent and considering they would not be expanded upon I would not be surprised that the engineers and quality assurance people put in minimal effort to wrap stuff up and gave the green light to free up resources for the iMac Intel and Mac Pro. The iMac Intel shipping literally 3 months after the 2005 iMac says a lot to me about how these last few PPC products may have been treated internally.
Out with the old, in with the new, and in with the dumb speculation from me too lol. Amazing work by the way.
Thanks!
And yeah, 'Kodiak G5s' definitely sounds much better than 'Late 2005 blah blah blah this is past my attention span already', lol.
Also, thanks for the weigh-in on the laziness speculation. Kodiak being designed by IBM, I think, is also kind of indicative of how little Apple cared by that point.
By the way, the funny thing about all the speculations is... I don't know if the flash is even protected. I mean, I'm assuming it is, and I'd give it a solid 99% chance. But there's also technically a chance it just isn't, which would make everything much easier.
And yeah, 'Kodiak G5s' definitely sounds much better than 'Late 2005 blah blah blah this is past my attention span already', lol.
Also, thanks for the weigh-in on the laziness speculation. Kodiak being designed by IBM, I think, is also kind of indicative of how little Apple cared by that point.
By the way, the funny thing about all the speculations is... I don't know if the flash is even protected. I mean, I'm assuming it is, and I'd give it a solid 99% chance. But there's also technically a chance it just isn't, which would make everything much easier.
I don't think I wanna risk my Quad to find out lmfao. It has become my baby. But there are quite a few of these Kodiak G5s out there to futz around with. The iMacs are rarer but no one is really looking to overclock those. It's these Dual Core G5s that people wanna see pushed to their absolute limits. Couple this progress with @mac57mac57 's recent efforts to help people update the cooling in their Quads and DCs, we could legitimately be seeing 3.0GHz G5's in a couple years. Who knows?
Some machines will need to be sacrificed to get there and then once this is shown to be possible some cooling upgrade kits will likely need to be made.
So funny though that this 10-pin header is something I have looked at a lot during upgrading my GPU and putting in other cards into the machine and I just never really bothered to think "well what's it for?" It seems totally innocuous and maybe some jumper is supposed to go there but you don't pay it mind.
Yeah, no, doing something on a working Quad is definitely out of the question. A non-working Dual Core is what would be preferrable for initial experiments.
And yeah, the SMU connector is certainly well-camouflaged, lol. I didn't even know it existed before I looked through the datasheets, and I've been spending way more time than I should be looking at PMG5 boards as of late, lol.
I wouldn't bet on 3 GHz, though. It'd certainly be fun, lol. "Fine, I'll do it myself", 22 years after Apple announced they'd hit 3 GHz on PowerPC 'within 12 months'.
But like, realistically... You'll probably have to use, like, two external AIOs with liquid metal for thermal paste, along with an external power supply. And those air cooling mod heatsinks? They'll come in handy for barely keeping the VRMs cool.
It might be possible with some of that bus slewing wizardry and SMU reflashing, to make the processors run at 3 GHz, for, like, 10 cycles at a time and then downclock themselves to dissipate the heat, which would be a fun experiment. But to run them like that... It wouldn't be an overclock, it would be an "underclock, except the processor does russian roulette every once in a while".
Or it might also be possible with some heavy modifications. I'm talking redesigning processor daughter cards and putting VRMs on their own little cards with edge connectors, so that they can sit perpendicular to the daughtercards and have heatsinks attached to them which get cooled by the original fans. Then probably designing an entirely new power supply, which would probably require some GaN magic (or just keeping the fans at max level all of the time, lol). And then, as a cherry on top, yes, liquid metal and external AIOs. If that doesn't cut it, up it to a refrigeration cycle based chiller thing, then to liquid nitrogen.
Thing is, the power consumption usually spikes near-exponentially when you surpass the design frequency limit. And besudes, architectures usually just have a frequency you just can't go past, even if you can cool the CPU. Whether it's due to hotspots or some other effects, idk. But I believe that's the case. Correct me if I'm wrong, though.
I can see 2.7 maybe being reasonably possible, though, on some lucky daughtercards and probably after solving a few non-trivial problems, but possible nonetheless.
I'll be honest, though, as fun as overclocking is, it'd probably be more reasonable to mod the SPU ROM slightly, just to allow easily changing the speed of the system between 2.0, 2.3 and 2.5 GHz, effective next boot. This way, you would be able to run an underclock by default, but then reboot into high performance mode on demand, and thus prolong the lives of the few remaining Quads.
And yeah, the SMU connector is certainly well-camouflaged, lol. I didn't even know it existed before I looked through the datasheets, and I've been spending way more time than I should be looking at PMG5 boards as of late, lol.
I wouldn't bet on 3 GHz, though. It'd certainly be fun, lol. "Fine, I'll do it myself", 22 years after Apple announced they'd hit 3 GHz on PowerPC 'within 12 months'.
But like, realistically... You'll probably have to use, like, two external AIOs with liquid metal for thermal paste, along with an external power supply. And those air cooling mod heatsinks? They'll come in handy for barely keeping the VRMs cool.
It might be possible with some of that bus slewing wizardry and SMU reflashing, to make the processors run at 3 GHz, for, like, 10 cycles at a time and then downclock themselves to dissipate the heat, which would be a fun experiment. But to run them like that... It wouldn't be an overclock, it would be an "underclock, except the processor does russian roulette every once in a while".
Or it might also be possible with some heavy modifications. I'm talking redesigning processor daughter cards and putting VRMs on their own little cards with edge connectors, so that they can sit perpendicular to the daughtercards and have heatsinks attached to them which get cooled by the original fans. Then probably designing an entirely new power supply, which would probably require some GaN magic (or just keeping the fans at max level all of the time, lol). And then, as a cherry on top, yes, liquid metal and external AIOs. If that doesn't cut it, up it to a refrigeration cycle based chiller thing, then to liquid nitrogen.
Thing is, the power consumption usually spikes near-exponentially when you surpass the design frequency limit. And besudes, architectures usually just have a frequency you just can't go past, even if you can cool the CPU. Whether it's due to hotspots or some other effects, idk. But I believe that's the case. Correct me if I'm wrong, though.
I can see 2.7 maybe being reasonably possible, though, on some lucky daughtercards and probably after solving a few non-trivial problems, but possible nonetheless.
I'll be honest, though, as fun as overclocking is, it'd probably be more reasonable to mod the SPU ROM slightly, just to allow easily changing the speed of the system between 2.0, 2.3 and 2.5 GHz, effective next boot. This way, you would be able to run an underclock by default, but then reboot into high performance mode on demand, and thus prolong the lives of the few remaining Quads.