Jump to content

DSDT for Asus P8P67-M PRO

Time2Retire

By Time2Retire,
in Patches

 Share
834 posts in this topic

Recommended Posts

flAked
flAked
Posted
Posted
And CPLT points to some unknown IO region:

    OperationRegion (PLMT, SystemIO, 0x0310, 0x0A)
   Field (PLMT, WordAcc, Lock, Preserve)
   {
       CPLT,   8, 
       GPLT,   4, 
               Offset (0x02), 
       MPLT,   8, 
       CFIL,   8

 

PCT (Performance Control) is used to directly set the performance state either via control register (FFixedHW 0x199) or SystemIO (0x00). Ok, so MBP8,3 is using the SystemIO to set the state.

 

PPC (Performance Present Capabilities) is used by PCT to determine, which of the performance states are currently available. Intel is suggesting using this bit to set different states for docked or mobile scenarios.

Educated guess: PPC is determined by 4 values, could be AC status, Temps, GPU, Battery.

 

1) We could set PPC to always Zero, hence all performance state available.

 

2) We must check for _OST Evaluation in the SSDT, as this is called after PPC to propagate the states to OPSM.

 

 

Ok there is a second way and that is to write a little command tool to dump the MSR's. And looking at my agreement. That's not part of it. I better check LOL Nah better not. But anyone willing to have a go with it should keep an eye on RevoBoot i386/libsaio/cpu/essentials.h :(

:)

 

Hey hey. Intel made an error in the P-State calculation because they assumed that everyone is using the uncore graphics. Err. Not us.

Could you elaborate on that? Sure, we have this massive number of 255W of which we only strive to use 95W (overclock anyone :D ), but in the p-state calculation we only use that - or do we?

 

 

I just read about Thermal Model 3.0 - do we have PTC, TSS & TPC indicating OSX is using it? I do have those in my vanilla SSDT, so SandyBridge i5 is supporting it. But I'm not sure what's different to SpeedStep / Turbo.

Link to comment
Share on other sites
Time2Retire
Time2Retire
Posted
  • Author
Posted
Could you elaborate on that? Sure, we have this massive number of 255W of which we only strive to use 95W (overclock anyone ;) ), but in the p-state calculation we only use that - or do we?

We do not use the graphics part, but Apple does, and they stuff 0xA0 (160) in that register. The one I am reading.

 

I just read about Thermal Model 3.0 - do we have PTC, TSS & TPC indicating OSX is using it? I do have those in my vanilla SSDT, so SandyBridge i5 is supporting it. But I'm not sure what's different to SpeedStep / Turbo.

Thermal throttling seems more like a precaution to prevent the hardware from running hot. Shutting it down when it gets over a certain threshold.

 

And I would say yes. Almost obvious since method _TSS is responsibe for adding the P-States for turbo speeds, at least on the new MBP 8 series. Luckily our DSDT also has this info, but we need to convert/add the missing bits.

 

BTW; Do you have a link to the thermal info?

Link to comment
Share on other sites
flAked
flAked
Posted
Posted
We do not use the graphics part, but Apple does, and they stuff 0xA0 (160) in that register. The one I am reading.

I get it, so we need to set the register and be happy.

 

And I would say yes. Almost obvious since method _TSS is responsibe for adding the P-States for turbo speeds, at least on the new MBP 8 series. Luckily our DSDT also has this info, but we need to convert/add the missing bits.

 

BTW; Do you have a link to the thermal info?

 

TSS is just like PSS, but it defines T-states for processor throttling. I think it is a separate mechanism and not directly influenced/linked to P-states.

 

In the ACPI specs, chapter 8.4.3 http://www.acpi.info/DOWNLOADS/ACPIspec40a.pdf

 

 

@github: will test the TDP code later today, thanks!

 

EDIT: Nice, TDP info and RAPL are getting recognized. The question is, if we can read the value and it is correctly set by our BIOS, then AICPUM might crash for another reason all together?

 

