1. Edk2 | Devel
  2. Topics

Intel NUC platform firmware -- no serial I/O support?

Laszlo Ersek
 

Hi List,

my toolbox has been extended with an Intel NUC, the base kit model being
NUC8i3PNH. The NUC has a serial port connector on the back, and indeed
Serial I/O works fine once an OS starts.

However, the UEFI platform firmware seems to have no support for Serial
I/O. I've built a fresh UEFI Shell binary from edk2 master and poked
around in the protocol database, with "drivers" and "dh". The necessary
drivers seem to be included, however they do not appear to bind the
hardware that's inside the chassis. ("connect -r" makes no difference in
this regard, so it's not just BDS policy.)

Interestingly, the related drivers are all called "AMI ...", which I
find somewhat strange on an Intel-branded NUC. I don't know whom I
should be addressing with my question in the first place. Just to be
sure, I'm CC'ing a bunch of randomly picked @ami.com email addresses
from my edk2-devel list archive.

I can provide more details if needed, but first I'd like to ask if *any*
firmware update exists for this kit -- NUC8i3PNH -- where the platform
firmware can drive the serial port. My goal is (of course) completely
headless operation of the NUC; ideally, that would cover the UEFI
console too.

Right now, I need to connect an HDMI monitor and a USB keyboard+mouse to
the NUC just to get into the Setup UI / UEFI Shell.

Thanks!
Laszlo

Gerd Hoffmann
 

Hi,

However, the UEFI platform firmware seems to have no support for Serial
I/O. I've built a fresh UEFI Shell binary from edk2 master and poked
around in the protocol database, with "drivers" and "dh". The necessary
drivers seem to be included, however they do not appear to bind the
hardware that's inside the chassis. ("connect -r" makes no difference in
this regard, so it's not just BDS policy.)
Disclaimer: Havn't used amt/vpro for a quite while. But possibly those
drivers bind to the serial device which shows up when you enable remote
management and serial-over-lan support?

take care,
Gerd

Laszlo Ersek
 

On 04/07/22 10:00, Gerd Hoffmann wrote:
Hi,

However, the UEFI platform firmware seems to have no support for
Serial I/O. I've built a fresh UEFI Shell binary from edk2 master and
poked around in the protocol database, with "drivers" and "dh". The
necessary drivers seem to be included, however they do not appear to
bind the hardware that's inside the chassis. ("connect -r" makes no
difference in this regard, so it's not just BDS policy.)
Disclaimer: Havn't used amt/vpro for a quite while. But possibly
those drivers bind to the serial device which shows up when you enable
remote management and serial-over-lan support?
Hm... it boggles my mind a bit to think about this, but... considering
Serial-over-LAN, what that would do, I expect, is provide a SerialIo
protocol interface on top of *some* networking protocol (directly or
indirectly). Then TerminalDxe would provide SimpleTextIn and
SimpleTextOut on top of SerialIo, and then those SimpleTextIn and
SimpleTextOut protocol instances would become part of the UEFI console.

But my goal here is to use the *serial port hardware* in the NUC. The
above Serial-over-LAN-oriented protocol stack is completely independent
of serial port hardware in the NUC.

For comparison, here's the protocol stack in OVMF:

Shell> dh -d -v AC
AC: BE0B8F18
864E1CA8-85EB-4D63-9DCC-6E0FC90FFD55(BE08E118)
PCIIO(BE0BD028)
Segment #.....: 00
Bus #.........: 00
Device #......: 01
Function #....: 00
ROM Size......: 0
ROM Location..: 00000000
Vendor ID.....: 8086
Device ID.....: 7000
Class Code....: 00 01 06
Configuration Header :
86800070070000020000010600008000
00000000000000000000000000000000
000000000000000000000000F41A0011
000000000000000000000000FF000000
DevicePath(BE0BE198)
PciRoot(0x0)/Pci(0x1,0x0)
Controller Name : PciRoot(0x0)/Pci(0x1,0x0)
Device Path : PciRoot(0x0)/Pci(0x1,0x0)
Controller Type : BUS
Configuration : NO
Diagnostics : NO
Managed by :
Drv[7E] : OVMF Sio Bus Driver
Parent Controllers :
Parent[36] : PciRoot(0x0)
Child Controllers :
Child[BB] : PciRoot(0x0)/Pci(0x1,0x0)/Serial(0x0)
Child[BC] : PciRoot(0x0)/Pci(0x1,0x0)/Serial(0x1)
Child[BD] : PS/2 Keyboard Device
This is PCI B/D/F 00:01.0, that is, "PIIX3", on QEMU. It is bound by
"OvmfPkg/SioBusDxe", which is a bus driver. The one child that's
relevant for us now is handle BB. On that child controller,
"OvmfPkg/SioBusDxe" installs:
- the Super-I/O protocol
- the device path PciRoot(0x0)/Pci(0x1,0x0)/Serial(0x0).

(Side comment: the Super I/O protocol is not standardized in the UEFI
spec, therefore it should not be defined in MdePkg, in
"MdePkg/Include/Protocol/SuperIo.h". But, I digress.)

Now, looking at that handle:

Shell> dh -d -v BB
BB: BE08E718
Sio(BE08F138)
DevicePath(BE08E918)
PciRoot(0x0)/Pci(0x1,0x0)/Serial(0x0)
Controller Name : PciRoot(0x0)/Pci(0x1,0x0)/Serial(0x0)
Device Path : PciRoot(0x0)/Pci(0x1,0x0)/Serial(0x0)
Controller Type : BUS
Configuration : NO
Diagnostics : NO
Managed by :
Drv[7F] : PCI SIO Serial Driver
Parent Controllers :
Parent[AC] : PciRoot(0x0)/Pci(0x1,0x0)
Child Controllers :
Child[BE] : SIO Serial Port #0
This is bound by "MdeModulePkg/Bus/Pci/PciSioSerialDxe", another bus
driver. The child we care about is handle BE. On that child controller,
"PciSioSerialDxe" installs:
- the SerialIo protocol,
- the device path
PciRoot(0x0)/Pci(0x1,0x0)/Serial(0x0)/Uart(115200,8,N,1)

Looking at that handle:

Shell> dh -d -v BE
BE: BE041A18
SerialIO(BE041028)
DevicePath(BE041E98)
PciRoot(0x0)/Pci(0x1,0x0)/Serial(0x0)/Uart(115200,8,N,1)
Controller Name : SIO Serial Port #0
Device Path : PciRoot(0x0)/Pci(0x1,0x0)/Serial(0x0)/Uart(115200,8,N,1)
Controller Type : BUS
Configuration : NO
Diagnostics : NO
Managed by :
Drv[73] : Serial Terminal Driver
Parent Controllers :
Parent[BB] : PciRoot(0x0)/Pci(0x1,0x0)/Serial(0x0)
Child Controllers :
Child[BF] : VT-100 Serial Console
This is bound by "MdeModulePkg/Universal/Console/TerminalDxe", yet
another bus driver. The child we care about is BF. On that child
controller, TerminalDxe installs:
- the SimpleTextIn and SimpleTextOut protocols
- the device path
PciRoot(0x0)/Pci(0x1,0x0)/Serial(0x0)/Uart(115200,8,N,1)/VenVt100().

Looking at that child:

Shell> dh -d -v BF
BF: BE017A18
StdErr(0)
ConsoleOut(0)
ConsoleIn(0)
DevicePath(BE017618)
PciRoot(0x0)/Pci(0x1,0x0)/Serial(0x0)/Uart(115200,8,N,1)/VenVt100()
SimpleTextOut(BE017458)
Address: BE017458 Attrib 07
mode 0: Col 80 Row 25
mode 1: Col 80 Row 50
mode 2: Col 100 Row 25
mode 3: Col 100 Row 31
mode 4: Col 104 Row 32
mode 5: Col 120 Row 33
mode 6: Col 128 Row 31
* mode 7: Col 128 Row 40
mode 8: Col 144 Row 45
mode 9: Col 144 Row 45
mode 10: Col 160 Row 37
mode 11: Col 160 Row 40
mode 12: Col 160 Row 40
mode 13: Col 160 Row 42
mode 14: Col 160 Row 50
mode 15: Col 160 Row 53
mode 16: Col 170 Row 40
mode 17: Col 170 Row 40
mode 18: Col 175 Row 55
mode 19: Col 180 Row 47
mode 20: Col 200 Row 47
mode 21: Col 200 Row 63
mode 22: Col 210 Row 55
mode 23: Col 240 Row 56
mode 24: Col 240 Row 63
mode 25: Col 240 Row 75
mode 26: Col 250 Row 105
mode 27: Col 256 Row 80
mode 28: Col 256 Row 107
mode 29: Col 320 Row 75
mode 30: Col 320 Row 84
mode 31: Col 320 Row 107
mode 32: Col 350 Row 110
mode 33: Col 400 Row 126
mode 34: Col 480 Row 113
mode 35: Col 512 Row 113
mode 36: Col 960 Row 227
mode 37: Col 1024 Row 227
SimpleTextInEx(BE017528)
SimpleTextIn(BE017440)
Controller Name : VT-100 Serial Console
Device Path : PciRoot(0x0)/Pci(0x1,0x0)/Serial(0x0)/Uart(115200,8,N,1)/VenMsg(DFA66065-B419-11D3-9A2D-0090273FC14D)
Controller Type : BUS
Configuration : NO
Diagnostics : NO
Managed by :
Drv[68] : Platform Console Management Driver
Drv[69] : Platform Console Management Driver
Drv[6A] : Console Splitter Driver
Drv[6D] : Console Splitter Driver
Drv[6E] : Console Splitter Driver
Parent Controllers :
Parent[BE] : SIO Serial Port #0
Child Controllers :
Child[6F] : Primary Console Input Device
Child[70] : Primary Console Output Device
Child[71] : Primary Standard Error Device
On the NUC, this whole child controller chain, and protocol stack,
breaks down because there is no SerialIo protocol interface in the
protocol db. The following command returns nothing, even after "connect
-r":

Shell> dh -d -v -p SerialIo
(On OVMF, the command returns handle BE, see above.)

And, although Super-IO is not a standard protocol, the UEFI shell
supports it, so I even tried one level deeper:

Shell> dh -d -v -p Sio
which also returns nothing on the NUC (on OVMF, it returns handles BB,
BC, BD).

