synaesthesia

This is intended to be a short set of notes on successful hardware upgrades to a C700 series (C771US specifically) Compaq Presario laptop.

CPU

The system shipped with an anemic 1.86GHz Pentium-M T2390 with only 1M cache and a 533MHz FSB.

Additionally, the CPU heatsink locking mechanism relies on metal flanges which lose their tension over time and as a result allow the CPU heatsink to lose contact with the CPU package, leading to incessant fan operation and system lockups under load.

If you’re going to tear apart the laptop to fix the heatsink situation, you might as well replace the CPU while you are at it.

In my case I obtained a Core 2 Duo T9300 for about $50 which is a 2.5GHz, 6M cache monster by comparison. The specific CPU model that you obtain is not important, except that 1) it must be Socket P package; the Intel GM965 chipset in the C700 does not support greater than 800MHz bus speeds, so 2) it must be for an 800MHz or less bus; and 3) it must match the 35W thermal dissipation profile (TDP) of the T2390 to ensure that the OEM cooling hardware will be adequate.

When you install the CPU be sure to use a thicker than normal layer of Arctic Silver between the CPU and heatsink. The heatsink does not fit that well and a layer of heatsink compound will fill that gap. (Alternately you could probably use a thermal pad of some kind.)

CPU Issues

VT/Virtualization

The C700 BIOS does not enable VT virtualization acceleration, and furthermore locks the IA32_FEATURE_CONTROL MSR to prevent its enablement by the OS, so this feature is unavailable. It is possible to hack the InsydeBIOS and force-flash it via a specific type of USB thumb drive in order to enable this feature. (Similar to the procedure needed to modify the BIOS whitelist to be able to use a third-party mini-PCI WiFi card.)

SpeedStep

The C700 BIOS does not set up the ACPI Performance Supported States tables correctly for later Core 2 CPUs. As a result CPU frequency scaling (SpeedStep) does not work. The CPU boots at 2.4GHz (despite e.g. my T9300 being a 2.5GHz CPU) and stays there. ACPI CPU idling (C3 state) still works, which can be verified with the “Idle stats” tab in powertop. Linux presents the following error in dmesg:

[Firmware Bug]: ACPI: Invalid BIOS_PSS frequency: 0x0MHz

For an in-depth solution, see below.

RAM

The C771US shipped with 2GB of PC2-5300 DDR SDRAM. The system specifications are listed as if this is the maximum the computer will support, but the GM965 chipset is capable of using up to 8GB and up to PC2-6400 speed SDRAM, so it seems to be worth a try to upgrade the RAM anyway.

I have good news: the memory can be upgraded to a total of 5GB of RAM running at 667MHz (PC2-5300 speed).

The bad news is that the reason it can only be upgraded to 5GB is that the Compaq BIOS seems to have a bug in configuring the memory that causes loss of system stability if any module of size greater than 1GB is inserted into slot 0 (the slot closest to the motherboard). This will manifest as errors/hangs in memtest86, errors in Linux under moderate utilization, etc. I assume the difference between a 1GB module that works and a 2GB module that doesn’t is in the geometry and/or the timing parameters encoded in the SPD EEPROM, which can be viewed using decode-dimms. (Note: at least two individuals claim to have gotten unspecified 2GB modules to work in that slot; one in the comments, and one on the HP forums. I was unable to. I attempted a 2GB PC2-6400 Micron MT16HTF25664HY-800J2 as well as 2GB PC2-5300 Hynix HYMP125S64CP8-Y5 in the first slot, and in both cases memtest86 hung and the system was unstable in Linux, even though the 2GB module passed the tests when installed alone. I could not isolate any geometry or timing factor at fault.)

Another bit of bad news is that regardless of the memory module configuration and capabilities, the BIOS configures the memory controller for 667MHz 5-5-5 timing. So PC2-5300 CL5 RAM is really the fastest that is needed for this system. Additionally, it seems that according to the GM965 memory configuration datasheet, it would not be possible to use a GM965 laptop with 4GB modules at 800MHz speed, only 667MHz or lower. So there is probably nothing lost with this 5GB configuration by how the BIOS configures the memory speed.

