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

[KalleKikkeli]

The HackrNVMeFamily you attached was not generated with --spoof. Read post #1.

Sorry, my bad! I was sure that I used the correct command. Clearly I had an error. Thanks!

 

[Stork]

...

The only thing I noticed that isn't working since my apparent update to 10.12.6 is my audio. Could you direct me to a thread that could show me how to fix it? Is it as simple as running multibeast again and reinstalling drivers?

Off Topic, but yes. See MacMan's explanation > https://www.tonymacx86.com/threads/multibeast-audio-failure-solved.220942/

Please create a thread the Audio forum section for future audio problems and/or questions.
https://www.tonymacx86.com/forums/audio.14/

 

[huifengruxun]

Since you can obviously boot from another device (and are not doing this from scratch with a new install), attach all typical "Problem Reporting" files.

Read FAQ, "Problem Reporting"
https://www.tonymacx86.com/threads/faq-read-first-laptop-frequent-questions.164990/

Hi, RehabMan.

In order to provide details as much as possible, I did it once again from scratch. Here was what I did this time.

Machine: Gigabyte GA-Z97X-UD3H + i5 4690 + NVMe Samsung Pro 960 SSD
USB Bootable Drive:
Clover Version: v2.4k r4045 EFI bootloader

- Determining the ACPI path of your NVMe device(s)
\_SB.PCI0.RP01.PXSX
Please see the attachment.

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