BTW, is there a way to enable DB_LOG for the kernel via RevoBoot?

Link to comment
Share on other sites
Time2Retire
Time2Retire
Posted
  • Author
Posted
@github: will test the TDP code later today, thanks!

 

EDIT: Nice, TDP info and RAPL are getting recognized. The question is, if we can read the value and it is correctly set by our BIOS, then AICPUM might crash for another reason all together?

Thanks. Now. While I'm not aware of what that might be, but I think that running a small tool on the MBP 8 series to collect info might help us.

 

BTW, is there a way to enable DB_LOG for the kernel via RevoBoot?

I'm not familiar with DB_LOG but I do know that people use something like: debug=0x108 as boot argument.

 

One of my grandmothers died today so I am prolly off-line for some time. Need to get my thought straiten out first. Just so sad for grandpa :wacko:

Link to comment
Share on other sites
flAked
flAked
Posted
Posted
One of my grandmothers died today so I am prolly off-line for some time. Need to get my thought straiten out first. Just so sad for grandpa :D

So sad to hear that :)

 

Take your time and don't rush being normal again - unless it helps to get things off your mind, of course.

 

Best wishes!

Link to comment
Share on other sites
flAked
flAked
Posted
Posted
Sorry to hear about her grandmother. Anyhow here are the acpi dumps for my Asus P8P67 Deluxe rev3 2600K board...

 

Thanks.

Could you post the exact differences between the Normal and Deluxe version? Thanks.

 

Edit: I mean different numbers of PCI-lanes, more USB ports, etc.

Link to comment
Share on other sites
flAked
flAked
Posted
Posted

Some new findings as I switch to RevoBoot

 

1) Device definitions may cause troubles:

Device (GFX0)
{
   Name (_ADR, Zero)
}

Disables Q/E for my GTS250.

 

Device (BR24)	// PCI-bridge
{
   Name (_ADR, Zero)
   Alias (AR17, _PRT)
   Alias (PWB4, _PRW)
}

The same goes for the PCI-bridge definition. My sound-card driver cmi8738 won't load correctly.

However, GIGE, SATA and some others work fine. I don't know why that is, might be a IOMatching problem.

 

 

2) We need to drop SSDT's, otherwise P001-3 will get matched as additional CPU's (with own ID's) to our CPU0-3. Replacing existing ones doesn't work correctly in the case of SSDT_PR.

 

 

3) More of a question, if I boot Chameleon and use efidp2struct, which data is actually extracted? I tried adding the data to a CFDictionary but couldn't dump the information.

Link to comment
Share on other sites
davidm71
davidm71
Posted
Posted

Hi,

 

I tried to do the basic Nvidia display dsdt patch within the DSDTse Editior and had issues. I used ioregistry explorer to find my addresses which where something like 0x00010000,0x00010001,0x001C0000 as my gpu root pci ids are (x0,x0),(x1,x0),(x0,x0) and (x0,x0),(x1,x1),(x0,x0), and (x0,x0),(x1C,x0),(x0,x0). Plugging those values into a hex device id gfx string in the com.apple.boot.plist file worked and gave me multigpu support but putting those into a DSDT file that I used DSDTse to pull ended up causing a reboot and black screen. Thats even after removing the DSDT.aml files from the root and Extra folder!

 

I know I'm a beginner at this but I don't have the slightest idea why I can't revert back to how it was even after putting back my original gfx string into the boot.plist file? I tried running pfix to rebuild the cache and still that partition is borked!

 

 

Anyone care to comment please?

 

Thank you.

 

Note: I made appropriate edits to the NVCAP section as well and even took it one gpu at a time...

Link to comment
Share on other sites
davidm71
davidm71
Posted
Posted
Take a look at this :blink:

 

 

Thank you but how do I install that piece of code? Its a SSDT file correct? I guess I will have to study about SSDTs more.. Will I have to modify the NVCAP section based on ioregistry info? Also will Ioregistryexplorer be influenced by my current device-id string? Such that if I have already a generic nvidia device-id gfx string will copying ioexplorer display info be accurate to my particular hardware?

 