So in order to upgrade a C700 series laptop to 5GB RAM, insert a 1GB DDR2 SO-DIMM into slot 0, the slot closest to the motherboard, and a 4GB DDR2 SO-DIMM into slot 1, the outer slot. The speeds do not need to be matched as long as the SPD EEPROM on the faster module includes timings for the fallback transfer rate (the usual case). In the image below I have mixed a PC2-5300 1GB module with a PC2-6400 4GB module and the system simply configures both to run at 667MHz.

Of note is that there is a minor performance loss from falling back from dual channel symmetric mode to dual channel asymmetric mode when running in a mismatched size configuration according to the GM965 memory configuration datasheet. Dual channel performance will only be available for the portion of the larger module that is covered by the size of the smaller module; in this case, 1GB of the 4GB module will thus enjoy dual channel performance.

Second hard disk

It is possible to replace the PATA DVD drive with an aftermarket caddy that can contain a second SATA hard disk. This interface will be somewhat slower than the main SATA hard disk since it contains a PATA-to-SATA converter.

SSDT Modification

After dumping the ACPI tables and disassembling the SSDT containing the _PSS table, I found that the _PSS table contains only three entries:

        Name (_PSS, Package (0x03)  // _PSS: Performance Supported States
        {
            Package (0x06)
            {
                0x00000960, 
                0x00007D00, 
                0x0000000A, 
                0x0000000A, 
                0x00000C22, 
                0x00000C22
            }, 

            Package (0x06)
            {
                0x00000960, 
                0x00003A98, 
                0x0000000A, 
                0x0000000A, 
                0x00000C22, 
                0x00000C22
            }, 

            Package (0x06)
            {
                0x00000000, 
                0x00000000, 
                0x0000000A, 
                0x0000000A, 
                0x00008000, 
                0x00008000
            }
        })

One can verify in the ACPI specification that these entries correspond respectively to a 2.4GHz, 2.4GHz, and “0 GHz” modes, the latter at which Linux complains with the 0x0 MHz error. Further, it can be observed (despite Intel’s insistence on secrecy, the register encoding scheme has been reverse engineered) that the bits [8:15] of the PERF_CTL and PERF_STATUS register values (the last two values in each frequency entry) correspond to the FSB multiplier needed to derive the target CPU frequency. So the problem here is that the Compaq BIOS has simply given us no valid entries that could possibly allow the CPU to run at any frequency other than 2.4GHz.

I solved this with the following steps.

Extract the _PSS table from the ACPI SSDT of another similar laptop (HP DV2700 series with Core 2 T7700), using acpidump > dsdt, acpixtract -a dsdt, and iasl -d ssdt2.dat. This provides the following _PSS table which I will discuss:

Name (_PSS, Package (0x06)  // _PSS: Performance Supported States
        {
            Package (0x06)
            {
                0x0961, 
                0x88B8, 
                0x0A, 
                0x0A, 
                0x0D30, 
                0x0D30
            }, 

            Package (0x06)
            {
                0x0960, 
                0x88B8, 
                0x0A, 
                0x0A, 
                0x0C24, 
                0x0C24
            }, 

            Package (0x06)
            {
                0x07D0, 
                0x6D60, 
                0x0A, 
                0x0A, 
                0x0A1E, 
                0x0A1E
            }, 

            Package (0x06)
            {
                0x0640, 
                0x55F0, 
                0x0A, 
                0x0A, 
                0x0818, 
                0x0818
            }, 

            Package (0x06)
            {
                0x04B0, 
                0x3E80, 
                0x0A, 
                0x0A, 
                0x0612, 
                0x0612
            }, 

            Package (0x06)
            {
                0x0320, 
                0x36B0, 
                0x0A, 
                0x0A, 
                0x880B, 
                0x880B
            }
        })

This table as constructed by the HP BIOS for the T7700 provides a range of frequencies labeled as 800MHz (0x0320) to 2401MHz (0x0961). Based on a 200MHz FSB, it will mostly step in 400MHz and 75mV increments, with a lowest voltage of .9375V.

