[Solution] COM Serial Port on Gigabyte Z170X running 10.11.4

[rs1n]

I tested macOS Sierra. There is no panic with no changes in BIOS (leave Super IO enabled), and with no removing or adding or patching of kexts required. The serial port just works. It's only El Capitan (and probably earlier Mac OS X versions) that need a workaround.

I have a Dell Optiplex 990 SFF that comes with a serial port built in. There are no issues that I am aware of with it enabled, and I am running El Capitan (10.11.6). I only briefly looked at the Apple16X50ACPI and IOBluetoothHostControllerUARTTransport kexts so this post may be complete non-sense. That said, the changes in how USB is handled (in some cases, requiring renaming EHC1 to EH01 for example) lead me to see if perhaps the bluetooth controller was also matching on the name. My device is attached as \_SB.PCI0.LPCB.COM1 (different from your UAR1) and I have the OS strings in my DSDT binding "Darwin" to "Windows 2009" to enable the ACPI devices for OS X. Alas, my brief "grep" session lead me nowhere. Anyway, I just wanted to share that I have no issues at all with my serial port and I have not done anything special (other than to enable the serial port as COM1 in bios). If you need any more info, just ask.

 

[joevt]

I have a Dell Optiplex 990 SFF that comes with a serial port built in. There are no issues that I am aware of with it enabled, and I am running El Capitan (10.11.6). I only briefly looked at the Apple16X50ACPI and IOBluetoothHostControllerUARTTransport kexts so this post may be complete non-sense. That said, the changes in how USB is handled (in some cases, requiring renaming EHC1 to EH01 for example) lead me to see if perhaps the bluetooth controller was also matching on the name. My device is attached as \_SB.PCI0.LPCB.COM1 (different from your UAR1) and I have the OS strings in my DSDT binding "Darwin" to "Windows 2009" to enable the ACPI devices for OS X. Alas, my brief "grep" session lead me nowhere. Anyway, I just wanted to share that I have no issues at all with my serial port and I have not done anything special (other than to enable the serial port as COM1 in bios). If you need any more info, just ask.

Do you have a Apple16X50ACPI in IORegistry attached to COM1? Is it named Apple16X50ACPI0? What is the value of the IOTTYSuffix property? Does the COM1 device have name PNP0501?

 

[rs1n]

Yes, Apple16X50ACPI is attached to COM1, but no it is not named Apple16X50ACPI0. It is in fact named Apple16X50ACPI1 and the IOTTYSuffix is 1. Yes, COM1's "name" is indeed PNP0501.

Incidentally, Apple16X50ACPI is also attached to another device (Intel Active Management Technology) as Apple16X50ACPI22. The AMT uses serial-over-LAN as opposed to a physical DB9 port like COM1. The AMT is connected to the the PCI bus as device 22. Its IOTTYSuffix is 22. I do not know if there is a connection between the two values; just thought I would mention it.

The system is a Dell Optiplex 990 SFF running El Capitan 10.11.6 in case you want to look up the specs.

PNP0501

• rs1n
• May 11, 2017

AMT serial-over-LAN

• rs1n
• May 11, 2017

COM1 serial port

• rs1n
• May 11, 2017

 

[rs1n]

Also, I do not recommend setting IOST to 0 in DSDT -- at least not via any sort of patch. The reason is that most patches will do a hex search for the IOST code, and this name is actually used by several other devices typically found in laptops (e.g. PS2 keyboards and mice/touchpads). I could simply be behind the times (patches could be much more sophisticated these days and have additional checks).

 

[joevt]

Yes, Apple16X50ACPI is attached to COM1, but no it is not named Apple16X50ACPI0. It is in fact named Apple16X50ACPI1 and the IOTTYSuffix is 1. Yes, COM1's "name" is indeed PNP0501.

So El Capitan doesn't crash in your case because your IOTTYSuffix is not 0.

Incidentally, Apple16X50ACPI is also attached to another device (Intel Active Management Technology) as Apple16X50ACPI22. The AMT uses serial-over-LAN as opposed to a physical DB9 port like COM1. The AMT is connected to the the PCI bus as device 22. Its IOTTYSuffix is 22. I do not know if there is a connection between the two values; just thought I would mention it.

Looking at the source code, https://opensource.apple.com/source...IOSerialFamily.kmodproj/IOSerialBSDClient.cpp , it does appear that the suffix is the device ID in this case. But that's for PCI device. What about the case of our ACPI devices (my UAR1 and your COM1)?

The solution is probably in https://opensource.apple.com/source/Apple16X50Serial/Apple16X50Serial-24/Apple16X50BusInterface.cpp
I haven't followed that code too closely. I believe the 16X50 has more than one UART, and maybe my computer uses the first and yours uses the second? That's the file I patched for my Hack16X50Serial.kext so that IOTTYSuffix would not be 0.

Can you show the properties of your COM1 device?

Also, I do not recommend setting IOST to 0 in DSDT -- at least not via any sort of patch. The reason is that most patches will do a hex search for the IOST code, and this name is actually used by several other devices typically found in laptops (e.g. PS2 keyboards and mice/touchpads). I could simply be behind the times (patches could be much more sophisticated these days and have additional checks).

Of course, you want a patch that does what you want and not affect anything else. This requires searching for more than just the name IOST. So in this case, you want to look at the bytes as listed by an aml disassembler. Anyway, this solution disables the serial port which I would rather not do.

 

[rs1n]

I'm not sure I follow what you mean by COM1 properties. Did you want information pulled from ioreg? from DSDT? network settings (they appear as network interfaces, too)? or something else?

 

[joevt]

I'm not sure I follow what you mean by COM1 properties. Did you want information pulled from ioreg? from DSDT? network settings (they appear as network interfaces, too)? or something else?

You have a screenshot for Apple16X50ACPI1 and Apple16X50UARTSync1 and Apple16X50UARTSync22. I was asking for a screenshot of COM1.

 

[rs1n]

The properties list spans several windows vertically, so I opted to extract it via:

ioreg -p IOService -n COM1 -r > ioreg.txt

It is attached below.

 

[joevt]

The properties list spans several windows vertically, so I opted to extract it via:
ioreg -p IOService -n COM1 -r > ioreg.txt
It is attached below.

Thanks. The only difference between my UAR1 and your COM1 is that my UAR1 has _UID 0 and your COM1 has _UID 1.

Apple16X50ACPI.cpp has code in the probe method that sets InterfaceInstance to _UID. This is then used to set the name ("Apple16X50ACPI1" in your case).

Apple16X50PCI.cpp sets InterfaceInstance to the PCI device number.

Apple16X50BusInterface.cpp uses InterfaceInstance to set the IOTTYSuffix property.

So, another solution would be to patch the DSDT so that _UID is not 0.

 

[rs1n]

Thanks. The only difference between my UAR1 and your COM1 is that my UAR1 has _UID 0 and your COM1 has _UID 1.

Apple16X50ACPI.cpp has code in the probe method that sets InterfaceInstance to _UID. This is then used to set the name ("Apple16X50ACPI1" in your case).

Apple16X50PCI.cpp sets InterfaceInstance to the PCI device number.

Apple16X50BusInterface.cpp uses InterfaceInstance to set the IOTTYSuffix property.

So, another solution would be to patch the DSDT so that _UID is not 0.

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.