Jump to content

DSDT for Asus P8P67-M PRO

Time2Retire

By Time2Retire,
in Patches

 Share
834 posts in this topic

Recommended Posts

ThisName
ThisName
Posted
Posted
If you boot the new BIOS without NullCPU please write down RCX of the KP, thanks!

 

According to that hardware site that you were referring to earlier, 0902 is the latest M PRO update. From what I've seen, they post there far before anything is posted to the Asus site itself. Odd but my PRO (non-M) updates have been legit (and eventually posted to the main Asus site). I think this is why you may actually get the attention of the people that need to know if a bug is found.

 

EDIT: Sorry, my mistake. The 0902 update is for the H67 board. :)

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

I don't know what to do with this needle in a haystack. I mean the MSR we should use. I can't find anything. We do have some good news also. We obtained the missing ACPI tables, being:

 

SSDT (Cpu0Cst).dsl

SSDT (ApCst).dsl

SSDT (ApIst).dsl

 

At least now we know what Apple is using, and what we have to change. However. Without knowing what this mystical MSR is... it is impossible for me to get things going.

 

Update: I found something that isn't right. CPUID.6H is 0x77 while is should be 0x7F and thus we have to set bit.

CPUID.6H:ECX[3] but I don't know how.

 

We use this function to read values: 

static inline void do_cpuid(uint32_t selector, uint32_t *data)
{
asm("cpuid"
	: "=a" (data[0]),
	  "=b" (data[1]),
	  "=c" (data[2]),
	  "=d" (data[3])
	: "a"(selector));
}

But there's also: 

static inline void cpuid(uint32_t *data)
{
asm("cpuid"
	: "=a" (data[eax]),
	  "=b" (data[ebx]),
	  "=c" (data[ecx]),
	  "=d" (data[edx])
	: "a"  (data[eax]),
	  "b"  (data[ebx]),
	  "c"  (data[ecx]),
	  "d"  (data[edx]));
}

Which I assume is what we should use. No luck so far...

Link to comment
Share on other sites
flAked
flAked
Posted
Posted

I believe CPUID is read-only throughout. The cpuid instruction is designed that way.

 

6H is about power management right? why is 0x77 wrong exactly and where is it being used?

 

If we need to change it, we must do it through a MSR.

Link to comment
Share on other sites
Time2Retire
Time2Retire
Posted
  • Author
Posted
I believe CPUID is read-only throughout. The cpuid instruction is designed that way.

Then why does BITS do this: 

	  DWORD_REGS cpuid6;
  cpuid32(0x6, &cpuid6._eax, &cpuid6._ebx, &cpuid6._ecx, &cpuid6._edx);
  temp64 = cpuid6._ecx & (1UL << 3);

That to me looks like a write action. See function detect_and_enable_energy_perf_bias_msr in

ppmstart.c

 

6H is about power management right? why is 0x77 wrong exactly and where is it being used?

 

If we need to change it, we must do it through a MSR.

It isn't wrong (bit 3 of ecx is already set). I got confused. Mixed eax and ecx. Well it is wrong but for a different reason; bit 5 (of eax) is set which should not be set, or we should extend _TSS.

 

BTW. This is what I get: 

	do_cpuid(0x00000006, gPlatform.CPU.ID[LEAF_6]);

printf("LEAF_6[eax]: 0x%x\n", getCachedCPUID(LEAF_6, eax)); // 0x77
printf("LEAF_6[ebx]: 0x%x\n", getCachedCPUID(LEAF_6, ebx)); // 0x02
printf("LEAF_6[ecx]: 0x%x\n", getCachedCPUID(LEAF_6, ecx)); // 0x09
printf("LEAF_6[edx]: 0x%x\n", getCachedCPUID(LEAF_6, edx)); // 0x00

Link to comment
Share on other sites
ThisName
ThisName
Posted
Posted

Not sure if this is relevant at all but I noticed in the BIOS updates that they listed this as a change. Maybe it'll be useful. If not, ignore. ;-)

 

"- Minor Bug Fixes including new Auto Rules for C-States (C3/C6) when overclocking. If you are overclocking, C-States will be disabled for enhanced performance. If you want EIST to work properly while overclocking, please ensure that C1E is enabled, C3 and C6 are also recommended to be enabled unless you are benchmarking 3DMark, PCMark, or Super PI."

Link to comment
Share on other sites
flAked
flAked
Posted
Posted
Then why does BITS do this: 
	  DWORD_REGS cpuid6;
  cpuid32(0x6, &cpuid6._eax, &cpuid6._ebx, &cpuid6._ecx, &cpuid6._edx);
  temp64 = cpuid6._ecx & (1UL << 3);

