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

Passmore
Passmore
Posted
Posted

i used Rehabman's script in 10.11.5, stuck the kext in clover - booted and works perfectly :D. Then i upgraded to 10.11.6, ran the script for that and replaced the kext. SSD natively shows up as internal on my GA-Z170X-UD5 TH Mobo too. Delighted :). Thank you so, so much.

  • Like 1
Link to comment
Share on other sites
PatriotSpade
PatriotSpade
Posted
Posted (edited)

I am attempting to install to an Intel 750 SSD 400 GB using Stork's Gene Build as a guide along with using RehabMan's patch-nvme tool. I am using El Capitan 10.11.6 and followed the instructions in the readme to a tee. I have not made any other changes. When booting OSX Installer and opening Disk Utility, I can not get the 750 SSD to appear as an Internal Drive. I'm not sure what I could be doing wrong. I am using a Macbook Pro running El Capitan v10.11.6 with the security update. I created the HackrNVMeFamily-10_11_6_sec2016-001.kext file (md5 good) and copied it to EFI/CLOVER/kexts/10.11.

 

EDIT: I have run the installer using the verbose flag and did not see any errors or warnings that were alarming.

Edited by Micky1979
Our rule, sorry
Link to comment
Share on other sites
RehabMan
RehabMan
Posted
Posted

I am attempting to install to an Intel 750 SSD 400 GB using Stork's Gene Build as a guide along with using RehabMan's patch-nvme tool. I am using El Capitan 10.11.6 and followed the instructions in the readme to a tee. I have not made any other changes. When booting OSX Installer and opening Disk Utility, I can not get the 750 SSD to appear as an Internal Drive. I'm not sure what I could be doing wrong. I am using a Macbook Pro running El Capitan v10.11.6 with the security update. I created the HackrNVMeFamily-10_11_6_sec2016-001.kext file (md5 good) and copied it to EFI/CLOVER/kexts/10.11.

 

EDIT: I have run the installer using the verbose flag and did not see any errors or warnings that were alarming.

 

I don't think your Intel drive is compatible with Pike's patches.

 

Samsung 950 Pro is known to be compatible...

Link to comment
Share on other sites
Micky1979
Micky1979
Posted
Posted

If same hardware, same firmware (Intel 750 SSD 400 GB), then error is @PatriotSpade procedures.

An user opened an issue later fixed. The Intel 750 was the 1,2 TB one, with device id "pci8086,0953"

 

with your App ? Not compatible with EL?  :rolleyes:

look at the issue:

"Not working for Intel 750 PCI-E SSD on Sierra DP4 and newer"

is not implicit that was working in El Capitan, He tried on DP builds of Sierra.

  • Like 1
Link to comment
Share on other sites
Micky1979
Micky1979
Posted
Posted

My kext matches on NVMe class, not specific device-ids.

Yep the same, pci id is added for El Capitan kexts only (in truth always if the "IONameMatch" array exist). mentioned just to compare with @PatriotSpade if want let us know its id

 

@Carmine, no idea. These patches are done by Pike.

  • Like 1
Link to comment
Share on other sites
RehabMan
RehabMan
Posted
Posted

Yep the same, pci id is added for El Capitan kexts only (in truth always if the "IONameMatch" array exist). mentioned just to compare with @PatriotSpade if want let us know its id

No need for device-id specific matching with NVMe class match.

  • Like 1
Link to comment
Share on other sites
Micky1979
Micky1979
Posted
Posted

No need for device-id specific matching with NVMe class match.

mmmh, not tried this way for EC, in Sierra Apple did that, but different matching. You use "0x01080200&0xffffff00" (yep appear ok) instead of "0x01800200&0xffffff00" (Apple).

- The Class Codes of PCI Header of the target device need to be compliant with:
  Base Class Code: Mass Storage Controller (01h)
  Sub-Class Code: Non-Volatile Memory Controller (08h)
  Programming Interface: NVM Express (02h) 

Why? Apple apparently does not conform to the standard? (what kind of memory controller??)

The Intel 750 was working with the Apple Class code matching, can be this that make it work?

 

EDIT

sub class 80h stand for "Other ....", only guessing what is the difference, but apparently Intel " think diffrent" for their ssd. And now I realize why can or cannot work on some model (not sure)

  • Like 1
Link to comment
Share on other sites
RehabMan
RehabMan
Posted
Posted

mmmh, not tried this way for EC, in Sierra Apple did that, but different matching. You use "0x01080200&0xffffff00" (yep appear ok) instead of "0x01800200&0xffffff00" (Apple).

...

Why? Apple apparently does not conform to the standard? (what kind of memory controller??)

Apple likes to make their own rules.

 

The Intel 750 was working with the Apple Class code matching, can be this that make it work?

Last I looked at the Intel 750 class-code in ioreg, it looked according to the NVMe spec, but maybe I made a mistake in looking at it...

But if it is a IOKit matching issue, and not a kext probe/start issue, easy to verify by running kextstat after booting (with an IOKit match, even if probe/start fails, the kext will show loaded).

 

So far, no real information provided by the OP on what is happening...

 

If some devices have a non-standard class-code, easy to add it to the patch script. But we need to be sure that is what is needed first...

Link to comment
Share on other sites
Micky1979
Micky1979
Posted
Posted

