[Solution] COM Serial Port on Gigabyte Z170X running 10.11.4

[joevt]

Interesting find! Do you think you will test this out? If it does work, it seems like the least amount of work in terms of getting a working serial port if it can be incorporated as a clover hotpatch.

I've added the instructions to #10 in the original post. I've tested the result in Sierra and El Capitan and it seems to be working as expected. No kernel panics, and the serial ports work with the built in drivers.

 

[rs1n]

For #10, I would recommend that users should first check what other serial devices are present in their system before immediately choosing _UID to be 1. My own DSDT actually has an additional COM2. So if in theory COM1 had been assigned UID 0 and COM2 been assigned UID 1, then there will definitely be a conflict.

And less significant: you may also want to mention that there are devices that are classified as serial that people don't think of. And example would be AMT (usually on boards meant for large deployment such as in businesses and universities).

 

[joevt]

For #10, I would recommend that users should first check what other serial devices are present in their system before immediately choosing _UID to be 1. My own DSDT actually has an additional COM2. So if in theory COM1 had been assigned UID 0 and COM2 been assigned UID 1, then there will definitely be a conflict.

I'll add a comment. I don't know if it's actually a problem if two devices have the same _UID. There is code to append a letter to the ID if there's more than one UART instance but I'm not sure if that refers to this case or not (it may be only for PCI serial port which may have multiple UARTs - probed from the PCI BAR registers).

And less significant: you may also want to mention that there are devices that are classified as serial that people don't think of. And example would be AMT (usually on boards meant for large deployment such as in businesses and universities).

The following command finds extensions that use IOTTYSuffix (~13 results):

grep -r IOTTYSuffix /System/Library/Extensions /Library/Extensions

If any of them can set IOTTYSuffix to 0 then that could be a problem for IOBluetoothHostControllerUARTTransport. However, for now, we'll assume that the problem is only with PNP0501 devices that Apple16X50Serial matches. We can also assume no-one has a PCI serial device with PCI device ID 0 until someone encounters evidence to the contrary.

grep -r PNP0501 /System/Library/Extensions /Library/Extensions

 

[joevt]

I'll add a comment.

I've updated the original post with more detail on creating the patch.

 

[jaredkipe]

So the latest Gigabyte BIOSes don't let you disable this anymore.

I would probably be fine with "Disable the serial port in Clover by setting IOST = 0" as I don't need PS2 mice or anything else that has been mentioned as being a side effect. Does anyone know how to actually do this? I don't see anything related (i.e. anything directly mentioning IOST) in Acpi, or any other section in Clover Configurator.

Would anyone be able to help out with disabling this? I believe it is related to crashes and audio instability I'm having.

 

[chickenlittleextremists]

Hello joevt,
This is the only post on this topic on the entire site and hackintosh community, and although i tried my hand on it, i couldn't successfully disable it.
So for me, the serial port is causing issues while booting up, and my BIOS doesn't have an option to disable it.

Here it is:

So, I would like to know, how can i disable this device?
I'm attaching my DSDT and my debug files.
I would really appreciate it if you can have a quick look on this.

Thanks!

 

[joevt]

Hello joevt,
This is the only post on this topic on the entire site and hackintosh community, and although i tried my hand on it, i couldn't successfully disable it.
So for me, the serial port is causing issues while booting up, and my BIOS doesn't have an option to disable it.

Here it is:

So, I would like to know, how can i disable this device?
I'm attaching my DSDT and my debug files.
I would really appreciate it if you can have a quick look on this.

Need a picture of the Apple16X50PCI22 properties. Discover how Apple16X50PCI22 matches that device, then make some property changes in config.plist that make it not match anymore.

There's two Apple16X50 drivers.
PCI: /System/Library/Extensions/Apple16X50Serial.kext/Contents/Info.plist
ACPI: /System/Library/Extensions/Apple16X50Serial.kext/Contents/PlugIns/Apple16X50ACPI.kext/Contents/Info.plist

Your's appears to be PCI (it doesn't have an ACPI name).
The PCI version matches by class-code (0x0700....)

