Contribute
Register

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

Status
Not open for further replies.
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.
Click to expand...

Should HackrNVMeFamily-10_12_6.kext be placed in EFI/Clover/kexts/Other or /L/E or both? Pros/Cons?
 
RehabMan said:
Then you use use the --unpatched option to specify the location of your extracted vanilla IONVMeFamily.kext.
Click to expand...
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?
 
Chebattler said:
I installed 10.13 on 850 evo, there took native IONVMeFamily.kext, tried to generate HackrNVMeFamily-10_12_6.kext
Click to expand...

10.13.x has native support in IONVMeFamily for your device.
This guide is for macOS Sierra and OS X El Capitan, not macOS High Sierra.
 
RehabMan said:
This guide is for macOS Sierra and OS X El Capitan, not macOS High Sierra.
Click to expand...
sure, i understood that, and found it strange, that installator of 10.13 with support of nvme still cant see that nvme (960 evo) as an installation destination. So is there way, to make usb installator accept nvme as location for installation? if its not possible to generate that kext for 10.13. sorry, i got really confused, trying to figure it out second day.

p.s probably, i will try just to clone it , bcz clean install is not very obvious so far.
 
Last edited:
Chebattler said:
sure, i understood that, and found it strange, that installator of 10.13 with support of nvme still cant see that nvme (960 evo) as an installation destination.
Click to expand...

If you're implementing the class-code spoof with SSDT_NVMe-Pcc.aml, that is what you should expect.
For 10.13, must remove the class-code injection, or use HackrNVMeFamilyInjector.kext.
 
Last edited:
Understood, everything works great :)
Thanks.
 
RehabMan said:
I don't see where you attached the photos from Windows Device Manager...
Click to expand...

Hi Rehabman,

I didn't put the screen grabs of Windows Device manager in the post as i described the Windows ACPI/BIOS paths in what i wrote and you can also clearly see the path on the highlighted line on the ioreg screen grab ..

Was trying to not post duplicate information... no matter, I've edited the post and for completeness have added the device manager screen grabs from windows of the NVME device that i cant get the spoofing working with :-

Please see my updated post for more info ...

https://www.tonymacx86.com/threads/...class-code-spoof.210316/page-111#post-1677201

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

View attachment 312014 View attachment 312013

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
View attachment 308209
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
Click to expand...

No "Problem Reporting" files attached.
Read FAQ, "Problem Reporting" again. Carefully. Attach all requested files/output.
https://www.tonymacx86.com/threads/faq-read-first-laptop-frequent-questions.164990/
Use the gen_debug.sh tool mentioned in the FAQ, that way it is less likely you'll omit something.

Just guessing from limited information provided... it is likely something you're doing in SSDT-0.aml.
 
Last edited:
RehabMan said:
No "Problem Reporting" files attached.
Read FAQ, "Problem Reporting" again. Carefully. Attach all requested files/output.
https://www.tonymacx86.com/threads/faq-read-first-laptop-frequent-questions.164990/
Use the gen_debug.sh tool mentioned in the FAQ, that way it is less likely you'll omit something.

Just guessing from limited information provided... it is likely something you're doing in SSDT-0.aml.
Click to expand...

Hi Rehab Man,

In reference to my post :-
https://www.tonymacx86.com/threads/...class-code-spoof.210316/page-111#post-1677201

And your above Request ... Debug files are attached to this new post ...

I did some more investigate work on this today but have still been unsuccessful at getting either of the NVme SSD's to Spoof, for debug purposes i created two SSDT's one for each of the NVME drives ...

Clover is using the native system DSDT but now re-naming the _DSM methods where as before i was using a custom DSDT, this has changed the behaviour slightly ...

If i boot and allow clover to load the spoof ssdt for the Windows drive which is a Samsung 850 Pro (_SB_.PCI0.RP01.PXSX) it no longer shows up as a device in the system (in IOREG)

If I boot and allow clover to load the spoof ssdt for the OSX drive which is a Samsung PM961 (_SB.PCI0.PEG2.PEGP) OSX no longer loads and eventually gives the no entry sign so i suspect it too is getting removed from the system.

