Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

startergo

macrumors 603
Sep 20, 2018
5,020
2,282
You mean the built-in property? The reason is that the rest of the tree is not ready yet, so Innie simply gets out of the way. Of course, we can keep querying the I/O Registry, but when do we stop? We can also insert delays, but how long?
Maybe not based on time, but on feedback after interrogation. Checking if the tree downstream is ready. Is there an indication?
 

cdf

macrumors 68020
Original poster
Jul 27, 2012
2,256
2,583
Maybe not based on time, but on feedback after interrogation. Checking if the tree downstream is ready. Is there an indication?
Right. So there are two indicators that Innie uses: "IOPCIConfigured" and "IOPCIResourced". The assumption is that if the "built-in" property is set before the rest of the tree is ready, then the corresponding internal properties are automatically applied, but this is clearly not the case. Innie still needs to apply them. If enough of the tree is present, then the issue is easy to fix. On the other hand, the indicators don't tell the whole story. It's possible for a device (often behind multiple bridges) to still appear afterwards. This is where we need to resort to heuristics, such as delays and iterations through the I/O Registry, being careful not to impact the boot process...
 

hwojtek

macrumors 68020
Jan 26, 2008
2,274
1,277
Poznan, Poland
Right. So there are two indicators that Innie uses: "IOPCIConfigured" and "IOPCIResourced". The assumption is that if the "built-in" property is set before the rest of the tree is ready, then the corresponding internal properties are automatically applied, but this is clearly not the case. Innie still needs to apply them. If enough of the tree is present, then the issue is easy to fix. On the other hand, the indicators don't tell the whole story. It's possible for a device (often behind multiple bridges) to still appear afterwards. This is where we need to resort to heuristics, such as delays and iterations through the I/O Registry, being careful not to impact the boot process...
That's an effin amount of work for something that would seem so simple...
 

Syncretic

macrumors 6502
Apr 22, 2019
311
1,533
Right. So there are two indicators that Innie uses: "IOPCIConfigured" and "IOPCIResourced". The assumption is that if the "built-in" property is set before the rest of the tree is ready, then the corresponding internal properties are automatically applied, but this is clearly not the case. Innie still needs to apply them. If enough of the tree is present, then the issue is easy to fix. On the other hand, the indicators don't tell the whole story. It's possible for a device (often behind multiple bridges) to still appear afterwards. This is where we need to resort to heuristics, such as delays and iterations through the I/O Registry, being careful not to impact the boot process...

(I haven't read this whole thread, so my apologies if this has already been discussed, or you've already found this to be unworkable.) Mightn't you save some aggravation by using a narrower IOResourceMatch/IONameMatch/IOPropertyMatch in Info.plist to defer loading the kext until your desired scenario arises? It seems like the IOPCIConfigured and IOPCIResourced properties could be picked up with IOPropertyMatch, and you might not need to wait at all (just walk the subtree when loaded). You could probably even put multiple matching scenarios in the same Info.plist, or narrow the scope to just the actual PCI drives you're targeting (I haven't looked to see if that's reasonable) - basically, let IOKit do the heavy lifting for you.
 

cdf

macrumors 68020
Original poster
Jul 27, 2012
2,256
2,583
(I haven't read this whole thread, so my apologies if this has already been discussed, or you've already found this to be unworkable.) Mightn't you save some aggravation by using a narrower IOResourceMatch/IONameMatch/IOPropertyMatch in Info.plist to defer loading the kext until your desired scenario arises? It seems like the IOPCIConfigured and IOPCIResourced properties could be picked up with IOPropertyMatch, and you might not need to wait at all (just walk the subtree when loaded). You could probably even put multiple matching scenarios in the same Info.plist, or narrow the scope to just the actual PCI drives you're targeting (I haven't looked to see if that's reasonable) - basically, let IOKit do the heavy lifting for you.
Thanks for this! I think that relying more on IOKit is indeed the right approach, though given my current code, it might be easier to use IOServiceMatching than changing the driver personality. I'll have to experiment.
 

Chris_P

macrumors newbie
Mar 13, 2022
1
1
I know I'm very late chiming in here, but I recently got hold of a 12-core Mac Pro 5,1 for the right money and decided to go the NVME route (Flexx LX400 Pro SSD 512GB - card and ssd sold together). Followed the info to the letter and it worked right away - now my boot drive. It's showing as internal in all the right places. Just a couple of days in but all seems well. Just to say thanks for this. Great work.
 
  • Like
Reactions: hwojtek

kings79

macrumors regular
Sep 16, 2015
227
105
Sorry haven't read the whole thread but is there a script somewhere that will work with the cMP Mac Pro 2019?
 

startergo

macrumors 603
Sep 20, 2018
5,020
2,282
BUMP