Thanks

Link to comment
Share on other sites
flAked
flAked
Posted
Posted

I know it's tempting, but please try and keep on topic.

 

Now, onto new findings.

 

 

The reason why SMC_PlatformPlugin is acting so quiet is because there is no PM-definition for MacBookPro8,1 in the IOPlatformPluginFamily if we are using stock 10.6.7 with just the new kernel. It is also not part of the MBP2011 10.6.7 update, bummer.

 

By setting MacPro5,1 SMC_PlatformPlugin loads further and is now complaining about:

 

ACPI_SMC_PlatformPlugin::gatherCStateOverrides - failed to set c-state demotion data: -1

 

 

At the moment I'm experimenting with more SSDT_PR implementations and did PDC, TSS and TPC without success.

I hope we get more fun out of the new iMac's and a 10.6.8 on the horizon next week!

Link to comment
Share on other sites
flAked
flAked
Posted
Posted
Can you gently attach here your new(s) SSDT_PR or a diff to see what you added?

Thanks

 

My assumptions were wrong in the last post. The PM-definition for MacPro5,1 has a CStateDemotion-property, which seems to be specific to the CPU so it fails on mine. This brings us no further.

I crafted my own definition for the MacBookPro8,3, but it doesn't change anything.

 

We need to figure out why IntelCPUPM is crashing and _then_ configure our CPU correctly via SMC_PlatformPlugin.

 

My SSDT_PR is a mess right now and potentially dangerous. It also doesn't change anything. I don't know if the MBP8,3 actually has T-States and if OSX is using them.

 

If you are curious I added Methods _TPC, _PTC and _TSS - you can check them out in the ACPI specification.

 

- TPC defines which T-States are available

- PTC is doing the actual throttling and

- TSS defines the T-States

 

IntelCPUPM is crashing with a correct implementation of those methods, so they are irrelevant at this point.

 

EDIT: Err, I totally forgot that we were suspecting TSS to generate the missing P-states.

 

In my vanilla SSDT, TSS is defined like that:

Name (TSS, Package (0x01) //Throttle off, 100%
       {
           Package (0x05)
           {
               0x64, 
               0x03E8, 
               Zero, 
               Zero, 
               Zero
           }
       })

The 0x64 = 100% and there are 2 more T-states with a lesser percentage. This corresponds the the ACPI specs.

But I think Apple is using this differently. The invocation of _TSS generates some data and writes it to either TSMF or TSMC, using PSS as a reference.

 

Sam, could you send me the dumps for the MBP8,3 please?

Link to comment
Share on other sites
Time2Retire
Time2Retire
Posted
  • Author
Posted

Oops. I thought that the AGPM stuff was common knowledge since my father introduced people to it, so I didn't bother to mention it here. Sorry. And one thing I would like to add is that the MBP8,1 should be left alone because that one won't work. The MBP8,2 and bigger brother 8,3 are a better match (for now).

 

BTW: I already use the iMac12_1.plist but it sure isn't a perfect match. Need modifications since not everyone will have a... wait I can't tell you that yet...

 

/me ducks

 

Correction:

Do not remove the following code. This is something Apple uses. It was pretty much hidden, but adding the boot flag debug=127 revealed the error; ACPI: setPicMode AE_NOT_FOUND

 

One other thing. dgsga removed the _PIC method from his DSDT and at first I thought that he had done something stupid, but he is right. I cross checked two stripped DSDT's of a P5K PRO and he is right. Dad removed it in 2009 so no. We don't need it – Apple is using the ACPI APIC mode (not legacy PIC) so we can safely remove the following three code snippets from our DSDT:

Method (_PIC, 1, NotSerialized)
{
	Store (0xAA, DBG8)
}

and:

OperationRegion (DEB0, SystemIO, 0x80, One)
Field (DEB0, ByteAcc, NoLock, Preserve)
{
	DBG8,   8
}

and:

Device (IPIC)	// Renamed from: PIC
               {
                   Name (_HID, EisaId ("PNP0000"))
                   Name (_CRS, ResourceTemplate () {
                       IO (Decode16,
                           0x0020,             // Range Minimum
                           0x0020,             // Range Maximum
                           0x00,               // Alignment
                           0x02,               // Length
                           )
                       IO (Decode16,
                           0x00A0,             // Range Minimum
                           0x00A0,             // Range Maximum
                           0x00,               // Alignment
                           0x02,               // Length
                           )
                       IRQNoFlags ()
                           {2}
                   })
               }

And that brings us to the exact spot why Lion can't boot without the dreadful double fault. Yup. These are the registers cparm writes to in boot.c with his patch for Chameleon.

 

Now read this in the ACPI specification:

A one indicates that the system also has a PC-AT-compatible dual-8259 setup. The 8259 vectors must be disabled (that is, masked) when enabling the ACPI APIC operation.

Oh yes. That's your MADT flags (PCAT_COMPAT) in APIC.dsl And while some say that something has changed, which is true because Apple went from ACPI v1.5 to ACPI 3.0a, but this is just a silly bug.

Link to comment
Share on other sites
flAked
flAked
Posted
Posted
BTW: I already use the iMac12_1.plist but it sure isn't a perfect match. Need modifications since not everyone will have a... wait I can't tell you that yet...

You are such a teaser :unsure:

 

Apple is using the ACPI APIC mode (not legacy PIC) so we can safely remove the following three code snippets from our DSDT.

Working great without them, thanks for the info.

 

With the MBP8 dumps I replicated the whole SSDT_PR and figured out what the _TSS method does and where the missing P-States are coming from. It's rather simple.

 

1) _PSS as we know it, defines normal P-states + a meta Turbo state. But there is another table named APSS, that defines all states, including Turbo modes. I now have all of them correctly showing up in IOReg.

Name (PSS, Package (0x10)
       {
/*  Core Frequency (MHz), Power (milliwats), Latency (ms), Bus Latency (ms), Control, Status */
           Package (0x06) { /* 3301 MHz */ 0xCE5, 0x17318, 10, 10, /* 37 */ 0x2500, 0x2500 },
           Package (0x06) { /* 3300 MHz */ 0xCE4, 0x17318, 10, 10, /* 33 */ 0x2100, 0x2100 }, 
           Package (0x06) { /* 3200 MHz */ 0xC80, 0x163c6, 10, 10, /* 32 */ 0x2000, 0x2000 }, 
           Package (0x06) { /* 3100 MHz */ 0xC1C, 0x154ba, 10, 10, /* 31 */ 0x1F00, 0x1F00 }, 
           Package (0x06) { /* 3000 MHz */ 0xBB8, 0x145f5, 10, 10, /* 30 */ 0x1E00, 0x1E00 }, 
           Package (0x06) { /* 2900 MHz */ 0xB54, 0x13776, 10, 10, /* 29 */ 0x1D00, 0x1D00 }, 
           Package (0x06) { /* 2800 MHz */ 0xAF0, 0x1293c, 10, 10, /* 28 */ 0x1C00, 0x1C00 }, 
           Package (0x06) { /* 2700 MHz */ 0xA8C, 0x11b47, 10, 10, /* 27 */ 0x1B00, 0x1B00 }, 
           Package (0x06) { /* 2600 MHz */ 0xA28, 0x10d96, 10, 10, /* 26 */ 0x1A00, 0x1A00 }, 
           Package (0x06) { /* 2500 MHz */ 0x9C4, 0x10028, 10, 10, /* 25 */ 0x1900, 0x1900 }, 
           Package (0x06) { /* 2400 MHz */ 0x960, 0xf2fe, 10, 10, /* 24 */ 0x1800, 0x1800 }, 
           Package (0x06) { /* 2300 MHz */ 0x8FC, 0xe616, 10, 10, /* 23 */ 0x1700, 0x1700 },
           Package (0x06) { /* 2200 MHz */ 0x898, 0xd971, 10, 10, /* 22 */ 0x1600, 0x1600 }, 
           Package (0x06) { /* 2100 MHz */ 0x834, 0xcd0c, 10, 10, /* 21 */ 0x1500, 0x1500 }, 
           Package (0x06) { /* 2000 MHz */ 0x7D0, 0xc0e9, 10, 10, /* 20 */ 0x1400, 0x1400 }, 
           Package (0x06) { /* 1600 MHz */ 0x640, 0x92d9, 10, 10, /* 16 */ 0x1000, 0x1000 }
       })