So, at first, I'd want to see a SerialIo protocol instance, and then,
I'd want it to be provided by a driver similar to "PciSioSerialDxe" --
or whatever else, I'd just want it to be rooted in the actual serial
port hardware. :)

Thanks,
Laszlo

Gerd Hoffmann
 

On Thu, Apr 07, 2022 at 12:49:38PM +0200, Laszlo Ersek wrote:
Disclaimer: Havn't used amt/vpro for a quite while. But possibly
those drivers bind to the serial device which shows up when you enable
remote management and serial-over-lan support?
Hm... it boggles my mind a bit to think about this, but... considering
Serial-over-LAN, what that would do, I expect, is provide a SerialIo
protocol interface on top of *some* networking protocol (directly or
indirectly).
The hardware I've used years ago had PCI devices. A 16550 for
serial-over-lan (much like qemu -device pci-serial) and a PCI IDE
controller (for media redirect over network).

Serial-over-lan console works also for the linux kernel, just needs
"console=ttyS0,<magic-words-for-nonstandard-port-here>" on the command
line.

The PCI devices only show up when enabled in the management engine
configuration.

(that all was non-uefi capable hardware, so *really* long ago).

But my goal here is to use the *serial port hardware* in the NUC.
Well, it at least looks like 16550 / ide hardware. Not sure how this
is actually implemented, I suspect it is virtual, maybe port access
traps into SMM and it's emulated there. Or the management engine can
intercept those port accesses somehow.

This is PCI B/D/F 00:01.0, that is, "PIIX3", on QEMU. It is bound by
"OvmfPkg/SioBusDxe", which is a bus driver. The one child that's
relevant for us now is handle BB. On that child controller,
"OvmfPkg/SioBusDxe" installs:
- the Super-I/O protocol
- the device path PciRoot(0x0)/Pci(0x1,0x0)/Serial(0x0).
This is bound by "MdeModulePkg/Bus/Pci/PciSioSerialDxe", another bus
driver. The child we care about is handle BE. On that child controller,
"PciSioSerialDxe" installs:
- the SerialIo protocol,
- the device path
PciRoot(0x0)/Pci(0x1,0x0)/Serial(0x0)/Uart(115200,8,N,1)
Yep.

If today's hardware still works the same way I'd expect you have a
little driver taking the role of SioBusDxe, but binding to
PCI_CLASS_COMMUNICATION_SERIAL devices instead of a LPC bridge with
isa serial ports behind it. Possibly the AMI drivers you've seen
are just that.

Does the NUC accept unsigned firmware updates? If so we can maybe just
add a SioBusDxe driver variant customized for the NUC hardware ...

take care,
Gerd

Laszlo Ersek
 

On 04/07/22 14:50, Gerd Hoffmann wrote:

Well, it at least looks like 16550 / ide hardware. Not sure how this
is actually implemented, I suspect it is virtual, maybe port access
traps into SMM and it's emulated there. Or the management engine can
intercept those port accesses somehow.
If today's hardware still works the same way I'd expect you have a
little driver taking the role of SioBusDxe, but binding to
PCI_CLASS_COMMUNICATION_SERIAL devices instead of a LPC bridge with
isa serial ports behind it. Possibly the AMI drivers you've seen
are just that.

Does the NUC accept unsigned firmware updates? If so we can maybe
just add a SioBusDxe driver variant customized for the NUC hardware
You are spot on, but reality is even simpler than this. :)

Here's what I've done:

(1) I cross-referenced three lists of PCI IDs:

(1.1) The supported IDs in the windows UART driver INF file, downloaded
from Intel, for this NUC.

(1.2) The "lspci" output on the NUC.

(1.3) The "drivers/mfd/intel-lpss-pci.c" file in the Linux tree.

Result: there is no separate PCI device on this NUC that stands for a
serial controller. Furthermore, "intel-lpss-pci.c" suggests all the
"LPSS" serial ports (UARTs) are 16550 compatible -- see the reference
chain

<all UART IDs> -> spt_uart_info -> uart_node -> uart_properties ->
"snps,uart-16550-compatible".

(2) While navigating the (graphical) Setup UI, I noticed that HII debug
messages *were* sent to the serial port, by this nice, graphical, Setup
Browser.

(3) The particular (non-Linux) kernel that I booted on this NUC could
flawlessly drive the serial port for input and output just by my
specification of the bog standard params baud-rate=115200, 8 data bits,
no parity, 1 stop bit.

That gave me the following idea:

commit 0e794fe273b77830532ffb003b0d5539d7ae9823 (HEAD -> nuc_serial_pkg)
Author: Laszlo Ersek <lersek@...>
Date: Thu Apr 7 14:37:13 2022 +0200

add NucSerialPkg: build SerialDxe and TerminalDxe for the NUC8i3PNH

Signed-off-by: Laszlo Ersek <lersek@...>

diff --git a/NucSerialPkg/NucSerialPkg.dec b/NucSerialPkg/NucSerialPkg.dec
new file mode 100644
index 000000000000..b077cde229c0
--- /dev/null
+++ b/NucSerialPkg/NucSerialPkg.dec
@@ -0,0 +1,13 @@
+## @file
+# UART 16650 serial port driver build for the NUC8i3PNH.
+#
+# Copyright (c) 2022, Red Hat, Inc.
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+##
+
+[Defines]
+ DEC_SPECIFICATION = 1.29
+ PACKAGE_NAME = NucSerialPkg
+ PACKAGE_GUID = afdaaf17-4a06-4d97-a456-1ede0db46bc0
+ PACKAGE_VERSION = 0.1
diff --git a/NucSerialPkg/NucSerialPkg.dsc b/NucSerialPkg/NucSerialPkg.dsc
new file mode 100644
index 000000000000..971fb2f96a43
--- /dev/null
+++ b/NucSerialPkg/NucSerialPkg.dsc
@@ -0,0 +1,46 @@
+## @file
+# UART 16650 serial port driver build for the NUC8i3PNH.
+#
+# Copyright (c) 2022, Red Hat, Inc.
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+##
+
+[Defines]
+ PLATFORM_NAME = NucSerial
+ PLATFORM_GUID = 30c397cf-a446-4f41-858f-9ae677547094
+ PLATFORM_VERSION = 0.1
+ DSC_SPECIFICATION = 1.30
+ OUTPUT_DIRECTORY = Build/NucSerial
+ SUPPORTED_ARCHITECTURES = X64
+ BUILD_TARGETS = NOOPT|DEBUG|RELEASE
+ SKUID_IDENTIFIER = DEFAULT
+
+[BuildOptions]
+ GCC:RELEASE_*_*_CC_FLAGS = -DMDEPKG_NDEBUG
+ RELEASE_*_*_GENFW_FLAGS = --zero
+ GCC:*_*_*_CC_FLAGS = -D DISABLE_NEW_DEPRECATED_INTERFACES
+
+[LibraryClasses]
+ BaseLib|MdePkg/Library/BaseLib/BaseLib.inf
+ BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
+ DebugLib|MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf
+ DevicePathLib|MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.inf
+ IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf
+ MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
+ PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
+ PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
+ RegisterFilterLib|MdePkg/Library/RegisterFilterLibNull/RegisterFilterLibNull.inf
+ ReportStatusCodeLib|MdePkg/Library/BaseReportStatusCodeLibNull/BaseReportStatusCodeLibNull.inf
+ SerialPortLib|PcAtChipsetPkg/Library/SerialIoLib/SerialIoLib.inf
+ UefiBootServicesTableLib|MdePkg/Library/UefiBootServicesTableLib/UefiBootServicesTableLib.inf
+ UefiDriverEntryPoint|MdePkg/Library/UefiDriverEntryPoint/UefiDriverEntryPoint.inf
+ UefiLib|MdePkg/Library/UefiLib/UefiLib.inf
+ UefiRuntimeServicesTableLib|MdePkg/Library/UefiRuntimeServicesTableLib/UefiRuntimeServicesTableLib.inf
+
+[PcdsFeatureFlag]
+ gEfiMdePkgTokenSpaceGuid.PcdUgaConsumeSupport|FALSE
+
+[Components]
+ MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf
+ MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
The key line is the following lib class resolution:

SerialPortLib|PcAtChipsetPkg/Library/SerialIoLib/SerialIoLib.inf

It's the simplest possible (= most compatible) approach on X64.

And It Just Works (TM), with the following two commands in the UEFI
shell (after I copied the binaries to the USB stick, alongside the UEFI
Shell binary I built earlier):

Shell> fs0:
FS0:\> cd efi\boot
FS0:\efi\boot\> load SerialDxe.efi
Image 'FS0:\EFI\BOOT\SerialDxe.efi' loaded at 2C801000 - Success
FS0:\efi\boot\> load TerminalDxe.efi
Image 'FS0:\EFI\BOOT\TerminalDxe.efi' loaded at 2C7FB000 - Success
FS0:\efi\boot\>
At this point, the UEFI console is properly multiplexed to both serial
and HDMI+USB.

(Side comment: SerialDxe is not even a UEFI_DRIVER just a DXE_DRIVER, so
it produces SerialIo immediately.)

With the serial console up, I can provide a "drivers" output too:

FS0:\efi\boot\> drivers
T D
D Y C I
R P F A
V VERSION E G G #D #C DRIVER NAME IMAGE NAME
== ======== = = = == == =================================== ==========
49 00000017 D - - 1 - AMI USB Driver Uhcd
4B 00000017 B - - 1 3 AMI USB Bus Driver Uhcd
4C 00000002 D - - 2 - AMI USB Hid Driver Uhcd
4D 00000001 D - - 1 - AMI USB Mass Storage Driver Uhcd
78 00010000 ? - - - - AMI NTFS Driver NTFS
7A 00000001 D - - 2 - <null string> MouseDriver
7D 00000001 D - - 1 - AMI AHCI BUS Driver Ahci
7F 00000010 ? - - - - AMI Serial I/O Driver SerialIo
83 00000001 B - - 1 1 AMI NVMe BUS Driver Nvme
124 00000010 D - - 1 - Serial ATA Controller Initializatio SataController
132 00000010 B - - 2 2 AMI Console Splitter Text Out Drive ConSplitter
133 00000010 B - - 2 2 AMI Console Splitter Text In Driver ConSplitter
134 00000010 B - - 1 1 AMI Console Splitter Pointer Driver ConSplitter
137 00000010 D - - 1 - AMI Graphic Console Driver GraphicsConsole
138 0000000A D - - 8 - Generic Disk I/O Driver DiskIoDxe
139 0000000B B - - 2 6 Partition Driver(MBR/GPT/El Torito) PartitionDxe
13D 00000000 ? - - - - Integrated Touch Driver IntegratedTouch
13E 0000000A ? - - - - Bluetooth Bus Driver BluetoothBusDxe
13F 0000000A ? - - - - <null string> BluetoothBusDxe
140 0000000A ? - - - - Bluetooth Connection Manager BluetoothConfigDxe
141 0000000A ? - - - - Bluetooth HID Driver BluetoothHidDxe
142 0000000A ? - - - - Hid Keyboard Driver HidKbDxe
143 0000000A ? - - - - Hid Mouse Driver HidMouseDxe
147 00000010 D - - 1 - AMI Generic LPC Super I/O Driver GenericSio
149 00A50111 B - - 1 17 AMI PCI Bus Driver PciBus
14B 00000010 ? - - - - AMI PS/2 Driver Ps2Main
14D 00000010 ? - - - - AMI Terminal Driver TerminalSrc
14E 0000000A ? - - - - IpSec Driver IpSecDxe
150 0000000A ? - - - - IpSec Driver IpSecDxe
151 0000000A ? - - - - VLAN Configuration Driver VlanConfigDxe
152 0000000A ? - - - - HttpDxe HttpDxe
153 0000000A ? - - - - HttpDxe HttpDxe
154 00000000 ? - - - - DNS Network Service Driver DnsDxe
155 00000000 ? - - - - DNS Network Service Driver DnsDxe
158 0000000A D - - 4 - FAT File System Driver Fat
159 0000000A ? - - - - iSCSI Driver IScsiDxe
15A 0000000A ? - - - - iSCSI Driver IScsiDxe
15C 0000000A ? - - - - SCSI Bus Driver ScsiBus
15D 0000000A ? - - - - Scsi Disk Driver ScsiDisk
16A 0900044A B - - 1 1 Intel(R) GOP Driver [9.0.1098] MemoryMapped(0x3,0x29A33018,0x29A44A98)
19B 0000000A B - - 1 1 Serial Terminal Driver \EFI\BOOT\TerminalDxe.efi
SerialDxe is not in the list, as it is not a UEFI driver (it does not
install an instance of the Driver Binding protocol).

The curious parts are:

- what the "TerminalSrc" driver ("AMI Terminal Driver") stands for (it
does not bind the SerialIo instance installed by SerialDxe, not even
after "connect -r" -- that's why I need TerminalDxe from edk2),

- why the platform firmware packager thought it would be a good idea to
*exclude* the SerialDxe and TerminalDxe drivers -- these binaries
weigh in at 23 KB together, in a DEBUG build! And the hardware is
there...

Thanks,
Laszlo

manickavasakam karpagavinayagam
 

Laszlo/Gred :

Can you please let us know the GITHUB project location from where you have downloaded the source ?

Thank you

-Manic

-----Original Message-----
From: Laszlo Ersek <lersek@...>
Sent: Thursday, April 7, 2022 10:12 AM
To: Gerd Hoffmann <kraxel@...>
Cc: devel@edk2.groups.io; Ramesh R. <rameshr@...>; Sivaraman Nainar <sivaramann@...>; Manickavasakam Karpagavinayagam <manickavasakamk@...>
Subject: [EXTERNAL] Re: [edk2-devel] Intel NUC platform firmware -- no serial I/O support?


**CAUTION: The e-mail below is from an external source. Please exercise caution before opening attachments, clicking links, or following guidance.**

On 04/07/22 14:50, Gerd Hoffmann wrote:

Well, it at least looks like 16550 / ide hardware. Not sure how this
is actually implemented, I suspect it is virtual, maybe port access
traps into SMM and it's emulated there. Or the management engine can
intercept those port accesses somehow.
If today's hardware still works the same way I'd expect you have a
little driver taking the role of SioBusDxe, but binding to
PCI_CLASS_COMMUNICATION_SERIAL devices instead of a LPC bridge with
isa serial ports behind it. Possibly the AMI drivers you've seen are
just that.

Does the NUC accept unsigned firmware updates? If so we can maybe
just add a SioBusDxe driver variant customized for the NUC hardware
You are spot on, but reality is even simpler than this. :)

Here's what I've done:

(1) I cross-referenced three lists of PCI IDs:

(1.1) The supported IDs in the windows UART driver INF file, downloaded from Intel, for this NUC.

(1.2) The "lspci" output on the NUC.

(1.3) The "drivers/mfd/intel-lpss-pci.c" file in the Linux tree.

Result: there is no separate PCI device on this NUC that stands for a serial controller. Furthermore, "intel-lpss-pci.c" suggests all the "LPSS" serial ports (UARTs) are 16550 compatible -- see the reference chain

<all UART IDs> -> spt_uart_info -> uart_node -> uart_properties -> "snps,uart-16550-compatible".

(2) While navigating the (graphical) Setup UI, I noticed that HII debug messages *were* sent to the serial port, by this nice, graphical, Setup Browser.

(3) The particular (non-Linux) kernel that I booted on this NUC could flawlessly drive the serial port for input and output just by my specification of the bog standard params baud-rate=115200, 8 data bits, no parity, 1 stop bit.

That gave me the following idea:

commit 0e794fe273b77830532ffb003b0d5539d7ae9823 (HEAD ->
nuc_serial_pkg)
Author: Laszlo Ersek <lersek@...>
Date: Thu Apr 7 14:37:13 2022 +0200

add NucSerialPkg: build SerialDxe and TerminalDxe for the
NUC8i3PNH

Signed-off-by: Laszlo Ersek <lersek@...>

diff --git a/NucSerialPkg/NucSerialPkg.dec
b/NucSerialPkg/NucSerialPkg.dec new file mode 100644 index
000000000000..b077cde229c0
--- /dev/null
+++ b/NucSerialPkg/NucSerialPkg.dec
@@ -0,0 +1,13 @@
+## @file
+# UART 16650 serial port driver build for the NUC8i3PNH.
+#
+# Copyright (c) 2022, Red Hat, Inc.
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent ##
+
+[Defines]
+ DEC_SPECIFICATION = 1.29
+ PACKAGE_NAME = NucSerialPkg
+ PACKAGE_GUID = afdaaf17-4a06-4d97-a456-1ede0db46bc0
+ PACKAGE_VERSION = 0.1
diff --git a/NucSerialPkg/NucSerialPkg.dsc
b/NucSerialPkg/NucSerialPkg.dsc new file mode 100644 index
000000000000..971fb2f96a43
--- /dev/null
+++ b/NucSerialPkg/NucSerialPkg.dsc
@@ -0,0 +1,46 @@
+## @file
+# UART 16650 serial port driver build for the NUC8i3PNH.
+#
+# Copyright (c) 2022, Red Hat, Inc.
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent ##
+
+[Defines]
+ PLATFORM_NAME = NucSerial
+ PLATFORM_GUID = 30c397cf-a446-4f41-858f-9ae677547094
+ PLATFORM_VERSION = 0.1
+ DSC_SPECIFICATION = 1.30
+ OUTPUT_DIRECTORY = Build/NucSerial
+ SUPPORTED_ARCHITECTURES = X64
+ BUILD_TARGETS = NOOPT|DEBUG|RELEASE
+ SKUID_IDENTIFIER = DEFAULT
+
+[BuildOptions]
+ GCC:RELEASE_*_*_CC_FLAGS = -DMDEPKG_NDEBUG
+ RELEASE_*_*_GENFW_FLAGS = --zero
+ GCC:*_*_*_CC_FLAGS = -D DISABLE_NEW_DEPRECATED_INTERFACES
+
+[LibraryClasses]
+ BaseLib|MdePkg/Library/BaseLib/BaseLib.inf
+ BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
+ DebugLib|MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf
+
+DevicePathLib|MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.inf
+ IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf
+
+MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemory
+AllocationLib.inf
+ PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
+ PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
+
+RegisterFilterLib|MdePkg/Library/RegisterFilterLibNull/RegisterFilter
+LibNull.inf
+
+ReportStatusCodeLib|MdePkg/Library/BaseReportStatusCodeLibNull/BaseRe
+portStatusCodeLibNull.inf
+ SerialPortLib|PcAtChipsetPkg/Library/SerialIoLib/SerialIoLib.inf
+
+UefiBootServicesTableLib|MdePkg/Library/UefiBootServicesTableLib/Uefi
+BootServicesTableLib.inf
+
+UefiDriverEntryPoint|MdePkg/Library/UefiDriverEntryPoint/UefiDriverEn
+tryPoint.inf
+ UefiLib|MdePkg/Library/UefiLib/UefiLib.inf
+
+UefiRuntimeServicesTableLib|MdePkg/Library/UefiRuntimeServicesTableLi
+b/UefiRuntimeServicesTableLib.inf
+
+[PcdsFeatureFlag]
+ gEfiMdePkgTokenSpaceGuid.PcdUgaConsumeSupport|FALSE
+
+[Components]
+ MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf
+ MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
The key line is the following lib class resolution:

SerialPortLib|PcAtChipsetPkg/Library/SerialIoLib/SerialIoLib.inf

It's the simplest possible (= most compatible) approach on X64.

And It Just Works (TM), with the following two commands in the UEFI shell (after I copied the binaries to the USB stick, alongside the UEFI Shell binary I built earlier):

Shell> fs0:
FS0:\> cd efi\boot
FS0:\efi\boot\> load SerialDxe.efi
Image 'FS0:\EFI\BOOT\SerialDxe.efi' loaded at 2C801000 - Success
FS0:\efi\boot\> load TerminalDxe.efi Image
'FS0:\EFI\BOOT\TerminalDxe.efi' loaded at 2C7FB000 - Success
FS0:\efi\boot\>
At this point, the UEFI console is properly multiplexed to both serial and HDMI+USB.

(Side comment: SerialDxe is not even a UEFI_DRIVER just a DXE_DRIVER, so it produces SerialIo immediately.)

With the serial console up, I can provide a "drivers" output too:

FS0:\efi\boot\> drivers
T D
D Y C I
R P F A
V VERSION E G G #D #C DRIVER NAME IMAGE NAME
== ======== = = = == == =================================== ==========
49 00000017 D - - 1 - AMI USB Driver Uhcd
4B 00000017 B - - 1 3 AMI USB Bus Driver Uhcd
4C 00000002 D - - 2 - AMI USB Hid Driver Uhcd
4D 00000001 D - - 1 - AMI USB Mass Storage Driver Uhcd
78 00010000 ? - - - - AMI NTFS Driver NTFS
7A 00000001 D - - 2 - <null string> MouseDriver
7D 00000001 D - - 1 - AMI AHCI BUS Driver Ahci
7F 00000010 ? - - - - AMI Serial I/O Driver SerialIo
83 00000001 B - - 1 1 AMI NVMe BUS Driver Nvme
124 00000010 D - - 1 - Serial ATA Controller Initializatio
SataController
132 00000010 B - - 2 2 AMI Console Splitter Text Out Drive
ConSplitter
133 00000010 B - - 2 2 AMI Console Splitter Text In Driver
ConSplitter
134 00000010 B - - 1 1 AMI Console Splitter Pointer Driver ConSplitter
137 00000010 D - - 1 - AMI Graphic Console Driver GraphicsConsole
138 0000000A D - - 8 - Generic Disk I/O Driver DiskIoDxe
139 0000000B B - - 2 6 Partition Driver(MBR/GPT/El Torito) PartitionDxe
13D 00000000 ? - - - - Integrated Touch Driver IntegratedTouch
13E 0000000A ? - - - - Bluetooth Bus Driver BluetoothBusDxe
13F 0000000A ? - - - - <null string> BluetoothBusDxe
140 0000000A ? - - - - Bluetooth Connection Manager BluetoothConfigDxe
141 0000000A ? - - - - Bluetooth HID Driver BluetoothHidDxe
142 0000000A ? - - - - Hid Keyboard Driver HidKbDxe
143 0000000A ? - - - - Hid Mouse Driver HidMouseDxe
147 00000010 D - - 1 - AMI Generic LPC Super I/O Driver GenericSio
149 00A50111 B - - 1 17 AMI PCI Bus Driver PciBus
14B 00000010 ? - - - - AMI PS/2 Driver Ps2Main
14D 00000010 ? - - - - AMI Terminal Driver TerminalSrc
14E 0000000A ? - - - - IpSec Driver IpSecDxe
150 0000000A ? - - - - IpSec Driver IpSecDxe
151 0000000A ? - - - - VLAN Configuration Driver VlanConfigDxe
152 0000000A ? - - - - HttpDxe HttpDxe
153 0000000A ? - - - - HttpDxe HttpDxe
154 00000000 ? - - - - DNS Network Service Driver DnsDxe
155 00000000 ? - - - - DNS Network Service Driver DnsDxe
158 0000000A D - - 4 - FAT File System Driver Fat
159 0000000A ? - - - - iSCSI Driver IScsiDxe
15A 0000000A ? - - - - iSCSI Driver IScsiDxe
15C 0000000A ? - - - - SCSI Bus Driver ScsiBus
15D 0000000A ? - - - - Scsi Disk Driver ScsiDisk
16A 0900044A B - - 1 1 Intel(R) GOP Driver [9.0.1098] MemoryMapped(0x3,0x29A33018,0x29A44A98)
19B 0000000A B - - 1 1 Serial Terminal Driver \EFI\BOOT\TerminalDxe.efi
SerialDxe is not in the list, as it is not a UEFI driver (it does not install an instance of the Driver Binding protocol).

The curious parts are:

- what the "TerminalSrc" driver ("AMI Terminal Driver") stands for (it
does not bind the SerialIo instance installed by SerialDxe, not even
after "connect -r" -- that's why I need TerminalDxe from edk2),

- why the platform firmware packager thought it would be a good idea to
*exclude* the SerialDxe and TerminalDxe drivers -- these binaries
weigh in at 23 KB together, in a DEBUG build! And the hardware is
there...

Thanks,
Laszlo

-The information contained in this message may be confidential and proprietary to American Megatrends (AMI). This communication is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any distribution of this message, in any form, is strictly prohibited. Please promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and then delete or destroy all copies of the transmission.

Nate DeSimone
 

Hi Laszlo,

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Laszlo
Ersek
Sent: Thursday, April 7, 2022 12:46 AM
To: edk2-devel-groups-io <devel@edk2.groups.io>
Cc: r, ramesh <rameshr@...>; Sivaraman Nainar
<sivaramann@...>; KARPAGAVINAYAGAM, MANICKAVASAKAM
<manickavasakamk@...>
Subject: [edk2-devel] Intel NUC platform firmware -- no serial I/O support?

Hi List,

my toolbox has been extended with an Intel NUC, the base kit model being
NUC8i3PNH. The NUC has a serial port connector on the back, and indeed
Serial I/O works fine once an OS starts.

However, the UEFI platform firmware seems to have no support for Serial
I/O. I've built a fresh UEFI Shell binary from edk2 master and poked around in
the protocol database, with "drivers" and "dh". The necessary drivers seem
to be included, however they do not appear to bind the hardware that's
inside the chassis. ("connect -r" makes no difference in this regard, so it's not
just BDS policy.)
Yeah you are right the Super I/O stuff is barrels of fun. However it is actually a spec defined protocol, it is just in the PI spec not the UEFI spec. The PI spec also counts for addition to MdePkg. On the MinPlatform side we built a small/simple Super I/O bus driver for UARTs and PS/2 keyboard/mouse: https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel/BoardModulePkg/LegacySioDxe

Volume 5, Chapter 14 of the PI spec waxes rather poetic about how to build a full ISA plug-and-play capable DXE driver stack for a system that incorporates both a Super I/O and physical ISA slots.

I can say is that the NUC team has opted to build their systems with AMI Aptio instead of starting with the Intel reference UEFI firmware. I'm not privy to the conversation there. Accordingly, there might be some Aptio specific drivers as you note in your listing of the driver handle database. I'm afraid I have as much knowledge about how that driver stack works as you do.

Thanks,
Nate

Interestingly, the related drivers are all called "AMI ...", which I find
somewhat strange on an Intel-branded NUC. I don't know whom I should be
addressing with my question in the first place. Just to be sure, I'm CC'ing a
bunch of randomly picked @ami.com email addresses from my edk2-devel
list archive.

I can provide more details if needed, but first I'd like to ask if *any* firmware
update exists for this kit -- NUC8i3PNH -- where the platform firmware can
drive the serial port. My goal is (of course) completely headless operation of
the NUC; ideally, that would cover the UEFI console too.

Right now, I need to connect an HDMI monitor and a USB keyboard+mouse
to the NUC just to get into the Setup UI / UEFI Shell.

Thanks!
Laszlo




Laszlo Ersek
 

Hi Manic,

On 04/07/22 19:04, Manickavasakam Karpagavinayagam wrote:
Laszlo/Gred :

Can you please let us know the GITHUB project location from where you have downloaded the source ?
I didn't download any new source code. I've just had my local edk2 clone
as always, and the small patch at the bottom (adding "NucSerialPkg",
just for the sake of buildig SerialDxe and TerminalDxe in separation)
applies on top of current master.

Thanks
Laszlo


Thank you

-Manic

-----Original Message-----
From: Laszlo Ersek <lersek@...>
Sent: Thursday, April 7, 2022 10:12 AM
To: Gerd Hoffmann <kraxel@...>
Cc: devel@edk2.groups.io; Ramesh R. <rameshr@...>; Sivaraman Nainar <sivaramann@...>; Manickavasakam Karpagavinayagam <manickavasakamk@...>
Subject: [EXTERNAL] Re: [edk2-devel] Intel NUC platform firmware -- no serial I/O support?


**CAUTION: The e-mail below is from an external source. Please exercise caution before opening attachments, clicking links, or following guidance.**

On 04/07/22 14:50, Gerd Hoffmann wrote:

Well, it at least looks like 16550 / ide hardware. Not sure how this
is actually implemented, I suspect it is virtual, maybe port access
traps into SMM and it's emulated there. Or the management engine can
intercept those port accesses somehow.
If today's hardware still works the same way I'd expect you have a
little driver taking the role of SioBusDxe, but binding to
PCI_CLASS_COMMUNICATION_SERIAL devices instead of a LPC bridge with
isa serial ports behind it. Possibly the AMI drivers you've seen are
just that.

Does the NUC accept unsigned firmware updates? If so we can maybe
just add a SioBusDxe driver variant customized for the NUC hardware
You are spot on, but reality is even simpler than this. :)

Here's what I've done:

(1) I cross-referenced three lists of PCI IDs:

(1.1) The supported IDs in the windows UART driver INF file, downloaded from Intel, for this NUC.

(1.2) The "lspci" output on the NUC.

(1.3) The "drivers/mfd/intel-lpss-pci.c" file in the Linux tree.

Result: there is no separate PCI device on this NUC that stands for a serial controller. Furthermore, "intel-lpss-pci.c" suggests all the "LPSS" serial ports (UARTs) are 16550 compatible -- see the reference chain

<all UART IDs> -> spt_uart_info -> uart_node -> uart_properties -> "snps,uart-16550-compatible".

(2) While navigating the (graphical) Setup UI, I noticed that HII debug messages *were* sent to the serial port, by this nice, graphical, Setup Browser.

(3) The particular (non-Linux) kernel that I booted on this NUC could flawlessly drive the serial port for input and output just by my specification of the bog standard params baud-rate=115200, 8 data bits, no parity, 1 stop bit.

That gave me the following idea:

commit 0e794fe273b77830532ffb003b0d5539d7ae9823 (HEAD ->
nuc_serial_pkg)
Author: Laszlo Ersek <lersek@...>
Date: Thu Apr 7 14:37:13 2022 +0200

add NucSerialPkg: build SerialDxe and TerminalDxe for the
NUC8i3PNH

Signed-off-by: Laszlo Ersek <lersek@...>

