Asus Rampage IV Extreme Guide: Create your DSDT in 5 min using MacIASL.

[RehabMan]

I have DTGP in my DSDT and I just added DTGP to the end of my current SSDT and it still loads.

Also, I'd love your input on assigning IRQs in the SSDT. Is it possible to assign 4 of them to HPET without removing it completely and adding it back with a new name?

How are you determining that it loads?

 

[shilohh]

How are you determining that it loads?

X86PlatformPlugin loads properly in IOReg and MacIASL extracts it as SSDT-1 (I don't drop the OEM SSDT).

 

[RehabMan]

X86PlatformPlugin loads properly in IOReg and MacIASL extracts it as SSDT-1.

MaciASL extracts whatever is in ioreg. Doesn't mean that the OS loaded it.

I just know that I've seen problems when you have duplicates. It could be an exception made if the bits in the method are equal in both files.

Without seeing an ioreg, I can't make any assumptions/conclusions.

 

[shilohh]

IOReg with/without DTGP in the SSDT attached.

And I know they are both loaded because I have audio from HDEF in the DSDT and the X86PlatformPlugin doesn't load without the PluginType 1 edit from the SSDT (SpeedStep and Turbo are both working). Spoke too soon. Multiplier is locked @ 12 so there's definitely an issue but the table is loaded.

 

[RehabMan]

IOReg with/without DTGP in the SSDT attached.

And I know they are both loaded because I have audio from HDEF in the DSDT and the X86PlatformPlugin doesn't load without the PluginType 1 edit from the SSDT (SpeedStep and Turbo are both working). Spoke too soon. Multiplier is locked @ 12 so there's definitely an issue but the table is loaded.

If you don't have SS/Turbo then it is likely the cause.

I just tried it here and my system won't boot that way (only safe mode).

If I extract your tables from ioreg, then use 'iasl -da *' to disassemble from one ACPI namespace, it fails (due to duplicate DTGP)... a sure sign that something will not work as you expect.

The table in ioreg means nothing...

I think the conclusion here is duplicate methods are a bad idea, and the specifics are not worth investigating.

 

[shilohh]

I fully agree with you after this little exercise. Any thoughts on assigning IRQs to HPET in a SSDT?

 

[RehabMan]

... Any thoughts on assigning IRQs to HPET in a SSDT?

Not really. I don't see the point.

 

[shilohh]

Not really. I don't see the point.

The point would be not extracting the DSDT at all and just overriding the code from the OEM DSDT with a SSDT.

 

[RehabMan]

The point would be not extracting the DSDT at all and just overriding the code from the OEM DSDT with a SSDT.

I don't see the point to that either. I have an automated process to patch DSDT/SSDTs should I flash a new BIOS or upgrade other hardware. It takes less time to create the new ACPI set than it does to flash the new BIOS.

IRQ fix requires removing from one place and inserting in another. I don't see how you're going to do that with SSDT alone.

 

[frontend-dev]

The USB edits in the patch list mainly just fix ACPI 5.0 compiling errors and tell OS X what current capabilities the ports have. These aren't REALLY necessary if you want to use the SSDT method. USB has always functioned fine without a DSDT with the exception of IRQ conflicts. Just add this to your SSDT before SAT0 or NPE3 to get your "power button only wake function".

Think the current capabilities aren't really necessary. Just the same result with my various devices. What I needed to enable is additional charging support with USB3 (to get my iPad charging) but this was done via BIOS and OS X was OK with it.

And yes, that was the clock ID patch I talked about - Already had done that

I've never had a single issue with CMOS resets or the Real Time Clock misbehaving. I'm not even sure that "RTC: Only single RAM bank (128 bytes)" is a problem but I'll add a DSDT patch to my system and see how it goes.

Also not sure this is a problem without the patch. The message went away but not much else seems to have changed. Obviously this has something to do with memory allocation to the RTC. But as it seems RTC is also fine with just 128 bytes so not sure if more RAM gives additional benefits / stability.