Jump to content

DSDT for Asus P8P67-M PRO


Time2Retire
 Share

834 posts in this topic

Recommended Posts

RevoBoot:

bus-frequency : 400000000

clock-frequency : 3310000000

timebased-frequency: 1000000000

 

Chameleon:

*reboot*

Thanks. I may have found something in AppleSMBIOS.cpp

		if (busSpeedMTs == 0)
	{
		busSpeedMTs = cpuInfo->externalClock;
		busSpeedMTs *= 4;  // Assume quad-pumped FSB
		DEBUG_LOG("SMBIOS: FSB speed (MT/s) = %u\n", busSpeedMTs);
	}

Let me try something...

Link to comment
Share on other sites

I can't get my chipset recognized well :(

With new AppleAHCIPort.kext (2.1.7) is not recognized also with huronplist in FakeSMC.kext.

Any suggestion?

Yes. Please be patience. We shouldn't waste our time on cosmetic only issue. We should try to fix the more important issues first. Like trying AppleSMBIOS.kext from Lion :P

Link to comment
Share on other sites

Booting Chameleon with the same DSDT/SSDT as in Revo and using DropSSDT I get:

 

- bus-frequency: <ff ff ff ff>

 

- matched AppleSMCPDRC under MCHC

 

- matched AGPMEnabler

 

using a MBP8,1 definition.

 

 

Booting Chameleon with iMac12,3 and the two matchings are gone.

 

 

I'll try Chimera next if it changes anything @bus-frequency. Nope.

 

And the strange part is that Revo, Chameleon, Chimera all doing the same calculation:

203	                msr = rdmsr64(MSR_PLATFORM_INFO);
204	                DBG("msr(%d): platform_info %08x\n", __LINE__, msr & 0xffffffff);
205	                currcoef = (msr >> 8) & 0xff;
206	                msr = rdmsr64(MSR_FLEX_RATIO);
207	                DBG("msr(%d): flex_ratio %08x\n", __LINE__, msr & 0xffffffff);
208	                if ((msr >> 16) & 0x01) {
209	                    flex_ratio = (msr >> 8) & 0xff;
210	                    if (currcoef > flex_ratio) {
211	                        currcoef = flex_ratio;
212	                    }
213	                }
214	
215	                if (currcoef) {
216	                    fsbFrequency = (tscFrequency / currcoef);
217	                }
218	                cpuFrequency = tscFrequency;

 

NEWS: as promised, here are the full ACPI tables from ghorwith, I decompiled them with iasl already.

acpi_ghorwith.zip

Link to comment
Share on other sites

Booting Chameleon with the same DSDT/SSDT as in Revo and using DropSSDT I get:

 

- bus-frequency: <ff ff ff ff>

This is wrong. There is no QPI (Interconnect Speed) on our SB CPU's. We use DMI instead.

 

I'll try Chimera next if it changes anything @bus-frequency. Nope.

Thank you for testing this!

 

And the strange part is that Revo, Chameleon, Chimera all doing the same calculation:...

Correct. Looked into this and I had it loaded when I lowered the bus speed so this is definitely worth the trouble of fixing it. My number one priority now!

 

NEWS: as promised, here are the full ACPI tables from ghorwith, I decompiled them with iasl already.

acpi_ghorwith.zip

Fabulous. Too bad that I don't have time to look at it now. Way too busy fixing that stupid bug.

Link to comment
Share on other sites

Great work! ;)

 

(if you need testing, send me a diff)

Thanks. Will update github a.s.a.p. And here's my Cinebench 11.5 report:

 

post-669976-1304638182_thumb.png post-669976-1304664546_thumb.png

 

The right one is from before my changes – had a similar Geekbench improvement with RevoBoot (called Revolution at that time) back in the day that I worked on the HP G72. So what do you think of it?

 

Note: Everything with default (factory) settings!

 

p.s. I will take a break first because I am starting to make errors. Back later...

Link to comment
Share on other sites

What do you think?

 

Note: Everything with default (factory) settings!

Could be Cinebenchs fault...

 

If you look at this http://browse.geekbench.ca/geekbench2/view/404772 you'll see that you have much better memory performance, hence a higher score.

 

Also remember that the iMac12 is on Z67 and they possibly adjusted the thermal threshold - and remember that we run a different system, slashed together without PowerManagement, which could have be active at the start of this Geekbench run.

 

Those numbers are still reasonable, if you did something completely wrong, it would be more astronomical and probably crashed.

 

BTW, Cinebench 11.5 only shows 2 Cores, 4 Threads @ 3.31 GHz and only 4.82 pts - which is totally wrong. I'll take another shot booting Revo.

Link to comment
Share on other sites

I have an audio stutter to fix. Patch is not ready for prime time. Might need to rethink / rewrite the whole thing again.

 

And is it just me or what? Am I getting crazy? Didn't we had EHC1@1D,7 EHC1@1A,7 at first? I somehow lost the ,7 LOL

 

Note: This could mean that I have to update ssdt_usb.dsl again

 