Is the INNIE fix working with the new Mac Pro (2019)?
You can try it. As long as the SSD is not connected through a pci-bridge (check with ioregistry) it should work. If it is, you might need an SSDT. I 've been monkeying recently with MP7,1 SSDT and it is a pain in the neck.
 

kings79

macrumors regular
Sep 16, 2015
227
105
You can try it. As long as the SSD is not connected through a pci-bridge (check with ioregistry) it should work. If it is, you might need an SSDT. I 've been monkeying recently with MP7,1 SSDT and it is a pain in the neck.
SO you've never tried it?
 

cdf

macrumors 68020
Original poster
Jul 27, 2012
2,256
2,583
I have a M1 with an external TB-Drive. System is Big Sur. Does Innie convert the external icons to internal?
Innie hasn’t been tested with M1 systems. Besides, TB drives should probably be considered external…
 

Macschrauber

macrumors 68030
Dec 27, 2015
2,979
1,487
Germany
I have tried Innie on a Mac Pro 5,1 / Mojave with an Apple AHCI Blade and it worked.

Tested Hibernatemode 25 - and it worked since Innie got the blade shown as internal.

#11

but that was just a test for my main machine. This did not set my NVME Blade as internal, so Hibernatemode 25 did not worked

Code:
kextstat | grep Innie

   16    0 0xffffff7f80f0d000 0x2000     0x2000     com.cdf.Innie (1.3.0) DAF7FB11-5303-3B26-BE94-45F4BB79D3CE <5 3>

so I think it loaded

my NVME is a very common Samsung SSD 970 EVO Plus

is there a chance to get it in Innie?
 

macuser_007

macrumors newbie
Jul 10, 2015
2
0
I have a Mac Pro 5.1 and had Mac OS Big Sur with NVMe M.2 as a boot drive that was detected as an external drive. After I installed Innie.kext and it changed back to internal. Recently upgraded to Monterey and it changed back to an external drive. I've tried to re-install the Innie.kext twice but was still unable to change it back. Any suggestion?

*update on Jan 6

I found the problem and fixed it. Innie.kext works fine now.

Thanks (Unable to delete this post)
 
Last edited:

argp74

macrumors newbie
Jan 22, 2023
2
0
I have a Mac Pro 5.1 and had Mac OS Big Sur with NVMe M.2 as a boot drive that was detected as an external drive. After I installed Innie.kext and it changed back to internal. Recently upgraded to Monterey and it changed back to an external drive. I've tried to re-install the Innie.kext twice but was still unable to change it back. Any suggestion?

*update on Jan 6

I found the problem and fixed it. Innie.kext works fine now.

Thanks (Unable to delete this post)
I have a Mac Pro 5.1 with Monterey using OCLP. I successfully install Innie.kext with the instructions of post #9 but the Finder show my nvie drive as external. DiskUtility shows the disk as internal. You have this issue? and if not how you solve it? Thanks anyway!!
 

macuser_007

macrumors newbie
Jul 10, 2015
2
0
I have a Mac Pro 5.1 with Monterey using OCLP. I successfully install Innie.kext with the instructions of post #9 but the Finder show my nvie drive as external. DiskUtility shows the disk as internal. You have this issue? and if not how you solve it? Thanks anyway!!
It was the permission problem with the Innie.kext. I changed the owner back to 'system' with Read & Write. Not my user account with Read & Write.
 

argp74

macrumors newbie
Jan 22, 2023
2
0
If you're using OCLP, then you should really add the kext through OC.
Thanks a lot .. it works!!
I thing it needs new instructions for users with OCLP. We did not need to edit config.plist to install OS, so we didn't now that new kexts you had to load from EFI.
 

startergo

macrumors 603
Sep 20, 2018
5,020
2,282
Thanks a lot .. it works!!
I thing it needs new instructions for users with OCLP. We did not need to edit config.plist to install OS, so we didn't now that new kexts you had to load from EFI.
With OC you can enable the built-in property under devices no need for Innie. Where Innie shines is on systems without OC (booted natively) or with boot-args="-no_compat_check"
 

barral39

macrumors newbie
Mar 23, 2023
2
0
Innie has been updated to version 1.3.1. This version addresses a long-standing detection bug (many thanks to @Macschrauber for testing)!

Huge Thanks to you CDF for the Innie Project !

I installed Innie on my machine :

Mac Pro 6,1 with 3 NVME SSDs on a Amfeltec Angelshark Carrier Board - MacOS Monterey 12.6.2

Now with Innie installed the 3 SSDs are recognized as internal.

The Only Issue is :

Since I've installed Innie my booting time is 1min longer than before
My machine use to boot in about 20/30sec and now boot in 1min20/30 sec.

So is there anything I can do to fix this longer/slower booting time ?

Thanks !

Baptiste
 
Last edited:
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.