DSDT for Asus P8P67-M PRO

Posted 07 June 2011 - 07:40 PM

neogeo

InsanelyMac Protégé

Members

45 posts

Trying to digest this thread as best I can. I am just starting out with a build based on this board. Will there be a step by step guide on setting this up with revoboot? Would love to get this working but kinda lost at the moment...

Posted 07 June 2011 - 07:57 PM

buoo

The Prodigal Son

Moderators

4,582 posts

Gender:Male

Location:Italy

Excuse me flAked

Do the values those we add in CPU/STATIC_DATA.C complete the job that the SSDT does to get the speedstep working? I mean.... if I don't add these values does the speedstep work in the same way ?
Looking around I could see that several users have a no complete working (9 different p-states, like you).
Probably they use Chameleon which doesn't allow to insert these values.

Posted 07 June 2011 - 09:16 PM

mrmojorisin17

InsanelyMacaholic

Members

3,942 posts

Gender:Male

Yep, I've seen it I think that the sound assertion that comes out in kernel.log depends on something on AppleHDADriver.cpp, so I asked you if you know where to get AppleHDA source code.Or maybe it depends to something else in NVClockX code... I don't know

For sure sound assertion depends to NVClockX (I don't think it depends to IntelCPUMonitor) because the errors in kernel.log appears after upgrading this PlugIn!

Posted 08 June 2011 - 01:52 PM

They have changed a lot in the NVClockX code, but I don't have the time to look into it.

I suggest posting this issue @projectosx in the FakeSMC thread.

I posted and explained my issue yesterday but for the moment I get no-response.I take a look at NVClockX code but I didn't find anything related to a possible sound assertion, surely because I don't know where I have to look exactly.

Any news regarding chipset? Is there a possibility to get correct info showed in System Profiler without plist injection in FakeSMC?

Posted 08 June 2011 - 02:29 PM

mrmojorisin17

InsanelyMacaholic

Members

3,942 posts

Gender:Male

Sorry, maybe I explained in a bad way.I know that instead of injection plist I can use a method _DSM in DSDT or a dummy kext I just want to know if there is a method to get chipset perfectly recognized in a Vanilla way, only with AppleAHCPort that contains the id of our chipset.

EFI injection is favored, but as discussed in the thread I wasn't able to manually generate the injection data for my GFX.

What are you using at the moment to get VGA working? Graphics Enabler? Or something else?You can try to get your current VGA injection with Lizard and compare the plist-out with the one that you've created.

Posted 08 June 2011 - 03:00 PM

I just want to know if there is a method to get chipset perfectly recognized in a Vanilla way, only with AppleAHCPort that contains the id of our chipset.

Does it work if you delete Item1 in the AppleAHCIPort plist?

Looking at the iMac12,2 ACPI tables 1C,2 is actually the firewire device. That must mean that the SATA device is at 1C,3 and getting matched on that address. If we look at the device definitions there is actually no RP04 device defined, which would have the 1C,3 address.

Posted 08 June 2011 - 04:10 PM

flAked

InsanelyMac Sage

Members

470 posts

Gender:Male

Location:internets

What are you using at the moment to get VGA working? Graphics Enabler? Or something else?You can try to get your current VGA injection with Lizard and compare the plist-out with the one that you've created.

Oh wow, that is very cool. It's actually doing what I was trying to figure out, getting the current injection, sweet I'm currently using static injection data that I got from booting Chameleon with GraphicEnabler and the efi2struct tool.

Posted 08 June 2011 - 06:15 PM

Looking at the iMac12,2 ACPI tables 1C,2 is actually the firewire device. That must mean that the SATA device is at 1C,3 and getting matched on that address. If we look at the device definitions there is actually no RP04 device defined, which would have the 1C,3 address.

Posted 08 June 2011 - 06:40 PM

You need the processor definitions in the PR scope of your DSDT. The factory tables don't include them.You don't want any generated P/C-States by Chameleon, it is all done in the DSDT/SSDT.

So have you changed AR13 with AR12?Any idea to solve this issue?

Yes I have updated all the AR definitions for the P8P67, anyone modifying DHP's DSDT to match their board must do the same, on top of additional differences.

I don't have an idea right now, but it's pretty low priority because it is only cosmetic and can be fixed by various means. I think DHP mentioned something about missing IRQs. Would be a lot of work figuring out why it doesn't match and emulating IRQs of a different hardware system is not something I'm keen to do.