Jump to content

SSDT, Darwin only (_OSI)

hafnium

By hafnium,
in General Discussion

 Share
10 posts in this topic

Recommended Posts

hafnium
hafnium
Posted
Posted (edited)

Hello,

 

I am using OpenCore and my setup is working great in terms of macOS. But OpenCore does not discriminate between e.g. macOS and Windows (in terms of DSDT/SSDT patching at least) and some of my SSDT fixes (needed for various reasons) breaks Windows (ACPI errors).

 

I know that I can use an _OSI method to only apply the SSDT fixes when the OS is Darwin (or at least that is what I figure - I am a noobie in this regard), but I am not able to fix the code myself. Hope someone here can help. I have three SSDTs (and they are based on samples available here and elsewhere):

 

PCIE Ethernet card built-in 

/*
 * Intel ACPI Component Architecture
 * AML/ASL+ Disassembler version 20190509 (64-bit version)
 * Copyright (c) 2000 - 2019 Intel Corporation
 * 
 * Disassembling to symbolic ASL+ operators
 *
 * Disassembly of iASL4tbwzO.aml, Mon Dec 16 20:42:43 2019
 *
 * Original Table Header:
 *     Signature        "SSDT"
 *     Length           0x000000F8 (248)
 *     Revision         0x02
 *     Checksum         0xE2
 *     OEM ID           "hack"
 *     OEM Table ID     "GIGE"
 *     OEM Revision     0x00000000 (0)
 *     Compiler ID      "INTL"
 *     Compiler Version 0x20180810 (538445840)
 */
DefinitionBlock ("", "SSDT", 2, "hack", "GIGE", 0x00000000)
{
    External (_SB_.PCI0.RP07, DeviceObj)
    External (_SB_.PCI0.RP07.PXSX._ADR, UnknownObj)

    Scope (\_SB.PCI0.RP07)
    {
        Device (GIGE)
        {
            Name (_ADR, Zero)  // _ADR: Address
            Name (_SUN, One)  // _SUN: Slot User Number
            Method (_INI, 0, NotSerialized)  // _INI: Initialize
            {
                \_SB.PCI0.RP07.PXSX._ADR = 0x0F
            }

            Method (_DSM, 4, NotSerialized)  // _DSM: Device-Specific Method
            {
                If ((Arg2 == Zero))
                {
                    Return (Buffer (One)
                    {
                         0x03                                             // .
                    })
                }

                Return (Package (0x08)
                {
                    "built-in", 
                    Zero, 
                    "model", 
                    "Intel i210", 
                    "AAPL,slot-name", 
                    "PCIe x1", 
                    "name", 
                    "Ethernet"
                })
            }
        }
    }
}

 

PCIE NVME controller built-in 

/*
 * Intel ACPI Component Architecture
 * AML/ASL+ Disassembler version 20190509 (64-bit version)
 * Copyright (c) 2000 - 2019 Intel Corporation
 * 
 * Disassembling to symbolic ASL+ operators
 *
 * Disassembly of iASLpMESa3.aml, Mon Dec 16 20:43:56 2019
 *
 * Original Table Header:
 *     Signature        "SSDT"
 *     Length           0x000000FE (254)
 *     Revision         0x02
 *     Checksum         0x60
 *     OEM ID           "hack"
 *     OEM Table ID     "NVME"
 *     OEM Revision     0x00000000 (0)
 *     Compiler ID      "INTL"
 *     Compiler Version 0x20180810 (538445840)
 */
DefinitionBlock ("", "SSDT", 2, "hack", "NVME", 0x00000000)
{
    External (_SB_.PCI0.PEG1, DeviceObj)
    External (_SB_.PCI0.PEG1.A808._ADR, UnknownObj)

    Scope (\_SB.PCI0.PEG1)
    {
        Device (NVME)
        {
            Name (_ADR, Zero)  // _ADR: Address
            Name (_SUN, One)  // _SUN: Slot User Number
            Method (_INI, 0, NotSerialized)  // _INI: Initialize
            {
                \_SB.PCI0.PEG1.A808._ADR = 0x0F
            }

            Method (_DSM, 4, NotSerialized)  // _DSM: Device-Specific Method
            {
                If ((Arg2 == Zero))
                {
                    Return (Buffer (One)
                    {
                         0x03                                             // .
                    })
                }

                Return (Package (0x08)
                {
                    "built-in", 
                    Zero, 
                    "model", 
                    "NVME", 
                    "AAPL,slot-name", 
                    "PCIe x4", 
                    "name", 
                    "Apple SSD Controller"
                })
            }
        }
    }
}

 

CPU powermanagement (via OpenCore) 