That to me looks like a write action. See function detect_and_enable_energy_perf_bias_msr in

ppmstart.c

cpuid6 is just a struct that get's filled in by cpuid32 and then we check on bit 3 locally.

Link to comment
Share on other sites
flAked
flAked
Posted
Posted
Ouch. Do I need glasses or what LOL

One get's easily confused with all these tech docs and registers :(

 

This one got me thinking: If we drop SSDT in RevoBoot and access 0x2E before _CST is read from the new SSDT, might that cause problems?

 

(not sure, but initPlatform -> initCPUstruct get called pretty early, do we have the SSDT loaded by that time?)

Link to comment
Share on other sites
Time2Retire
Time2Retire
Posted
  • Author
Posted
This one got me thinking: If we drop SSDT in RevoBoot and access 0x2E before _CST is read from the new SSDT, might that cause problems?

I checked this with the factory tables and with Apple replacement tables. No change / luck.

 

(not sure, but initPlatform -> initCPUstruct get called pretty early, do we have the SSDT loaded by that time?)

No. Done in finalizeEFITree().

 

Maybe this is just a side effect of the IGPU being disabled on P67P boards, or that boot.efi does something special. Unpacking this file and searching for rdmsr / wrmsr instructions might clue us in on what we need to do :mellow:

 

I know someone who unpacked the Asus BIOS and replaced the ACPI tables. so maybe he could help us. Tell us how this works so that we can change it and prevent bit 15 from being set maybe?

Link to comment
Share on other sites
flAked
flAked
Posted
Posted
I know someone who unpacked the Asus BIOS and replaced the ACPI tables. so maybe he could help us. Tell us how this works so that we can change it and prevent bit 15 from being set maybe?

Sounds like a plan.

 

In the changelog for the Maximus:

CFG Lock to Disable should improve SuperPI times even better now

As C-States are performance-related maybe this is just our CFG Lock, I don't know. Maybe we can unlock hidden BIOS features.

 

I also posted in the Intel developer forum, no response so far.

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

Interesting. He asked you to PM him with what we need. That sure sounds promissing doesn't it.

 

