833 replies to this topic

[Time2Retire]

Here are the first new findings:

1.) We have to fill in the Frequency and Power fields ourself now, because it no longer gets done for us. Unlike before with other models.

2.) Some of the data in our _PSS object, the one from our BIOS, has some serious errors in it. We have to correct the errors.

3.) We have to add Name (APSN, 0x04) in the CPU0 scope to keep ACPI_SMC_PlatformPlugin happy. The value 0x04 in the Adaptive Power State Number simply means that we have 4 Turbo Speeds above the normal CPU speed. We found this value in all new MacBookPro 8 series. There it was 6, 9 or 11 and matched with the Intel datasheets of the installed CPU.

4.) The number of P-States in the _PSS object in the new MacBookPro 8 series does not match up with the data found in the PerformanceStateArray (checked with ioreg / IORegistryExplorer).

5.) The new MacBookPro 8 series have 22 or 26 P-States (depends on model) and like I said; the number of P-States in the ACPI tables are less than the 22 and 26 I see in ioreg / IORegistryExplorer.

6.) The Turbo States in the new MacBookPro 8 series use the same amount of power as the normal CPU top speed.

7.) Here are the PerformanceStateArray's of the new MacBookPro 8[1/2/3] series:

 MBP8_1.png   63.23K   150 downloads
 MBP8_2.png   63.63K   113 downloads
 MBP8_3.png   73.94K   119 downloads

Now look at the CPU specifications of the used models:
MBP8,1 = i5-2415M CPU @ 2.30 GHz (Max Turbo Frequency 2.9 GHz / APSN = 6)
MBP8,2 = i7-2635QM CPU @ 2.00 GHz (Max Turbo Frequency 2.9 GHz / APSN = 9)
MBP8,3 = i7-2720QM CPU @ 2.20 GHz (Max Turbo Frequency 3.3 GHz / APSN = 11)

That should tell you enough for now

[flAked]

DutchHockeyPro, on Apr 25 2011, 03:01 PM, said:

Here are the first new findings:

5.) The new MacBookPro 8 series have 22 or 26 P-States (depends on model) and like I said; the number of P-States in the ACPI tables are less than the 22 and 26 I see in ioreg / IORegistryExplorer.

I suspect the additional P-States are predefined Turbo States, makes sense to have the regular 16 P-States + APSN = 22 on the i5.

For MBP8,2 we start at a lower frequency while having the same freq_max, ergo more additional States to cover the range.


Looking at the PerformanceStateArray (PSA) we see a direct correlation between base frequency and multiplier.

For the MBP8,3 for example we see 0x21 = 33 correlating to a freq_max of 3,3 GHz.

In my current PSA the max value of 16 states is 0x3b = 59 which doesn't look right in this context...


Should be interesting to see if supplying 16 states and setting APSN=0x00 would still work.

[Time2Retire]

Yup. And here is an example. This is the original P-State object of a MBP8,3 (copied from SSDT-5.dsl aka Cpu0Ist) with 'only' 16 P-States but the PerformanceStateArray has 26:

Name (_PSS, Package (0x10)
{
	Package (0x06) { 0x00000899, 0x0000AFC8, 0x0000000A, 0x0000000A, 0x00002100, 0x00002100 }, 
	Package (0x06) { 0x00000898, 0x0000AFC8, 0x0000000A, 0x0000000A, 0x00001600, 0x00001600 }, 
	Package (0x06) { 0x00000834, 0x0000A518, 0x0000000A, 0x0000000A, 0x00001500, 0x00001500 }, 
	Package (0x06) { 0x000007D0, 0x00009A9D, 0x0000000A, 0x0000000A, 0x00001400, 0x00001400 }, 
	Package (0x06) { 0x0000076C, 0x0000920B, 0x0000000A, 0x0000000A, 0x00001300, 0x00001300 }, 
	Package (0x06) { 0x00000708, 0x000087F6, 0x0000000A, 0x0000000A, 0x00001200, 0x00001200 }, 
	Package (0x06) { 0x000006A4, 0x00007FBF, 0x0000000A, 0x0000000A, 0x00001100, 0x00001100 }, 
	Package (0x06) { 0x00000640, 0x00007613, 0x0000000A, 0x0000000A, 0x00001000, 0x00001000 }, 
	Package (0x06) { 0x000005DC, 0x00006E34, 0x0000000A, 0x0000000A, 0x00000F00, 0x00000F00 }, 
	Package (0x06) { 0x00000578, 0x000064E4, 0x0000000A, 0x0000000A, 0x00000E00, 0x00000E00 }, 
	Package (0x06) { 0x00000514, 0x00005D5C, 0x0000000A, 0x0000000A, 0x00000D00, 0x00000D00 }, 
	Package (0x06) { 0x000004B0, 0x0000546D, 0x0000000A, 0x0000000A, 0x00000C00, 0x00000C00 }, 
	Package (0x06) { 0x0000044C, 0x00004D3F, 0x0000000A, 0x0000000A, 0x00000B00, 0x00000B00 }, 
	Package (0x06) { 0x000003E8, 0x000044AE, 0x0000000A, 0x0000000A, 0x00000A00, 0x00000A00 }, 
	Package (0x06) { 0x00000384, 0x00003C4D, 0x0000000A, 0x0000000A, 0x00000900, 0x00000900 }, 
	Package (0x06) { 0x00000320, 0x0000359B, 0x0000000A, 0x0000000A, 0x00000800, 0x00000800 }
})

Again APSN is set to 11 (0x0b) for this model, and that is exactly where the normal CPU speed is located in the array. Now ask your self this question: If non of the kexts is adding to the table, what does? I think this one solves that puzzle:

		Name (TSSF, 0x00)
		Mutex (TSMO, 0x00)
		Method (_TSS, 0, NotSerialized)
		{
			If (LAnd (LNot (TSSF), CondRefOf (_PSS)))
			{
				Acquire (TSMO, 0xFFFF)
				If (LAnd (LNot (TSSF), CondRefOf (_PSS)))
				{
					Name (LFMI, 0x00)
					Store (SizeOf (_PSS), LFMI)
					Decrement (LFMI)
					Name (LFMP, 0x00)
					Store (DerefOf (Index (DerefOf (Index (_PSS, LFMI)), 0x01)), 
						LFMP)
					Store (0x00, Local0)
					If (And (CFGD, 0x00080000))
					{
						Store (RefOf (TSMF), Local1)
						Store (SizeOf (TSMF), Local2)
					}
					Else
					{
						Store (RefOf (TSMC), Local1)
						Store (SizeOf (TSMC), Local2)
					}

					While (LLess (Local0, Local2))
					{
						Store (Divide (Multiply (LFMP, Subtract (Local2, Local0)), Local2, 
							), Local4)
						Store (Local4, Index (DerefOf (Index (DerefOf (Local1), Local0)), 0x01
							))
						Increment (Local0)
					}

					Store (Ones, TSSF)
				}

				Release (TSMO)
			}

			If (And (CFGD, 0x00080000))
			{
				Return (TSMF)
			}
			Else
			{
				Return (TSMC)
			}
		}

At least that's the only place in the ACPI files where _PSS is being used. No idea what it does however!

Note: I also have the other ACPI tables, of the MBP8,1 and 8,2 but it is too much work to change the data.

[flAked]

Comparing PSA and _PSS the sudden jump from 0x16 to 0x21 is very strange, it seems the last p-state defines the freq_max and this mysterious function is filling in the ones between.

Again, comparing this to my current p-states, I have continuous values with no max value.

Using that function would be great, as we only need to supply one extra p-state (read: replace p[15]). Still, how would we fabricate that last one?


EDIT: According to the ACPI specs:  Throttling Supported States (_TSS) – returns supported throttling state information (p. 321), it's definitely the right spot!