Compiled with MaciASL (downloaded from your link at https://bitbucket.org/RehabMan/os-x-maciasl-patchmatic/downloads/) and saved as SSDT_NVMe-Pcc.aml with ACPI Machine Language Binary. Please see the attachment.

Copied SSDT_NVMe-Pcc.aml to EFI/Clover/ACPI/patched/SSDT_NVMe-Pcc.aml on my USB Bootable Drive.

I am not using config.plist/ACPI/SortedOrder.

- Examples with incomplete ACPI identities
Skipped since Samsung Pro 960 has complete ACPI identities.

- Special injections required for 10.11.x and Samsung 960 EVO (or other 144d:a804 NVMe device)
Skipped since either the SSD or the OS applies.

- Existing _DSM methods
Did it anyway even though I started from scratch with a clean drive.
I don't have a statically patched DSDT.aml in ACPI/patched.

- Creating HackrNVMeFamily*.kext with the spoofed class-code
./patch_nvme.sh --spoof
Determined patch automatically from vanilla IONVMeFamily: 10_12_6
Creating patched HackrNVMeFamily-10_12_6.kext from /System/Library/Extensions/IONVMeFamily.kext
Vanilla MD5 matches expected MD5 entry (c506f1fc40026c0262a736f0be318223)
Patched MD5 matches expected MD5 entry (ff9c55bf11e522dd86e3dc5b2df7ff24)

Copied to EFI/Clover/kexts/Other.

Please see the attachments as well. Thank you for your time.

 

[RehabMan]

Hi, RehabMan.

In order to provide details as much as possible, I did it once again from scratch. Here was what I did this time.

Machine: Gigabyte GA-Z97X-UD3H + i5 4690 + NVMe Samsung Pro 960 SSD
USB Bootable Drive:
Clover Version: v2.4k r4045 EFI bootloader

- Determining the ACPI path of your NVMe device(s)
\_SB.PCI0.RP01.PXSX
Please see the attachment.

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

Compiled with MaciASL (downloaded from your link at https://bitbucket.org/RehabMan/os-x-maciasl-patchmatic/downloads/) and saved as SSDT_NVMe-Pcc.aml with ACPI Machine Language Binary. Please see the attachment.

Copied SSDT_NVMe-Pcc.aml to EFI/Clover/ACPI/patched/SSDT_NVMe-Pcc.aml on my USB Bootable Drive.

I am not using config.plist/ACPI/SortedOrder.

- Examples with incomplete ACPI identities
Skipped since Samsung Pro 960 has complete ACPI identities.

- Special injections required for 10.11.x and Samsung 960 EVO (or other 144d:a804 NVMe device)
Skipped since either the SSD or the OS applies.

- Existing _DSM methods
Did it anyway even though I started from scratch with a clean drive.
I don't have a statically patched DSDT.aml in ACPI/patched.

- Creating HackrNVMeFamily*.kext with the spoofed class-code
./patch_nvme.sh --spoof
Determined patch automatically from vanilla IONVMeFamily: 10_12_6
Creating patched HackrNVMeFamily-10_12_6.kext from /System/Library/Extensions/IONVMeFamily.kext
Vanilla MD5 matches expected MD5 entry (c506f1fc40026c0262a736f0be318223)
Patched MD5 matches expected MD5 entry (ff9c55bf11e522dd86e3dc5b2df7ff24)

Copied to EFI/Clover/kexts/Other.

Please see the attachments as well. Thank you for your time.

The md5 of your HackrNVMeFamily (in CLOVER.zip) is 5093d2f6b472e6660f5242324ba958a6.
It does not match your output above, but rather matches vanilla 10.12.5 kext.
In fact, looking at the rest of the kext content, it *is* vanilla 10.12.5 IONVMeFamily.kext, just renamed to HackrNVMeFamily-10_12_6.kext.

Without correct HackrNVMeFamily, not expected to work.

The separate HackrNVMeFamily-10_12_6.kext.zip does contain a correctly patched kext. But that doesn't help you if you are not using it in EFI/Clover/kexts/Other.

 

[huifengruxun]

The md5 of your HackrNVMeFamily (in CLOVER.zip) is 5093d2f6b472e6660f5242324ba958a6.
It does not match your output above, but rather matches vanilla 10.12.5 kext.
In fact, looking at the rest of the kext content, it *is* vanilla 10.12.5 IONVMeFamily.kext, just renamed to HackrNVMeFamily-10_12_6.kext.

Without correct HackrNVMeFamily, not expected to work.

The separate HackrNVMeFamily-10_12_6.kext.zip does contain a correctly patched kext. But that doesn't help you if you are not using it in EFI/Clover/kexts/Other.

Thanks for looking into this, RehabMan. How come that ./patch_nvme.sh --spoof created HackrNVMeFamily for 10.12.5 instead of 10.12.6? Does the version of the OS that I ran this script matter? I believe I did run it on a 10.12.6 mbp. Also how did you calculate MD5 for a directory?

 

[huifengruxun]

Thanks for looking into this, RehabMan. How come that ./patch_nvme.sh --spoof created HackrNVMeFamily for 10.12.5 instead of 10.12.6? Does the version of the OS that I ran this script matter? I believe I did run it on a 10.12.6 mbp. Also how did you calculate MD5 for a directory?

I re-copied HackrNVMeFamily kext after removing the old incorrect version. Now it can detect the SSD! Thanks for the hint, RehabMan. However, it is still good to know how you calculate the MD5 so that I can check it myself in the future. Millions of thanks!

Another question, does ACPI value change if I use the same motherboard and same SSD (not multiple of course)?

 

[RehabMan]

Thanks for looking into this, RehabMan. How come that ./patch_nvme.sh --spoof created HackrNVMeFamily for 10.12.5 instead of 10.12.6? Does the version of the OS that I ran this script matter?

Yes.
As the script patches the vanilla IONVMeFamily in order to create HackrNVMeFamily, you can only create HackrNVMeFamily-10_12_6.kext from a system actually running 10.12.6.
If you run it on 10.12.5, you get HackrNVMeFamily-10_12_5.kext.

I believe I did run it on a 10.12.6 mbp.

Evidently not.

Also how did you calculate MD5 for a directory?

I didn't.
The md5 is the md5 sum for the binary at HackrNVMeFamily*.kext/Contents/MacOS/HackrNVMeFamily*

Another question, does ACPI value change if I use the same motherboard and same SSD (not multiple of course)?

Same board, same BIOS version, same BIOS settings, same slot, should be same ACPI path.

 

[Abed122]

@RehabMan hi I installed Mac OS 10.12.3 on my hdd because I didn't have my friends MacBook anymore so I made all the files and I checked the aml file with for the same pc and it had the same address but then when I tried to boot to the installer the nvme drive didn't appear in the disk utility in the installer here are my files ,what might be wrong ?

 

[RehabMan]

@RehabMan hi I installed Mac OS 10.12.3 on my hdd because I didn't have my friends MacBook anymore so I made all the files and I checked the aml file with for the same pc and it had the same address but then when I tried to boot to the installer the nvme drive didn't appear in the disk utility in the installer here are my files ,what might be wrong ?

This is the EFI/Clover you're using to boot the installer?
(looks like more of a post-install EFI/Clover is why I ask...)

Why do you have multiple copies of HackrNVMeFamily in EFI/Clover/kexts/Other?

 

[Kulaan]

Problem Reporting
Trying to get my existing installation of macOS Sierra 10.12.6 to recognize a newly installed Samsung 960 Evo. Plan to migrate boot volume to NVMe once NVMe SSD is detectable and mounted. (CCC or something)

Determined ACPI namespace path by using IORegistryExplorer.
name: Data <"pci14e4,43b1">
acpi-path String IOACPIPlane:/_SB/PCI0@0/RP04@1c0003/PXSX@0

Used EFI mounter to mount EFI partition.

Generated and copied SSDT_NVMe-Pcc.aml into /Volumes/EFI/EFI/CLOVER/ACPI/patched using MaciASL

Was able to determine that there is an OEM defined a _DSM method at the ACPI path. MaciASL opens DSDT by default, and I was able to find a _DSM method under _SB.PCI0.RP04.PXSX (clicked on triangle icon next to labeled path and found an "Application" icon labeled _DSM).

Made a copy of config.plist and named copy as config-XDSM.plist. Used TextWrangler to copy and paste in the "change _DSM to XDSM" patch into config-XDSM.plist.

Rebooted and using Clover boot options to boot using newly created config-XDSM.plist and verified that XDSM patch is working by checking in MasiASL. Only the XDSM method was listed under the ACPI path.

Was able to create a HackrNVMeFamily-10_12_6.kext
cd ~/Projects/patch-nvme.git
sudo cp -R HackrNVMeFamily-10_12_6.kext /Library/Extensions

sudo kextcache -i /
returns:
kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext realtekALC.kext
kext-dev-mode allowing invalid signature -67030 0xFFFFFFFFFFFEFA2A for kext HackrNVMeFamily-10_12_6.kext
kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext FakeSMC.kext
kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext AppleIntelE1000e.kext
kext-dev-mode allowing invalid signature -67054 0xFFFFFFFFFFFEFA12 for kext AppleHDA.kext
KernelCache ID: 1DC750034F53979CF109EE69B9B3EB84

When using config-XDSM to boot, kernel panic at boot.
When using config.plist to boot, no kernel panic but does not detect NVMe drive.
Kernel Panic said something about "unable to allocate class". Looks like the stock AppleNVMeFamily kext is still running.
EFI.zip attached.

kextstat output:
Joes-iMac:~ joe$ kextstat|grep -y acpiplat

13 2 0xffffff7f82b3a000 0x60000 0x60000 com.apple.driver.AppleACPIPlatform (5.0) 65E05472-6AE7-3308-8CC8-FA6CB0DB2AEE <12 11 7 6 5 4 3 1>

Joes-iMac:~ joe$ kextstat|grep -y applelpc

Joes-iMac:~ joe$ kextstat|grep -y appleintelcpu

Joes-iMac:~ joe$ kextstat|grep -y applelpc


Joes-iMac:~ joe$ sudo touch /System/Library/Extensions && sudo kextcache -u /

Password:

kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext realtekALC.kext

kext-dev-mode allowing invalid signature -67030 0xFFFFFFFFFFFEFA2A for kext HackrNVMeFamily-10_12_6.kext

kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext FakeSMC.kext

kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext AppleIntelE1000e.kext

kext-dev-mode allowing invalid signature -67054 0xFFFFFFFFFFFEFA12 for kext AppleHDA.kext

KernelCache ID: AD33584C88EA011780A14A64B93A7200