I have been collecting data and info to see what I can do to keep my highest Geekbench score ever (17K OC'ed) but without the latest xnu source code... that is close to impossible. More like a time wasting event, but at least I am learning a lot new things. And when that new source code is there... soon, I think to know what I have to do with it :)

Link to comment
Share on other sites
flAked
flAked
Posted
Posted
Interesting. He asked you to PM him with what we need. That sure sounds promissing doesn't it.
Sent you a copy :D

 

I have been collecting data and info to see what I can do to keep my highest Geekbench score ever (17K OC'ed) but without the latest xnu source code... that is close to impossible. More like a time wasting event, but at least I am learning a lot new things. And when that new source code is there... soon, I think to know what I have to do with it :D

What's the highest multiplier you can use reliably? I also got a watercooler-block with a 30cm radiator. My stock temps on 3,3GHz are at 40°C, so plenty headroom.

Link to comment
Share on other sites
Time2Retire
Time2Retire
Posted
  • Author
Posted
Sent you a copy :P

Thanks. Can you add the P8P67-M PRO and Deluxe as well? That might trigger more attention (not just one board / customer).

 

What's the highest multiplier you can use reliably? I also got a watercooler-block with a 30cm radiator. My stock temps on 3,3GHz are at 40°C, so plenty headroom.

I'm not much of an OC lady but my brother got it to run at 54 but I'm down to 50 to let the fans run more quiet.

 

Note that I have two radiators. One large 3 x 120 and one smaller 1 x 120 with two pumps. One dedicated to the chipset (blue hoses) and the other with red hoses for the CPU and GPU combo. The highest temperature reading I got so far was only 68°C but still, I am thinking of going for a triple hose / pump / radiator system or at least change the combination of CPU and GPU. As long as I don't have to mess with the coolant :D

Link to comment
Share on other sites
davidm71
davidm71
Posted
Posted
Note that I have two radiators. One large 3 x 120 and one smaller 1 x 120 with two pumps. One dedicated to the chipset (blue hoses) and the other with red hoses for the CPU and GPU combo. The highest temperature reading I got so far was only 68°C but still, I am thinking of going for a triple hose / pump / radiator system or at least change the combination of CPU and GPU. As long as I don't have to mess with the coolant :P

 

Since your off topic now curious to see your water cooled rig. Please post a picture...

Link to comment
Share on other sites
flAked
flAked
Posted
Posted
No. Done in finalizeEFITree().

So the debug code in intel/dynamic_data is actually using the old ACPI information?

 

I'm not sure about this, are any of the MSR influenced by the ACPI tables?

 

Basically, if we define a different _CST at which point is it going to be used and is there some kind of resync into register-data after a table changed?

Link to comment
Share on other sites
Time2Retire
Time2Retire
Posted
  • Author
Posted
So the debug code in intel/dynamic_data is actually using the old ACPI information?

It is using the BIOS/UEFI defaults and what we give it.

 

I'm not sure about this, are any of the MSR influenced by the ACPI tables?

Not that I'm aware of, and I can't find any rdmsr/wrmsr opcodes in AppleACPIPlatform.kext. What I did find was a bunch of PCI configuration space register read/write actions.

 

Basically, if we define a different _CST at which point is it going to be used and is there some kind of resync into register-data after a table changed?

I located both _CST and ACST (just like APSS) in ACPI_SMC_PlatformPlugin.kext and thus this kext must be loaded/started, which of course only works after the mach_kernel itself is fired up.

 

And there's Notify (0x81) for which I found this text in the ACPI specification:

"C States Changed. Used to notify OSPM that the number or type of supported processor C States has changed. This notification causes OSPM to re-evaluate the _CST object. See section 8, “Processor Configuration and Control,” for more information."

 

I also noticed the following text in the Intel docs:

"Note: C-state values are processor specific C- state code names, unrelated to MWAIT extension C-state parameters or ACPI C- States."

Taken from (252046.pdf) MSR 0x60A, 0x60B and 0x60C That's a lot of different C-States. Getting a bit confusing isn't it?

Link to comment
Share on other sites
flAked
flAked
Posted
Posted
And there's Notify (0x81) for which I found this text in the ACPI specification:

"C States Changed. Used to notify OSPM that the number or type of supported processor C States has changed. This notification causes OSPM to re-evaluate the _CST object. See section 8, “Processor Configuration and Control,” for more information."

I found some Notfiy() uses for sleep-related functions but not for C-States. I would think this is also just a implementation choice and not something that is required by ACPI specs.

 

I also noticed the following text in the Intel docs:

"Note: C-state values are processor specific C- state code names, unrelated to MWAIT extension C-state parameters or ACPI C- States."

Taken from (252046.pdf) MSR 0x60A, 0x60B and 0x60C That's a lot of different C-States. Getting a bit confusing isn't it?

So, ACPI C-States are a kind of meta-states, identical across all CPU's of certain family. Then we have the actual hardcoded states, so I would think this makes the difference of FFixedHW vs SystemIO.

Those MWAIT extension C-states are a bit unclear to me.

 

ACST was in the missing tables right? Maybe this will populate CSTInfo once again.

Link to comment
Share on other sites
Time2Retire
Time2Retire
Posted
  • Author
Posted
I found some Notfiy() uses for sleep-related functions but not for C-States. I would think this is also just a implementation choice and not something that is required by ACPI specs.

I think to have seen it (mention) once but I have to check that.

 

 

So, ACPI C-States are a kind of meta-states, identical across all CPU's of certain family. Then we have the actual hardcoded states, so I would think this makes the difference of FFixedHW vs SystemIO. Those MWAIT extension C-states are a bit unclear to me.

 

ACST was in the missing tables right? Maybe this will populate CSTInfo once again.

Yup. SSDT(ApCst).dsl does:

Method (_CST, 0, NotSerialized)
	{
		Return (\_PR.CPU0._CST)
	}

For CPU 1-7 and SSDT(ApCst).dsl does the same kind of thing for methods _PPC, _PCT, _PSS, APSS and _PSD while SSDT(Cpu0Cst).dsl

includes all (A)CST goodies. Just to let you know so that when you do look at the new iMac ACPI tables (see attachment) that you know where to look for :thumbsup_anim:

iMac12_ACPI_tables.zip

Link to comment
Share on other sites
flAked
flAked
Posted
Posted

Nice writeup of C-States: http://software.intel.com/en-us/blogs/2008...n-more-c-states

 

Some news?

I heard nothing specific, the biggest news for us is that we get a combo update with all necessary files and a unified system.

 

You could check if they included a new version of AppleIntelCPUPM, although I doubt they changed the code that is kp'ing on us.

 

At the moment we can just wait and see what the contact at ASUS will tell us (hopefully some time next week).

Link to comment
Share on other sites
mrmojorisin17
mrmojorisin17
Posted
Posted
I heard nothing specific, the biggest news for us is that we get a combo update with all necessary files and a unified system.

 

You could check if they included a new version of AppleIntelCPUPM, although I doubt they changed the code that is kp'ing on us.

I'll don't have my hack until monday...

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