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

[RehabMan]

Copied EFI partition from my USB stick to my 960 EVO and.... everything is working!!! You guys rock, you can't believe how happy I am after weeks and weeks of setting this up. Just waiting for my Broadcom M.2 wifi module, last step. Should arrive tomorrow.
- Ethernet working
- Internal audio working
- Intel HD 530 working
- App Store working

Seriously, you guys did it! THANK YOU!

Great.

Now, about the "W" word... any thoughts??

What do you mean by "W" word?

 

[RehabMan]

Mr. RehabMan, coder, sir:

I believe I need your help one last time regarding class code for NVMe SSDs since the remaining SSDs I had on order arrived (finally). Currently, my boot drive (1 TB 960 Pro) is located in PCI Slot #5 of my mobo. I am trying to migrate to a 4x M.2 Carrier board in PCI Slot #4 (512 GB 960 Pro x 4), although I am still not 100% certain I'll be able to use it as the boot; I hope so, however, since that's its intended purpose. I looked up the location paths of each SSD on the board using Windows 10 Pro, and it is identical to the path for my current setup utilizing PCI Slot 5, except for the addition of #PCI(0*00)#PCI(0000) at the end of the paths [where * = 4, 5, 6, or 7 for each SSD on the carrier card] (see screenshots for clarity).

I have attached the .txt replica of the SSDT-NVMe-Pcc.aml patch that I am currently using. Although I currently have three NVMe SSDs installed, I only have to inject class code for two of them since the top M.2 port on the Z170-WS can be manually disabled in BIOS.

Thanks again for all of your help!

View attachment 233934 View attachment 233935 View attachment 233936

Upload full images. I cannot read the ones you attached.

 

[Lsucorey]

Upload full images. I cannot read the ones you attached.

Done.

 

[Technotron]

You need to partition it properly in Disk Utility (assuming you can see the drive).
If you can't see it in Disk Utility, then you didn't do the NVMe configuration properly.

I don't know if there is a way to go from IRST to MS-NVMe without re-install. There probably is a way... I remember tweaking the Windows registry for going from IDE to AHCI, and the process is probably similar to that... You might do some google searching. In the case of a new PC though, it is almost always better to re-install Windows due to all the crapware provided by OEMs, so I would probably be doing that anyway.

If you're using this guide, IONVMeFamily.kext should have never been placed in EFI/Clover/kexts/Other ...

Cheers man, see my solution in the previous post for fixing the AHCI situation

Yeah, being stuck in trying to solve something for a good while, plus being completely inexperienced with Hackintosh etc., I guess I mixed up several guides again.... well everything is working so I am happy. And thank you again!

Oh and thanks, I changed my signature.

 

[RehabMan]

Mr. RehabMan, coder, sir:

I believe I need your help one last time regarding class code for NVMe SSDs since the remaining SSDs I had on order arrived (finally). Currently, my boot drive (1 TB 960 Pro) is located in PCI Slot #5 of my mobo. I am trying to migrate to a 4x M.2 Carrier board in PCI Slot #4 (512 GB 960 Pro x 4), although I am still not 100% certain I'll be able to use it as the boot; I hope so, however, since that's its intended purpose. I looked up the location paths of each SSD on the board using Windows 10 Pro, and it is identical to the path for my current setup utilizing PCI Slot 5, except for the addition of #PCI(0*00)#PCI(0000) at the end of the paths [where * = 4, 5, 6, or 7 for each SSD on the carrier card] (see screenshots for clarity).

I have attached the SSDT-NVMe-Pcc.aml patch that I am currently using. Although I currently have three NVMe SSDs installed, I only have to inject class code for two of them since the top M.2 port on the Z170-WS can be manually disabled in BIOS.

Thanks again for all of your help!

View attachment 233973 View attachment 233974 View attachment 233975

Probably something like this (SSDT just for the 4 SSDs in the "carrier card"):