It doesn't appear to be in the DSDT? Maybe it can be added, then adjusted - research how RehabMan does the class code spoofing method to enable NVMe support for older macOS versions. Maybe these methods are applicable to this device.

[Guide] HackrNVMeFamily co-existence with IONVMeFamily using class-code spoof

Overview The purpose of this guide is to explain how to use the class-code spoof technique to keep un-patched IONVMeFamily.kext (incompatible with most PC NVMe SSDs) from loading such that HackrNVMeFamily can be used along side it in EFI/Clover/kexts or installed to the system volume...

www.tonymacx86.com

 

[joevt]

Another option might be a codeless kext that matches to the device with a higher probe score? Since you don't want to load a driver, then the IOClass would be excluded.

 

[chickenlittleextremists]

Another option might be a codeless kext that matches to the device with a higher probe score? Since you don't want to load a driver, then the IOClass would be excluded.

This sounds much easier, here attaching a pic for the same, the probe score for this is 0x384.

Also attaching the debug files again, just in case needed.
I remember trying that from Rehabman on my laptop 2-3 years ago, ill check it again, just in case, but if you know how to work this, kindly help me with it, ill try it out.

Thanks!

 

[joevt]

This sounds much easier, here attaching a pic for the same, the probe score for this is 0x384.

Also attaching the debug files again, just in case needed.
I remember trying that from Rehabman on my laptop 2-3 years ago, ill check it again, just in case, but if you know how to work this, kindly help me with it, ill try it out.

Oh right. Your debug files contain the ioreg which I didn't look at. It has all the information. 0x384 is the Probe Score from the info.plist (900 decimal). So a codeless kext would be identical, without all the extra code. Replace Apple16 with Hack16 or some other name. Change probe score to 1000. Install in clover and see what happens.

It would look like this:
Hack16X50Serial.kext/Contents/Info.plist

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>BuildMachineOSBuild</key>
    <string>18A391019</string>
    <key>CFBundleDevelopmentRegion</key>
    <string>English</string>
    <key>CFBundleExecutable</key>
    <string>Hack16X50Serial</string>
    <key>CFBundleIdentifier</key>
    <string>com.hack.driver.Hack16X50Serial</string>
    <key>CFBundleInfoDictionaryVersion</key>
    <string>6.0</string>
    <key>CFBundleName</key>
    <string>Hack16X50Serial</string>
    <key>CFBundlePackageType</key>
    <string>KEXT</string>
    <key>CFBundleShortVersionString</key>
    <string>3.2</string>
    <key>CFBundleSignature</key>
    <string>????</string>
    <key>CFBundleSupportedPlatforms</key>
    <array>
        <string>MacOSX</string>
    </array>
    <key>CFBundleVersion</key>
    <string>3.2</string>
    <key>DTCompiler</key>
    <string>com.apple.compilers.llvm.clang.1_0</string>
    <key>DTPlatformBuild</key>
    <string>11O62d</string>
    <key>DTPlatformName</key>
    <string>macosx</string>
    <key>DTPlatformVersion</key>
    <string>10.15.4</string>
    <key>DTSDKBuild</key>
    <string>19F81</string>
    <key>DTSDKName</key>
    <string>macosx10.15internal</string>
    <key>DTXcode</key>
    <string>1140</string>
    <key>DTXcodeBuild</key>
    <string>11O62d</string>
    <key>IOKitPersonalities</key>
    <dict>
        <key>PCI 16X50 Serial Port</key>
        <dict>
            <key>CFBundleIdentifier</key>
            <string>com.hack.driver.Hack16X50Serial</string>
            <key>IOPCIClassMatch</key>
            <string>0x07000000&amp;0xFFFF0000</string>
            <key>IOProbeScore</key>
            <integer>1000</integer>
            <key>IOProviderClass</key>
            <string>IOPCIDevice</string>
        </dict>
    </dict>
    <key>LSMinimumSystemVersion</key>
    <string>10.15</string>
    <key>OSBundleCompatibleVersion</key>
    <string>1.9</string>
</dict>
</plist>

If it doesn't work, fix permissions, unload the Apple kext with kextunload -b com.apple.driver.Hack16X50Serial

Load the new kext with kextutil -v 6 Hack16X50Serial.kext and check the errors.