Sorry to dig up a dead thread, but I put together a pic from the intel datasheets for socket M/P pinmodding. Haven't tried it yet; anyone willing to give it a shot?
EDIT: I did not make a pic for voltage modding: it's generally undesirable.
VID is determined by the formula:
1.500V - VID0*0.0125 - VID1*0.025 - VID2*0.05 - VID3*0.1 - VID4*0.2 - VID5*0.4 - VID6*0.8
If we set any of them, we'll throw out half of the voltage possibilities. This is demonstrated by a voltage selection range with "holes" where the VID change is masked by the pinmod. For mobile CPUs we like to have full VID control since battery life suffers without it; most XSers will not be messing with anything less significant than VID4. But that also limits our modding range by whatever VIDx's multiplier is.
For example: to get a better overclock, we'll take a 1.2375V CPU and set VID4 to zero. Now we'll have up to 1.4375V to play with, but we lose all voltage settings between 1.3000V and 1.1125V (inclusive) [as well as others that we can't set at runtime]. We won't be able to choose VIDs optimally for the multipliers between maximum and minimum anymore; this will have a negative impact on battery life. Also, I'm pretty sure Deeper Sleep and C4E both use even lower VIDs, hence the range of VIDs from 1.5V to 0V. If the VID for either of these idle states is affected by the modified VIDs, (for the case of overvolting) battery life will suffer considerably, or (for the case of undervolting) the CPU may crash as it tries to enter an "apparent VID" that is too low.
EDIT: Added VID spreadsheet.
I looked into the 6x multiplier issue. I suspect the Intel *chipsets* are responsible for the "anti-overclocking protection" (http://www.freepatentsonline.com/6535988.html): one person who has pin modded their yonah/merom successfully without the 6x multiplier lock used an AMD/ATI 200M chipset, not an intel chipset. To overcome this lock, the reference clock for the chipset will probably have to be replaced, or overclocking must be done after booting the operating system (ie. Clockgen or SetFSB fashion). The second option is probably not as bad as it sounds. Since Santa Rosa platforms have Dynamic FSB Frequency Switching, the FSB clock generator on the motherboards should be safely programmable on-the-fly and independent of the PCI/PCIe buses. The only problem, then, is writing the software to interface to the clock generator.
Continuing edit:
Edited VID spreadsheet again; wasn't clear how to use it correctly. Linked from CPU Rightmark folks.
Reply With Quote
Bookmarks