Jump to content

DSDT for Asus P8P67-M PRO


  • Please log in to reply
833 replies to this topic

#761
neogeo

neogeo

    InsanelyMac Protégé

  • Members
  • Pip
  • 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...

#762
buoo

buoo

    The Prodigal Son

  • Moderators
  • 4,536 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.

#763
flAked

flAked

    InsanelyMac Sage

  • Members
  • PipPipPipPipPipPip
  • 470 posts
  • Gender:Male
  • Location:internets

Can you make a test with onboard sound active?
Do you know where I can find AppleHDA source code?
Are you kidding me? After all the work that you and DHP had made it was the least I could do!

Sound is active at the moment, but I get assertions anyways, because I didn't patch AppleHDA, which is closed source btw. Otherwise we wouldn't need to bin-patch it.

Oh, well. I'm still grateful if people are doing experiments on their own, I constantly get angry at the "everything gets fixed for you" attitude.

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...

I'll include a quick rundown of the important RevoBoot settings, yes.

Do the values those we add in CPU/STATIC_DATA.C complete the job that the SSDT does to get the speedstep working?

You can use either the static or dynamic CPU detection in RevoBoot, it's just a speedup to the boot process.

The last time I checked the Chimera code there were still bugs for SandyBridge (wrong busspeed for example). RevoBoot was extended/developed to set up things correctly for SB.

And no, the CPU data is just for basic setup, the SSDT_PR includes the necessary P-State information.

#764
mrmojorisin17

mrmojorisin17

    InsanelyMacaholic

  • Members
  • PipPipPipPipPipPipPipPipPipPipPip
  • 3,942 posts
  • Gender:Male

Sound is active at the moment, but I get assertions anyways, because I didn't patch AppleHDA, which is closed source btw. Otherwise we wouldn't need to bin-patch it.

Ok, thanks. I'll make some other test when someone'll reply @ my post to ProjectOSX.

Oh, well. I'm still grateful if people are doing experiments on their own, I constantly get angry at the "everything gets fixed for you" attitude.

I like to make test because is a method to learn something new.
Naturally for things that don't require development knowledges ;)

#765
flAked

flAked

    InsanelyMac Sage

  • Members
  • PipPipPipPipPipPip
  • 470 posts
  • Gender:Male
  • Location:internets

Ok, thanks. I'll make some other test when someone'll reply @ my post to ProjectOSX.

If you haven't seen it already, here is a in-depth tutorial: http://www.projectos...p?showtopic=465

#766
mrmojorisin17

mrmojorisin17

    InsanelyMacaholic

  • Members
  • PipPipPipPipPipPipPipPipPipPipPip
  • 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 :wacko:

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!

But from what in particular?

#767
buoo

buoo

    The Prodigal Son

  • Moderators
  • 4,536 posts
  • Gender:Male
  • Location:Italy
Hei flaked could you verify the validity of this ssdt_pr for 2600k ?

Thanks ;)

Attached Files



#768
flAked

flAked

    InsanelyMac Sage

  • Members
  • PipPipPipPipPipPip
  • 470 posts
  • Gender:Male
  • Location:internets

Hei flaked could you verify the validity of this ssdt_pr for 2600k ?

Looks good. Have you changed anything? This looks like the standard SSDT_PR for 2600K.

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!

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.

#769
mrmojorisin17

mrmojorisin17

    InsanelyMacaholic

  • Members
  • PipPipPipPipPipPipPipPipPipPipPip
  • 3,942 posts
  • Gender:Male

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?

#770
flAked

flAked

    InsanelyMac Sage

  • Members
  • PipPipPipPipPipPip
  • 470 posts
  • Gender:Male
  • Location:internets

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

