Resolved How to force MacPro5,1 integrated SATA bus drives appear as external (non built-in) in macOS with OpenCore?

[ylluminate]

I have a scenario where I'd like to flip the default behavior one sees with OpenCore (specifically OpenCore Legacy Patcher) wherein the integrated SATA controller on a MacPro5,1 shows all attached drives internal (aka `built-in`) drives. Note this behavior is defined in the DeviceProperties section of the config.plist for the Device:

PciRoot(0x0)/Pci(0x1f,0x2)

gfxutil also confirms:

$ ./gfxutil -f SATA
00:1f.2 8086:3a22 /PCI0@0/SATA@1F,2 = PciRoot(0x0)/Pci(0x1F,0x2)

The key and value is normally set by this for OpenCore Legacy Patcher:

Device	Key	Value
PciRoot(0x0)/Pci(0x1f,0x2)	built-in	1

When I change the value to "0" I thought that it should then force these drives to become / be seen as "external" drives, however following modification of the config.plist and rebooting, the drives on this PCI SATA bus are still showing up as EXTERNAL drives instead of internal...

Any idea of how to force all the drives attached to this integrated SATA controller to show up as external / non-built-in?

 

[cdf]

This property (for the SATA drive bays) already exists natively, so changing its value requires that you delete it first. This is done in OC like adding device properties, except that the plist entry is “Delete” rather than “Add” and the dictionary of property-value pairs is replaced by an array of property names (in this case, just “built-in”).

Note that merely the presence of “built-in” rather than its value (1 vs 0) can keep the drive internal, so it’s probably best to just delete the property and not re-add it after.

I’ve never tried getting a drive to show up as external like this, so please keep us updated.

 

[ylluminate]

Thanks for the elucidation of this @cdf. Please confirm that I'm understanding you correctly:

The following (both entries present for Add and Delete within DeviceProperties):

To this only (the Delete only):

Upon rebooting with only the Delete entry the drives attached thereunto are still showing up as INTERNAL/built-in.

 

[cdf]

This looks OK. Try with the zero value also (first example above). Another thing to check would be whether the expected changes are reflected in the I/O Registry (you can use ioreg in Terminal or the I/O Registry Explorer app).

 

[rpmurray]

When I change the value to "0" I thought that it should then force these drives to become / be seen as "external" drives, however following modification of the config.plist and rebooting, the drives on this PCI SATA bus are still showing up as EXTERNAL drives instead of internal...

Kind of confused by this. If they're still showing as external and you want them to be external, what's the problem?

 

[ylluminate]