Name (APSS, Package (0x13)
       {
/*  Core Frequency (MHz), Power (milliwats), Latency (ms), Bus Latency (ms), Control, Status */
           Package (0x06) { /* 3700 MHz */ 0xE74, 0x17318, 10, 10, /* 37 */ 0x2500, 0x2500 },
    Package (0x06) { /* 3600 MHz */ 0xE10, 0x17318, 10, 10, /* 36 */ 0x2400, 0x2400 }, 
    Package (0x06) { /* 3500 MHz */ 0xDAC, 0x17318, 10, 10, /* 35 */ 0x2300, 0x2300 }, 
    Package (0x06) { /* 3400 MHz */ 0xD48, 0x17318, 10, 10, /* 34 */ 0x2200, 0x2200 }, 
           Package (0x06) { /* 3300 MHz */ 0xCE4, 0x17318, 10, 10, /* 33 */ 0x2100, 0x2100 }, 
           Package (0x06) { /* 3200 MHz */ 0xC80, 0x163c6, 10, 10, /* 32 */ 0x2000, 0x2000 }, 
           Package (0x06) { /* 3100 MHz */ 0xC1C, 0x154ba, 10, 10, /* 31 */ 0x1F00, 0x1F00 }, 
           Package (0x06) { /* 3000 MHz */ 0xBB8, 0x145f5, 10, 10, /* 30 */ 0x1E00, 0x1E00 }, 
           Package (0x06) { /* 2900 MHz */ 0xB54, 0x13776, 10, 10, /* 29 */ 0x1D00, 0x1D00 }, 
           Package (0x06) { /* 2800 MHz */ 0xAF0, 0x1293c, 10, 10, /* 28 */ 0x1C00, 0x1C00 }, 
           Package (0x06) { /* 2700 MHz */ 0xA8C, 0x11b47, 10, 10, /* 27 */ 0x1B00, 0x1B00 }, 
           Package (0x06) { /* 2600 MHz */ 0xA28, 0x10d96, 10, 10, /* 26 */ 0x1A00, 0x1A00 }, 
           Package (0x06) { /* 2500 MHz */ 0x9C4, 0x10028, 10, 10, /* 25 */ 0x1900, 0x1900 }, 
           Package (0x06) { /* 2400 MHz */ 0x960, 0xf2fe, 10, 10, /* 24 */ 0x1800, 0x1800 }, 
           Package (0x06) { /* 2300 MHz */ 0x8FC, 0xe616, 10, 10, /* 23 */ 0x1700, 0x1700 },
           Package (0x06) { /* 2200 MHz */ 0x898, 0xd971, 10, 10, /* 22 */ 0x1600, 0x1600 }, 
           Package (0x06) { /* 2100 MHz */ 0x834, 0xcd0c, 10, 10, /* 21 */ 0x1500, 0x1500 }, 
           Package (0x06) { /* 2000 MHz */ 0x7D0, 0xc0e9, 10, 10, /* 20 */ 0x1400, 0x1400 }, 
           Package (0x06) { /* 1600 MHz */ 0x640, 0x92d9, 10, 10, /* 16 */ 0x1000, 0x1000 }
       })

 

 

 

