Wow, thanks for bringing eventually light to the SpeedStep issue!
Software initiated DeepSleep: What a great idea! Newer came to think of that before. I always assumed that the state transitions were driven by platform hardware signals.
Is there any danger of left hanging there in DeepSleep? What causes the processor leave DeepSleep? Real-Time clock, Fn-key/keyboard, mouse?
If it works, you might consider to prepare a download site for it. Would be interesting to test your DeepSleep utility.
Do you know if your DeepSleep utility's XP version works in Windows98? (I am still using original Windows98 installation in my TP600E)
I have newer come even to think that wiring some additional BX Southport signals could solve the SpeedStep propblem! Thanks for your insight.
I have to check if BX Southport versions are the same on 600E and 600X, and if the BX SouthPort version on 600E supports those signals. I can measure wiring differences between 600E and 600X.
Based on my reading of the original Intel Patent application for SpeedStep, the first generation SpeedStep is a combination of H/W and software (mostly BIOS routines). It looks like they were attempting to keep the external H/W changes to a minimum - and isolated most of those to an ASIC. They use some of the GPIO lines on the southbridge for interrupt processing and to signal the PIIX4 southbridge to bring the processor out of deepsleep. The basic transaction is:
- BIOS sets up appropriate Power Management (PM-APIC) interrupt vector for power events (ac - plugin/battery, lid open/close, etc.)
- The Speedstep lines on the MMC-2 are connected to GPIO lines on the southbridge. Once a PM event is triggered the BIOS programs the Sourthbridge to pull the G_LOHI# signal low and programs a Stop Break event on the triggering of a GPIO interrupt line (this interrupt is raised by the SpeedStep ASIC via the VRCHGNG# signal and is called a System Controller Interupt).
- This causes the Speedstep ASIC to transitions the PIII from the running state to DeepSleep by asserting the STPCLK# signal followed by the DPSLP# signal (and then stops the local bus clock BCLK).
- The ASIC basically toggles the processor between two multiplier states, fast and slow. by transistioning the power controller to output the higher/lower core voltage and asserts/deasserts the GHI# processor signal (this is what your mod hardwires to the larger multipler state). After this it asserts the VRCHGNG# signal to the southbridge. The VRCHCNG# line is also used to gate the CPU_STP signal from the southbridge to the MMC-2 connector (the gated signal becomes G_CPU_STP).
- The southbridge receives the ASCI interrupt and executes a Stop Break cycle to bring the processor out of DeepSleep. As the processor transitions from DeepSleep it senses the level on the GHI# line (if low, it uses the larger core multiplier, and the smaller value otherwise).
I would say it would only be worth wiring the MMC-2 and southbridge lines - if the TP600e BIOS actually includes the SpeedStep routines (which I doubt, unless IBM has economized and uses the same core BIOS for all the 600 series). If the TP600e BIOS does not contain those routines, then their function would need to be supported in software (or added to the BIOS - not too easy as you already know).
Turns out you can have the southbridge transition the processor through DeepSleep without the ASIC because you can program the PIIX4 to execute a Stop Break cycle based on either the Fast or Slow Bust internal timers. This is what the utility that I wrote does. I program the PIIX4 to transition the processor into DeepSleep. Before executing the DeepSleep command (via a read to the PLVL3 register), I program the Fast Burst timer to fire a Stop Break transition after 1 ms. This is all documented fairly well in the Intel 82371AB (PIIXA) datasheet.
The version I wrote is a Win32 app, so that would likely run on Win98SE,
but... the way I access the southbridge registers from user space is via a 32 bit protected mode device driver, and I think this would not work under Win98SE. You would probably need a "Real Mode" device driver. I'm certain of this for Win98 First Edition, but not sure about SE. In any event it would be very easy to write such a driver for any of the Windows platforms if it would be useful.