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

[RehabMan]

Could it be hidden, then? Here's what the fresh install on my 960 Pro M.2 looks like:
View attachment 237280

In Terminal:

open /System/Library/Extensions

Just to confirm, once Sierra is installed on my new M.2, the HackrNVMeFamily can live in *either* S/L/E, *or* EFI/Clover/Kexts/Other (but not both)....yes?

It should be present both on the system volume and in EFI/Clover/kexts/Other. You will install FakeSMC.kext to the system volume, and you likely have InjectKexts=Detect. Which means kexts from Clover/kexts will not be injected when you're booting your system volume.

So... you'll need it on your system volume (/L/E or /S/L/E) and you will need it on EFI/Clover/kexts when booting recovery or the installer (upgrade scenarios).

In other words... the same as any other "essential" kext you want to work in all scenarios...

Note: I install HackrNVMeFamily to /L/E.

 

[locmer]

Trying to get Sierra to see y intel 600p M2 NVMe. I *can* get it work find when patching Clover on my USB stick and use the Intel 600p M2 NVMe as the only drive in my configuration with this procedure:

https://github.com/RehabMan/patch-nvme

http://www.insanelymac.com/forum/to...g-nvme-under-macos-sierra-is-ready/?p=2246306

Installs and boot from Intel 600p M2 NVMe fine.

So I know the Intel 600p M2 NVMe can work. But I do not want to use the intel 600p M2 NVMe as the boot drive because I think it is easier to maintain my install when I use a standard sata3 ssd as the boot drive. So I have installed Sierra just fine (As per normal unibeast/Multibeast installation) on my SATA 3 ssd. And next I’d like to make the intel 600p M2 NVMe work as a data storage.

So I found this procedure:

https://www.tonymacx86.com/threads/...h-ionvmefamily-using-class-code-spoof.210316/

But I cannot get Disk Utility to see my intel 600p M2 NVMe. Can you spot what I do wrong or any tips to get it going?

Figuring out where Intel NVMe Is hanging out in the device tree:

So I deduct it to be like this :

/_SB/PCI0@0/RP09@1d0000/PXSX@0

And therefore my SSDT-NVMe-Pcc.aml looks like this, compile to version 6.1 with MaciASL.

// Inject bogus class-code for NVMe SSD to prevent IONVMeFamily.kext from loading
DefinitionBlock("", "SSDT", 2, "hack", "NVMe-Pcc", 0)
{
External(_SB.PCI0.RP9.PXSX, DeviceObj)
Method(_SB.PCI0.RP9.PXSX._DSM, 4)
{
If (!Arg2) { Return (Buffer() { 0x03 } ) }
Return(Package()
{
"class-code", Buffer() { 0xff, 0x08, 0x01, 0x00 },
"built-in", Buffer() { 0 },
})
}
}
//EOF

And put in place:

xxx-iMacatched xxx$ pwd
/Volumes/EFI/EFI/CLOVER/ACPI/patched
xxx-iMacatched xxx$ ls -l
total 1
-rwxrwxrwx@ 1 xxx staff 118 Feb 20 15:04 SSDT-NVMe-Pcc.aml

Although I understand this part the least I made the edits in the config.plist:

Also I have downloaded patch-mve-master from GitHub and created the spoofed package for 10_12_3