Nah you silly. That's on a real Mac :)

 

It's probably a side effect of what I see in kernel.log but hey... I like to know things:

PFM64 0xf10000000, 0xf0000000
[ PCI configuration begin ]
console relocated to 0xf10000000
PCI configuration changed (bridge=5 device=2 cardbus=0)
[ PCI configuration end, bridges 7 devices 12 ]

Link to comment
Share on other sites

{censored}. I found a serious error in my boot loader:

 

RevoBoot

--------

bus-frequency : 400000000

clock-frequency : 3411000000

timebased-frequency: 1000000000

 

MacBookPro8,3

-------------

bus-frequency : 100000000

clock-frequency : 2200000000

timebased-frequency: 1000000000

 

If that can help you with chameleon chimera branch and a core i5 2500 (10.6.7 imac upate)

and a P8H67-V (hope this is close enought of your board):

 

bus-frequency: 4294967295

clock-frequency: 3432000000

timebased-frequency: 1000000000

Link to comment
Share on other sites

If that can help you with chameleon chimera branch and a core i5 2500 (10.6.7 imac upate) and a P8H67-V (hope this is close enought of your board):

 

bus-frequency: 4294967295

Thanks. Your bus frequency is 430% of what it should be. Same problem.

 

clock-frequency: 3432000000

This value is either wrong, or you've OC'ed your rig?

 

timebased-frequency: 1000000000

This one is fine.

 

Update: Audio stutter issue is slowly becoming a non-issue. Still there but now in rare circumstances only but I still want/need to figure out what is causing it.

 

Turbo appears to working too because I see very different results in Geekbench – with a top score of almost 14.000 (be it only once).

 

post-669976-1304680183_thumb.png

Link to comment
Share on other sites

Thanks. Your bus frequency is 430% of what it should be. Same problem.

 

This value is either wrong, or you've OC'ed your rig?

 

This is the value in BIOS, same under linux, I did something int he bios with the dram to push it a little, so it's ok.

The difference with the real one is maybe just cause the CPU PM client is not loaded...

Good investigation.

Link to comment
Share on other sites

Thanks. Your bus frequency is 430% of what it should be. Same problem.

That's the same I got, 0xFFFFFFFF = 4294967295

 

 

This is the value in BIOS, same under linux, I did something int he bios with the dram to push it a little, so it's ok.

The difference with the real one is maybe just cause the CPU PM client is not loaded...

Good investigation.

How did you extract the fsb-value under linux, dmidecode?

Link to comment
Share on other sites

That's the same I got, 0xFFFFFFFF = 4294967295

That's the limiter. Look here (AppleSMBIOS.cpp):

gPEClockFrequencyInfo.bus_clock_rate_hz = (rateInTs < (1ULL << 32)) ? (uint32_t) rateInTs : 0xFFFFFFFF;

Anything above it (4294967296 / 0x100000000) gets reset to: 0xFFFFFFFF hence the 4294967295

 

And there's the new iMac LATER!!!!

Link to comment
Share on other sites

Yeah it is great to have friends who are avid Mac users... but can't install OS X – I told her that the first thing we devs do is to backup the installation disc :P

 

Anyway. I need to reconfigure some IRQ's in the DSDT for the PCI device and learn to write a (very) simple kext. One that writes exactly one property on efi/platform (to see if I am right) but I'm exhausted by all this work. Have hockey training in a few minutes anyway.

 

Anyone else here up for the job? Go ask, beg if you have to, so that we can continue.

 

There's also a wealth of new dumps and info that I need to digest. Like I haven't anything else to do LOL

Link to comment
Share on other sites

Anyone else here up for the job? Go ask, beg if you have to, so that we can continue.

Not a problem, I know my way around. Currently working on the CMI8738 driver.

So just write me note what you need.

Link to comment
Share on other sites

Not a problem, I know my way around. Currently working on the CMI8738 driver. So just write me note what you need.

Ah great. Just back home. Now. I need to inject a property on the IODeviceTree under /efi/platform Can you write up a basic sceleton that we can use? That would be great. So and now I need drink first. I'm thirsty...

Link to comment
Share on other sites

Ah great. Just back home. Now. I need to inject a property on the IODeviceTree under /efi/platform Can you write up a basic sceleton that we can use? That would be great. So and now I need drink first. I'm thirsty...

OK, on it.

Link to comment
Share on other sites

Based on superhai's SMBIOSResolver I made this little kext.

 

It reads out /efi/platform and you can use setProperty() to do your magic.

 

You might want to change IOResourceMatch to IOKit and IOProviderClass to IOService in the plist, depending on what you want to do. I'll load it up and see if it's necessary. Working as is, if you change the IOLog line it will actually print out some frequency, in my case 100329070.

 

Edit: removed. Will be released if necessary and when finished.

 

For anybody else downloading this: it's an Xcode project with a kext skeleton, it doesn't actually do anything ;)

Link to comment
Share on other sites

 Share

×
×
  • Create New...