[Time2Retire]

Yeah. I need to have another look tomorrow. Right after school. Need to get some sleep now (is 2AM already) so good night for now...

[flAked]

OK, using the current information I crafted a new PSS for my i5-2500K:

Name (PSS, Package (0x10)
{
	/*  Core Frequency (MHz), Power (milliwats), Latency (ms), Bus Latency (ms), Control, Status */
			Package (0x06) { /* 3301 MHz */ 0xCE5, Zero, 10, 10, /* 37 */ 0x2500, 0x2500 },
			Package (0x06) { /* 3300 MHz */ 0xCE4, Zero, 10, 10, /* 33 */ 0x2100, 0x2100 }, 
			Package (0x06) { /* 3200 MHz */ 0xC80, Zero, 10, 10, /* 32 */ 0x2000, 0x2000 }, 
			Package (0x06) { /* 3100 MHz */ 0xC1C, Zero, 10, 10, /* 31 */ 0x1F00, 0x1F00 }, 
			Package (0x06) { /* 3000 MHz */ 0xBB8, Zero, 10, 10, /* 30 */ 0x1E00, 0x1E00 }, 
			Package (0x06) { /* 2900 MHz */ 0xB54, Zero, 10, 10, /* 29 */ 0x1D00, 0x1D00 }, 
			Package (0x06) { /* 2800 MHz */ 0xAF0, Zero, 10, 10, /* 28 */ 0x1C00, 0x1C00 }, 
			Package (0x06) { /* 2700 MHz */ 0xA8C, Zero, 10, 10, /* 27 */ 0x1B00, 0x1B00 }, 
			Package (0x06) { /* 2600 MHz */ 0xA28, Zero, 10, 10, /* 26 */ 0x1A00, 0x1A00 }, 
			Package (0x06) { /* 2500 MHz */ 0x9C4, Zero, 10, 10, /* 25 */ 0x1900, 0x1900 }, 
			Package (0x06) { /* 2400 MHz */ 0x960, Zero, 10, 10, /* 24 */ 0x1800, 0x1800 }, 
			Package (0x06) { /* 2300 MHz */ 0x8FC, Zero, 10, 10, /* 23 */ 0x1700, 0x1700 },
			Package (0x06) { /* 2200 MHz */ 0x898, Zero, 10, 10, /* 22 */ 0x1600, 0x1600 }, 
			Package (0x06) { /* 2100 MHz */ 0x834, Zero, 10, 10, /* 21 */ 0x1500, 0x1500 }, 
			Package (0x06) { /* 2000 MHz */ 0x7D0, Zero, 10, 10, /* 20 */ 0x1400, 0x1400 }, 
			Package (0x06) { /* 1600 MHz */ 0x640, Zero, 10, 10, /* 16 */ 0x1000, 0x1000 }
})

1) The first state defines the TurboMode

2) APSN is the difference (0x25 - 0x21 = 0x04) of normal and turbo control bit

3) MagicFunction or SMCPlatform replaces the TurboMode p-state with scaled frequencies of #APSN

For example, looking at the PerformanceStateArray of MBP8,3 we see the top most frequencies of 0xCE4 = 3300 and 0xC80 = 3200. The TurboMode state 0x899 = 2201 was replaced.

4) Power in mW is missing, how do I get those?

For the MBP8,3 0xAFC8 = 45000mW = 45W TDP, so it should be max 95W for my model, but how do those values get scaled? No info in the intel docs as far as I can see.

5) We need to fill the values in MCST again?

6) Observation: AICPUPM is crashing even if EIST & TM is disabled, is it loading for any one else?

[elitee]

It turns out that the reason your method for Audio not working, as well as the proper displaying of the Sata controller was because of this line in your Info.plist,

			<key>IONameMatch</key>
			<array>
				<string>pci8086,1c03</string>
			</array>

