[Guide] HackrNVMeFamily co-existence with IONVMeFamily using class-code spoof

gerbl · Jan 24, 2018

Actually, it's not the NVMe drive. I just tried it on a SATA drive with the same results - Clover shows the Recovery partitions and the UNIBEAST USB, but none of the hard drives. It's most likely something to do with my BIOS config, I suppose....?

gerbl said:
Greetings. I just followed this guide with success and was able to install to the NVMe drive from 10.12.6 UNIBEAST installer. However, when I rebooted, Clover did not see the MacOS drive. I can boot back into the UNIBEAST installer and Disk Utility still sees the drive, but Clover does not. I have tried everything I could think of. Any suggestions?

jaymonkey · Jan 24, 2018

Hi ReHabMan,

I'm try to get the NVMe spoof method to work on my Desktop system but for some reason i cant get the spoof _DSM method to attach to one of my NVME SSD's ( i have two NVMe's installed)

Windows is installed on Samsung 850 EVO Nvme which has a ACPI path of _SB.PCI0.RP01.PXSX so that was easy .. and straight forward and the spoof method worked fine giving it a class code of FF,08,00,01

However OSX is installed on a Samsung PM961 which has a ACPI Path of _SB.PCI0.PEG2.PEGP .. it also has a PID/VID of 144d,a804 and thus requires the extra spoof parameters ..

I followed your guide but at the moment the spoofing for the PM961 SSD's is not working ?
Is it necessary to create a PXSX device name for it or can i use the ACPI/BIOS name path as is ?

This is my SSDT spoof code :-

Code:

/*
* Intel ACPI Component Architecture
* AML/ASL+ Disassembler version 20161117-64(RM)
* Copyright (c) 2000 - 2016 Intel Corporation
*
* Disassembling to non-symbolic legacy ASL operators
*
* Disassembly of iASL7fX4BI.aml, Wed Jan 24 18:26:53 2018
*
* Original Table Header:
*     Signature        "SSDT"
*     Length           0x00000130 (304)
*     Revision         0x02
*     Checksum         0x4A
*     OEM ID           "hack"
*     OEM Table ID     "NVMe-Pcc"
*     OEM Revision     0x00000000 (0)
*     Compiler ID      "INTL"
*     Compiler Version 0x20161117 (538317079)
*/
DefinitionBlock ("", "SSDT", 2, "hack", "NVMe-Pcc", 0x00000000)
{
    External (_SB_.PCI0.PEG2.PEGP, DeviceObj)    // (from opcode)
    External (_SB_.PCI0.RP01.PXSX, DeviceObj)    // (from opcode)

    Method (_SB.PCI0.RP01.PXSX._DSM, 4, NotSerialized)  // _DSM: Device-Specific Method
    {
        If (LNot (Arg2))
        {
            Return (Buffer (One)
            {
                 0x03                                       
            })
        }

        Return (Package (0x04)
        {
            "class-code",
            Buffer (0x04)
            {
                 0xFF, 0x08, 0x01, 0x00                     
            },

            "built-in",
            Buffer (One)
            {
                 0x00                                       
            }
        })
    }

    Method (_SB.PCI0.PEG2.PEGP._DSM, 4, NotSerialized)  // _DSM: Device-Specific Method
    {
        If (LNot (Arg2))
        {
            Return (Buffer (One)
            {
                 0x03                                       
            })
        }

        Return (Package (0x0A)
        {
            "class-code",
            Buffer (0x04)
            {
                 0xFF, 0x08, 0x01, 0x00                     
            },

            "built-in",
            Buffer (One)
            {
                 0x00                                       
            },

            "compatible",
            Buffer (0x0D)
            {
                "pci144d,a801"
            },

            "IOName",
            "pci144d,a801",
            "name",
            Buffer (0x0D)
            {
                "pci144d,a801"
            }
        })
    }
}

I've added it to Clovers patched ACPI folder and to the sorted SSDT load order ...
Clover's boot log shows that its been inserted ok :-

Code:

68:090  0:000  === [ ACPIPatchedAML ] ====================================
68:090  0:000  Sorted
68:090  0:000  Inserting table[0]:SSDT.aml from EFI\CLOVER\ACPI\patched ... Success
68:092  0:001  Inserting table[1]:SSDT-0.aml from EFI\CLOVER\ACPI\patched ... Success
68:093  0:001  Inserting table[2]:SSDT_NVMe-Pcc.aml from EFI\CLOVER\ACPI\patched ... Success
68:094  0:001  CPUBase=0 and ApicCPUBase=1 ApicCPUNum=8

Here is an IOreg dump of the device after the above ssdt has been loaded

As you can see it still has the old PID/VID ACPI Name and Class-Code ? so it looks like the ssdt DSM method has not taken ?
Do i need to create a PXSX device or have i missed something from the ACPI path ?

There is no _DSM method defined for _SB.PCI0.PEG2.PEGP in the systems DSDT, however there is a _DSM method defined for it in a SSDT called SSDT-4-SaSsdt ..... but i have the Clover option "Drop OEM" checked so this should not be being loaded which is indicated as being the case in the Clover boot log :-

Code:

  === [ DropSSDT ] ==========================================
10:594  0:000  Drop tables from Xsdt, SIGN=SSDT TableID= Length=0
10:594  0:000   Xsdt has tables count=13
10:594  0:000   Table: SSDT  CpuSsdt  2932 dropped
10:594  0:000   Table: SSDT  LakeTiny  455 dropped
10:594  0:000   Table: SSDT  SataTabl  877 dropped
10:594  0:000   Table: SSDT  SaSsdt   23094 dropped
10:594  0:000   Table: SSDT  IsctTabl  1401 dropped

If you could confirm that my SSDT code is correct and should work then that's one less thing to work on but right now i am at a loss as to why the new _DSM method defined in my spoof ssdt is not working for the Samsung PM961 while it works perfect for the EVO 850 ... as such i can only assume it is something to do with the non standard ACPI path ?

For now I've renamed IONVMeFamily.kext to stop it from being included in the kext cache ... and thus working around the problem but would like to get the spoof method working as updates are a real pain if the update re-installs IONVMeFamily.kext

Can supply further debug files if required but i think the above should cover my question ?

Cheers
Jay

RehabMan · Jan 30, 2018

gerbl said:
Greetings. I just followed this guide with success and was able to install to the NVMe drive from 10.12.6 UNIBEAST installer. However, when I rebooted, Clover did not see the MacOS drive. I can boot back into the UNIBEAST installer and Disk Utility still sees the drive, but Clover does not. I have tried everything I could think of. Any suggestions?

gerbl said:
Actually, it's not the NVMe drive. I just tried it on a SATA drive with the same results - Clover shows the Recovery partitions and the UNIBEAST USB, but none of the hard drives. It's most likely something to do with my BIOS config, I suppose....?

Maybe you installed on APFS but forgot apfs.efi in drivers64UEFI.

RehabMan · Jan 30, 2018

jaymonkey said:
Hi ReHabMan,

I'm try to get the NVMe spoof method to work on my Desktop system but for some reason i cant get the spoof _DSM method to attach to one of my NVME SSD's ( i have two NVMe's installed)

Windows is installed on Samsung 850 EVO Nvme which has a ACPI path of _SB.PCI0.RP01.PXSX so that easy .. and straight forward, however OSX is installed on a Samsung PM961 which has a ACPI Path of _SB.PCI0.PEG2.PEGP .. it also has a PID/VID of 144d,a804 and thus requires the extra spoof parameters ..

I followed your guide but at the moment the spoofing for the PM961 SSD's is not working ?
Is it necessary to create a PXSX device name for it or can i use the ACPI path as is ?

This is my SSDT spoof code :-

Code:

/* * Intel ACPI Component Architecture * AML/ASL+ Disassembler version 20161117-64(RM) * Copyright (c) 2000 - 2016 Intel Corporation * * Disassembling to non-symbolic legacy ASL operators * * Disassembly of iASL7fX4BI.aml, Wed Jan 24 18:26:53 2018 * * Original Table Header: * Signature "SSDT" * Length 0x00000130 (304) * Revision 0x02 * Checksum 0x4A * OEM ID "hack" * OEM Table ID "NVMe-Pcc" * OEM Revision 0x00000000 (0) * Compiler ID "INTL" * Compiler Version 0x20161117 (538317079) */ DefinitionBlock ("", "SSDT", 2, "hack", "NVMe-Pcc", 0x00000000) { External (_SB_.PCI0.PEG2.PEGP, DeviceObj) // (from opcode) External (_SB_.PCI0.RP01.PXSX, DeviceObj) // (from opcode) Method (_SB.PCI0.RP01.PXSX._DSM, 4, NotSerialized) // _DSM: Device-Specific Method { If (LNot (Arg2)) { Return (Buffer (One) { 0x03 }) } Return (Package (0x04) { "class-code", Buffer (0x04) { 0xFF, 0x08, 0x01, 0x00 }, "built-in", Buffer (One) { 0x00 } }) } Method (_SB.PCI0.PEG2.PEGP._DSM, 4, NotSerialized) // _DSM: Device-Specific Method { If (LNot (Arg2)) { Return (Buffer (One) { 0x03 }) } Return (Package (0x0A) { "class-code", Buffer (0x04) { 0xFF, 0x08, 0x01, 0x00 }, "built-in", Buffer (One) { 0x00 }, "compatible", Buffer (0x0D) { "pci144d,a801" }, "IOName", "pci144d,a801", "name", Buffer (0x0D) { "pci144d,a801" } }) } }

I've added it to Clovers patched ACPI folder and to the sorted SSDT load order ... Clover's boot log shows that its been inserted ok :-

Code:

68:090 0:000 === [ ACPIPatchedAML ] ==================================== 68:090 0:000 Sorted 68:090 0:000 Inserting table[0]:SSDT.aml from EFI\CLOVER\ACPI\patched ... Success 68:092 0:001 Inserting table[1]:SSDT-0.aml from EFI\CLOVER\ACPI\patched ... Success 68:093 0:001 Inserting table[2]:SSDT_NVMe-Pcc.aml from EFI\CLOVER\ACPI\patched ... Success 68:094 0:001 CPUBase=0 and ApicCPUBase=1 ApicCPUNum=8

But looking at the IOreg i can see that it still has the old PID/VID ACPI Name ??
Do i need to create a PXSX device or have i missed something from the ACPI path ?

This is how it looks in my ioreg :-
View attachment 308209
Right now i've renamed IONVMeFamily.kext to stop it from being included in the kext cache ... and thus working around the problem but would like to get the spoof method working as updates are a real pain if the update reinstalls IONVMeFamily.kext

Can supply debug files if required but i think the above should cover my question ?

Cheers
Jay

I don't see where you attached the photos from Windows Device Manager...

Chebattler · Feb 1, 2018

Dear members,

What are my options, if, generating kext without spoof method i lost my backup original kext of IONVMEFamily, and now when I try to generate kext with spoof option - it says MD5 hashes are not the same, i ve tried different versions of this file from other people - same error.
I want to install 10.13.2 on 960evo , atm i m at 10.12.6 (on 850 evo). with gen. file without --spoof and SSDT_NVMe-Pcc I can load installation, but there is no device 960 listed there ... :/

RehabMan · Feb 1, 2018

Chebattler said:
Dear members,

What are my options, if, generating kext without spoof method i lost my backup original kext of IONVMEFamily, and now when I try to generate kext with spoof option - it says MD5 hashes are not the same, i ve tried different versions of this file from other people - same error.
I want to install 10.13.2 on 960evo , atm i m at 10.12.6 (on 850 evo). with gen. file without --spoof and SSDT_NVMe-Pcc I can load installation, but there is no device 960 listed there ... :/

You can extract vanilla IONVMeFamily.kext from the installer.
Then you use use the --unpatched option to specify the location of your extracted vanilla IONVMeFamily.kext.

msbc42 · Feb 1, 2018

Hi, I'm not sure what is needed for upgrading a Sierra hack to High Sierra? My boot drive is Samsung 960PRO. I have a SSDT-NVMe-Pcc.aml in CLOVER and spoofed HackrNVMeFamily-10_12_6.kext in /L/E.

Do I leave those in place during upgrade and remove after?

RehabMan · Feb 1, 2018

msbc42 said:
Hi, I'm not sure what is needed for upgrading a Sierra hack to High Sierra? My boot drive is Samsung 960PRO. I have a SSDT-NVMe-Pcc.aml in CLOVER and spoofed HackrNVMeFamily-10_12_6.kext in /L/E.

Do I leave those in place during upgrade and remove after?

The HackrNVMeFamily will continue to work with the spoof in 10.13.
But since 10.13 has better native support, you can remove both the spoof and the HackrNVMeFamily and use just native IONVMeFamily.
If you plan to dual boot Sierra/High Sierra, then keep the spoof SSDT and use HackrNVMeFamilyInjector.kext on 10.13.

msbc42 · Feb 1, 2018

RehabMan said:
The HackrNVMeFamily will continue to work with the spoof in 10.13.
But since 10.13 has better native support, you can remove both the spoof and the HackrNVMeFamily and use just native IONVMeFamily.
If you plan to dual boot Sierra/High Sierra, then keep the spoof SSDT and use HackrNVMeFamilyInjector.kext on 10.13.

Should HackrNVMeFamily-10_12_6.kext be placed in EFI/Clover/kexts/Other or /L/E or both? Pros/Cons?

Chebattler · Feb 1, 2018

RehabMan said:
Then you use use the --unpatched option to specify the location of your extracted vanilla IONVMeFamily.kext.

I installed 10.13 on 850 evo, there took native IONVMeFamily.kext, tried to generate HackrNVMeFamily-10_12_6.kext, but still that error: vanilla md5 doesnt match and override not specified. : / . also by removing aml , i solved problem with not recognized nvme on 10.13, but even so installer of 10.13 says 960 is not ok for installation ... there is not smart way of clonning mac os from sata ssd to nvme. But may be you know what i m doing wrong with generating spoof method HackrNVMeFamily?

Search

[Guide] HackrNVMeFamily co-existence with IONVMeFamily using class-code spoof

gerbl

jaymonkey

Moderator

RehabMan

Moderator

RehabMan

Moderator

Chebattler

RehabMan

Moderator

msbc42

RehabMan

Moderator

msbc42

Chebattler

Forum

Guides

Downloads