Contribute
Register

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

Status
Not open for further replies.
opoeta said:
Can someone help me ? My NVME always stays as external. I must be wrong about something.
Click to expand...
Maybe this could help you (my hardware being not so different of yours...)
(GA-Z170X GAMING 5 + EVO 960 1Tb)
- I use M.2 slot "M2H" (farest from CPU) instead of "M2D or G" (nearest CPU) because I need SATA ports 1,2 and 3.
- I generated this .aml file specified by Rehabman in post #1, specially crafted for 960 EVO because I use dual boot El Capitan + Sierra (and the code seems 100% OK for both) and placed it in EFI/Clover/ACPI/patched/:

Code: 
// Inject bogus class-code for NVMe SSD to prevent IONVMeFamily.kext from loading
// also inject "compatible", "IOName", and "name" such that 10.11.x IONVMeFamily
// does not match on pci144d,a804 (Samsung 960 EVO)
DefinitionBlock("", "SSDT", 2, "hack", "NVMe-Pcc", 0)
{
    External(_SB.PCI0.RP09.PXSX, DeviceObj)
    Method(_SB.PCI0.RP09.PXSX._DSM, 4)
    {
        If (!Arg2) { Return (Buffer() { 0x03 } ) }
        Return(Package()
        {
            "class-code", Buffer() { 0xff, 0x08, 0x01, 0x00 },
            "built-in", Buffer() { 0 },
            "compatible", Buffer() { "pci144d,a801" },
            "IOName", "pci144d,a801",
            "name", Buffer() { "pci144d,a801" },
        })
    }
}
//EOF

- I generated both HackrNVMeFamily-10_11_6.kext and HackrNVMeFamily-10_12_5.kext and placed them in Libray/Extensions/ of according OSX versions boot partitions; and in EFI/Clover/kexts/10.11/ + EFI/Clover/kexts/10.12/ respectively.

And it mounts or boot as internal drive at full speed.
Hope it helps.
 
Last edited:
I followed the guide below and injected the NvmExpressDxe in to my motherboard BIOS so that it could support the 960 Pro NVMe:

http://www.win-raid.com/t871f16-Gui...rt-for-all-Systems-with-an-AMI-UEFI-BIOS.html

It is working on 10.12.1 - however it is not using the class code spoof. And I have deleted the IONVMeFamily.kext

I want to upgrade and would like to change it to use the class code spoof first, however I am not sure of my ACPI path. I booted to a Windows 7 drive and checked Device Manager, however under Location paths it only shows: PCIROOT(0)#PCI(0300)#PCI(0000)

There is no BIOS device name and I can’t find any properties to specifying ACPI identities

Can anyone help with what I should build as my class-code spoof SSDT ? Or should I be using something different to find it (ioreg ?)
 
lishuai123 said:
Can you help me?
Click to expand...

With what?
Open your config.plist in Xcode.
Search (with Find) for IONVMeFamily.
It will highlight all the patches in KextsToPatch that have IONVMeFamily...
 
ccozmo said:
I followed the guide below and injected the NvmExpressDxe in to my motherboard BIOS so that it could support the 960 Pro NVMe:

http://www.win-raid.com/t871f16-Gui...rt-for-all-Systems-with-an-AMI-UEFI-BIOS.html

It is working on 10.12.1 - however it is not using the class code spoof. And I have deleted the IONVMeFamily.kext

I want to upgrade and would like to change it to use the class code spoof first, however I am not sure of my ACPI path. I booted to a Windows 7 drive and checked Device Manager, however under Location paths it only shows: PCIROOT(0)#PCI(0300)#PCI(0000)

There is no BIOS device name and I can’t find any properties to specifying ACPI identities

Can anyone help with what I should build as my class-code spoof SSDT ? Or should I be using something different to find it (ioreg ?)
Click to expand...

Attach ioreg as ZIP: http://www.tonymacx86.com/audio/58368-guide-how-make-copy-ioreg.html. Please, use the IORegistryExplorer v2.1 attached to the post! DO NOT reply with an ioreg from any other version of IORegistryExplorer.app.
 

Attachments

  • ccozmo_IOReg.zip
    757.5 KB · Views: 76
ccozmo said:
Thanks for helping, attached is the IOreg
Click to expand...