However, the first and last entries are interesting because they break the apparent rules. The documentation for the Pentium M SpeedStep, upon which the Core 2 Duo is based, sheds some light on why. These entries are known as HFM and LFM respectively. The Core 2 Duo added a “SLFM” (Super Low Frequency Mode) which is described in the Core 2 Duo datasheet. The SLFM mode additionally uses the Dynamic FSB feature to reduce the FSB clock in half (e.g. from 200MHz to 100MHz). The Dynamic FSB bit is the leftmost bit of the PERF_CTL word according to the CoreBoot source code. So the LFM (SLFM) register value is now fully explained: 200MHz FSB / 2 = 100MHz FSB * 8 = 800MHz, at a core voltage .800V + 12.5*0x0B(11) = .9375V.

What about the first entry? It is labeled 2401MHz, which seems a bit odd because the next entry is labeled 2400MHz, provides 2400MHz at 1.25V, and the T7700 processor itself is clocked at 2.4GHz anyway. What’s even stranger is that despite being labeled 2401MHz, the multiplier actually puts it at 2600MHz, and the core voltage increases to 1.4V! Looking at the specs of the T7700, it becomes a bit clearer. The reason 2.6GHz is an available configuration is Intel Dynamic Acceleration, a precursor to the more recent Turbo Boost. With IDA, the host system can set a MSR bit that allows one or more cores to exceed design frequency and voltage specifications as long as the overall constraints (thermal, etc.) for the CPU package are met. The frequency label on the first mode is a bit of marketing trickery from what I can determine. It is set at 2401MHz, one greater than 2400MHz, to preserve relative ordering and to indicate to the OS that this is the highest frequency. A user who views his configuration will see the 2.4GHz CPU he believes he has, and the OS will believe this too, even if IDA is enabled and actively overclocking a core to 2.6GHz. In effect, this provides invisible help to workloads that cannot effectively be parallelized. The only evidence we have of what is really going on is the _PSS table, and, only for later Core 2 models, tools like CoreFreq tool which directly computes clock speed using performance counters.

So, what about the solution to enable SpeedStep on the C700? The first thing I did was to take this copied _PSS table, compile it as-is using iasl -tc, and override the BIOS SSDT of the C700 using GRUB as described here. The ACPI table could load:

[    0.118337] ACPI: Dynamic OEM Table Load:
[    0.118342] ACPI: SSDT 0xFFFF880179151100 0000C4 (v01 PmRef  Cpu1Ist  00003000 INTL 20051117)

And more importantly, the _PSS error was gone and frequency scaling was working immediately!

I was lucky that I had a very similar CPU with a correct _PSS table to draw from. But could we tweak it to actually match the specs of the T9300? And what about the more general case where a closely matched reference is unavailable? The c2ctl tool has some limited ability to generate a _PSS table, for example. But let’s try to create one that’s correct for the T9300.

The first challenge is the 12.5x and 13.5x multipliers needed for the 2.5GHz HFM and 2.7GHz IDA modes, which cannot be represented as a (hex) integer. The second challenge is the slightly different design voltage ranges.

For the first challenge, it is useful to observe from the Penryn core datasheet that there is a “Half-ratio (N/2)” mode for the FSB. While it provides no more details, going back to the CoreBoot source code we find that the second to leftmost bit in the register value is a “ratio nonint” bit which is commented as “add .5 to the ratio”. So we can just set that bit for the HFM and IDA modes to replace the 2.4GHz and 2.6GHz cases with 2.5GHz and 2.7GHz respectively.

For the voltage issue, we can see from the spec sheet that the voltage ranges for the T9300 are greater than those of the T7700: the highs are higher and the lows lower. Assuming the same base voltage of .800V, we’ll put .85V on the LFM mode and 1.45V on the IDA mode, leaving the rest within the range much as before. We can tweak this later if we have stability issues.

As for the rest of the values, the latency will remain the same 10uS for all Core 2 chips, and the power dissipation we can assume will scale similarly for the T9300 as it shares a 35W TDP (thermal design profile) with the T7700. For an arbitrary chip, the TDP and frequency change latency can be encoded as necessary.

So, our final T9300 _PSS table:

Name (_PSS, Package (0x06)  // _PSS: Performance Supported States
        {
            Package (0x06)
            {
                2501,   /* Frequency reported to OS, MHz */
                35000,  /* Power dissipation, mW */
                10,     /* Transition latency, uS */
                10,     /* Transition latency, uS */
                0x4D34, /* PERF_CTL value (13.5x, 52 * 12.5mV + .800V = 1.45V) */
                0x4D34  /* PERF_STATUS readback value */
            }, 

            Package (0x06)
            {
                2500, 
                35000, 
                10, 
                10, 
                0x4C28, /* 12.5x, 40 * 12.5mV + .800V = 1.3V */
                0x4C28
            }, 

            Package (0x06)
            {
                2000, 
                28000, 
                10, 
                10, 
                0x0A1E, /* 10x, 30 * 12.5mV + .800V = 1.175V */
                0x0A1E
            }, 

            Package (0x06)
            {
                1600, 
                22000, 
                10, 
                10, 
                0x0818, /* 8x, 24 * 12.5mV + .800V = 1.1V */
                0x0818
            }, 

            Package (0x06)
            {
                1200, 
                16000, 
                10, 
                10, 
                0x0610, /* 6x, 16 * 12.5mV + .800V = 1V */
                0x0610
            }, 

            Package (0x06)
            {
                800, 
                14000, 
                10, 
                10, 
                0x8804, /* Dynamic FSB (100MHz), 8x, 4 * 12.5mV + .800V = .85V */
                0x8804
            }
        })

I then compile this with iasl -tc, replace the /boot/dsdt.aml with it, and reboot to check my work. (If it all goes wrong and the system is unbootable due to CPU errors, I append nocpufreq to the Linux command line in GRUB to bypass my mistake.) Afterwards, I can see that CPU frequency scaling is working using powertop. Now I only have to use the system heavily to see if there is any instability that could be attributed to guesswork in this modification.

A minor complication is that when the BIOS Cpu0Ist SSDT fails to load after the custom SSDT with the same-named objects has already been loaded (this is expected):

[    0.118134] ACPI: Dynamic OEM Table Load:
[    0.118140] ACPI: SSDT 0xFFFF880179343E00 0001EA (v01 PmRef  Cpu0Ist  00003000 INTL 20051117)
[    0.118147] ACPI Error: [_PPC] Namespace lookup failure, AE_ALREADY_EXISTS (20160108/dswload-378)
[    0.118152] ACPI Exception: AE_ALREADY_EXISTS, During name lookup/catalog (20160108/psobject-227)
[    0.118165] ACPI Error: Method parse/execution failed [\_PR.CPU0._OSC] (Node ffff88017a0b0f00), AE_ALREADY_EXISTS (20160108/psparse-542)
[    0.118177] ACPI Error: Method parse/execution failed [\_PR.CPU0._PDC] (Node ffff88017a0b0ed8), AE_ALREADY_EXISTS (20160108/psparse-542)
[    0.118338] ACPI: Dynamic OEM Table Load:
[    0.118343] ACPI: SSDT 0xFFFF88017932DA00 0000C4 (v01 PmRef  Cpu1Ist  00003000 INTL 20051117)
[    0.118635] ACPI: Dynamic OEM Table Load:
[    0.118639] ACPI: SSDT 0xFFFF880179337240 000083 (v01 PmRef  Cpu1Cst  00003000 INTL 20051117)

After the expected failure, the ACPI interpreter also does not load the Cpu0Cst table which contains the C-state information, so ACPI idle states don’t work:

[    1.228457] ACPI Error: [\_PR_.CPU0._CST] Namespace lookup failure, AE_NOT_FOUND (20160108/psargs-359)
[    1.228462] ACPI Error: Method parse/execution failed [\_PR.CPU1._CST] (Node ffff88017a0a2348), AE_NOT_FOUND (20160108/psparse-542)

I fixed this by combining the hacked Cpu0Ist withe the original Cpu0Cst into one Cpu0IstCst SSDT that is then loaded with GRUB. Now everything works!

Motherboard schematic

Well, in case you needed it for some reason:
HP Compaq C700 motherboard schematics.

This entry was posted on Friday, November 16th, 2012 at 10:47 pm and is filed under PC Hardware/Consumer Electronics, Reverse Engineering. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.