// Inject bogus class-code for NVMe SSD to prevent IONVMeFamily.kext from loading
DefinitionBlock("", "SSDT", 2, "hack", "NVMe-Pcc-CC", 0)
{
    External(_SB.PCI0.PEG0.PEGP, DeviceObj)
    // create identities for the bridge @8 and SSD0 @0
    Device(_SB.PCI0.PEG0.PEGP.PBR8)
    {
        Name(_ADR, 0x00080000)  // corresponds to #PCI(0800), MSW byte reversed
        Device(PBR0)
        {
            Name(_ADR, 0) // corresponds to #PCI(0000)
            Device(PBR4)
            {
                Name(_ADR, 0x00040000) // #PCI(0400)
                Device(SSD4) { Name(_ADR, 0) } // SSD leaf #PCI(0000)
            }
            Device(PBR5)
            {
                Name(_ADR, 0x00050000) // #PCI(0500)
                Device(SSD5) { Name(_ADR, 0) } // SSD leaf #PCI(0000)
            }
            Device(PBR6)
            {
                Name(_ADR, 0x00060000) // #PCI(0600)
                Device(SSD6) { Name(_ADR, 0) } // SSD leaf #PCI(0000)
            }
            Device(PBR7)
            {
                Name(_ADR, 0x00070000) // #PCI(0700)
                Device(SSD7) { Name(_ADR, 0) } // SSD leaf #PCI(0000)
            }
        }
    }
    // now we can inject the _DSM at the newly created ACPI paths
    Method(_SB.PCI0.PEG0.PEGP.PBR8.PBR0.PBR4.SSD4._DSM, 4)
    {
        If (!Arg2) { Return (Buffer() { 0x03 } ) }
        Return(Package()
        {
            "class-code", Buffer() { 0xff, 0x08, 0x01, 0x00 },
            "built-in", Buffer() { 0 },
        })
    }
    Method(_SB.PCI0.PEG0.PEGP.PBR8.PBR0.PBR5.SSD5._DSM, 4)
    {
        If (!Arg2) { Return (Buffer() { 0x03 } ) }
        Return(Package()
        {
            "class-code", Buffer() { 0xff, 0x08, 0x01, 0x00 },
            "built-in", Buffer() { 0 },
        })
    }
    Method(_SB.PCI0.PEG0.PEGP.PBR8.PBR0.PBR6.SSD6._DSM, 4)
    {
        If (!Arg2) { Return (Buffer() { 0x03 } ) }
        Return(Package()
        {
            "class-code", Buffer() { 0xff, 0x08, 0x01, 0x00 },
            "built-in", Buffer() { 0 },
        })
    }
    Method(_SB.PCI0.PEG0.PEGP.PBR8.PBR0.PBR7.SSD7._DSM, 4)
    {
        If (!Arg2) { Return (Buffer() { 0x03 } ) }
        Return(Package()
        {
            "class-code", Buffer() { 0xff, 0x08, 0x01, 0x00 },
            "built-in", Buffer() { 0 },
        })
    }
}
//EOF

 

[Lsucorey]

Probably something like this (SSDT just for the 4 SSDs in the "carrier card"):

// Inject bogus class-code for NVMe SSD to prevent IONVMeFamily.kext from loading
DefinitionBlock("", "SSDT", 2, "hack", "NVMe-Pcc-CC", 0)
{
    External(_SB.PCI0.PEG0.PEGP, DeviceObj)
    // create identities for the bridge @8 and SSD0 @0
    Device(_SB.PCI0.PEG0.PEGP.PBR8)
    {
        Name(_ADR, 0x00080000)  // corresponds to #PCI(0800), MSW byte reversed
        Device(PBR0)
        {
            Name(_ADR, 0) // corresponds to #PCI(0000)
            Device(PBR4)
            {
                Name(_ADR, 0x00040000) // #PCI(0400)
                Device(SSD4) { Name(_ADR, 0) } // SSD leaf #PCI(0000)
            }
            Device(PBR5)
            {
                Name(_ADR, 0x00050000) // #PCI(0500)
                Device(SSD5) { Name(_ADR, 0) } // SSD leaf #PCI(0000)
            }
            Device(PBR6)
            {
                Name(_ADR, 0x00060000) // #PCI(0600)
                Device(SSD6) { Name(_ADR, 0) } // SSD leaf #PCI(0000)
            }
            Device(PBR7)
            {
                Name(_ADR, 0x00070000) // #PCI(0700)
                Device(SSD7) { Name(_ADR, 0) } // SSD leaf #PCI(0000)
            }
        }
    }
    // now we can inject the _DSM at the newly created ACPI paths
    Method(_SB.PCI0.PEG0.PEGP.PBR8.PBR0.PBR4.SSD4._DSM, 4)
    {
        If (!Arg2) { Return (Buffer() { 0x03 } ) }
        Return(Package()
        {
            "class-code", Buffer() { 0xff, 0x08, 0x01, 0x00 },
            "built-in", Buffer() { 0 },
        })
    }
    Method(_SB.PCI0.PEG0.PEGP.PBR8.PBR0.PBR5.SSD5._DSM, 4)
    {
        If (!Arg2) { Return (Buffer() { 0x03 } ) }
        Return(Package()
        {
            "class-code", Buffer() { 0xff, 0x08, 0x01, 0x00 },
            "built-in", Buffer() { 0 },
        })
    }
    Method(_SB.PCI0.PEG0.PEGP.PBR8.PBR0.PBR6.SSD6._DSM, 4)
    {
        If (!Arg2) { Return (Buffer() { 0x03 } ) }
        Return(Package()
        {
            "class-code", Buffer() { 0xff, 0x08, 0x01, 0x00 },
            "built-in", Buffer() { 0 },
        })
    }
    Method(_SB.PCI0.PEG0.PEGP.PBR8.PBR0.PBR7.SSD7._DSM, 4)
    {
        If (!Arg2) { Return (Buffer() { 0x03 } ) }
        Return(Package()
        {
            "class-code", Buffer() { 0xff, 0x08, 0x01, 0x00 },
            "built-in", Buffer() { 0 },
        })
    }
}
//EOF