SSDT-0.aml is Toleda's fix to get Nvidia HDMI audio working its been on the system for quite a long time so not sure if its a cause of an issue or not ... but i doubt it as it references a completely different ACPI path (\_SB.PCI0.PEG0.PEGP) and its working fine .. has done for many years and quite a few different Nvidia cards.

I've included the disassembled DSDT and SSDT's .... the _DSM methods for _SB_.PCI0.RP01.PXSX (in DSDT) and _SB.PCI0.PEG2.PEGP (in SSDT-4-SaSsdt) contain quite a bit of nested "if" code .. seems that the system does not like replacing those methods with the simple _DSM spoof code ?

Would appreciate if you could take a look and let me know if you sport anything and give me a clue as to why its not working.
I've used your NVMe spoof method on many other systems with no problems at all but this ones got me dumfounded :crazy:

For clarity the system is built around a ASRock Z97 Extreme 6 Motherboard, I7 4790K CPU, 16GB Corsair Dominator RAM and Nvidia 980TI GPU .. Running OSX 10.11.6 (El-Capitan). Although the system is over clocked to 4.5Ghz it rock solid stable and before you ask ... yes i tried removing the overclock to see if that was the cause but no dice.

The IOREG in the attached debug archive is without either of the Nvme spoof files loaded.

Cheers
Jay

Update: I just noticed that NvmExpressDxe-64.efi was in Clovers UEFIDrivers 64 & 32 Folders .. have since removed them but issue remains, system boots fine without them but still does not like me spoofing either of the NVMe SSD's. A remnant from a long time ago ... please assume that they are no longer with-in Clover's folders in the attached archive.

Update-2: I tried booting without SSDT-0 .. but no dice ...
 

Attachments

  • WK-Nvme_Spoof_Issue.zip
    6.9 MB · Views: 93
Last edited:
jaymonkey said:
Hi Rehab Man,

In reference to my post :-
https://www.tonymacx86.com/threads/...class-code-spoof.210316/page-111#post-1677201

And your above Request ... Debug files are attached to this new post ...

I did some more investigate work on this today but have still been unsuccessful at getting either of the NVme SSD's to Spoof, for debug purposes i created two SSDT's one for each of the NVME drives ...

Clover is using the native system DSDT but now re-naming the _DSM methods where as before i was using a custom DSDT, this has changed the behaviour slightly ...

If i boot and allow clover to load the spoof ssdt for the Windows drive which is a Samsung 850 Pro (_SB_.PCI0.RP01.PXSX) it no longer shows up as a device in the system (in IOREG)

If I boot and allow clover to load the spoof ssdt for the OSX drive which is a Samsung PM961 (_SB.PCI0.PEG2.PEGP) OSX no longer loads and eventually gives teh no entry sign so i suspect it too is getting removed from the system.

SSDT-0.aml is Toleda's fix to get Nvidia HDMI audio working its been on the system for quite a long time so not sure if its a cause of an issue or not ... but i doubt it as it references a completely different ACPI path (\_SB.PCI0.PEG0.PEGP) and its working fine .. has done for many years and quite a fe different Nvidia cards.

I've included the disassembled DSDT and SSDT's .... the _DSM methods for _SB_.PCI0.RP01.PXSX (in DSDT) and _SB.PCI0.PEG2.PEGP (in SSDT-4-SaSsdt) contain quite a bit of nnested "if" code .. seems that the system does not like replacing those methods with the simple _DSM spoof code ?

Would appreciate if you could take a look and let me know if you sport anything and give me a clue as to why its not working.
I've used your NVMe spoof method on many other systems with no problems at all but this ones got me dumfounded :crazy:

For clarity the system is built around a ASRock Z97 Extreme 6 Motherboard, I7 4790K CPU, 16GB Corsair Dominator RAM and Nvidia 980TI GPU .. Running OSX 10.11.6 (El-Capitan)

Cheers
Jay
Click to expand...

"Problem Reporting" files are incomplete/wrong:
- patchmatic -extract output missing
- ioreg is corrupt (not saved with IORegistryExplorer v2.1)

Please note that the HackrNVMeFamily-10_11_6.kext you have in EFI/Clover/kexts/Other was not generated with --spoof. You should NOT expect that kext to work with a successful spoof injected device.
 
Last edited:
Status
Not open for further replies.
Copyright © 2010 - 2024 tonymacx86 LLC
Back
Top