./patch_nvme.sh --spoof 10_12_3
Creating patched HackrNVMeFamily-10_12_3.kext
Vanilla MD5 matches expected MD5 entry (b54230d2816150a4d57b000d23bf1fc1)
Patched MD5 matches expected MD5 entry (2ea6658fbc1b161b4e1131ba5c2c5196)
And put it in the right place with kextbeast:
ls -l /Library/Extensions/
total 0
drwxr-xr-x 3 root wheel 102 Jun 13 2014 ACS6x.kext
drwxr-xr-x 3 root wheel 102 Jun 27 2016 ATTOCelerityFC8.kext
drwxr-xr-x 3 root wheel 102 Jun 27 2016 ATTOExpressSASHBA2.kext
drwxr-xr-x 3 root wheel 102 Jun 27 2016 ATTOExpressSASRAID2.kext
drwxr-xr-x 3 root wheel 102 Feb 18 21:56 AppleHDA1150.kext
drwxr-xr-x 3 root wheel 102 Aug 20 2013 ArcMSR.kext
drwxr-xr-x 3 root wheel 102 Sep 1 2013 CalDigitHDProDrv.kext
drwxr-xr-x 3 root wheel 102 Apr 12 2016 EnergyDriver.kext
drwxr-xr-x 3 root wheel 102 Sep 8 18:22 FakeSMC.kext
drwxr-xr-x 3 root wheel 102 Feb 18 22:38 HackrNVMeFamily-10_12_3.kext
drwxr-xr-x 3 root wheel 102 Aug 15 2014 HighPointIOP.kext
drwxr-xr-x 3 root wheel 102 Aug 15 2014 HighPointRR.kext
drwxr-xr-x 3 root wheel 102 Sep 23 23:47 IntelMausiEthernet.kext
drwxr-xr-x 3 root wheel 102 Apr 28 2014 PromiseSTEX.kext
drwxr-xr-x 3 root wheel 102 Aug 4 2016 SoftRAID.kext
drwxr-xr-x 3 root wheel 102 Sep 7 17:10 USBInjectAll.kext
drwxr-xr-x 3 root wheel 102 Nov 6 2015 realtekALC.kext

And also in /System/Library/Extensions/

Still no Intel 600p NVMe in Disk Utility. Any idea what to test or try?

 

[RehabMan]

Figuring out where Intel NVMe Is hanging out in the device tree:

View attachment 237289

So I deduct it to be like this :

/_SB/PCI0@0/RP09@1d0000/PXSX@0

And therefore my SSDT-NVMe-Pcc.aml looks like this, compile to version 6.1 with MaciASL.

// Inject bogus class-code for NVMe SSD to prevent IONVMeFamily.kext from loading
DefinitionBlock("", "SSDT", 2, "hack", "NVMe-Pcc", 0)
{
External(_SB.PCI0.RP9.PXSX, DeviceObj)
Method(_SB.PCI0.RP9.PXSX._DSM, 4)
{
If (!Arg2) { Return (Buffer() { 0x03 } ) }
Return(Package()
{
"class-code", Buffer() { 0xff, 0x08, 0x01, 0x00 },
"built-in", Buffer() { 0 },
})
}
}
//EOF

The (first) mistake is obvious: RP9 is not the same as RP09.

 

[BoomR]

One or the other. However, I used KextBeast to install the patched kext in /S/L/E. KextBeast makes it soooo easy.

After I wrote that post, I ended up using Kext Wizard to install to S/L/E, and then had KW do repair permissions/rebuild KCs. Now after reboot from the m.2, I'm getting stuck at USBMSC Identifier (non-unique): blah-blah-blah.. Must be because it's a rainy day AND a Monday in Dallas? Sigh..

 

[RehabMan]

After I wrote that post, I ended up using Kext Wizard to install to S/L/E, and then had KW do repair permissions/rebuild KCs. Now after reboot from the m.2, I'm getting stuck at USBMSC Identifier (non-unique): blah-blah-blah.. Must be because it's a rainy day AND a Monday in Dallas? Sigh..

Read post #1, "Problem Reporting".

Note: No need to "repair permissions" if the kext was installed correctly in the first place.

Keep in mind other requirements besides the kext (correct SSDT in ACPI/patched, kext generated with --spoof, _DSM->XDSM patch).

 

[BoomR]

Read post #1, "Problem Reporting".

Note: No need to "repair permissions" if the kext was installed correctly in the first place.

Keep in mind other requirements besides the kext (correct SSDT in ACPI/patched, kext generated with --spoof, _DSM->XDSM patch).

OK, evidently I did something correctly when I modified my UniBeast installer with the instructions in OP. I was able to boot to Sierra installer USB, format my M.2, and install Sierra. Rebooting with UB bootloader, then selecting M.2 to complete boot & install MultiBeast. Next used KextWizard to install HackrNVMe to S/L/E. Finally copied SSDT-NVMe-Pcc.aml to m.2's EFI/Clover/ACPI/patched. Somewhere in there I also installed NVIDIA Web drivers, then updated Clover to 4012 (as I needed to also add EmuVariableUefi-64.efi so that Web driver setting would "stick.") Used Clover Configurator > System Parameters to select NvidiaWeb option too.