/*
 * Intel ACPI Component Architecture
 * AML/ASL+ Disassembler version 20190509 (64-bit version)
 * Copyright (c) 2000 - 2019 Intel Corporation
 * 
 * Disassembling to symbolic ASL+ operators
 *
 * Disassembly of iASLHFBi2J.aml, Mon Dec 16 20:44:52 2019
 *
 * Original Table Header:
 *     Signature        "SSDT"
 *     Length           0x000000A7 (167)
 *     Revision         0x02
 *     Checksum         0xD1
 *     OEM ID           "ACDT"
 *     OEM Table ID     "CpuPlug"
 *     OEM Revision     0x00003000 (12288)
 *     Compiler ID      "INTL"
 *     Compiler Version 0x20180810 (538445840)
 */
DefinitionBlock ("", "SSDT", 2, "ACDT", "CpuPlug", 0x00003000)
{
    External (_PR_.CPU0, ProcessorObj)

    Scope (\_PR.CPU0)
    {
        Method (DTGP, 5, NotSerialized)
        {
            If ((Arg0 == ToUUID ("a0b5b7c6-1318-441c-b0c9-fe695eaf949b")))
            {
                If ((Arg1 == One))
                {
                    If ((Arg2 == Zero))
                    {
                        Arg4 = Buffer (One)
                            {
                                 0x03                                             // .
                            }
                        Return (One)
                    }

                    If ((Arg2 == One))
                    {
                        Return (One)
                    }
                }
            }

            Arg4 = Buffer (One)
                {
                     0x00                                             // .
                }
            Return (Zero)
        }

        Method (_DSM, 4, NotSerialized)  // _DSM: Device-Specific Method
        {
            Local0 = Package (0x02)
                {
                    "plugin-type", 
                    One
                }
            DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
            Return (Local0)
        }
    }
}

 

Edited by hafnium
Link to comment
https://www.insanelymac.com/forum/topic/341781-ssdt-darwin-only-_osi/
Share on other sites
  • 3 months later...
dreamwhite
dreamwhite
Posted
Posted
On 12/18/2019 at 12:48 PM, Baio77 said:

This file :thumbsup_anim: https://github.com/RehabMan/OS-X-USB-Inject-All/blob/master/SSDT-XOSI.dsl

The file is too old. Need to add more Windows versions :) check it out here: https://docs.microsoft.com/en-us/windows-hardware/drivers/acpi/winacpi-osi

  • 2 weeks later...
MacKonsti
MacKonsti
Posted
Posted (edited)

Hi everyone, I am posting my updated definitions in SSDT-XOSI.dsl file for your information. Using this in Clover with _OSI to XOSI rename.

 

In OpenCore if you do not do this same rename (I am not using OpenCore yet) you should possibly either add this renaming OR change inside this DSL file to use _OSI instead of XOSI. I am not sure. however. A user of OpenCore to please advise?

SSDT-XOSI.dsl

Edited by MacKonsti
  • 2 months later...
deeveedee
deeveedee
Posted
Posted (edited)
On 4/25/2020 at 11:00 AM, MacKonsti said:

Hi everyone, I am posting my updated definitions in SSDT-XOSI.dsl file for your information. Using this in Clover with _OSI to XOSI rename.

 

I stumbled upon this thread when I was searching for answers to the question that I posted here.  In your SSDT-XOSI, why have you commented-out certain older client versions of Windows (e.g. why is Vista SP1 commented out)?  I thought that SSDT-XOSI should list all client versions, up to and including the most current Windows version supported by your platform.  Am I misunderstanding the way SSDT-XOSI is supposed to work?

 

Note that I'm not claiming that the SSDT-XOSI that I posted here is correct.  The more I read about this, the more differing opinions I find and the less I realize I understand this.

Edited by tonyx86
MacKonsti
MacKonsti
Posted
Posted
On 7/13/2020 at 9:56 PM, tonyx86 said:

I stumbled upon this thread when I was searching for answers to the question that I posted here.  In your SSDT-XOSI, why have you commented-out certain older client versions of Windows (e.g. why is Vista SP1 commented out)?  I thought that SSDT-XOSI should list all client versions, up to and including the most current Windows version supported by your platform.  Am I misunderstanding the way SSDT-XOSI is supposed to work?

 

Note that I'm not claiming that the SSDT-XOSI that I posted here is correct.  The more I read about this, the more differing opinions I find and the less I realize I understand this.

My understanding @tonyx86 was that it would use multiple value to return a single one, but seems editing the DSDT is much preferred to set an OSYS value that's appropriate (usually found in Method (_INI) of Scope (_SB.PCI0) on my machines).

 