Looks like I need a bit more help, RehabMan, since I have been through several iterations now with no progress . I was able to successfully install 10.12.3 onto the RAID 0 array as well as the Nvidia drivers, etc., but I could only boot via the Unibeast USB (even though I edited config.plist in the USB EFI so that it was identical to the config.plist installed on the RAID EFI). Initially, I thought it might be the RAID array causing issues, so I deleted the RAID array and reinstalled on a single SSD on the carrier board and striped the remaining three. But I'm getting the same result where I can't boot to the drive without the Unibeast USB inserted even though I see the 960 UEFI in BIOS. I have attached the SSDT-NVMe-Pcc.aml file I most recently tried to use as well as my .ioreg.
On my most recent attempt, computer restarted about 2 seconds after trying to boot into OS X via the 960 Pro. Thanks again for the help.

 

[RehabMan]

Looks like I need a bit more help, RehabMan, since I have been through several iterations now with no progress . I was able to successfully install 10.12.3 onto the RAID 0 array as well as the Nvidia drivers, etc., but I could only boot via the Unibeast USB (even though I edited config.plist in the USB EFI so that it was identical to the config.plist installed on the RAID EFI). Initially, I thought it might be the RAID array causing issues, so I deleted the RAID array and reinstalled on a single SSD on the carrier board and striped the remaining three. But I'm getting the same result where I can't boot to the drive without the Unibeast USB inserted even though I see the 960 UEFI in BIOS. I have attached the SSDT-NVMe-Pcc.aml file I most recently tried to use as well as my .ioreg.
On my most recent attempt, computer restarted about 2 seconds after trying to boot into OS X via the 960 Pro. Thanks again for the help.

Change all "class-code" in the SSDT-NVMe-Pcc.aml to "#class-code". Then add the SSDT-NVMe-Pcc.aml to your Unibeast USB ACPI/patched. Boot using it, then attach ioreg.

 

[Lsucorey]

Change all "class-code" in the SSDT-NVMe-Pcc.aml to "#class-code". Then add the SSDT-NVMe-Pcc.aml to your Unibeast USB ACPI/patched. Boot using it, then attach ioreg.

Will do. Thanks again for taking the time out of your very busy schedule to look at everything! It's always most efficient when I let RehabMan see it directly .

 

[RehabMan]

View attachment 234400
Will do. In the mean time, take a look at this screen shot of ioreg. It may be nothing, but I'm still knee high to a grasshopper when it comes to ioreg, so I knew it would be most efficient to let you see . The screenshot pertains to the drive inserted in the native M.2 port (dedicated to Windows 10 and striped with another 960 Pro that I manually disable in BIOS before booting OS X - I have to disable it to get access to all of my SATA ports, in fact).

It looks normal. I don't see anything unusual or unexpected...
What am I supposed to be seeing that is interesting to you?

 

[Lsucorey]

It looks normal. I don't see anything unusual or unexpected...
What am I supposed to be seeing that is interesting to you?

The "@1D" location was throwing me off (RP09@1D). Here is my new ioreg (I switched out the 960 pro with a 950 Pro since I'm really only wanting it to serve as my clover boot loader, but everything else is the same). I have also attached a screenshot since it seems that the problem is most likely related to the IONVMeFamily kext; also, USB port limit is reached despite installing your 01/2017 USB-InjectAll kext manually with KextBeast and injecting the UpgradeMaxPort code via MultiBeast (and even make sure I manually inject your most recent InjectAll kext after just to be sure I have it updated). Anyways, just seeking a little direction since you're the man - I don't mind putting in the hours, but when I run up against a brick wall then I kinda need some insight - not satisfied relying on USB, I want it to be via real internal AHCI SATA or NVMe PCIe, as petty as that may be, for my clover boot loader, and not have to rely on the UniBeast USB (otherwise the setup is not professional Imo). Thanks again RehabMan!

Note: Ideally, I would just use my 850 EVO as my clover boot loader and keep all 4 960 SSDs for the Squid OS X RAID 0 Array, instead of reverting to 3. I initially tried to do this, but wasn't able to boot without the UniBeast USB inserted (same problem as now), so I changed methods. Also, it shouldn't make a difference whether I install the kexts into the System Library Extensions or the User Library Ext, right? The way I understand it, installing the kexts into the System Library just means it will be applied to all users. Anyways, it seems the kexts obviously aren't loading properly without the USB no matter what I do with that squid board installed.