Result: I get stuck at USBMSC Identifier (non-unique)... when I boot from M.2. Only way I can boot from m.2 is to use unibeast bootloader. Also replying to items in your previous post:

• I used Terminal & verified that HackrNVMeFamily-10_12_3.kext is installed to S/L/E of M.2
• I didn't have a copy of HackrNVMe in EFI/Clover/kexts/Other, so that is now in place.
• FakeSMC.kext is in system volume (/L/E) per MultiBeast install.
• My InjectKexts was set to =Yes, so changed to =Detect
• My HackrNVMeFamily was compiled using "spoof"
• Used PList Edit Pro to edit m.2 config.plist and do the _DSM->XDSM per your instructions in OP.

Here are troubleshooting items you've requested:

...and .zip of my EFI/Clover folder (removed Themes) should be attached below. Thanks so much for looking into this & the expert assist!

 

[RehabMan]

OK, evidently I did something correctly when I modified my UniBeast installer with the instructions in OP. I was able to boot to Sierra installer USB, format my M.2, and install Sierra. Rebooting with UB bootloader, then selecting M.2 to complete boot & install MultiBeast. Next used KextWizard to install HackrNVMe to S/L/E. Finally copied SSDT-NVMe-Pcc.aml to m.2's EFI/Clover/ACPI/patched. Somewhere in there I also installed NVIDIA Web drivers, then updated Clover to 4012 (as I needed to also add EmuVariableUefi-64.efi so that Web driver setting would "stick.") Used Clover Configurator > System Parameters to select NvidiaWeb option too.

Result: I get stuck at USBMSC Identifier (non-unique)... when I boot from M.2. Only way I can boot from m.2 is to use unibeast bootloader. Also replying to items in your previous post:

• I used Terminal & verified that HackrNVMeFamily-10_12_3.kext is installed to S/L/E of M.2
• I didn't have a copy of HackrNVMe in EFI/Clover/kexts/Other, so that is now in place.
• FakeSMC.kext is in system volume (/L/E) per MultiBeast install.
• My InjectKexts was set to =Yes, so changed to =Detect
• My HackrNVMeFamily was compiled using "spoof"
• Used PList Edit Pro to edit m.2 config.plist and do the _DSM->XDSM per your instructions in OP.

Here are troubleshooting items you've requested:
View attachment 237312 View attachment 237313
...and .zip of my EFI/Clover folder (removed Themes) should be attached below. Thanks so much for looking into this & the expert assist!

You have an existing _DSM method at _SB.PCI0.RP17.PXSX (in DSDT).
Your config.plist has no patch for _DSM->XDSM.

 

[locmer]

The (first) mistake is obvious: RP9 is not the same as RP09.

Fantastic, the difference a 0 makes , Voila there it is! Thanks so much Rehabman!



The correct path for a Gigabyte GA-Z170N-WIFI (2.0) and an Intel SSD 600p Series 512GB, M.2 80mm PCIe 3.0 x4 (SSDPEKKW512G7), for others benefit:

External (_SB_.PCI0.RP09.PXSX, DeviceObj) // (from opcode)
Method (_SB.PCI0.RP09.PXSX._DSM, 4, NotSerialized) // _DSM: Device-Specific Method

SSDT-NVMe-Pcc.aml file attached

 

[BoomR]

You have an existing _DSM method at _SB.PCI0.RP17.PXSX (in DSDT).
Your config.plist has no patch for _DSM->XDSM.

I **swear** to you - during the initial configuration process, I right-clicked on the config.plist and opened with PlistEdit Pro, and the patch was mysteriously already there...

You were spot-on, sir. Thanks for the catch! I'm writing this post after successfully booting from the Samsung 960 PRo into Sierra 10.2.3.


At the risk of straying slightly OT, if I drop the SSDT.aml that I made from Piker Alpha's script for power mgmt. into Clover/ACPI/patched, will that cause any conflict with the SSDT-NVMe-Pcc.aml that we created using your instructions here?

Once again, a bazillion thanks!
--B

 

[RehabMan]

At the risk of straying slightly OT, if I drop the SSDT.aml that I made from Piker Alpha's script for power mgmt. into Clover/ACPI/patched, will that cause any conflict with the SSDT-NVMe-Pcc.aml that we created using your instructions here?

No conflict. Each is a separate add-on SSDT with its own content for unrelated fixes.