Either by using DSM (which is slow), making a dummy kext (so you haven't have to worry about FakeSMC updates) or the EFI injecting discussed here

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

#771
mrmojorisin17

mrmojorisin17

    InsanelyMacaholic

  • Members
  • PipPipPipPipPipPipPipPipPipPipPip
  • 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.

#772
flAked

flAked

    InsanelyMac Sage

  • Members
  • PipPipPipPipPipPip
  • 470 posts
  • Gender:Male
  • Location:internets

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.

In our DSDT we do have this:
Device (RP03) // Renamed from: PEX2
{
 Alias (AR13, _PRT) //changed from AR12
 Alias (PW94, _PRW)
 Name (_ADR, 0x001C0002)
}
So the device gets matched twice. Let's try and remove that.

That didn't change anything. Now let's remove Item1. That didn't change anything, either.

We have the identical plist definition and still no match. That can only mean that the kext probe() function is checking for more (IRQs?) where the dummy kext is just matching without probing.

#773
flAked

flAked

    InsanelyMac Sage

  • Members
  • PipPipPipPipPipPip
  • 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.

#774
mrmojorisin17

mrmojorisin17

    InsanelyMacaholic

  • Members
  • PipPipPipPipPipPipPipPipPipPipPip
  • 3,942 posts
  • Gender:Male
With Lizard I got my VGA injection (Graphics Enabler in com.apple.Boot.plist) that, after conversion in little endian format, is working great here in EFI/data.h.

#775
Regi Yassin

Regi Yassin

    Who am I ?

  • Members
  • PipPipPipPipPip
  • 278 posts
  • Gender:Not Telling
can i ask my question here?

why my bdmesg showed me this,

ACPI CPUs not found: C-States not generated !!!
ACPI CPUs not found: P-States not generated !!!

how can i fix this?

#776
mrmojorisin17

mrmojorisin17

    InsanelyMacaholic

  • Members
  • PipPipPipPipPipPipPipPipPipPipPip
  • 3,942 posts
  • Gender:Male

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

Nope. System Profiler always shows me Unknown AHCI Standard Controller.

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.

In our DSDT we do have this:

Device (RP03) // Renamed from: PEX2
 {
  Alias (AR13, _PRT) //changed from AR12
  Alias (PW94, _PRW)
  Name (_ADR, 0x001C0002)
 }
So the device gets matched twice. Let's try and remove that.

In my DSDT I have this:
Device (RP03)
			{
				Alias (AR12, _PRT)
				Alias (PW94, _PRW)
				Name (_ADR, 0x001C0002)
			}
So have you changed AR13 with AR12?

We have the identical plist definition and still no match. That can only mean that the kext probe() function is checking for more (IRQs?) where the dummy kext is just matching without probing.

Any idea to solve this issue?

#777
buoo

buoo

    The Prodigal Son

  • Moderators
  • 4,536 posts
  • Gender:Male
  • Location:Italy

can i ask my question here?

why my bdmesg showed me this,

ACPI CPUs not found: C-States not generated !!!
ACPI CPUs not found: P-States not generated !!!

how can i fix this?



"not found" Did you name correctly the SSDT ?

#778
Regi Yassin

Regi Yassin

    Who am I ?

  • Members
  • PipPipPipPipPip
  • 278 posts
  • Gender:Not Telling

"not found" Did you name correctly the SSDT ?


Read HFS+ file: [hd(0,2)/Extra/DSDT.aml] 34179 bytes.
Table /Extra/DSDT.aml read and stored at: e5f000
Read HFS+ file: [hd(0,2)/Extra/SSDT.aml] 1304 bytes.
Table /Extra/SSDT.aml read and stored at: e68000
Read HFS+ file: [hd(0,2)/Extra/SSDT-1.aml] 1046 bytes.
Table /Extra/SSDT-1.aml read and stored at: e69000

its loaded, right?

#779
flAked

flAked

    InsanelyMac Sage

  • Members
  • PipPipPipPipPipPip
  • 470 posts
  • Gender:Male
  • Location:internets

"not found" Did you name correctly the SSDT ?

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.

#780
buoo

buoo

    The Prodigal Son

  • Moderators
  • 4,536 posts
  • Gender:Male
  • Location:Italy

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 in the DSDT there must to be

Scope (_PR)
{
	   Processor (CPU0, 0x01, 0x00000410, 0x06) {}
	   Processor (CPU1, 0x02, 0x00000410, 0x06) {}
	   Processor (CPU2, 0x03, 0x00000410, 0x06) {}
	   Processor (CPU3, 0x04, 0x00000410, 0x06) {}
	   Processor (CPU4, 0x05, 0x00000410, 0x06) {}
	   Processor (CPU5, 0x06, 0x00000410, 0x06) {}
	   Processor (CPU6, 0x07, 0x00000410, 0x06) {}
	   Processor (CPU7, 0x08, 0x00000410, 0x06) {}
   }

I got it. Right?


@edit: regae says that using the SSDT that I've posted before and adding this in DSDT he gets a kernel panic.





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

© 2014 InsanelyMac  |   News  |   Forum  |   Downloads  |   OSx86 Wiki  |   Mac Netbook  |   PHP hosting by CatN  |   Designed by Ed Gain  |   Logo by irfan  |   Privacy Policy