UART and COM port problem

[idata]

Hi all,

On MinnowMax I work on Windows 8.1 with UART. In BIOS Setup I enable UART. In LSS & SCC Configuration menu in BIOS Setup I enable : LSS HSUART # 1 Support , LSS HSUART # 1 FlowCtrl , LSS HSUART # 2 Support , and LSS HSUART # 2 FlowCtrl . But I don't know if I need to in BIOS Setup in Miscellaneous configuration set UART interface on Super IO UART, for now I set Internal UART for UART interface. I install Intel driver ( https://downloadcenter.intel.com/download/24228/Intel-embedded-drivers-for-Windows-8-1-32-bit- https://downloadcenter.intel.com/download/24228/Intel-embedded-drivers-for-Windows-8-1-32-bit- ) and I got two UART controllers.

Problem :

Problem is that I have only one COM port ( COM1) and it is for debugging. I looking in inf (iaiouart.inf ) file of driver for which device is , and I find APCI/INT33BC device. The COM1 is device APCI/PNP0501 .

What I need to do to get COM 2 device ? I saw BaseSerialPortLib 16550 module in MdeModulePkg/Library for what it is this module. Need I add some module for UART or Serial port in fdf (PlatformPkg.fdf ) file to get COM2 device, or add COM2 in ACPI_table? Where I can find ACPI_table in source of firmware?

Best regards,

Anteja

[idata]

Hello Anteja,

Welcome back to the Intel Embedded community.

We're working on your case and will post an update as soon as possible.

Best regards,

Jimmy.

[idata]

Hello AntejaVM,

According to this document (# 545879): Intel® Atom™ Processor E3800 Product Family Intel® Celeron® Processor N2807 Intel® Celeron® Processor J1900 Microsoft Windows* 8 (Win8, WES8) 32-bit & 64-bit I/O Drivers Programming Guide chapter 4 UART Driver :

The UART driver in Win8 uses the framework of Microsoft called Serial Framework Extension (SerCx). To use UART controller, there must be a sub-device mounted under the specific UART controller. A user mode application can open this sub-device by using its symbolic name or GUID, and send IOCTLs or requests to it. Then only this sub-device can open parent target (UART controller) and forward IOCTLs or requests to SerCx framework, thus to UART controller driver.

Refer to the following for Microsoft framework:

http://msdn.microsoft.com/en-us/library/windows/hardware/dn265348%28v=vs.85%29.aspx http://msdn.microsoft.com/en-us/library/windows/hardware/dn265348%28v=vs.85%29.aspx

And the description of supported IOCTLs is here:

http://msdn.microsoft.com/en-us/library/windows/hardware/ff547466(v=vs.85).aspx http://msdn.microsoft.com/en-us/library/windows/hardware/ff547466(v=vs.85).aspx

There are no sample codes of the sub-device provided by Microsoft, but it's quite similar to the

SPB or GPIO interface.

Hope this helps, if you have any other question please let us know.

Regards,

Jimmy.

[idata]

Hello Jimmy,

I know for that solution, but I want somehow add in APCI_table ( in http://firmware.intel.com/projects/minnowboard-max original firmware for MinnowMax board ) COM2 device or enable it if is possible.

Thank you,

Anteja.

[idata]

Hello,

I tried with IOCTL, but problem was I couldn't open driver file with CreateFile method because I couldn't find path ( something like this \\\\.\\PCI# VEN_8086&DEV_0F0E&SUBSYS_72708086&REV_0C# 3&11583659&0&F5# {badc33d6-be37-4372-b90e-bbf2d986b0eb} ). For UART I have iaiouart.sys driver and I want to know if this driver return SerCx framework. I find for Windows 8 UART driver ( uart16550pc.sys ), but I don't know if I need some kind of bridge driver between two drivers.

[idata]

Hi Anteja,

We'll keep working on this case,and as soon as we have more information we'll write back.

Regards,

Jimmy.

[idata]

Hello AntejaVM,

Regarding the Microsoft framework, the best would be to post it in the Microsoft software developers forum:

https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/home?forum=wdk https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/home?forum=wdk

Since we don't troubleshoot nor support third party software.

Regards,

Jimmy.

[Ivan_R_Intel]

Anteja,

As far as I understand we have 2 UARTs but only one follows legacy COM-interface and the other one does not so Windows inbox driver serial.sys does not work with it so you only have one COM port.

(Basically COMx is just a symbolic link serial.sys creates to point to its device object, so if it does not service a device like in the case of the second HSUART, then it is not a COM-port). If you need to use COM-port and have ability to debug, I'd suggest to use Ethernet for debugging and free up COM1 for your other needs.

I hope this helps.

Best regards,

Ivan Rouzanov.

[BBerg7]

Hi Anteja,

The high speed UARTs can be setup to work as the legacy UARTs through SMM emulation. However, the ACPI code tells me that this is not the case in your system.

The ACPI code only reflects two UARTs and the debug UARTs are expected to be disabled at the OS level. If you turn off the debug UART, your two high speed UARTs may turn up in the ACPI code. That in turn, may load the drivers for the high speed UARTs instead of the legacy UART.

Best regards,

B-O

[idata]

Hi Berth,

Thank you for your input!

Best,

Scott

[idata]

Hello B-O,

Thank you for solution.

Could you tell me more about setup legacy UARTs through SMM emulation and which ACPI code tells you that is not case in my system ? Could you elaborate how disable debug UART at the OS level ?

Best regards,

Anteja

[BBerg7]

Hello Anteja,

The COM1 device ACPI _HID is PNP0501 indicating it's a legacy UART. The COM2 device ACPI _HID is INT33BC indicating it's not a legacy UART. If the high speed UARTs are emulated, then they would also have the PNP0501 ACPI _HID value.

The debug UART should normally be disabled by the BIOS. The decoding and IRQ can be disabled by LPC registers. The normal GPIO functionality of the pins used by UART RX/TX should also be restored to make a clean disable of the debug UART.

The easiest is disable the debug UART in the BIOS. If you want to do it from the OS I advice you to read the BWG.

BR,

B-O