diff --git a/NucSerialPkg/NucSerialPkg.dec
b/NucSerialPkg/NucSerialPkg.dec new file mode 100644 index
000000000000..b077cde229c0
--- /dev/null
+++ b/NucSerialPkg/NucSerialPkg.dec
@@ -0,0 +1,13 @@
+## @file
+# UART 16650 serial port driver build for the NUC8i3PNH.
+#
+# Copyright (c) 2022, Red Hat, Inc.
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent ##
+
+[Defines]
+ DEC_SPECIFICATION = 1.29
+ PACKAGE_NAME = NucSerialPkg
+ PACKAGE_GUID = afdaaf17-4a06-4d97-a456-1ede0db46bc0
+ PACKAGE_VERSION = 0.1
diff --git a/NucSerialPkg/NucSerialPkg.dsc
b/NucSerialPkg/NucSerialPkg.dsc new file mode 100644 index
000000000000..971fb2f96a43
--- /dev/null
+++ b/NucSerialPkg/NucSerialPkg.dsc
@@ -0,0 +1,46 @@
+## @file
+# UART 16650 serial port driver build for the NUC8i3PNH.
+#
+# Copyright (c) 2022, Red Hat, Inc.
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent ##
+
+[Defines]
+ PLATFORM_NAME = NucSerial
+ PLATFORM_GUID = 30c397cf-a446-4f41-858f-9ae677547094
+ PLATFORM_VERSION = 0.1
+ DSC_SPECIFICATION = 1.30
+ OUTPUT_DIRECTORY = Build/NucSerial
+ SUPPORTED_ARCHITECTURES = X64
+ BUILD_TARGETS = NOOPT|DEBUG|RELEASE
+ SKUID_IDENTIFIER = DEFAULT
+
+[BuildOptions]
+ GCC:RELEASE_*_*_CC_FLAGS = -DMDEPKG_NDEBUG
+ RELEASE_*_*_GENFW_FLAGS = --zero
+ GCC:*_*_*_CC_FLAGS = -D DISABLE_NEW_DEPRECATED_INTERFACES
+
+[LibraryClasses]
+ BaseLib|MdePkg/Library/BaseLib/BaseLib.inf
+ BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
+ DebugLib|MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf
+
+DevicePathLib|MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.inf
+ IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf
+
+MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemory
+AllocationLib.inf
+ PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
+ PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
+
+RegisterFilterLib|MdePkg/Library/RegisterFilterLibNull/RegisterFilter
+LibNull.inf
+
+ReportStatusCodeLib|MdePkg/Library/BaseReportStatusCodeLibNull/BaseRe
+portStatusCodeLibNull.inf
+ SerialPortLib|PcAtChipsetPkg/Library/SerialIoLib/SerialIoLib.inf
+
+UefiBootServicesTableLib|MdePkg/Library/UefiBootServicesTableLib/Uefi
+BootServicesTableLib.inf
+
+UefiDriverEntryPoint|MdePkg/Library/UefiDriverEntryPoint/UefiDriverEn
+tryPoint.inf
+ UefiLib|MdePkg/Library/UefiLib/UefiLib.inf
+
+UefiRuntimeServicesTableLib|MdePkg/Library/UefiRuntimeServicesTableLi
+b/UefiRuntimeServicesTableLib.inf
+
+[PcdsFeatureFlag]
+ gEfiMdePkgTokenSpaceGuid.PcdUgaConsumeSupport|FALSE
+
+[Components]
+ MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf
+ MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
The key line is the following lib class resolution:

SerialPortLib|PcAtChipsetPkg/Library/SerialIoLib/SerialIoLib.inf

It's the simplest possible (= most compatible) approach on X64.

And It Just Works (TM), with the following two commands in the UEFI shell (after I copied the binaries to the USB stick, alongside the UEFI Shell binary I built earlier):

Shell> fs0:
FS0:\> cd efi\boot
FS0:\efi\boot\> load SerialDxe.efi
Image 'FS0:\EFI\BOOT\SerialDxe.efi' loaded at 2C801000 - Success
FS0:\efi\boot\> load TerminalDxe.efi Image
'FS0:\EFI\BOOT\TerminalDxe.efi' loaded at 2C7FB000 - Success
FS0:\efi\boot\>
At this point, the UEFI console is properly multiplexed to both serial and HDMI+USB.

(Side comment: SerialDxe is not even a UEFI_DRIVER just a DXE_DRIVER, so it produces SerialIo immediately.)

With the serial console up, I can provide a "drivers" output too:

FS0:\efi\boot\> drivers
T D
D Y C I
R P F A
V VERSION E G G #D #C DRIVER NAME IMAGE NAME
== ======== = = = == == =================================== ==========
49 00000017 D - - 1 - AMI USB Driver Uhcd
4B 00000017 B - - 1 3 AMI USB Bus Driver Uhcd
4C 00000002 D - - 2 - AMI USB Hid Driver Uhcd
4D 00000001 D - - 1 - AMI USB Mass Storage Driver Uhcd
78 00010000 ? - - - - AMI NTFS Driver NTFS
7A 00000001 D - - 2 - <null string> MouseDriver
7D 00000001 D - - 1 - AMI AHCI BUS Driver Ahci
7F 00000010 ? - - - - AMI Serial I/O Driver SerialIo
83 00000001 B - - 1 1 AMI NVMe BUS Driver Nvme
124 00000010 D - - 1 - Serial ATA Controller Initializatio
SataController
132 00000010 B - - 2 2 AMI Console Splitter Text Out Drive
ConSplitter
133 00000010 B - - 2 2 AMI Console Splitter Text In Driver
ConSplitter
134 00000010 B - - 1 1 AMI Console Splitter Pointer Driver ConSplitter
137 00000010 D - - 1 - AMI Graphic Console Driver GraphicsConsole
138 0000000A D - - 8 - Generic Disk I/O Driver DiskIoDxe
139 0000000B B - - 2 6 Partition Driver(MBR/GPT/El Torito) PartitionDxe
13D 00000000 ? - - - - Integrated Touch Driver IntegratedTouch
13E 0000000A ? - - - - Bluetooth Bus Driver BluetoothBusDxe
13F 0000000A ? - - - - <null string> BluetoothBusDxe
140 0000000A ? - - - - Bluetooth Connection Manager BluetoothConfigDxe
141 0000000A ? - - - - Bluetooth HID Driver BluetoothHidDxe
142 0000000A ? - - - - Hid Keyboard Driver HidKbDxe
143 0000000A ? - - - - Hid Mouse Driver HidMouseDxe
147 00000010 D - - 1 - AMI Generic LPC Super I/O Driver GenericSio
149 00A50111 B - - 1 17 AMI PCI Bus Driver PciBus
14B 00000010 ? - - - - AMI PS/2 Driver Ps2Main
14D 00000010 ? - - - - AMI Terminal Driver TerminalSrc
14E 0000000A ? - - - - IpSec Driver IpSecDxe
150 0000000A ? - - - - IpSec Driver IpSecDxe
151 0000000A ? - - - - VLAN Configuration Driver VlanConfigDxe
152 0000000A ? - - - - HttpDxe HttpDxe
153 0000000A ? - - - - HttpDxe HttpDxe
154 00000000 ? - - - - DNS Network Service Driver DnsDxe
155 00000000 ? - - - - DNS Network Service Driver DnsDxe
158 0000000A D - - 4 - FAT File System Driver Fat
159 0000000A ? - - - - iSCSI Driver IScsiDxe
15A 0000000A ? - - - - iSCSI Driver IScsiDxe
15C 0000000A ? - - - - SCSI Bus Driver ScsiBus
15D 0000000A ? - - - - Scsi Disk Driver ScsiDisk
16A 0900044A B - - 1 1 Intel(R) GOP Driver [9.0.1098] MemoryMapped(0x3,0x29A33018,0x29A44A98)
19B 0000000A B - - 1 1 Serial Terminal Driver \EFI\BOOT\TerminalDxe.efi
SerialDxe is not in the list, as it is not a UEFI driver (it does not install an instance of the Driver Binding protocol).

The curious parts are:

- what the "TerminalSrc" driver ("AMI Terminal Driver") stands for (it
does not bind the SerialIo instance installed by SerialDxe, not even
after "connect -r" -- that's why I need TerminalDxe from edk2),

- why the platform firmware packager thought it would be a good idea to
*exclude* the SerialDxe and TerminalDxe drivers -- these binaries
weigh in at 23 KB together, in a DEBUG build! And the hardware is
there...

Thanks,
Laszlo

-The information contained in this message may be confidential and proprietary to American Megatrends (AMI). This communication is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any distribution of this message, in any form, is strictly prohibited. Please promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and then delete or destroy all copies of the transmission.

Laszlo Ersek
 

On 04/08/22 00:16, Desimone, Nathaniel L wrote:
Hi Laszlo,

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Laszlo
Ersek
Sent: Thursday, April 7, 2022 12:46 AM
To: edk2-devel-groups-io <devel@edk2.groups.io>
Cc: r, ramesh <rameshr@...>; Sivaraman Nainar
<sivaramann@...>; KARPAGAVINAYAGAM, MANICKAVASAKAM
<manickavasakamk@...>
Subject: [edk2-devel] Intel NUC platform firmware -- no serial I/O support?

Hi List,

my toolbox has been extended with an Intel NUC, the base kit model being
NUC8i3PNH. The NUC has a serial port connector on the back, and indeed
Serial I/O works fine once an OS starts.

However, the UEFI platform firmware seems to have no support for Serial
I/O. I've built a fresh UEFI Shell binary from edk2 master and poked around in
the protocol database, with "drivers" and "dh". The necessary drivers seem
to be included, however they do not appear to bind the hardware that's
inside the chassis. ("connect -r" makes no difference in this regard, so it's not
just BDS policy.)
Yeah you are right the Super I/O stuff is barrels of fun. However it is actually a spec defined protocol, it is just in the PI spec not the UEFI spec. The PI spec also counts for addition to MdePkg. On the MinPlatform side we built a small/simple Super I/O bus driver for UARTs and PS/2 keyboard/mouse: https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel/BoardModulePkg/LegacySioDxe

Volume 5, Chapter 14 of the PI spec waxes rather poetic about how to build a full ISA plug-and-play capable DXE driver stack for a system that incorporates both a Super I/O and physical ISA slots.
I always forget that the PI spec can very well define protocols to be
used by UEFI drivers...

I can say is that the NUC team has opted to build their systems with AMI Aptio instead of starting with the Intel reference UEFI firmware. I'm not privy to the conversation there. Accordingly, there might be some Aptio specific drivers as you note in your listing of the driver handle database. I'm afraid I have as much knowledge about how that driver stack works as you do.
Thanks for responding!

Yesterday I played a bit more with the NUC. I placed the UEFI shell as
EFI\BOOT\BOOTX64.EFI on a USB stick, together with SerialDxe.efi,
TerminalDxe.efi, and a "startup.nsh" script that loads SerialDxe and
TerminalDxe using the "consistent shell drive names" scheme. This way,
when I boot the NUC off the stick, I get a shell on serial at once.

Another experiment I tried was "bcfg driver". Unfortunately, the
platform BDS on the NUC seems to ignore Driver#### and DriverOrder.

Then I build UiApp.efi in separation too, and started it from the shell
-- it was then really strange to see the "Front Page" tab in the
graphical setup TUI :)

