mfc88 Posted January 2, 2017 Share Posted January 2, 2017 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)... Link to comment Share on other sites More sharing options...
RehabMan Posted January 2, 2017 Share Posted January 2, 2017 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)... You can determine SSDT content from ioreg. Link to comment Share on other sites More sharing options...
mfc88 Posted January 2, 2017 Share Posted January 2, 2017 You can determine SSDT content from ioreg. Is this right? _SB.PCI0.BR1B.H000 Link to comment Share on other sites More sharing options...
RehabMan Posted January 2, 2017 Share Posted January 2, 2017 Is this right? _SB.PCI0.BR1B.H000 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 More sharing options...
mfc88 Posted January 2, 2017 Share Posted January 2, 2017 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 More sharing options...
jeanchrijaz Posted January 2, 2017 Share Posted January 2, 2017 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 More sharing options...
mfc88 Posted January 2, 2017 Share Posted January 2, 2017 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 More sharing options...
jeanchrijaz Posted January 2, 2017 Share Posted January 2, 2017 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 Link to comment Share on other sites More sharing options...
mfc88 Posted January 2, 2017 Share Posted January 2, 2017 I tried but I can't find It's too complex for me now 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 More sharing options...
jeanchrijaz Posted January 2, 2017 Share Posted January 2, 2017 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") Refresh page I have edited my image Link to comment Share on other sites More sharing options...
mfc88 Posted January 2, 2017 Share Posted January 2, 2017 Refresh page I have edited my image Class code <02 08 01 00> Although he uses <ff 08 01 00>... so not 100% which class code to use! Link to comment Share on other sites More sharing options...
jeanchrijaz Posted January 3, 2017 Share Posted January 3, 2017 Class code <02 08 01 00> Although he uses <ff 08 01 00>... so not 100% which class code to use! I'm lost lol ^^ Link to comment Share on other sites More sharing options...
RehabMan Posted January 3, 2017 Share Posted January 3, 2017 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 More sharing options...
mfc88 Posted January 3, 2017 Share Posted January 3, 2017 // 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 More sharing options...
jeanchrijaz Posted January 3, 2017 Share Posted January 3, 2017 Thank you very much for your help, but my knowledges are too limited to understand allToo difficult for me, I will wait for an easier patch Link to comment Share on other sites More sharing options...
RehabMan Posted January 3, 2017 Share Posted January 3, 2017 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 More sharing options...
mfc88 Posted January 3, 2017 Share Posted January 3, 2017 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 More sharing options...
RehabMan Posted January 3, 2017 Share Posted January 3, 2017 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 More sharing options...
mfc88 Posted January 3, 2017 Share Posted January 3, 2017 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. decompiled aml.zip mfc88.acpi.zip Link to comment Share on other sites More sharing options...
RehabMan Posted January 3, 2017 Share Posted January 3, 2017 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 More sharing options...
mfc88 Posted January 3, 2017 Share Posted January 3, 2017 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 More sharing options...
RehabMan Posted January 3, 2017 Share Posted January 3, 2017 Okay! Cool, that's what I was thinking. I'm not using Clover's drop tables nor sorted tables, will I need to now? No. Link to comment Share on other sites More sharing options...
mfc88 Posted January 3, 2017 Share Posted January 3, 2017 And we're finally done! Thanks for hanging in and helping me out! Link to comment Share on other sites More sharing options...
jeanchrijaz Posted January 3, 2017 Share Posted January 3, 2017 Don't give up bud! I'll help you out as soon as I get mine working!!!! Thanks I really need help My computer is waiting to work properly Link to comment Share on other sites More sharing options...
mfc88 Posted January 3, 2017 Share Posted January 3, 2017 Thanks I really need help My computer is waiting to work properly IMG_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. **** 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) 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): 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): Rename it from _DSM to XDSM: 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): 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: 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 1 Link to comment Share on other sites More sharing options...
Recommended Posts