@cdf thanks - first, could you clarify what I should do to get the value (sanity check here since I'm not seeing them) via ioreg and reg explorer? For example BEFORE re-adding Add (ie, with only the device Delete key), ioreg yields:

$ ioreg | grep -i sata
    | |   +-o SATA@1F,2  <class IOPCIDevice, id 0x1000001da, registered, matched, active, busy 0 (2292 ms), retain 17>

While IORegistryExplorer yields:

I then modified config.plist so as to have the Add value again such that it contains this:

While `ioreg` again showed up identically as above (I'm obviously not querying it properly), IORegistryExplorer did show the value this time:

And unfortunately the drives on this PCI bus' SATA adapter still show up as internal:

@rpmurray I am attempting to do the reverse of what you normally want: converting internal drives to external. There is an interesting and good reason for this "madness," but I can explain it after I get this working.

 

[cdf]

Entering ioreg -c IOPCIDevice | grep "SATA@1F,2" -A 24 in Terminal should display the property. You can also see the same information in the I/O Registry Explorer app by navigating to IOService:/AppleACPIPIatformExpert/PCI0@0/AppleACPIPCI/SATA@1F,2 . You’ll notice that the native value is <00>. As I mentioned before, the particular value of the “built-in” property is not important; as long as the property is present, the drives will be internal. Still, as this concerns the drives bays, I’m not sure the drives won’t be made internal even if the property can be removed. It’s certainly worth a try, though.

 

[ylluminate]

Hmm, thanks @cdf. So with the Add and Delete present, it looks like this:

$ ioreg -c IOPCIDevice | grep "SATA@1F,2" -A 24
    | |   +-o SATA@1F,2  <class IOPCIDevice, id 0x1000001da, registered, matched, active, busy 0 (2306 ms), retain 17>
    | |   | | {
    | |   | |   "assigned-addresses" = <10fa00810000000038610000000000000800000014fa0081000000004c610000000000000400000018fa0081000000003061000000000000080000001cfa00810000000048610000000000000400000020fa00810000000020600000000000002000000024fa0082000000000080d2900000000000080000>
    | |   | |   "IOInterruptSpecifiers" = (<1100000007000000>,<0000000000000100>)
    | |   | |   "class-code" = <01060100>
    | |   | |   "IODeviceMemory" = ("IOSubMemoryDescriptor is not serializable","IOSubMemoryDescriptor is not serializable","IOSubMemoryDescriptor is not serializable","IOSubMemoryDescriptor is not serializable","IOSubMemoryDescriptor is not serializable",({"address"=2429714432,"length"=2048}))
    | |   | |   "built-in" = <00>
    | |   | |   "subsystem-vendor-id" = <86800000>
    | |   | |   "IOPowerManagement" = {"ChildrenPowerState"=2,"CurrentPowerState"=2,"CapabilityFlags"=258,"ChildProxyPowerState"=2,"MaxPowerState"=3}
    | |   | |   "acpi-device" = "IOACPIPlatformDevice is not serializable"
    | |   | |   "IOInterruptControllers" = ("io-apic-0","IOPCIMessagedInterruptController")
    | |   | |   "vendor-id" = <86800000>
    | |   | |   "name" = <"pci8086,3a22">
    | |   | |   "device-id" = <223a0000>
    | |   | |   "acpi-pmcap-offset" = 112
    | |   | |   "IOPCIResourced" = Yes
    | |   | |   "compatible" = <"pci8086,7270","pci8086,3a22","pciclass,010601","SATA">
    | |   | |   "IOServiceDEXTEntitlements" = (("com.apple.developer.driverkit.transport.pci"))
    | |   | |   "acpi-path" = "IOACPIPlane:/_SB/PCI0@0/SATA@1f0002"
    | |   | |   "subsystem-id" = <70720000>
    | |   | |   "revision-id" = <00000000>
    | |   | |   "pcidebug" = "0:31:2"
    | |   | |   "IOName" = "pci8086,3a22"
    | |   | |   "reg" = <00fa00000000000000000000000000000000000010fa00010000000000000000000000000800000014fa00010000000000000000000000000400000018fa0001000000000000000000000000080000001cfa00010000000000000000000000000400000020fa00010000000000000000000000002000000024fa000200000000000000000000000000080000>
    | |   | | }

Clearly built-in is indeed false here, but then when I remove the Add entry and ONLY have the Delete entry as before, this value still shows up:

$ ioreg -c IOPCIDevice | grep "SATA@1F,2" -A 24 | grep -i built
    | |   | |   "built-in" = <00>

So it seems that this value is irrelevant regardless of what we're doing here. Any additional ideas about how we might trick the system into considering these to be external?

 

[cdf]

Clearly built-in is indeed false here, but then when I remove the Add entry and ONLY have the Delete entry as before, this value still shows up:

$ ioreg -c IOPCIDevice | grep "SATA@1F,2" -A 24 | grep -i built
    | |   | |   "built-in" = <00>

So it seems that this value is irrelevant regardless of what we're doing here.

Just to clarify, <00> doesn’t mean false: “built-in” is true regardless of it’s value. The issue here is that the property isn’t being removed (or it’s being re-added afterwards).

Any additional ideas about how we might trick the system into considering these to be external?

Yes. But this would require developing a kext to change some higher level properties via IOKit.

 

[ylluminate]

Thanks. Hmm, I suppose that's concerning. Had hoped the facilities were already available via OC to force things like this in reverse, but perhaps since this is Apple hardware the detection does indeed happen at the kernel/driver level and consequently another option will need to be used somehow - sounding like you may be right about a kext... hmm.

 

[cdf]

I just thought of something. Try adding this patch to the array in Kernel>Patch:

<dict>
    <key>Arch</key>
    <string>Any</string>
    <key>Base</key>
    <string></string>
    <key>Comment</key>
    <string>Make drives external for some reason</string>
    <key>Count</key>
    <integer>0</integer>
    <key>Enabled</key>
    <true/>
    <key>Find</key>
    <data>SW50ZXJuYWw=</data>
    <key>Identifier</key>
    <string>com.apple.driver.AppleAHCIPort</string>
    <key>Limit</key>
    <integer>0</integer>
    <key>Mask</key>
    <data></data>
    <key>MaxKernel</key>
    <string></string>
    <key>MinKernel</key>
    <string></string>
    <key>Replace</key>
    <data>RXh0ZXJuYWw=</data>
    <key>ReplaceMask</key>
    <data></data>
    <key>Skip</key>
    <integer>0</integer>
</dict>

It's an ugly patch that makes all AHCI drives external. It might be worth trying.

 

[ylluminate]

Wow @cdf! What an interesting trick - it worked!!! I had hoped to retain the other drives as internal
(since I have a few other drives attached via PCI), but I don't see any immediate negative impacts of having everything recognized as external. Can you think of anything particular glaring in this regard?

So @rpmurray to clarify: the reason I'm doing this is due to the way Parallels works and my need to use this for being primarily a virtual machine host (server) while still retaining the ability to keep macOS as the operating system (eg, instead of running bare metal Linux). I tried VMware, but found a very longstanding bug (that they will not be fixing) where they simply do not allow multiple drives with the same mfg and model to be passed through on into a virtual machine and in my case I have several drives that have a lot of old data on them that I cannot simply format or modify and I consequently need to pass them on into a Linux virtual machine.

Parallels, on the other hand, DOES allow passing drives on into the virtual machine AS LONG AS they are EXTERNAL drives. When drives are recognized as internal Parallels disallows them from appearing to and being used in Parallels virtual machine guests. So, obviously, by tricking the system into showing drives as external drives Parallels is then able to use any drive as a direct access drive, thus passing the drive on into the virtual machine guest for handling.

Eg, in my specific case now the additional drives are detected within Proxmox such that we can use the old drives as-is. Note that the guest Linux system now sees them directly and as they are:

 

[cdf]

Can you think of anything particular glaring in this regard?

Well, macOS will treat the drives as if they’re external, so there may be permission and ownership differences, but nothing too serious.