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