Jump to content

Patch for using NVMe under macOS Sierra is ready.

Mork vom Ork

By Mork vom Ork,
in Other Peripheral Devices

 Share
1,382 posts in this topic

Recommended Posts

mfc88
mfc88
Posted
Posted

It means your SSD has no ACPI identity. If you go through the class-code spoofing process, you'll kill two birds with one stone:

- updates will be easier due to co-existing with IONVMeFamily.kext

- the device will be recognized as internal

 

Haha! You're killing me man! Today was supposed to be easy.

 

Now I gotta reinstall windows again (after I JUST reformatted the drive for a Mac OS backup)...   :hysterical:

Link to comment
Share on other sites
RehabMan
RehabMan
Posted
Posted

Haha! You're killing me man! Today was supposed to be easy.

 

Now I gotta reinstall windows again (after I JUST reformatted the drive for a OS backup)...   :hysterical:

You can determine SSDT content from ioreg.

Link to comment
Share on other sites
RehabMan
RehabMan
Posted
Posted

Is this right?

 

_SB.PCI0.BR1B.H000

 

5lAhIid.png

 

zxhNj04.png

Yes. I'm surprised it is not showing as internal though as it has an ACPI identity (H000 is the leaf node, directly corresponding to the SSD itself).

You may have to also inject "built-in"=<00>

Link to comment
Share on other sites
mfc88
mfc88
Posted
Posted

Yes. I'm surprised it is not showing as internal though as it has an ACPI identity (H000 is the leaf node, directly corresponding to the SSD itself).

You may have to also inject "built-in"=<00>

I'm a little confused about how to make the SSDT (my knowledge of low-level programming is non-existent).

 

MaciASL -> New file - > 

 

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

And then save as "SSDT-NVMe-Pcc.aml", Format: ACPI Machine Language Binary

 

Tried the compile the above, and I just get the spinning wheel for ages.

 

Switched to another version of MaciASL, now I get a syntax 6126 error, unexpected PARSEOP_EXP_EQUALS. Obviously, I'm not implementing "built-in" correctly....

 

Remove the built in instruction and managed to get this code to compile:

DefinitionBlock ("", "SSDT", 2, "hack", "NVMe-Pcc", 0x00000000)
{
    External (_SB_.PCI0.BR1B.H000, DeviceObj)    // (from opcode)

    Method (_SB.PCI0.BR1B.H000._DSM, 4)  // _DSM: Device-Specific Method
    {
        If (LNot (Arg2)) { Return (Buffer () { 0x03 } ) }

        Return (Package () 
            {
            "class-code", Buffer () { 0x02, 0x08, 0x01, 0x00 }
        })
    }
}

Tried following this guide:

https://www.tonymacx86.com/threads/guide-patching-laptop-dsdt-ssdts.152573/

 

Confused about this (not sure what/how to do it/where do it):

- Make sure existing _DSM methods at the NVMe SSD ACPI path are renamed or deleted (can't find _DSM methods near BR1B.H000, too vague, needs clearer instructions, I prefer to do it myself, but I'm lost... attached DSDT.dsl)

DSDT.dsl.zip

Link to comment
Share on other sites
jeanchrijaz
jeanchrijaz
Posted
Posted

https://www.tonymacx86.com/threads/guide-hackrnvmefamily-co-existence-with-ionvmefamily-using-class-code-spoof.210316/

 

Unfortunately,  I don't have Windows installed, so it makes finding the SSD controller a bit more difficult.

i don't have Windows too...

I found an old installation of Window 7 but It doesn't display location path of ACPI