My board (Asus P8P67 Rev 3 Vanilla) has a cheaper? AHCI controller and is identified by device ID 1c02, though the address appears to be the same @1F,2 - so adding another string for it works. Thanks a lot for your work DHP!

[flAked]

Good find! Do you have additional PCI-cards installed for any chance?

My Atheros WLAN-adapter doesn't work with Sam's DSDT at the moment, and I suspected AHCI already.

Do you have a PEX and BR device showing up in IOReg? Without the DSDT I have those and WLAN is working via AtherosFix (plist injection), with I only see pci_bridge.

[elitee]

polyglot, on Apr 26 2011, 05:45 PM, said:

Good find! Do you have additional PCI-cards installed for any chance?

My Atheros WLAN-adapter doesn't work with Sam's DSDT at the moment, and I suspected AHCI already.

Do you have a PEX and BR device showing up in IOReg? Without the DSDT I have those and WLAN is working via AtherosFix (plist injection), with I only see pci_bridge.

I don't have any of those devices, because in Sam's DSDT they're called rp*, I'm not sure what BR is. I diff'd her original factory AML and my original AML, and there were some discrepancies with some of the devices and I made the corrections, but I could've overlooked some. I also made some changes where she said the holy grail of sleep, but that still didn't correct sleep for me.

I still have the LAN issue as well, the DSDT devices are setup correct (I think), and Chameleon is injecting the device properties, but I get this error,

4/26/11 1:47:25 PM	kernel	AppleRTL8169Ethernet: Unknown hardware version ID (2c000000)

, so I assume the driver doesn't support 8111E like our boards have? Not sure about this one.

I attached my factory dsdt and my modified one.

[flAked]

elitee, on Apr 26 2011, 06:07 PM, said:

I still have the LAN issue as well, the DSDT devices are setup correct (I think), and Chameleon is injecting the device properties, but I get this error, so I assume the driver doesn't support 8111E like our boards have? Not sure about this one.

For LAN I'm using http://lnx2mac.blogs...osx-driver.html - working very well, not sure if our chip would work vanilla.

EDIT2: OK, so SAT0@1F,2 <pci8086,1c02> is working beautifully and AppleAHCI gets recognized.
We only need to change the matching in the plist, not in the DSDT.

For reference, here is my lspci:

00:00.0 Host bridge: Intel Corporation Device 0100 (rev 09)
00:01.0 PCI bridge: Intel Corporation Device 0101 (rev 09)
00:16.0 Communication controller: Intel Corporation Cougar Point HECI Controller #1 (rev 04)
00:1a.0 USB Controller: Intel Corporation Cougar Point USB Enhanced Host Controller #2 (rev 05)
00:1c.0 PCI bridge: Intel Corporation Cougar Point PCI Express Root Port 1 (rev b5)
00:1c.1 PCI bridge: Intel Corporation Cougar Point PCI Express Root Port 2 (rev b5)
00:1c.2 PCI bridge: Intel Corporation Cougar Point PCI Express Root Port 3 (rev b5)
00:1c.3 PCI bridge: Intel Corporation Cougar Point PCI Express Root Port 4 (rev b5)
00:1c.4 PCI bridge: Intel Corporation Cougar Point PCI Express Root Port 5 (rev b5)
00:1c.5 PCI bridge: Intel Corporation Cougar Point PCI Express Root Port 6 (rev b5)
00:1c.6 PCI bridge: Intel Corporation 82801 PCI Bridge (rev b5)
00:1c.7 PCI bridge: Intel Corporation Cougar Point PCI Express Root Port 8 (rev b5)
00:1d.0 USB Controller: Intel Corporation Cougar Point USB Enhanced Host Controller #1 (rev 05)
00:1f.0 ISA bridge: Intel Corporation Device 1c46 (rev 05)
00:1f.2 SATA controller: Intel Corporation Cougar Point 6 port SATA AHCI Controller (rev 05)
00:1f.3 SMBus: Intel Corporation Cougar Point SMBus Controller (rev 05)
01:00.0 VGA compatible controller: nVidia Corporation G92 [GeForce GTS 250] (rev a2)
03:00.0 USB Controller: NEC Corporation Device 0194 (rev 04)
06:00.0 USB Controller: NEC Corporation Device 0194 (rev 04)
07:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 06)
08:00.0 PCI bridge: Device 1b21:1080 (rev 01)
09:00.0 Ethernet controller: Atheros Communications Inc. Atheros AR5001X+ Wireless Network Adapter (rev 01)
09:01.0 Multimedia audio controller: C-Media Electronics Inc CM8738 (rev 10)
0a:00.0 SATA controller: Device 1b4b:9172 (rev 11)