2) the mysterious _TSS method is looking up index 0x1 in the PSS table (Power in mW) to populate the power field in the TSS table for processor throttling. ACPI specs are saying this value is normally ignored if P-states are defined, oh well. They are doing it anyways.

 

But as I'm ignoring additional throttling, I'm only defining one T-state (100%) and hardcoded the max TDP to 95W.

 

I now have this near replicate to the original SSDT and it still crashes. I'm wondering if the TableID in the DefinitionBlock at the beginning of the SSDT's are important.

 

 

ssdt_pr.dsl.zip

 

For the curious here is my complete rewrite of SSDT_PR, in this version I copied the SSDT-definition at the top to test if I could read out the C-states in their manner (thats why CMST is commented out). This might be rather dangerous.

Additionally there are some interesting comments throughout the file.

 

 

Edit: uhh, found a little bug. PSS must be called _PSS. Not that it makes a difference right now...

Link to comment
Share on other sites
flAked
flAked
Posted
Posted
I can safely test your SSDT_PR whit my system?

 

I'm currently running it on my system and didn't have any crashes. But after a test I would revert to your current version.

Try and see if IntelCPUPM loads.

 

In your DSDT.aml you need to change "Scope (_PR)" into "Scope (\_PR)" - not sure it's necessary, but I changed the SSDT to fit the original and they did it this way.

Link to comment
Share on other sites
Time2Retire
Time2Retire
Posted
  • Author
Posted

What about this:

I now have this near replicate to the original SSDT and it still crashes. I'm wondering if the TableID in the DefinitionBlock at the beginning of the SSDT's are important.

So he will get a KP or not?

 

BTW. I no longer have a _PSS object but only APSS in CPU0 and that works. That is. I see my 22 P-States in IORegistryExplorer. All other references to _PSS have been removed. Don't seem to need them anymore (because that was old school?). And yes. It still KP's like ever before.

 

p.s. APSS is read / used by ACPI_SMC_PlatformPlugin

Link to comment
Share on other sites
mrmojorisin17
mrmojorisin17
Posted
Posted

Currently testing your new SSDT_PR...

HackPro-di-mrmojorisin17:~ mrmojorisin17$ kextstat
  Index Refs Address			Size	   Wired	  Name (Version) <Linked Against>
  com.apple.driver.AppleIntelCPUPowerManagement (142.4.1) <7 6 5 4 3 1>

senzaolo.png

All appears to be ok.

One question: why in IORegistry I have CPU0,1,2,3 and also P000,1,2,3?

Thanks :rolleyes:

 

p.s. In E/E I have NullCPUPowerManagement.kext yet.

If I remove it I'll get a kp with dependencies AppleIntelCPUPowerManagement.kext.

Link to comment
Share on other sites
Time2Retire
Time2Retire
Posted
  • Author
Posted
Currently testing your new SSDT_PR...

All appears to be ok. One question: why in IORegistry I have CPU0,1,2,3 and also P000,1,2,3?

Thanks :rolleyes:

You need to drop the factory SSDT's. That's been said before here :P

 

I also have that in my kextstat output:

com.apple.driver.AppleIntelCPUPowerManagement (142.4.1) <7 6 5 4 3 1>

but I still need NullCPUPowerManagement (:

Link to comment
Share on other sites
flAked
flAked
Posted
Posted
What about this:

 

So he will get a KP or not?

 

BTW. I no longer have a _PSS object but only APSS in CPU0 and that works. That is. I see my 22 P-States in IORegistryExplorer. All other references to _PSS have been removed. Don't seem to need them anymore. And yes. It still KP's line ever before.

It will panic, sorry if I was misleading. I posted my edits to document the process.

 

Now thats interesting, seems they only read APSS and kept _PSS for some reason. At this point I'd like to be on the safe side and leave it in for now. That way we can rule it out in case of more errors later on.

I'll add a note that it could be removed once we load AICPUPM successfully.

Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...