at this time I can not install correctly RehabMan NVMe patches :(

I will stay with NVMeGeneric.kext It's not clean but it's more faster than the 850 pro

with luck someone has the same configuration as me and he send me the good kext....

• Asus Z97-Pro (Wifi ac)

• SSD intel 600p 256Go

• OSX El Capitan 10.11.6 (15G1212)

 

 

 

 

 

 

Link to comment
Share on other sites
mfc88
mfc88
Posted
Posted

i don't have Windows too...

I found an old installation of Window 7 but It doesn't display location path of ACPI

at this time I can not install correctly RehabMan NVMe patches :(

I will stay with NVMeGeneric.kext It's not clean but it's more faster than the 850 pro

with luck someone has the same configuration as me and he send me the good kext....

• Asus Z97-Pro (Wifi ac)

• SSD intel 600p 256Go

• OSX El Capitan 10.11.6 (15G1212)

Use the method I used above to find your device location (download IORegistryExplorer, in the "Search" box type "storage", and you should be able to see where your SSD is located).

Link to comment
Share on other sites
jeanchrijaz
jeanchrijaz
Posted
Posted

Use the method I used above to find your device location (download IORegistryExplorer, in the "Search" box type "storage", and you should be able to see where your SSD is located).

I tried but I can't find

It's too complex for me now :(

 

 

io.png

 

Link to comment
Share on other sites
mfc88
mfc88
Posted
Posted

I tried but I can't find

It's too complex for me now :(

 

 

io.png

 

 

If you're highlighting the correct drive, then it's going to be at:

 

_SB.PCI0.RP01.PXSX (select PXSX@0 in the device tree, then look on the right-hand side to get the correct "class code")

Link to comment
Share on other sites
RehabMan
RehabMan
Posted
Posted

I'm a little confused about how to make the SSDT (my knowledge of low-level programming is non-existent).

 ...

The SSDT you're trying to compile is incorrect. The thing you're trying with built-in is totally wrong...

 

You should have:

// Inject bogus class-code for NVMe SSD to prevent IONVMeFamily.kext from loading
DefinitionBlock("", "SSDT", 2, "hack", "NVMe-Pcc", 0)
{
    External(_SB.PCI0.BR1B.H000, DeviceObj)
    Method(_SB.PCI0.BR1B.H000._DSM, 4)
    {
        If (!Arg2) { Return (Buffer() { 0x03 } ) }
        Return(Package()
        {
            "class-code", Buffer() { 0xff, 0x08, 0x01, 0x00 },
            "built-in", Buffer() { 0 },
        })
    }
}
//EOF
Must use a version of MaciASL that supports ACPI 6.1 (such as my fork of MaciASL).

Class code <02 08 01 00> 

 

Although he uses <ff 08 01 00>... so not 100% which class code to use!

With class-code spoofing we change it from <02 08 01 00> to <ff 08 01 00>.

It is the goal of the class-code spoof to NOT use the industry standard NVMe class-code.

Link to comment
Share on other sites
mfc88
mfc88
Posted
Posted 
// Inject bogus class-code for NVMe SSD to prevent IONVMeFamily.kext from loading
DefinitionBlock("", "SSDT", 2, "hack", "NVMe-Pcc", 0)
{
    External(_SB.PCI0.BR1B.H000, DeviceObj)
    Method(_SB.PCI0.BR1B.H000._DSM, 4)
    {
        If (!Arg2) { Return (Buffer() { 0x03 } ) }
        Return(Package()
        {
            "class-code", Buffer() { 0x02, 0x08, 0x01, 0x00 },
            "built-in", Buffer() { 0 },
        })
    }
}
//EOF

I updated to a different MaciASL. Guess I was using an older version! Sorry, like I stated, I don't know much about this programming language!!!

 

Anyway, took your code above, compiled (no errors), and successfully created: SSDT-NVMe-Pcc.aml

 

Okay, okay, okay I think I get it... so it should be:

"class-code", Buffer() { 0x02, 0x08, 0x01, 0x00 },

 

NOT (in SSDT-NVMe-Pcc.aml):

"class-code", Buffer() { 0xFF, 0x08, 0x01, 0x00 },

 

This will be spoofed to 0xFF during boot up...

 

 

Now about this...

"Make sure existing _DSM methods at the NVMe SSD ACPI path are renamed or deleted"

 

I'm currently using a modified DSDT.aml in ACPI->Patched. When I disassemble it, I don't find any references to _DSM methods near the path: .BR1B.H000. 

Link to comment
Share on other sites
RehabMan
RehabMan
Posted
Posted

Okay, okay, okay I think I get it... so it should be:

"class-code", Buffer() { 0x02, 0x08, 0x01, 0x00 },

No. Pointless. You really need to read carefully.

 

I'm currently using a modified DSDT.aml in ACPI->Patched. When I disassemble it, I don't find any references to _DSM methods near the path: .BR1B.H000.

It doesn't have to be near. It could even be defined in a separate file, but in the same scope.

If you simply search all your DSDT.aml + SSDT*.aml files for _DSM with MaciASL (using Find), you will notice that MaciASL shows you the scope of each method in the status bar at the bottom.

Link to comment
Share on other sites
mfc88
mfc88
Posted
Posted

No. Pointless. You really need to read carefully.

 

The code you fixed for me contains:

"class-code", Buffer() { 0x02, 0x08, 0x01, 0x00 },

However, if I'm reading your post correctly, it should have been (so that it spoofs the class INSTEAD of using the OEM class):

"class-code", Buffer() { 0xFF, 0x08, 0x01, 0x00 },
Link to comment
Share on other sites
RehabMan
RehabMan
Posted
Posted

The code you fixed for me contains:

"class-code", Buffer() { 0x02, 0x08, 0x01, 0x00 },

 

I was just fixing the compiler error caused by your incorrect "built-in" inject attempt. I didn't look at the content not causing errors.

I will edit the post just to avoid confusion.

 

However, if I'm reading your post correctly, it should have been (so that it spoofs the class INSTEAD of using the OEM class):

"class-code", Buffer() { 0xFF, 0x08, 0x01, 0x00 },

 

Yes... template provided in my guide at tmx.

Link to comment
Share on other sites
mfc88
mfc88
Posted
Posted

It doesn't have to be near. It could even be defined in a separate file, but in the same scope.

If you simply search all your DSDT.aml + SSDT*.aml files for _DSM with MaciASL (using Find), you will notice that MaciASL shows you the scope of each method in the status bar at the bottom.

Went ahead and searched through all the decompiled DSDT.dsl + SSDT*.dsl's, searched for _DSM and none of them scoped to nor within _SB.PCI0.BR1B

 

Closest thing I've found was in my DSDT.dsl => _SB.PCI0.BR3A (Line 57340) and then _SB.PCI1.QR1A(Line 57371). Nothing in between them.

 

Attached decompiled DSDT/SSDTs

Attached Clover origin folder with untouched DSDT/SSDTs

 

I was just fixing the compiler error caused by your incorrect "built-in" inject attempt. I didn't look at the content not causing errors.

 

 

Yes... template provided in my guide at tmx.

Okay!!! That's what I was confused about! Now it makes more sense.  :yes:

decompiled aml.zip

mfc88.acpi.zip

Link to comment
Share on other sites
RehabMan
RehabMan
Posted
Posted

Went ahead and searched through all the decompiled DSDT.dsl + SSDT*.dsl's, searched for _DSM and none of them scoped to nor within _SB.PCI0.BR1B

It would only matter if you found one specifically at _SB.PCI0.BR1B.H000.

If you didn't find it, then you don't have to worry.

I always remove/rename all _DSM methods just as a precaution.

Link to comment
Share on other sites
mfc88
mfc88
Posted
Posted

It would only matter if you found one specifically at _SB.PCI0.BR1B.H000.

If you didn't find it, then you don't have to worry.

I always remove/rename all _DSM methods just as a precaution.

Okay! Cool, that's what I was thinking. So I got this SSDT (with fixed class 0xff080100) in ACPI->patched! I'm not using Clover's drop tables nor sorted tables, will I need to now?

 

In ACPI->patched, I have: pike's XCPM ssdt.aml, this SSDT-NVMe-Pcc.aml and my modified DSDT.aml file -- which is specified in "DSDT name" under the config.plist->ACPI tab. So before I swap in the spoofed NVME.ktext, will I need to add the SSDTs under drop tables?   

Thank you very much for your help, but my knowledges are too limited to understand all

Too difficult for me, I will wait for an easier patch

Don't give up bud! I'll help you out as soon as I get mine working!!!!

Link to comment
Share on other sites
mfc88
mfc88
Posted
Posted

Thanks I really need help :(

My computer is waiting to work properly

 

attachicon.gifIMG_2409 2.jpg

I'll help you with what I can...

 

This is a GENERAL *spoofed* HackrNVMEFamily.kext guide, but it'll at least give you an idea of where to start! Please read Rehabman's guide if you want more information (ANY and ALL credit goes to him):

HackrNVMeFamily co-existence with IONVMeFamily using class-code spoof

 

 

1. Download MaciASL from Rehabman's repo (download the latest version):

https://bitbucket.org/RehabMan/os-x-maciasl-patchmatic/downloads

 

2. Unzip the file and drop the MaciASL.app file into your Applications folder

 

3. Next, download a precompiled version of IASL (the newer one):

https://bitbucket.org/RehabMan/acpica/downloads/

 

4. Unzip the file in the Downloads folder and run this command to copy IASL to your usr/bin folder:

sudo cp $HOME/Downloads/iasl usr/bin/iasl

5.  Download and run IORegistryExplorerv2.1 (download from the attachment at the bottom of this post)

 

6. This assumes you either have Pike's 17 Patches in your config.plist's KextsToPatch (easy, but tedious) OR you've generated a non-spoofed HackrNVMEFamily.kext, removed the IONVMEFamily.kext (copied to another location first, before removing) from S/L/E, rebuilt the caches, then placed the HackrNVMEFamily.kext in S/L/E, then rebuilt the caches again (medium and tedious)*** OR skip the below and look for your ACPI location in the Windows 10 Device Manager (easiest)

 

***After you've created a *spoofed* HackrNVMEFamily.kext, you can then remove the non-spoofed HackrNVMEFamily.kext and replace IONVMEFamily.kext back into S/L/E.

 

If you've used method one or two from above, then in the IORegistry search bar, type "storage" and search for the device that contains your NVMe ssd...

You can read it like... PCI0@0 => in a PCI slot, BR1B@1,1 => at this PCI device, H000@0=> at this device's (BR1B) leaf node

In my case, my Samsung 950 NMVe Pro is at this ACPI path:  _SB.PCI0.BR1B.H000 (YOUR ACPI PATH MAY/WILL BE DIFFERENT!!!!)

 

***If your NVME is missing an ACPI identity (SB.PCISlot.Device.Address) or behind a PCI bridge (SB.PCISlot.Device.Leafnode.PCIAddress) instead of a complete APCI identity (SB.PCISlot.Device.Leafnode), see Rehabman's guide for more information. ****

GZyVj02.png

Next, you'll want to select the leaf node (H000@0). Look at the class code. For reference, we'll be overwriting this first value with a spoofed value so that IONVMEFamily.ktext doesn't load during the boot process:

 

OEM class-code => <02 08 01 00>  (will always be 02 08 01 00)

Spoofed class-code => <FF 08 01 00> (will always be FF 08 01 00)

yyiqgPz.png

 

7. I've created an app that now does steps 8 and 9 for you. Otherwise, open up MaciASL. Then go to: File->New (do NOT use any pre-defined stuff).

 

8. You'll want to copy the code below, then replace these highlighted portions with your location and the provided spoofed class-code:

 

Here's an image to highlight what sections should be updated with your ACPI path and the provided spoofed class-code values (again, the first value in the class-code will be spoofed):

w6TLScS.png

 

Code to copy and paste inside the new MaciASL file (again, update the values highlighted above with YOUR ACPI path and make sure that you use the provided spoofed class-code):

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

Note: If for some reason your NVMe doesn't get recognized as an internal drive (only external), then use this code instead (again, replace with YOUR ACPI PATH):

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

9. Once you're sure everything is correct, click "Compile" and make sure you don't get any errors. If all is good, go to File->Save as..->

Name: SSDT-NVMe-Pcc.aml 

Location: Desktop

Format: ACPI Machine Language Binary

 

 

10. Mount your primary SSD/HDD/NVMe using Clover Configurator, then add the SSDT-NVMe-Pcc.aml to EFI->CLOVER->ACPI->Patched

 

NOTE: IF YOU'RE NOT USING A CUSTOM DSDT.AML IN EFI->CLOVER->ACPI->Patched, THEN SKIP STEPS 11-16a, AND INSTEAD OPEN CLOVER CONFIGURATOR, MOUNT YOUR PRIMARY DRIVE, OPEN YOUR CONFIG.PLIST, AND INSERT THE FOLLOWING CODE UNDER THE ACPI TAB, DSDT Patches (it'll be the empty table at the very top):

 

Add an entry for _DSM->XDSM by clicking the "+" sign:

Comment: Rename _DSM to XDSM
Find: 5F44534D
Replace: 5844534D

11. Otherwise, if you're using a custom DSDT, then we need to make sure there aren't any _DSM methods that may overwrite/interfere with our newly created SSDT. So, restart your computer. When at the Clover Boot Manager screen hit F4, wait 5 seconds, and Clover should dump some OEM SSDT AML files into your EFI folder. We'll be needing these files to make sure we don't have to remove any SSDTs associated with your ACPI path (_SB.PCI0.XXXX.XXXX)

 

 

12. Once you've boot into your Mac OS desktop, remount your primary drive with Clover Configurator, then go inside the EFI Folder, and go to: CLOVER->ACPI->origin. Inside origin, you'll see several dumped .aml files. The ones we want are SSDT*.aml (* means if there are more than one SSDTs in this folder, then copy ALL of those OEM SSDTs over; for example: SSDT-0.am, SSDT-1.aml, SSDT-2.aml...etc. WE WANT THEM ALL)

 

 

13. You can either copy and paste these files to a new folder on your desktop or just copy the whole origin folder and remove any files not associated with the above! Then, take your custom DSDT.aml and place it inside this folder as well!

 

 

14. Open a terminal window, type "cd" then drag and drop the folder you just made on your desktop into the terminal window (again, we only want your custom DSDT.aml and the OEM SSDT*.aml files in this folder)

For example (then hit enter):

cd $HOME/Desktop/origin

 

15. Next, copy and paste the code below and hit enter. This code will decompile your .aml files to .dsl files -- WE DO NOT EDIT THE .AML FILES WITH MACIASL, ONLY THE DECOMPILED .DSL FILES!!:

iasl -da -dl *.aml

 

16a. Open your custom DSDT.dsl and SSDT*.dsl files with MaciASL and do a "find" search for "_DSM". There will be a lot, but the one(s) we're looking for should be located at or scoped to your ACPI path (_SB.PCISlot.Device.Leafnode)

As you click through the results (by hitting the arrow ">"), look at the bottom left of the MaciASL window and it'll show where it's looking. AGAIN, we're looking for something that points to your ACPI path. In my case, I didn't find anything at or scoped over/inside: _SB.PCI0.BR1B.H000. However, if you do find a _DSM method at or scoped to your ACPI path, then you'll have to rename/remove the _DSM method manually by renaming "_DSM" to "XDSM" or you can simply delete the entire code block.

 

For example, we'll open our custom DSDT.dsl, and lets say our NVME path is SB.PCI0.RP01.PXSX. We do a search for "_DSM" or "PXSX," and then we see this that there's a _DSM scoped to SB.PCI0.RP01.PXSX. Now, since our NVMe is located here, then we'd have remove the DSM by changing "_DSM" to "XDSM" -- no need to make it complicated, simply swap out the underscore "_" to an "X"):

 

Example of a _DSM scoped to the device (PXSX):

NwxM4hx.png

Rename it from _DSM to XDSM:

61CJI5q.png

 

Compile the DSDT.dsl and save it as DSDT.aml: 

 

Name: DSDT.aml 

Location: Desktop

Format: ACPI Machine Language Binary

 

Then we replace the old custom DSDT.aml with this new custom DSDT.aml in EFI->CLOVER->ACPI->patched.

 

----

16b. If one of the OEM SSDTs that you've dumped via Clover contains injection to your NVMe's ACPI path, then you'll need to drop the SSDT (this most likely won't be the case, but it's always best to check)...

 

Now we need to search through your OEM SSDTs. Open each of them and look for an external reference to our NVME ACPI path and see if there is a _DSM in the code below.

 

For example, let's say our NVMe is located at SB.PCI0.RP01.PXSX, we open up several of the OEM SSDTs, and then we come across one of them that has an external reference to NVME's ACPI address...

 External (_SB_.PCI0.RP01.PXSX, DeviceObj)    // (from opcode)

When looking below, we may see that there's a _DSM that is SCOPED to our NVME's ACPI path (the bottom of MaciASL shows: SB.PCI0.RP01.PXSX._DSM).

 

 

This will conflict with our custom built NVME SSDT. So, we'll need to find the TableId (example of where to find the TableId is highlighted below):

nrF6x0X.png

And open our config.plist with Clover Configurator, go to the Acpi tab, then under Drop Tables, we will add this "SSDT-5.aml" by referencing it's tableId (SaSsdt), then save the config.plist:

rZB1Hkc.png

 

 

17. Next, download Rehabman's patchnvme from the link below and save it into to your Downloads folder:

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

 

 

18.  Then copy these commands and paste them into a terminal window and hit enter:

cd $HOME/Downloads/patch-nvme-master

Use the command below to generate a spoofed HackrNVMEFamily.kext:

./patch_nvme.sh --spoof

19. Check and make sure the MD5 ouput hashes match, if they do NOT match, do not use it, and instead report it here. If they do match, then you should be okay to install the generated HackrNVMeFamily-xx_xx_x.kext in either: S/L/E or L/E or EFI->Clover->Kexts->Other

 

 

20. Restart your computer and boot into your primary drive. Your NVMe should now be recognized. It should have the spoofed class code in the leaf node, should be recognized as internal, and should be working despite IONVMefamily.kext being inside S/L/E!

 

You can reload IOREGExplorer, search for "storage" and go back to the NVME's location and now notice that the class code will be spoofed to <FF 08  01 00> instead of the OEM's class-code <02 08 01 00>.

 

Click to see my NMVe example

 

 

If you have any issues, you can try following Rehabman's guide (which goes more in-depth)

 

Once again, all credit to Rehabman!

IORegistryExplorerv2.1.zip

  • Like 1
Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...