Now, while that was somewhat useful (as it extended the NUC's setup UI
with some nifty features that I'd become used to with OVMF), I actually
wanted the inverse: to get all the original NUC setup stuff exposed over
serial. But I guess for that, I'd have to replace (override) the
graphical setup browser and/or the display engine DXE drivers of the
platform firmware... I guess I'll have to give up there.

Thanks!
Laszlo

Gerd Hoffmann
 

Hi,

And It Just Works (TM), with the following two commands in the UEFI
shell (after I copied the binaries to the USB stick, alongside the UEFI
Shell binary I built earlier):

Shell> fs0:
FS0:\> cd efi\boot
FS0:\efi\boot\> load SerialDxe.efi
Image 'FS0:\EFI\BOOT\SerialDxe.efi' loaded at 2C801000 - Success
FS0:\efi\boot\> load TerminalDxe.efi
Image 'FS0:\EFI\BOOT\TerminalDxe.efi' loaded at 2C7FB000 - Success
FS0:\efi\boot\>
At this point, the UEFI console is properly multiplexed to both serial
and HDMI+USB.
Neat. /me makes a mental note that one can load drivers like this.
Can this be automated to run on each boot? With a startup.nsh script?

take care,
Gerd

Laszlo Ersek
 

On 04/08/22 11:48, Gerd Hoffmann wrote:

Hi,

And It Just Works (TM), with the following two commands in the UEFI
shell (after I copied the binaries to the USB stick, alongside the UEFI
Shell binary I built earlier):

Shell> fs0:
FS0:\> cd efi\boot
FS0:\efi\boot\> load SerialDxe.efi
Image 'FS0:\EFI\BOOT\SerialDxe.efi' loaded at 2C801000 - Success
FS0:\efi\boot\> load TerminalDxe.efi
Image 'FS0:\EFI\BOOT\TerminalDxe.efi' loaded at 2C7FB000 - Success
FS0:\efi\boot\>
At this point, the UEFI console is properly multiplexed to both serial
and HDMI+USB.
Neat. /me makes a mental note that one can load drivers like this.
Can this be automated to run on each boot? With a startup.nsh script?
Yes, that's what I did:
<https://listman.redhat.com/archives/edk2-devel-archive/2022-April/047910.html>.

Even better would have been to copy the SerialDxe and TerminalDxe
drivers to the hard disk's EFI system partition, and then register them
as Driver#### / DriverOrder. I tried that with "bcfg driver addp", and
then validated with "bcfg driver dump -v" -- however, alas, this system
seems to ignore Driver* in platform BDS.

Regarding the startup.nsh script: the contents are like this:

load hd0c0b:\efi\boot\SerialDxe.efi
load hd0c0b:\efi\boot\TerminalDxe.efi

The "hd0c0b:" filesystem identifier is the "consistent naming" kind
(printed by "map -c"), as opposed to FS0: and friends. Without an FS
identifier, the script wouldn't work (the shell wouldn't know on what FS
to look for the pathname \efi\boot\SerialDxe.efi, because, at startup,
there would not be a "current" filesystem). And given that I had to
specify the filesystem, the "consistent" naming looked better. The UEFI
Shell spec explains what the consistent naming rules are -- in brief, as
long as I plug the stick in the same USB port, the FS identifier will work.

Thanks,
Laszlo

manickavasakam karpagavinayagam
 

Laszlo :

Checked internally and came to know that Aptio BIOS for this platform doesn't support the serial redirection support during POST.

Thank you

-Manic

-----Original Message-----
From: Laszlo Ersek <lersek@...>
Sent: Friday, April 8, 2022 5:20 AM
To: Manickavasakam Karpagavinayagam <manickavasakamk@...>; Gerd Hoffmann <kraxel@...>; Srini Narayana <SriniN@...>; KarenLee [李致瑤] <KarenLee@...>; Harikrishna Doppalapudi <Harikrishnad@...>
Cc: devel@edk2.groups.io; Ramesh R. <rameshr@...>; Sivaraman Nainar <sivaramann@...>
Subject: Re: [EXTERNAL] Re: [edk2-devel] Intel NUC platform firmware -- no serial I/O support?

Hi Manic,

On 04/07/22 19:04, Manickavasakam Karpagavinayagam wrote:
Laszlo/Gred :

Can you please let us know the GITHUB project location from where you have downloaded the source ?
I didn't download any new source code. I've just had my local edk2 clone as always, and the small patch at the bottom (adding "NucSerialPkg", just for the sake of buildig SerialDxe and TerminalDxe in separation) applies on top of current master.

Thanks
Laszlo


Thank you

-Manic

-----Original Message-----
From: Laszlo Ersek <lersek@...>
Sent: Thursday, April 7, 2022 10:12 AM
To: Gerd Hoffmann <kraxel@...>
Cc: devel@edk2.groups.io; Ramesh R. <rameshr@...>; Sivaraman
Nainar <sivaramann@...>; Manickavasakam Karpagavinayagam
<manickavasakamk@...>
Subject: [EXTERNAL] Re: [edk2-devel] Intel NUC platform firmware -- no serial I/O support?


**CAUTION: The e-mail below is from an external source. Please
exercise caution before opening attachments, clicking links, or
following guidance.**

On 04/07/22 14:50, Gerd Hoffmann wrote:

Well, it at least looks like 16550 / ide hardware. Not sure how this
is actually implemented, I suspect it is virtual, maybe port access
traps into SMM and it's emulated there. Or the management engine can
intercept those port accesses somehow.
If today's hardware still works the same way I'd expect you have a
little driver taking the role of SioBusDxe, but binding to
PCI_CLASS_COMMUNICATION_SERIAL devices instead of a LPC bridge with
isa serial ports behind it. Possibly the AMI drivers you've seen are
just that.

Does the NUC accept unsigned firmware updates? If so we can maybe
just add a SioBusDxe driver variant customized for the NUC hardware
You are spot on, but reality is even simpler than this. :)

Here's what I've done:

(1) I cross-referenced three lists of PCI IDs:

(1.1) The supported IDs in the windows UART driver INF file, downloaded from Intel, for this NUC.

(1.2) The "lspci" output on the NUC.

(1.3) The "drivers/mfd/intel-lpss-pci.c" file in the Linux tree.

Result: there is no separate PCI device on this NUC that stands for a
serial controller. Furthermore, "intel-lpss-pci.c" suggests all the
"LPSS" serial ports (UARTs) are 16550 compatible -- see the reference
chain

<all UART IDs> -> spt_uart_info -> uart_node -> uart_properties -> "snps,uart-16550-compatible".

(2) While navigating the (graphical) Setup UI, I noticed that HII debug messages *were* sent to the serial port, by this nice, graphical, Setup Browser.

(3) The particular (non-Linux) kernel that I booted on this NUC could flawlessly drive the serial port for input and output just by my specification of the bog standard params baud-rate=115200, 8 data bits, no parity, 1 stop bit.

That gave me the following idea:

commit 0e794fe273b77830532ffb003b0d5539d7ae9823 (HEAD ->
nuc_serial_pkg)
Author: Laszlo Ersek <lersek@...>
Date: Thu Apr 7 14:37:13 2022 +0200

add NucSerialPkg: build SerialDxe and TerminalDxe for the
NUC8i3PNH

Signed-off-by: Laszlo Ersek <lersek@...>

diff --git a/NucSerialPkg/NucSerialPkg.dec
b/NucSerialPkg/NucSerialPkg.dec new file mode 100644 index
000000000000..b077cde229c0
--- /dev/null
+++ b/NucSerialPkg/NucSerialPkg.dec
@@ -0,0 +1,13 @@
+## @file
+# UART 16650 serial port driver build for the NUC8i3PNH.
+#
+# Copyright (c) 2022, Red Hat, Inc.
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent ##
+
+[Defines]
+ DEC_SPECIFICATION = 1.29
+ PACKAGE_NAME = NucSerialPkg
+ PACKAGE_GUID = afdaaf17-4a06-4d97-a456-1ede0db46bc0
+ PACKAGE_VERSION = 0.1
diff --git a/NucSerialPkg/NucSerialPkg.dsc
b/NucSerialPkg/NucSerialPkg.dsc new file mode 100644 index
000000000000..971fb2f96a43
--- /dev/null
+++ b/NucSerialPkg/NucSerialPkg.dsc
@@ -0,0 +1,46 @@
+## @file
+# UART 16650 serial port driver build for the NUC8i3PNH.
+#
+# Copyright (c) 2022, Red Hat, Inc.
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent ##
+
+[Defines]
+ PLATFORM_NAME = NucSerial
+ PLATFORM_GUID = 30c397cf-a446-4f41-858f-9ae677547094
+ PLATFORM_VERSION = 0.1
+ DSC_SPECIFICATION = 1.30
+ OUTPUT_DIRECTORY = Build/NucSerial
+ SUPPORTED_ARCHITECTURES = X64
+ BUILD_TARGETS = NOOPT|DEBUG|RELEASE
+ SKUID_IDENTIFIER = DEFAULT
+
+[BuildOptions]
+ GCC:RELEASE_*_*_CC_FLAGS = -DMDEPKG_NDEBUG
+ RELEASE_*_*_GENFW_FLAGS = --zero
+ GCC:*_*_*_CC_FLAGS = -D DISABLE_NEW_DEPRECATED_INTERFACES
+
+[LibraryClasses]
+ BaseLib|MdePkg/Library/BaseLib/BaseLib.inf
+ BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
+ DebugLib|MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf
+
+DevicePathLib|MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.inf
+ IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf
+
+MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemor
+MemoryAllocationLib|y
+AllocationLib.inf
+ PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
+ PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
+
+RegisterFilterLib|MdePkg/Library/RegisterFilterLibNull/RegisterFilte
+RegisterFilterLib|r
+LibNull.inf
+
+ReportStatusCodeLib|MdePkg/Library/BaseReportStatusCodeLibNull/BaseR
+ReportStatusCodeLib|e
+portStatusCodeLibNull.inf
+ SerialPortLib|PcAtChipsetPkg/Library/SerialIoLib/SerialIoLib.inf
+
+UefiBootServicesTableLib|MdePkg/Library/UefiBootServicesTableLib/Uef
+UefiBootServicesTableLib|i
+BootServicesTableLib.inf
+
+UefiDriverEntryPoint|MdePkg/Library/UefiDriverEntryPoint/UefiDriverE
+UefiDriverEntryPoint|n
+tryPoint.inf
+ UefiLib|MdePkg/Library/UefiLib/UefiLib.inf
+
+UefiRuntimeServicesTableLib|MdePkg/Library/UefiRuntimeServicesTableL
+UefiRuntimeServicesTableLib|i
+b/UefiRuntimeServicesTableLib.inf
+
+[PcdsFeatureFlag]
+ gEfiMdePkgTokenSpaceGuid.PcdUgaConsumeSupport|FALSE
+
+[Components]
+ MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf
+ MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
The key line is the following lib class resolution:

SerialPortLib|PcAtChipsetPkg/Library/SerialIoLib/SerialIoLib.inf

It's the simplest possible (= most compatible) approach on X64.

And It Just Works (TM), with the following two commands in the UEFI shell (after I copied the binaries to the USB stick, alongside the UEFI Shell binary I built earlier):

Shell> fs0:
FS0:\> cd efi\boot
FS0:\efi\boot\> load SerialDxe.efi
Image 'FS0:\EFI\BOOT\SerialDxe.efi' loaded at 2C801000 - Success
FS0:\efi\boot\> load TerminalDxe.efi Image
'FS0:\EFI\BOOT\TerminalDxe.efi' loaded at 2C7FB000 - Success
FS0:\efi\boot\>
At this point, the UEFI console is properly multiplexed to both serial and HDMI+USB.

(Side comment: SerialDxe is not even a UEFI_DRIVER just a DXE_DRIVER,
so it produces SerialIo immediately.)

With the serial console up, I can provide a "drivers" output too:

FS0:\efi\boot\> drivers
T D
D Y C I
R P F A
V VERSION E G G #D #C DRIVER NAME IMAGE NAME
== ======== = = = == == =================================== ==========
49 00000017 D - - 1 - AMI USB Driver Uhcd
4B 00000017 B - - 1 3 AMI USB Bus Driver Uhcd
4C 00000002 D - - 2 - AMI USB Hid Driver Uhcd
4D 00000001 D - - 1 - AMI USB Mass Storage Driver Uhcd
78 00010000 ? - - - - AMI NTFS Driver NTFS
7A 00000001 D - - 2 - <null string> MouseDriver
7D 00000001 D - - 1 - AMI AHCI BUS Driver Ahci
7F 00000010 ? - - - - AMI Serial I/O Driver SerialIo
83 00000001 B - - 1 1 AMI NVMe BUS Driver Nvme
124 00000010 D - - 1 - Serial ATA Controller Initializatio
SataController
132 00000010 B - - 2 2 AMI Console Splitter Text Out Drive
ConSplitter
133 00000010 B - - 2 2 AMI Console Splitter Text In Driver
ConSplitter
134 00000010 B - - 1 1 AMI Console Splitter Pointer Driver ConSplitter
137 00000010 D - - 1 - AMI Graphic Console Driver GraphicsConsole
138 0000000A D - - 8 - Generic Disk I/O Driver DiskIoDxe
139 0000000B B - - 2 6 Partition Driver(MBR/GPT/El Torito) PartitionDxe
13D 00000000 ? - - - - Integrated Touch Driver IntegratedTouch
13E 0000000A ? - - - - Bluetooth Bus Driver BluetoothBusDxe
13F 0000000A ? - - - - <null string> BluetoothBusDxe
140 0000000A ? - - - - Bluetooth Connection Manager BluetoothConfigDxe
141 0000000A ? - - - - Bluetooth HID Driver BluetoothHidDxe
142 0000000A ? - - - - Hid Keyboard Driver HidKbDxe
143 0000000A ? - - - - Hid Mouse Driver HidMouseDxe
147 00000010 D - - 1 - AMI Generic LPC Super I/O Driver GenericSio
149 00A50111 B - - 1 17 AMI PCI Bus Driver PciBus
14B 00000010 ? - - - - AMI PS/2 Driver Ps2Main
14D 00000010 ? - - - - AMI Terminal Driver TerminalSrc
14E 0000000A ? - - - - IpSec Driver IpSecDxe
150 0000000A ? - - - - IpSec Driver IpSecDxe
151 0000000A ? - - - - VLAN Configuration Driver VlanConfigDxe
152 0000000A ? - - - - HttpDxe HttpDxe
153 0000000A ? - - - - HttpDxe HttpDxe
154 00000000 ? - - - - DNS Network Service Driver DnsDxe
155 00000000 ? - - - - DNS Network Service Driver DnsDxe
158 0000000A D - - 4 - FAT File System Driver Fat
159 0000000A ? - - - - iSCSI Driver IScsiDxe
15A 0000000A ? - - - - iSCSI Driver IScsiDxe
15C 0000000A ? - - - - SCSI Bus Driver ScsiBus
15D 0000000A ? - - - - Scsi Disk Driver ScsiDisk
16A 0900044A B - - 1 1 Intel(R) GOP Driver [9.0.1098] MemoryMapped(0x3,0x29A33018,0x29A44A98)
19B 0000000A B - - 1 1 Serial Terminal Driver \EFI\BOOT\TerminalDxe.efi
SerialDxe is not in the list, as it is not a UEFI driver (it does not install an instance of the Driver Binding protocol).

The curious parts are:

- what the "TerminalSrc" driver ("AMI Terminal Driver") stands for (it
does not bind the SerialIo instance installed by SerialDxe, not even
after "connect -r" -- that's why I need TerminalDxe from edk2),

- why the platform firmware packager thought it would be a good idea to
*exclude* the SerialDxe and TerminalDxe drivers -- these binaries
weigh in at 23 KB together, in a DEBUG build! And the hardware is
there...

Thanks,
Laszlo

-The information contained in this message may be confidential and proprietary to American Megatrends (AMI). This communication is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any distribution of this message, in any form, is strictly prohibited. Please promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and then delete or destroy all copies of the transmission.
-The information contained in this message may be confidential and proprietary to American Megatrends (AMI). This communication is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any distribution of this message, in any form, is strictly prohibited. Please promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and then delete or destroy all copies of the transmission.

Laszlo Ersek
 

Hi Manic,

thanks a lot for spending time on this!

Laszlo

On 04/12/22 20:40, Manickavasakam Karpagavinayagam wrote:
Laszlo :

Checked internally and came to know that Aptio BIOS for this platform doesn't support the serial redirection support during POST.

Thank you

-Manic

-----Original Message-----
From: Laszlo Ersek <lersek@...>
Sent: Friday, April 8, 2022 5:20 AM
To: Manickavasakam Karpagavinayagam <manickavasakamk@...>; Gerd Hoffmann <kraxel@...>; Srini Narayana <SriniN@...>; KarenLee [李致瑤] <KarenLee@...>; Harikrishna Doppalapudi <Harikrishnad@...>
Cc: devel@edk2.groups.io; Ramesh R. <rameshr@...>; Sivaraman Nainar <sivaramann@...>
Subject: Re: [EXTERNAL] Re: [edk2-devel] Intel NUC platform firmware -- no serial I/O support?

Hi Manic,

On 04/07/22 19:04, Manickavasakam Karpagavinayagam wrote:
Laszlo/Gred :

Can you please let us know the GITHUB project location from where you have downloaded the source ?
I didn't download any new source code. I've just had my local edk2 clone as always, and the small patch at the bottom (adding "NucSerialPkg", just for the sake of buildig SerialDxe and TerminalDxe in separation) applies on top of current master.

Thanks
Laszlo


Thank you

-Manic

-----Original Message-----
From: Laszlo Ersek <lersek@...>
Sent: Thursday, April 7, 2022 10:12 AM
To: Gerd Hoffmann <kraxel@...>
Cc: devel@edk2.groups.io; Ramesh R. <rameshr@...>; Sivaraman
Nainar <sivaramann@...>; Manickavasakam Karpagavinayagam
<manickavasakamk@...>
Subject: [EXTERNAL] Re: [edk2-devel] Intel NUC platform firmware -- no serial I/O support?


**CAUTION: The e-mail below is from an external source. Please
exercise caution before opening attachments, clicking links, or
following guidance.**

On 04/07/22 14:50, Gerd Hoffmann wrote:

Well, it at least looks like 16550 / ide hardware. Not sure how this
is actually implemented, I suspect it is virtual, maybe port access
traps into SMM and it's emulated there. Or the management engine can
intercept those port accesses somehow.
If today's hardware still works the same way I'd expect you have a
little driver taking the role of SioBusDxe, but binding to
PCI_CLASS_COMMUNICATION_SERIAL devices instead of a LPC bridge with
isa serial ports behind it. Possibly the AMI drivers you've seen are
just that.

Does the NUC accept unsigned firmware updates? If so we can maybe
just add a SioBusDxe driver variant customized for the NUC hardware
You are spot on, but reality is even simpler than this. :)

Here's what I've done:

(1) I cross-referenced three lists of PCI IDs:

(1.1) The supported IDs in the windows UART driver INF file, downloaded from Intel, for this NUC.

(1.2) The "lspci" output on the NUC.

(1.3) The "drivers/mfd/intel-lpss-pci.c" file in the Linux tree.

Result: there is no separate PCI device on this NUC that stands for a
serial controller. Furthermore, "intel-lpss-pci.c" suggests all the
"LPSS" serial ports (UARTs) are 16550 compatible -- see the reference
chain

<all UART IDs> -> spt_uart_info -> uart_node -> uart_properties -> "snps,uart-16550-compatible".

(2) While navigating the (graphical) Setup UI, I noticed that HII debug messages *were* sent to the serial port, by this nice, graphical, Setup Browser.

(3) The particular (non-Linux) kernel that I booted on this NUC could flawlessly drive the serial port for input and output just by my specification of the bog standard params baud-rate=115200, 8 data bits, no parity, 1 stop bit.

That gave me the following idea:

commit 0e794fe273b77830532ffb003b0d5539d7ae9823 (HEAD ->
nuc_serial_pkg)
Author: Laszlo Ersek <lersek@...>
Date: Thu Apr 7 14:37:13 2022 +0200

add NucSerialPkg: build SerialDxe and TerminalDxe for the
NUC8i3PNH

Signed-off-by: Laszlo Ersek <lersek@...>

diff --git a/NucSerialPkg/NucSerialPkg.dec
b/NucSerialPkg/NucSerialPkg.dec new file mode 100644 index
000000000000..b077cde229c0
--- /dev/null
+++ b/NucSerialPkg/NucSerialPkg.dec
@@ -0,0 +1,13 @@
+## @file
+# UART 16650 serial port driver build for the NUC8i3PNH.
+#
+# Copyright (c) 2022, Red Hat, Inc.
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent ##
+
+[Defines]
+ DEC_SPECIFICATION = 1.29
+ PACKAGE_NAME = NucSerialPkg
+ PACKAGE_GUID = afdaaf17-4a06-4d97-a456-1ede0db46bc0
+ PACKAGE_VERSION = 0.1
diff --git a/NucSerialPkg/NucSerialPkg.dsc
b/NucSerialPkg/NucSerialPkg.dsc new file mode 100644 index
000000000000..971fb2f96a43
--- /dev/null
+++ b/NucSerialPkg/NucSerialPkg.dsc
@@ -0,0 +1,46 @@
+## @file
+# UART 16650 serial port driver build for the NUC8i3PNH.
+#
+# Copyright (c) 2022, Red Hat, Inc.
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent ##
+
+[Defines]
+ PLATFORM_NAME = NucSerial
+ PLATFORM_GUID = 30c397cf-a446-4f41-858f-9ae677547094
+ PLATFORM_VERSION = 0.1
+ DSC_SPECIFICATION = 1.30
+ OUTPUT_DIRECTORY = Build/NucSerial
+ SUPPORTED_ARCHITECTURES = X64
+ BUILD_TARGETS = NOOPT|DEBUG|RELEASE
+ SKUID_IDENTIFIER = DEFAULT
+
+[BuildOptions]
+ GCC:RELEASE_*_*_CC_FLAGS = -DMDEPKG_NDEBUG
+ RELEASE_*_*_GENFW_FLAGS = --zero
+ GCC:*_*_*_CC_FLAGS = -D DISABLE_NEW_DEPRECATED_INTERFACES
+
+[LibraryClasses]
+ BaseLib|MdePkg/Library/BaseLib/BaseLib.inf
+ BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
+ DebugLib|MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf
+
+DevicePathLib|MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.inf
+ IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf
+
+MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemor
+MemoryAllocationLib|y
+AllocationLib.inf
+ PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
+ PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
+
+RegisterFilterLib|MdePkg/Library/RegisterFilterLibNull/RegisterFilte
+RegisterFilterLib|r
+LibNull.inf
+
+ReportStatusCodeLib|MdePkg/Library/BaseReportStatusCodeLibNull/BaseR
+ReportStatusCodeLib|e
+portStatusCodeLibNull.inf
+ SerialPortLib|PcAtChipsetPkg/Library/SerialIoLib/SerialIoLib.inf
+
+UefiBootServicesTableLib|MdePkg/Library/UefiBootServicesTableLib/Uef
+UefiBootServicesTableLib|i
+BootServicesTableLib.inf
+
+UefiDriverEntryPoint|MdePkg/Library/UefiDriverEntryPoint/UefiDriverE
+UefiDriverEntryPoint|n
+tryPoint.inf
+ UefiLib|MdePkg/Library/UefiLib/UefiLib.inf
+
+UefiRuntimeServicesTableLib|MdePkg/Library/UefiRuntimeServicesTableL
+UefiRuntimeServicesTableLib|i
+b/UefiRuntimeServicesTableLib.inf
+
+[PcdsFeatureFlag]
+ gEfiMdePkgTokenSpaceGuid.PcdUgaConsumeSupport|FALSE
+
+[Components]
+ MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf
+ MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
The key line is the following lib class resolution:

SerialPortLib|PcAtChipsetPkg/Library/SerialIoLib/SerialIoLib.inf

It's the simplest possible (= most compatible) approach on X64.

And It Just Works (TM), with the following two commands in the UEFI shell (after I copied the binaries to the USB stick, alongside the UEFI Shell binary I built earlier):

Shell> fs0:
FS0:\> cd efi\boot
FS0:\efi\boot\> load SerialDxe.efi
Image 'FS0:\EFI\BOOT\SerialDxe.efi' loaded at 2C801000 - Success
FS0:\efi\boot\> load TerminalDxe.efi Image
'FS0:\EFI\BOOT\TerminalDxe.efi' loaded at 2C7FB000 - Success
FS0:\efi\boot\>
At this point, the UEFI console is properly multiplexed to both serial and HDMI+USB.

(Side comment: SerialDxe is not even a UEFI_DRIVER just a DXE_DRIVER,
so it produces SerialIo immediately.)

With the serial console up, I can provide a "drivers" output too:

FS0:\efi\boot\> drivers
T D
D Y C I
R P F A
V VERSION E G G #D #C DRIVER NAME IMAGE NAME
== ======== = = = == == =================================== ==========
49 00000017 D - - 1 - AMI USB Driver Uhcd
4B 00000017 B - - 1 3 AMI USB Bus Driver Uhcd
4C 00000002 D - - 2 - AMI USB Hid Driver Uhcd
4D 00000001 D - - 1 - AMI USB Mass Storage Driver Uhcd
78 00010000 ? - - - - AMI NTFS Driver NTFS
7A 00000001 D - - 2 - <null string> MouseDriver
7D 00000001 D - - 1 - AMI AHCI BUS Driver Ahci
7F 00000010 ? - - - - AMI Serial I/O Driver SerialIo
83 00000001 B - - 1 1 AMI NVMe BUS Driver Nvme
124 00000010 D - - 1 - Serial ATA Controller Initializatio
SataController
132 00000010 B - - 2 2 AMI Console Splitter Text Out Drive
ConSplitter
133 00000010 B - - 2 2 AMI Console Splitter Text In Driver
ConSplitter
134 00000010 B - - 1 1 AMI Console Splitter Pointer Driver ConSplitter
137 00000010 D - - 1 - AMI Graphic Console Driver GraphicsConsole
138 0000000A D - - 8 - Generic Disk I/O Driver DiskIoDxe
139 0000000B B - - 2 6 Partition Driver(MBR/GPT/El Torito) PartitionDxe
13D 00000000 ? - - - - Integrated Touch Driver IntegratedTouch
13E 0000000A ? - - - - Bluetooth Bus Driver BluetoothBusDxe
13F 0000000A ? - - - - <null string> BluetoothBusDxe
140 0000000A ? - - - - Bluetooth Connection Manager BluetoothConfigDxe
141 0000000A ? - - - - Bluetooth HID Driver BluetoothHidDxe
142 0000000A ? - - - - Hid Keyboard Driver HidKbDxe
143 0000000A ? - - - - Hid Mouse Driver HidMouseDxe
147 00000010 D - - 1 - AMI Generic LPC Super I/O Driver GenericSio
149 00A50111 B - - 1 17 AMI PCI Bus Driver PciBus
14B 00000010 ? - - - - AMI PS/2 Driver Ps2Main
14D 00000010 ? - - - - AMI Terminal Driver TerminalSrc
14E 0000000A ? - - - - IpSec Driver IpSecDxe
150 0000000A ? - - - - IpSec Driver IpSecDxe
151 0000000A ? - - - - VLAN Configuration Driver VlanConfigDxe
152 0000000A ? - - - - HttpDxe HttpDxe
153 0000000A ? - - - - HttpDxe HttpDxe
154 00000000 ? - - - - DNS Network Service Driver DnsDxe
155 00000000 ? - - - - DNS Network Service Driver DnsDxe
158 0000000A D - - 4 - FAT File System Driver Fat
159 0000000A ? - - - - iSCSI Driver IScsiDxe
15A 0000000A ? - - - - iSCSI Driver IScsiDxe
15C 0000000A ? - - - - SCSI Bus Driver ScsiBus
15D 0000000A ? - - - - Scsi Disk Driver ScsiDisk
16A 0900044A B - - 1 1 Intel(R) GOP Driver [9.0.1098] MemoryMapped(0x3,0x29A33018,0x29A44A98)
19B 0000000A B - - 1 1 Serial Terminal Driver \EFI\BOOT\TerminalDxe.efi
SerialDxe is not in the list, as it is not a UEFI driver (it does not install an instance of the Driver Binding protocol).

The curious parts are:

- what the "TerminalSrc" driver ("AMI Terminal Driver") stands for (it
does not bind the SerialIo instance installed by SerialDxe, not even
after "connect -r" -- that's why I need TerminalDxe from edk2),

- why the platform firmware packager thought it would be a good idea to
*exclude* the SerialDxe and TerminalDxe drivers -- these binaries
weigh in at 23 KB together, in a DEBUG build! And the hardware is
there...

Thanks,
Laszlo

-The information contained in this message may be confidential and proprietary to American Megatrends (AMI). This communication is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any distribution of this message, in any form, is strictly prohibited. Please promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and then delete or destroy all copies of the transmission.
-The information contained in this message may be confidential and proprietary to American Megatrends (AMI). This communication is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any distribution of this message, in any form, is strictly prohibited. Please promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and then delete or destroy all copies of the transmission.

Laszlo Ersek
 

On 04/07/22 12:49, Laszlo Ersek wrote:

On the NUC, this whole child controller chain, and protocol stack,
breaks down because there is no SerialIo protocol interface in the
protocol db. The following command returns nothing, even after "connect
-r":

Shell> dh -d -v -p SerialIo
(On OVMF, the command returns handle BE, see above.)
It's hard to understand the "secret decisions" about physical platform
firmware. I'm working with a new NUC now, and this one does provide a
functional SerialIo protocol implementation out of the box (with the
"AMI Serial I/O Driver" actually doing its job, unlike in the previous
NUC). However, TerminalDxe is *still* not included in the platform
firmware. Unfathomable. (Well, "TerminalSrc", aka "AMI Terminal Driver"
is included, but like on the earlier NUC, it seems to be doing nothing;
it doesn't bind SerialIo.)

Laszlo

1 - 14 of 14