Intel Speedstep under DOS?
Intel Speedstep under DOS?
Can anyone explain how to change CPU multipliers and VIDs on a processor with Speedstep? Obviously there are several programs around for doing it under Windows but I haven`t seen any for DOS. I guess it involves tinkering with MSRs but I don`t know where to find the details. I checked the Pentium M datasheets but the programming side of things was not covered.
Re: Intel Speedstep under DOS?
Maybe some ASM / FASM / Hardware / Intel forum would be more productive :-)DamageX wrote:Can anyone explain how to change CPU multipliers and VIDs on a processor with Speedstep?
MSR's are a privileged resource, you will need a Ring0 DPMI host.guess it involves tinkering with MSRs but I don`t know where to find the details.
Better datasheets or better forum (or disassemble / debug the thing for "Windows" ...).checked the Pentium M datasheets but the programming side of things was not covered.
CPU clock speeds are simple. Every processor has a base run speed, and the active clock is afunction of the multipliers that it accepts.
For example. If you have a 1.00 GHz CPU. It can be clocked there, by several ways. 500 MHz x 2, 333 MHz x 3, 250 MHz x 4 or 1 GHz x 1.
Every processor is unique. The general rule, seems to be that the given processor family, has similarities. The only exceptions to this, are fro some custom Mobile, Chipset, GPU or Beta model processors.
As their specs and needs vary widely. The processor is affected, by memory timing, system bus clock clock speed, FSB clock speed and the I/O bus timings.
One of the things many people don't realize is that Windows does a great deal of system management for you. And those who don't program don't know this.
So, it's easy to get mislead or fooled...
For example. If you have a 1.00 GHz CPU. It can be clocked there, by several ways. 500 MHz x 2, 333 MHz x 3, 250 MHz x 4 or 1 GHz x 1.
Every processor is unique. The general rule, seems to be that the given processor family, has similarities. The only exceptions to this, are fro some custom Mobile, Chipset, GPU or Beta model processors.
As their specs and needs vary widely. The processor is affected, by memory timing, system bus clock clock speed, FSB clock speed and the I/O bus timings.
One of the things many people don't realize is that Windows does a great deal of system management for you. And those who don't program don't know this.
So, it's easy to get mislead or fooled...
Re: Intel Speedstep under DOS?
I finally stumbled across the answer to this question.
Set bit 16 of MSR $1A0 to enable speedstep
Read MSR $198 for status
bits 43~40 maximum FID (multiplier)
bits 37~32 maximum VID (voltage)
bits 11~8 current FID
bits 5~0 current VID
Write to MSR $199 to make changes
bits 11~8 current FID
bits 5~0 current VID
for voltage:
0=.700V
1=.716V
2=.732V
etc.
63=1.708V
this applies to Pentium M CPUs
Set bit 16 of MSR $1A0 to enable speedstep
Read MSR $198 for status
bits 43~40 maximum FID (multiplier)
bits 37~32 maximum VID (voltage)
bits 11~8 current FID
bits 5~0 current VID
Write to MSR $199 to make changes
bits 11~8 current FID
bits 5~0 current VID
for voltage:
0=.700V
1=.716V
2=.732V
etc.
63=1.708V
this applies to Pentium M CPUs
Re: Intel Speedstep under DOS?
I know this is late, but I never knew anything (until recently, and only barely!):
One guy on freedos-devel recently experimented with this a little bit. The thread (mentioned) explains some of it. However, he wasn't 100% successful (at least, not on Intel multi-core machines) because of the way things are designed. In other words, he has no idea (yet) how to make this work "universally" for all machines (via DOS). Maybe if someone wanted to delve into BareMetalOS and see how they do things, that would (IMHO) help, though admittedly that may be a big stretch and possibly naive. But users with single core Intel machines may actually have success with his "sstep" sample.
One guy on freedos-devel recently experimented with this a little bit. The thread (mentioned) explains some of it. However, he wasn't 100% successful (at least, not on Intel multi-core machines) because of the way things are designed. In other words, he has no idea (yet) how to make this work "universally" for all machines (via DOS). Maybe if someone wanted to delve into BareMetalOS and see how they do things, that would (IMHO) help, though admittedly that may be a big stretch and possibly naive. But users with single core Intel machines may actually have success with his "sstep" sample.
Re: Intel Speedstep under DOS?
I posted a DOS utility to freedos-user a while back. It is here http://www.hyakushiki.net/misc/speedstp.zip
The only CPU I have tested other than Pentium M is a Core 2 Duo SU9600. When I boot to DOS, the speed defaults to maximum (1.8GHZ "turbo") and I am able to adjust it down. The base clock is 200MHz and the only available multipliers are 6,7,8,9. But when it is set to 8, there is a separate bit (high bit of FID byte) that can be set which cuts the bus speed in half and knocks it down to 800MHz. The actual voltage levels corresponding to the register value are different than Pentium M... starts at .7125 and increases in steps of .0125V.
Under Windows (using a different utility, since it has to go through a driver to access MSRs) I did see that register writes sometimes appear to have no affect, perhaps because of which core the thread happens to be running on. My solution was to read back the register to verify that the change has been made and retry as needed.
The only CPU I have tested other than Pentium M is a Core 2 Duo SU9600. When I boot to DOS, the speed defaults to maximum (1.8GHZ "turbo") and I am able to adjust it down. The base clock is 200MHz and the only available multipliers are 6,7,8,9. But when it is set to 8, there is a separate bit (high bit of FID byte) that can be set which cuts the bus speed in half and knocks it down to 800MHz. The actual voltage levels corresponding to the register value are different than Pentium M... starts at .7125 and increases in steps of .0125V.
Under Windows (using a different utility, since it has to go through a driver to access MSRs) I did see that register writes sometimes appear to have no affect, perhaps because of which core the thread happens to be running on. My solution was to read back the register to verify that the change has been made and retry as needed.