- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
I have observed a possible problem in the UART1 PCI Configuration Space of Tiger Lake.
I think this may confuse Ubuntu kernel's serdev system, and make UART1 disappear from the /dev directory.
The problem is located at UART1’s PCI Configuration Header register located at offset 0x2C. This 32-bit register contains 0x00000000, which is wrong (i.e. System Device ID = 0x0000 and System Vendor ID = 0x0000). The correct value is 0x72708086. Here is a screenshot showing the problem:
$ lspci -x -s 00:1e.0
00:1e.0 Communication controller: Intel Corporation Tiger Lake-LP Serial IO UART Controller #0 (rev 20)
00: 86 80 a8 a0 06 00 10 00 20 00 80 07 10 00 80 00
10: 04 10 80 10 40 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 70 72 == Correct
30: 00 00 00 00 80 00 00 00 00 00 00 00 ff 01 00 00
$ lspci -x -s 00:1e.1
00:1e.1 Communication controller: Intel Corporation Tiger Lake-LP Serial IO UART Controller #1 (rev 20)
00: 86 80 a9 a0 06 00 10 00 20 00 80 07 10 00 80 00
10: 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 == Wrong
30: 00 00 00 00 80 00 00 00 00 00 00 00 ff 02 00 00
The UART0 and UART1 can be identified in the PCH documentation snapshot below.
I would be grateful to obtain the exact binary PCI Configuration Spaces of all devices in the PCH of Core i7-1185GRE.
Best regards,
Karl Osen
Intel® 500 Series Chipset Family OnPackage Platform Controller Hub
Datasheet, Volume 1 of 2
Rev. 007
September 2021
Table 6. PCH-UP3/UP4 Device and Revision ID Table
Dev ID | Device Function - Device Description | Z0 | A0 SRID | B0 | Note |
A080 - | D31:F0 - eSPI Controller | 00 | 10 | 20 | PCH Device IDs: |
A0A0 | D31:F1 - P2SB | 00 | 10 | 20 | |
A0A1 | D31:F2 - PMC | 00 | 10 | 20 | |
A0A3 | D31:F4 - SMBus | 00 | 10 | 20 | |
A0A4 | D31:F5 - SPI (flash) Controller | 00 | 10 | 20 | |
15E1 | D31:F6 - GbE Controller: Corporate/Intel® vPro™ | 00 | 10 | 20 | |
15E2 | D31:F6 - GbE Controller: Consumer | 00 | 10 | 20 | |
A0A6 | D31:F7 - Intel® Trace Hub (Intel® TH) | 00 | 10 | 20 | |
A0A8 | D30:F0 - UART #0 | 00 | 10 | 20 | |
A0A9 | D30:F1 - UART #1 | 00 | 10 | 20 | |
A0AA | D30:F2 - GSPI #0 | 00 | 10 | 20 | |
A0AB | D30:F3 - GSPI #1 | 00 | 10 | 20 | |
A0B0 | D29:F0 - PCI Express Root Port #9 | F0 | F0 | F0 | |
A0B1 | D29:F1 - PCI Express Root Port #10 | F0 | F0 | F0 | |
A0B2 | D29:F2 - PCI Express Root Port #11 | F0 | F0 | F0 | |
A0B3 | D29:F3 - PCI Express Root Port #12 | F0 | F0 | F0 | |
A0B8 | D28:F0 - PCI Express Root Port #1 | F0 | F0 | F0 | |
A0B9 | D28:F1 - PCI Express Root Port #2 | F0 | F0 | F0 | |
A0BA | D28:F2 - PCI Express Root Port #3 | F0 | F0 | F0 | |
A0BB | D28:F3 - PCI Express Root Port #4 | F0 | F0 | F0 | |
A0BC | D28:F4 - PCI Express Root Port #5 | F0 | F0 | F0 | |
A0BD | D28:F5 - PCI Express Root Port #6 | F0 | F0 | F0 | |
continued... |
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello KarlOsen,
Thank you for posting on the Intel® communities.
I would like to let you know that we have a specific forum for this kind of issue and product, it is called the "Embedded Intel® Core™ Processors". I will move the thread and there you will receive the appropriate support on this and other concerns you may have related to this product.
Here you will find the link to access the community forums:
Forums: https://community.intel.com/t5/Embedded-Intel-Core-Processors/bd-p/embedded-core-processors
Regards,
Deivid A.
Intel Customer Support Technician
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello, @KarlOsen:
Thank you for contacting Intel Embedded Community.
We received your consultation, but we want to address the following questions:
Could you please let us know if this situation is related to a third-party device or a design developed by you? Please mention the name of the manufacturer and the part number of the device.
Is this situation happening only with Ubuntu, or is happening also in Yocto Project 4.0, VxWorks 7, or Windows 10 RS5?
We are waiting for your answer to these questions.
Best regards,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi CarlosAM_INTEL.
For confidentiality reasons I cannot publish the name of the manufacturer of the Single Board Computer (SBC) having the described problem. Please send me your email address to karl@karlosenllc.com and I will send you information about the SBC and its manufacturer (it is a major European manufacturer of embedded electronics).
The cleared System Device ID and System Vendor ID fields in the UART1 PCI Configuration Space Header is not an Ubuntu artefact: The SBC has an UEFI Console that is a part of the Aptio BIOS system, and using the UEFI Console I have inspected the UART1 PCI Configuration Space Header and the System Device ID and System Vendor ID fields are cleared there too.
In Ubuntu kernel 5.4.0 (early 22.04 kernel) the UART1 is available as /dev/ttyS5 . However, in later Ubuntu kernel versions /dev/ttyS5 is absent. I believe that this regression is due to later versions of the Linux serdev code (which by the way make calls to the ACPI system).
FYI: I have discovered a work-around that consists of disabling serdev by inserting "return -ENODEV;" as the first line in the function static int acpi_serdev_register_devices located in the file jammy/drivers/tty/serdev/core.c .
Best regards,
Karl Osen
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello, @KarlOsen:
Thanks for your reply.
Based on your last communication since it seems to be a kernel issue, you should address this consultation as a reference to the channel listed on the following website:
Best regards,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello, @KarlOsen:
Thanks for your update.
We sent an email to the address related to this account with information that may help to solve this situation.
Best regards,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Hi CarlosAM_INTEL.
I understand that Intel considers there is nothing wrong with the Tiger Lake-LP Serial IO UART Controller #1 PCI Configuration Space Header, where System Device ID and System Vendor ID are both zero (whereas 0x7270 and 0x8086 are expected):
$ lspci -x -s 00:1e.1
00:1e.1 Communication controller: Intel Corporation Tiger Lake-LP Serial IO UART Controller #1 (rev 20)
00: 86 80 a9 a0 06 00 10 00 20 00 80 07 10 00 80 00
10: 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 (last 4 bytes are System Device ID and System Vendor ID)
30: 00 00 00 00 80 00 00 00 00 00 00 00 ff 02 00 00
Please confirm that this behavior is defined by Tiger Lake-LP Serial IO UART hardware, and that it is not a "feature" that can be introduced by integrators or BIOS developers.
Kind regards,
Karl Osen
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello, @KarlOsen:
Thanks for your reply.
We sent another email with information that may help you.
Best regards,
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page