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

[frontend-dev]

Seems you can workaround the startup freeze with VT-d using the "dart=0" flag. Not sure if VT-d is enabled yet but will continue testing.

Edit: just researched a bit, and even IF you could enable VT-d there is almost no point doing so, bc there seems not to be a single piece of software on OS X which would actually support that feature. So as I work a lot with VMs I hoped for better GPU Emulation, but as it seems neither Parallels nor VMWare do support VT-d on OS X.

So, it seems that I can disable it, bc it seems to be useless right now ... just FYI.

 

[shilohh]

My goal was not to enable Vt-d but simply to give the OS the tools (found in the mac pro dsdt) to interface with the x79 chipset. If you're on clover and you really want vt-d in OS X for some reason, you have to remove drop dmar from your config and make sure you're not booting with dart=0. It probably still won't work but those are all the things that disable Vt-d.

I've labeled all the patches in the list. Just remove anything you don't understand or want to use if you're really that worried about it. I'm not going to write a book about the patches I use but the information is out there on the Internet.

As far as trying to change as little as possible in the dsdt, that doesn't help or serve you in any way. The only thing that would help the dsdt table function more like it should, is not to extract it at all. Once you extract the dsdt and tell the bootloader to inject your modified dsdt instead of getting the AML code from the bios, the code is no longer dynamic and can't be changed by the bios when you add or remove hardware. This is why you need to extract and patch a new dsdt after switching or moving graphics cards or other pci hardware. Each extract is a snap shot but the bios usually gives code to the OS based on your hardware and settings. Until I find a way to fix irqs in the ssdt, I'll be using a patched dsdt and as long as I am, I'll be patching everything from the dsdt table, in the dsdt table. I'm not saying my way is the only right way. By all means, find your own way.

 

[frontend-dev]

If you're on clover and you really want vt-d in OS X for some reason, you have to remove drop dmar from your config and make sure you're not booting with dart=0. It probably still won't work but those are all the things that disable Vt-d.

Ah OK so it still might not work ... well I think I will disable it anyways.

I'm not going to write a book about the patches I use but the information is out there on the Internet.

Well for many edits I haven't found any information, and I know how to use a search engine

Until I find a way to fix irqs in the ssdt, I'll be using a patched dsdt and as long as I am, I'll be patching everything from the dsdt table, in the dsdt table. I'm not saying my way is the only right way. By all means, find your own way.

Hey I did not meant to offend anyone, in fact I do appreciate all your work Just curious why you did it this way and not the other way round.

 

[shilohh]

Hey I did not meant to offend anyone, in fact I do appreciate all your work Just curious why you did it this way and not the other way round.

Sorry if I came off as snarky. I do it this way because it just seems logical to me. You can use a ssdt to over ride or inject new code over the dsdt table but why not just put it in the dsdt if that's where the original devices and code are. Also, it's one less table to deal with. Apple used like 7 or 8 SSDTs for the MP6,1. They even have one just for the USB lol. It gets complicated when you do it this way because you're referencing external devices and methods back and forth and you have to name and load them in the correct order. They did it like that because those devices are on their own daughter boards so they are actually external. To me, simpler code is better. I also don't rename devices or fake different device IDs if the OS sees, loads and uses them properly without it. The only one that I've done here is faked 8 series SATA as Andrew pointed out it add a little functionality.


All that said, I respect you because you want to learn (like me) and you are finding your own way.

 

[frontend-dev]

Yeah I think ultimately it is as always: both approaches have their strengths and weaknesses. With the SSDT solution there is imho a better separation from the original DSDT definitions, and you do not have to repatch DSDT when updating BIOS - but on the other hand as you said not everything can be done via this method, and you have to deal with additional problems, like the need of multiple DTGP methods.

So I think I will only use the USB patches with the DSDT, also added the clock-id patch, bc I actually like that you can wake your machine only with the PWR button. As for the other patches, I leave them out until I actually know what they do Did not encounter any differences so far.

Ah, and I might have another snippet for you, this gets you rid of this message:

kernel[0]: RTC: Only single RAM bank (128 bytes)

DefinitionBlock ("iASL39sgSe.aml", "SSDT", 1, "Test", "test2", 0x00013400)
{
    External (RTC0, DeviceObj)
    External (SBRG, DeviceObj)
    External (PCI0, DeviceObj)

    Scope (\_SB)
    {
        Scope (PCI0)
        {
            Scope (SBRG)
            {
                Scope (RTC0)
                {
                    Name (_STA, Zero)
                }

                Device (RTC)
                {
                    Name (_HID, EisaId ("PNP0B00"))
                    Name (_CRS, ResourceTemplate ()
                    {
                        IO (Decode16,
                            0x0070,             // Range Minimum
                            0x0070,             // Range Maximum
                            0x01,               // Alignment
                            0x08,               // Length
                            )
                        IRQNoFlags ()
                            {8}
                    })
                }
            }
        }
    }
}

Of course, the scopes can be rewritten a bit. Found that here:

https://github.com/RevoGirl/RevoBoot/wiki/Tiny-SSDT-example-3:-Full-blown-example

Includes even more patches ... just FYI.

PS: yes this is the SSDT version But shouldn't be a problem to rewrite it for DSDT.

 

[shilohh]

both approaches have their strengths and weaknesses. With the SSDT solution there is imho a better separation from the original DSDT definitions, and you do not have to repatch DSDT when updating BIOS - but on the other hand as you said not everything can be done via this method, and you have to deal with additional problems, like the need of multiple DTGP methods.