Path is _SB.PCI0.NPE7.0 (eg. the .0 represents no leaf node ACPI identity).
So, following the example in post #1:
Code: 
// Inject bogus class-code for NVMe SSD to prevent IONVMeFamily.kext from loading
DefinitionBlock("", "SSDT", 2, "hack", "NVMe-Pcc", 0)
{
    External(_SB.PCI0.NPE7, DeviceObj)
    Device(_SB.PCI0.NPE7.SSD0) { Name(_ADR, 0) } // adding SSD0 identity under _SB.PCI0.NPE7
    Method(_SB.PCI0.NPE7.SSD0._DSM, 4)
    {
        If (!Arg2) { Return (Buffer() { 0x03 } ) }
        Return(Package()
        {
            "class-code", Buffer() { 0xff, 0x08, 0x01, 0x00 },
            "built-in", Buffer() { 0 },
        })
    }
}
//EOF
 
Thanks Rehabman !

I'm going to give it a try, are the following steps correct ?

1. Implement the class-code spoof with SSDT with _DSM (put in EFI/Clover/ACPI/patched). Don’t reboot ?

2. Create the spoof HackrNVMeFamily.kext and copy it into /S/L/E

3. Rebuild cache

4. Make sure is running correctly with kext created by class code spoof

5. Upgrade Sierra to 10.12.5

6. Update patch-name from GitHub

7. Create new HackrNVMeFamily*.kext spoof for 10.12.5

8. Install new HackrNVMeFamily-10_12_5.kext and remove old HackrNVMeFamily-10_12_1*.kext

9. Rebuild cache & reboot

Do I need to reboot after step 1 ? Or how does the spoof parameter know the modified class-code created in the SSDT ?
 
ccozmo said:
Thanks Rehabman !

I'm going to give it a try, are the following steps correct ?

1. Implement the class-code spoof with SSDT with _DSM (put in EFI/Clover/ACPI/patched). Don’t reboot ?

2. Create the spoof HackrNVMeFamily.kext and copy it into /S/L/E

3. Rebuild cache

4. Make sure is running correctly with kext created by class code spoof

5. Upgrade Sierra to 10.12.5

6. Update patch-name from GitHub

7. Create new HackrNVMeFamily*.kext spoof for 10.12.5

8. Install new HackrNVMeFamily-10_12_5.kext and remove old HackrNVMeFamily-10_12_1*.kext

9. Rebuild cache & reboot

Do I need to reboot after step 1 ? Or how does the spoof parameter know the modified class-code created in the SSDT ?
Click to expand...

You must prepare completely for using spoofed HackrNVMeFamily before rebooting.
It is a one shot, everything must be correct, sort of thing.
The modified class-code is always the same. The SSDT injects the value expected by the spoof HackrNVMeFamily.

I would suggest testing your SSDT first before committing... for example, inject "#class-code" instead of "class-code"... verify in ioreg before changing to "class-code", and installing new spoof HackrNVMeFamily.
 
Last edited:
RehabMan said:
You must prepare completely for using spoofed HackrNVMeFamily before rebooting.
It is a one shot, everything must be correct, sort of thing.
The modified class-code is always the same. The SSDT injects the value expected by the spoof HackrNVMeFamily.

I would suggest testing your SSDT first before committing... for example, inject "#class-code" instead of "class-code"... verify in ioreg before changing to "class-code", and installing new spoof HackrNVMeFamily.
Click to expand...
Ok, so then should I make the following changes to the SSDT first
Code: 
// Inject bogus class-code for NVMe SSD to prevent IONVMeFamily.kext from loading
DefinitionBlock("", "SSDT", 2, "hack", "NVMe-Pcc", 0)
{
    External(_SB.PCI0.NPE7, DeviceObj)
    Device(_SB.PCI0.NPE7.SSD0) { Name(_ADR, 0) } // adding SSD0 identity under _SB.PCI0.NPE7
    Method(_SB.PCI0.NPE7.SSD0._DSM, 4)
    {
        If (!Arg2) { Return (Buffer() { 0x03 } ) }
        Return(Package()
        {
            "#class-code", Buffer() { 0xff, 0x08, 0x01, 0x00 },
            "built-in", Buffer() { 0 },
        })
    }
}
//EOF

How do I then check that in IOreg ? Do I search for a string ?
 
Status
Not open for further replies.
Copyright © 2010 - 2024 tonymacx86 LLC
Back
Top