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

[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.

 

[BoomR]

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

Understood - thanks again for everything!

 

[BeBob]

Good evening @RehabMan
I really appreciate your guides.
Just to let you know I am still a newbie on OsX hacks. This is only my second on I am trying.
My hardware seems to be very similar to some you have installed 10.12.3 on.
I have a NUC 6i5SYK with a Samsung M.2 NMVe 950 Pro, and some 32 GB of ram.
I have followed all the steps to creating a bootable drive with Sierra on it (and it worked as I installed it on an external normal SSD)
But my goal is off course to install it on the NMVe drive inside the NUC.
I have made the HackrNVMeFamily-10_12_3.kext with the spoof option and put it in EFI/CLOVER/kexts/Other.
When trying to install, the installer does not see the NMVe drive.
I guess that it's normal as I have not made/put "SSDT-NVMe-Pcc.aml" in EFI/CLOVER/ACPI/patched
The problem is that I don't have a PC that would enable to follow your explanations to get path to the drive.
I was wondering, if, as you have installed on the same hardware as the one I am trying to install it on, and as I guess that on a NUC a NVMe is always attached on the same path, I was wondering if you could help/send me your SSDT-NVMe-Pcc.aml.
But maybe I have not understood everything and that the SSDT-NVMe-Pcc.aml not only contains the path to the NVMe, but also PartNumber and SerialNumber in which case I am doomed.
Thanks in advance for your help.
Cheers