Yes, agreed, but I don't own this disk and when I said "tested" was that an user reported it as working (the only difference from me and you, than, at this point is the class code... how can match otherwise?).

BTW the 08h define another tech.... but not NVM Express strictly, not sure what is now. Or I lost something.


EDIT

I would say that Apple treat the disk as a generic mass storage, like any other, with NVM tecnology, this affect performance. And in fact is.

Link to comment
Share on other sites
RehabMan
RehabMan
Posted
Posted

Yes, agreed, but I don't own this disk and when I said "tested" was that an user reported it as working (the only difference from me and you, than, at this point is the class code... how can match otherwise?).

BTW the 08h define another tech.... but not NVM Express strictly, not sure what is now. Or I lost something.

 

EDIT

I would say that Apple treat the disk as a generic mass storage, like any other, with NVM tecnology, this affect performance. And in fact is.

I based my class match on what is written in the NVMe 1.0 specification.

  • Like 1
Link to comment
Share on other sites
RehabMan
RehabMan
Posted
Posted

Right!

If we can get an ioreg from a computer that has this Intel device installed, we can compare the class-code to the NVMe standard (as in Samsung 950 Pro).

 

@PatriotSpade: Hint, hint...

 

That will at least tell us if Intel has done something funny here. And, of course, specifications being what they are, they are often not error free, and things are done in the industry not to spec regardless of what is written...

Link to comment
Share on other sites
Micky1979
Micky1979
Posted
Posted

That will at least tell us if Intel has done something funny here.

mmmh, if you look at my repo at issue 1 you can see that Intel 750 has  the standard "01080200" in ioreg, so at some point I advice to use that and edit the kext. In the issue 2 He asserted to have done all from scratch... but your kext should worked as expected,  so who know. Maybe too many tests, and not totally clear what happened in the user's pc.

Link to comment
Share on other sites
RehabMan
RehabMan
Posted
Posted

mmmh, if you look at my repo at issue 1 you can see that Intel 750 has  the standard "01080200

" in ioreg, so at some point I advice to use that and edit the kext. In the issue 2 He asserted to have done from scratch.. so who know..

With that class-code, it should match and the patched kext should load... assuming everything has been done correctly.

 

There is plenty of opportunity for mistakes:

- not creating HackrNVMeFamily correctly

- not installing HackrNVMeFamily correctly

- duplicate (different versions) HackrNVMeFamily installed

- leaving patches for IONVMeFamily in config.plist

- trying to inject from EFI when Clover kext injection isn't active (many do not understand the relationship between InjectKexts=Detect, FakeSMC.kext and EFI/Clover/kexts)

- patched IONVMeFamily.kext in /S/L/E instead of leaving it vanilla

- kextcache rebuild error (users of Kext Wizard don't know about errors during the process)

- forgetting to remove NVMeGeneric (and rebuild cache)

- etc

Link to comment
Share on other sites
Micky1979
Micky1979
Posted
Posted

a long list. You should add also:

- forgetting to install the generated kext somewhere. :hysterical:

(that happened to me with AppleHDA Patcher and aDummyHDA.kext... user thought he had done everything w/o installing it  ^_^ )

  • Like 1
Link to comment
Share on other sites
Badeendje
Badeendje
Posted
Posted

Caution! MD5 hash has changed!!!!

 

 

MD5 (IONVMeFamily DP6) = d525e0862b29c70b6d8393cb4ea44ed7

 

MD5 (IONVMeFamily DP7) = c69d50c9923557c0327b90a31be0e21b

 

 

Edit: after updating everything looks cool and still working, however besides booting and speed I have no real test

 

 

Caution! MD5 hash has changed again!!!!

 

 

MD5 (IONVMeFamily DP8) = 1c606275a9def674dfc6eea11e0af448

 

 

Caution! MD5 hash has changed once again in the GM!!!

 

MD5 (IONVMeFamily GM) = 68e7cad234ccf6b76cee6f7ba667c173

Link to comment
Share on other sites
Mork vom Ork
Mork vom Ork
Posted
  • Author
Posted

Just to let you all know:

 

IONVMeFamily.kext patch for SIERRA DB6 also gets passed and successfully applied to SIERRA GM. Just veryfied myself. So the patchscripts from Mickey and RehabMan could be used for patching SIERRA GM (build 16A319).

Hope it helps you to improve your both scripts.

 

Regards... Mork vom Ork

 

PS: i tested it by finding all instances of the patch in "vanilla" IONVMeFamily.kext's BIN file of SIERRA GM. All instances could be found and i am running the DB6 CLOVER patch right now in SIERRA GM.

  • Like 1
Link to comment
Share on other sites
SammlerG
SammlerG
Posted
Posted

For me the patched kext (patched with NVMeP 2.1) won´t boot with the vanilla NVME kext in S/L/E.

 

Tested with a clean install yesterday and tested with 10.11.6 / 10.12 PB 8 running system.

 

When i install the ...Borg.kext, i´m running into a KP at boot, but when i remove the original kext in S/L/E, system boots fine.

Clover kext patching works also.

 

Booted only with the original kext, i attached a screenshot from I/O reg.

 

What i am doing wrong?

 

Boot with the original NVME Kext:

mdRZOKF.jpg

 

 

KP when both kext are installed.

UgiDsFT.jpg

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