But you may be right -- we need to isolate and choose a value instead (in SSDT-XOSI.aml) because the DSDT dump has different Windows version values returning a specific OSYS: 

        Method (_INI, 0, Serialized)  // _INI: Initialize
        {
            TBPE = One
            OSYS = 0x03E8
            If (CondRefOf (\_OSI))
            {
                If (_OSI ("Windows 2001"))
                {
                    OSYS = 0x07D1
                }

                If (_OSI ("Windows 2001 SP1"))
                {
                    OSYS = 0x07D1
                }

                If (_OSI ("Windows 2001 SP2"))
                {
                    OSYS = 0x07D2
                }

                If (_OSI ("Windows 2001.1"))
                {
                    OSYS = 0x07D3
                }

                If (_OSI ("Windows 2006"))
                {
                    OSYS = 0x07D6
                }

                If (_OSI ("Windows 2009"))
                {
                    OSYS = 0x07D9
                }

                If (_OSI ("Windows 2012"))
                {
                    OSYS = 0x07DC
                }

                If (_OSI ("Windows 2013"))
                {
                    OSYS = 0x07DD
                }

                If ((_OSI ("Windows 2015")) || (_OSI ("Darwin")))
                {
                    OSYS = 0x07DF
                }
            }

            If (CondRefOf (\_SB.DTSE))
            {
                If ((DTSE >= One))
                {
                    DSAE = One
                }
            }

            If ((TBTS == One))
            {
                If ((RPN0 == One))
                {
                    Acquire (OSUM, 0xFFFF)
                    \_GPE.TINI (Zero, RPS0, RPT0)
                    Release (OSUM)
                }

                If ((RPN1 == One))
                {
                    Acquire (OSUM, 0xFFFF)
                    \_GPE.TINI (Zero, RPS1, RPT1)
                    Release (OSUM)
                }

                Signal (WFEV)
            }
        }

That's from my edited Lenovo IdeaPad S145 and I only added a "Darwin" condition at the entry "Windows 2015". That's my five cents...

 

My only concern is that I cannot think of a way to check if using SSDT-XOSI.aml (with the respective Clover _OSI -> XOSI change) actually works or verify it has been applied as needed... Any idea?

deeveedee
deeveedee
Posted
Posted (edited)
20 hours ago, MacKonsti said:

My understanding @tonyx86 was that it would use multiple value to return a single one, but seems editing the DSDT is much preferred to set an OSYS value that's appropriate (usually found in Method (_INI) of Scope (_SB.PCI0) on my machines).

 

But you may be right -- we need to isolate and choose a value instead (in SSDT-XOSI.aml) because the DSDT dump has different Windows version values returning a specific OSYS:

That's from my edited Lenovo IdeaPad S145 and I only added a "Darwin" condition at the entry "Windows 2015". That's my five cents...

 

My only concern is that I cannot think of a way to check if using SSDT-XOSI.aml (with the respective Clover _OSI -> XOSI change) actually works or verify it has been applied as needed... Any idea?

 

The Disassembled DSDT for my HP EliteDesk 800 G4 Mini performs _OSI checks in three places 

  1. It defines Method (GTOS) that performs _OSI checks up through _OSI ("Windows 2017") and GTOS is called multiple times in the DSDT
  2. In Method (_INI), it performs _OSI checks through (_OSI ("Windows 2015") (with no condition on "Windows 2017")
  3. It conditionally enables Device (PAGD) on _OSI("Processor Aggregator Device").  More about this below and here.
     

With my SSDT-XOSI here and enabling renaming _OSI->XOSI in my CLOVER config.plist, my Method (GTOS) will behave as though I'm running "Windows 2017" and my Method (_INI) will behave as though I'm running "Windows 2015."  I suspect this is why SSDT-XOSI must return TRUE for multiple client versions of Windows.  I probably could have used a minimized version of SSDT-XOSI for my system that includes only "Windows 2015" and "Windows 2017," but I'm not certain.

 

My HP EliteDesk 800 G4 Mini is the first system where I'm not manually patching my DSDT, so I'm new to this and not the best to advise about SSDT-XOSI.  I've read in Dortania's guide here that SSDT-XOSI 'is a very hacky solution known for breaking Windows boot, use the GPIO SSDT instead' so I continue to find as many opinions and conclusions about SSDT-XOSI as there are posts about it.  

 

Since I don't boot Windows via the CLOVER boot loader, I'm not concerned about breaking Windows with my SSDT-XOSI. At system startup, I press F9 and select my Windows 10 disk if I want to boot Windows, which is rarely.

 

EDIT: We could check to see if SSDT-XOSI is "working' by intentionally breaking it with missing or invalid Windows client versions.  I just assumed that since my system is working, SSDT-XOSI is working.  Maybe not a good assumption.  We could also use Rehabman's ACPI debugging to print the various _OSI checks, but that sounds tedious.

 

EDIT 2: My HP EliteDesk 800 G4 Mini DSDT also conditionally enables Device (PAGD) on _OSI ("Processor Aggregator Device").  I've searched for explanation of this and found this reference, but have not found anything that suggests that Device (PAGD) should be enabled for macOS.  Since my SSDT-XOSI does not include "Processor Aggregator Device", Device (PAGD) will never be enabled when I'm booting CLOVER / macOS.

Edited by tonyx86
Added note about Device (PAGD)
 Share
Go to topic listing
×
×
  • Create New...