[mrmojorisin17]

Yep, same here.
I didn't realize that in huronplist was injected an ID (8086,1c03) different from mine (8086,1c02).
Now chipset is correctly recognized with real ID in both huronplist and AppleAHCIPort.kext's Info.plist

[flAked]

After 4 hours I can present a first draft of a complete DSDT for P8P67 rev3!

I cross-referenced every method and every address and as expected there are a couple of differences, mainly because of more PCI-lanes. I started renaming/adding the ARxx references to keep it in sync with my vanilla DSDT, but soon found out, that it could be stripped down further. Not done yet.

1) PCI-cards, FireWire, all USB-ports should work now.

2) Bluetooth and Sound are not working. (There is a mysterious device called BR20, don't know what it does yet.)


Remember that this is a work in progress DSDT, as such you take all responsibility testing it on your hardware.

ssdt_pr is meant to be used for i5-2005K and is not complete yet. It is, however, safe to use with NullCPUPM.

Have fun!


Credit goes to Sam for doing a fantastic job, could not have done it without her work!

 P8P67_DSDT_WIP.zip   8.4K   69 downloads

[elitee]

Looks good, I will try it tomorrow: one thing I did notice was that this

		   OperationRegion (NBNV, SystemMemory, 0xBF5FCD98, 0x0100)

was different on my factory DSDT, the value was 0xDF5CBD98, and when I put the value in, putting the computer to sleep would actually shut it off, but never come on, whereas the other value would never turn the computer off, just attempt to.

polyglot, on Apr 26 2011, 11:15 PM, said:

After 4 hours I can present a first draft of a complete DSDT for P8P67 rev3!

I cross-referenced every method and every address and as expected there are a couple of differences, mainly because of more PCI-lanes. I started renaming/adding the ARxx references to keep it in sync with my vanilla DSDT, but soon found out, that it could be stripped down further. Not done yet.


P8P67_DSDT_WIP.zip

[elitee]

To get sound working with only DSDT and AppleHDA binpatch, add the following to your DSDT for Rev 3 Vanilla p8p67

			Device (HDEF)
			{
				Name (_ADR, 0x001B0000)
				Alias (PW94, _PRW)
				Method (_DSM, 4, NotSerialized)
				{
					Store (Package (0x04)
						{
							"layout-id", 
							Buffer (0x04)
							{
								0x7C, 0x03, 0x00, 0x00
							}, 

							"PinConfigurations", 
							Buffer (Zero) {}
						}, Local0)
					MCDP (Arg2, RefOf (Local0))
					Return (Local0)
				}
			}

	Method (MCDP, 2, NotSerialized)
	{
		If (LEqual (Arg0, Zero))
		{
			Store (Buffer (One)
				{
					0x03
				}, Arg1)
		}
	}

The second method was already in the DSDT, DHP had it commented out. You could also inject this information with device-properties as she suggested, which is what she did and why it worked for her.

[flAked]

Confirmed, Audio is working. I'm not sure if I actually patched AppleHDA or MacMan's ALC8xxHDA.kext (also only plist) did the trick. One thing I noticed was that the digital output will shut itself down rather quickly and will come up again when playing. But this could be influenced by using MBP8,3.

EDIT: Yep, using MacPro3,1 fixed this. But might not be desirable in the long run if we want to replicate a MBP8,3.

EDIT2: Could you maybe post the md5 of the original AppleHDA if you still have it?


I missed the address for sleep, yeah. On my system it will shutdown with the power light still on, but never wakes up.

Strangely enough, with the current DSDT my sound-card (cmi8738) isn't working anymore, the kext loads but no device showing up.

[flAked]

Looking further at how maximum power dissipation per p-state is calculated, we can't see a linear correlation.

Using MBP8,3 as example: 45W max TDP, normal clock 2.2GHz


TDP to clock speed ratio (W/GHz) is therefor:

45 W / 2.2GHz = 20.45


If we take the PStateArray from the MBP8,3 we see:

2200: AFC8 = 45 000  20.45
2100: A518 = 42 264  20.13 -0.32
2000: 9A9D = 39 581  19.80 -0.33
1900: 920B = 37 387  19.00 -0.80
1800: 87F6 = 34 806  19.00 -0.00
1700: 7FBF = 32 703  19.00 -0.00
1600: 7613 = 30 227  18.00 -1.00
1500: 6E34 = 28 212  18.00 -0.00
1400: 64E4 = 25 828  18.00 -0.00

Therefor a non linear factor. Now, it would be too easy if they just used 20.45 for every p-state!


If we would apply a constant factor of 20.45 we get slightly higher max power dissipation per state, meaning we would rather stay in one state longer, than just switch to the higher frequency. Essentially "underclock-throttling" the CPU.

[elitee]

polyglot, on Apr 27 2011, 11:50 AM, said:

Confirmed, Audio is working. I'm not sure if I actually patched AppleHDA or MacMan's ALC8xxHDA.kext (also only plist) did the trick. One thing I noticed was that the digital output will shut itself down rather quickly and will come up again when playing. But this could be influenced by using MBP8,3.

EDIT2: Could you maybe post the md5 of the original AppleHDA if you still have it?

Don't have any way to test digital out, sorry! the md5sum of the compressed AppleHDA.kext I took from my 10.6.7 2011 MB is:


MD5 (AppleHDA.kext.zip) = 901a7ef36b8fc747ef5b80a631f09704

Here's the unmodified kext:  AppleHDA.kext.zip   1.51MB   15 downloads

[Time2Retire]

Our SATA device-id is 1c02 because that's the desktop variant. Apple is using the mobility variant (1c03) with (using the Intel HM65 chipset). See also the Intel datasheets.

And about calculating the P-State Power. Look here:

M = ((1.1 - ((max_ratio - ratio) * 0.00625)) / 1.1) ^2
PStatePower = ((ratio / max_ratio) * M * TDP)

That's the formula to be used. The unknown value TDP can be calculated by reading two Sandy Bridge/Jaketown specific MSR's which I'll plan to add later tonight in RevoBoot.

[flAked]

DutchHockeyPro, on Apr 27 2011, 03:19 PM, said:

M = ((1.1 - ((max_ratio - ratio) * 0.00625)) / 1.1) ^2
PStatePower = ((ratio / max_ratio) * M * TDP)

That's the formula to be used. The unknown value TDP can be calculated by reading two Sandy Bridge/Jaketown specific MSR's which I'll plan to add later tonight in RevoBoot.

Isn't TDP just the fixed Thermal Design Power specified for each CPU?

Would be neat to extract that directly from the MSR, but my RevoBoot is not yet fully configured, so I would test that formula with a handcrafted PSS.

[Time2Retire]

It is really simple. My i7-2600K's TDP is 255 Watt or 255.000 Milliwatt. I presume because my CPU is unlocked, otherwise it probably should have returned 95 Watt aka 95.000 Milliwatts.

Now check the first value in my _PSS which is 0x3E418 or yup 255.000 In short: i5-2500(K) users need to check the first (highest) value and that's your TDP