Defining the DTGP method in each table is not a problem. Sounds like you'll need to pick 1 place to put DTGP and all edits that reference it. There are also ways to write the code so that the method doesn't need to be defined in each SSDT (if you know what you're doing). PikerAlpha (RevoGirl's brother) has pointed this out and you can see an example in the SSDT generated by PikerAlpha's ssdtPRgen script in my speedstep guide.

        Method (_DSM, 4, NotSerialized)
        {
            Store ("Method C000._DSM Called", Debug)
            If (LEqual (Arg2, Zero))
            {
                Return (Buffer (One)
                {
                    0x03
                })
            }


            Return (Package (0x02)
            {
                "plugin-type", 
                One
            })
        }

I don't understand the AML and ACPI coding well enough to write original code this way but it can be done. IMO, "separation from the DSDT definitions" just adds a layer of complexity and is unnecessary. But, if you get the bonus of not bypassing the factory DSDT with a patched one, and therefore don't need to update your DSDT with the BIOS or changes to your PCI hardware, then it's worth it.

So I think I will only use the USB patches with the DSDT, also added the clock-id patch, bc I actually like that you can wake your machine only with the PWR button. As for the other patches, I leave them out until I actually know what they do Did not encounter any differences so far.

Again, the only thing I haven't been able to figure out how to do in a SSDT is telling OS X exactly what IRQ interrupts to use for which devices. If you're not using the IRQ fixes, then you'd be better served not to bypass the factory DSDT at all. Just stick to your SSDT method and you'll get the ONLY benefit that the SSDT method offers (Not having to update the DSDT).

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

            Scope (EUSB)
            {
                Method (_DSM, 4, NotSerialized)
                {
                    Store (Package (0x02)
                        {
                            "AAPL,clock-id", 
                            Buffer (One)
                            {
                                0x01
                            }
                        }, Local0)
                    DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
                    Return (Local0)
                }  
            }
            
            Scope (USBE)
            {
                Method (_DSM, 4, NotSerialized)
                {
                    Store (Package (0x02)
                        {
                            "AAPL,clock-id", 
                            Buffer (One)
                            {
                                0x01
                            }
                        }, Local0)
                    DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
                    Return (Local0)
                }  
            }

Ah, and I might have another snippet for you, this gets you rid of this message:

kernel[0]: RTC: Only single RAM bank (128 bytes)

                Scope (RTC0)
                {
                    Name (_STA, Zero)
                }

                Device (RTC)
                {
                    Name (_HID, EisaId ("PNP0B00"))
                    Name (_CRS, ResourceTemplate ()
                    {
                        IO (Decode16,
                            0x0070,             // Range Minimum
                            0x0070,             // Range Maximum
                            0x01,               // Alignment
                            0x08,               // Length
                            )
                        IRQNoFlags ()
                            {8}
                    })
                }

Of course, the scopes can be rewritten a bit. Found that here:
https://github.com/RevoGirl/RevoBoot/wiki/Tiny-SSDT-example-3:-Full-blown-example
Includes even more patches ... just FYI.
PS: yes this is the SSDT version But shouldn't be a problem to rewrite it for DSDT.

Yes I am familiar with this page and RevoGirl's work. She was probably the most brilliant ACPI coder in the whole community. I am awed by her work. That page was my source of info when I first tried to use a SSDT as a substitute for patching the DSDT. I'd also bet that it's where Andrew got his inspiration.

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.

If you want to use that patch in your SSDT, you should use it without the IRQ assignment:

                Scope (RTC0)
                {
                    Name (_STA, Zero)
                }

                Device (RTC)
                {
                    Name (_HID, EisaId ("PNP0B00"))
                    Name (_CRS, ResourceTemplate ()
                    {
                        IO (Decode16,
                            0x0070,             // Range Minimum
                            0x0070,             // Range Maximum
                            0x01,               // Alignment
                            0x08,               // Length
                            )
                    })
                }

I'll say say this one more time for anyone who might be confused after reading this. If you extract and edit your DSDT, there is absolutely no reason to use a SSDT to modify the your DSDT's code. You can, and if done correctly, it shouldn't cause problems but there is no benefit to doing it this way.

 

[RehabMan]

Defining the DTGP method in each table is not a problem.

Not true. There can be only one method with the name \DTGP. If you have SSDT/DSDT that define duplicate \DTGP, the SSDTs will be thrown out/not loaded by OS X and will not have your desired effect. The only way to have multiple DTGPs would be to place it in a different scope in each file.

Device(FAK1) 
{
   Method(DTGP, ...) {...}
}

Device(FAK2)
{ 
   Method(DTGP, ...) {...}
}

Your _DSM methods would have to refer to it specifically, of course... eg. \FAK1.DTGP(...), and \FAK2.DTGP(...)

The other way is to have one definition, but use External.

In DSDT:

Method(DTGP, ...) {...}

...
// code that uses DTGP (eg. _DSM methods)

In SSDT:

External(DTGP, MethodObj)

...
// code that uses DTGP (eg. _DSM methods)

There are also ways to write the code so that the method doesn't need to be defined in each SSDT (if you know what you're doing).

Yes, best to avoid using DTGP.

 

[shilohh]

Thanks RehabMan,
I have used a SSDT for CPUPM which had DTGP in conjunction with my DSDT which had DTGP and both loaded (if I remember correctly). But as you mentioned they bust have been on different scopes. I'd use Pike's example in all my edits if I understood ACPI better.

 

[RehabMan]

Thanks RehabMan,
I have used a SSDT for CPUPM which had DTGP in conduction with my DSDT which had DTGP and both loaded (if I remember correctly). But as you mentioned they bust have been on different scopes. I'd use Pike's example in all my edits if I understood coding better.

Unless they were in different scopes, it didn't work. SSDT would be ignored in that case.

Most examples I see of DTGP have it in root scope.

 

[shilohh]

Unless they were in different scopes, it didn't work. SSDT would be ignored in that case.

Most examples I see of DTGP have it in root scope.

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?