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

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

Re: [edk2-devel] Intel NUC platform firmware -- no serial I/O support?

[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

Re: [edk2-devel] Intel NUC platform firmware -- no serial I/O support?

[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

Re: [edk2-devel] Intel NUC platform firmware -- no serial I/O support?

[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

Re: [edk2-devel] Intel NUC platform firmware -- no serial I/O support?

[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@redhat.com>
> Date:   Thu Apr 7 14:37:13 2022 +0200
>
>     add NucSerialPkg: build SerialDxe and TerminalDxe for the NUC8i3PNH
>
>     Signed-off-by: Laszlo Ersek <lersek@redhat.com>
>
> 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

Re: [edk2-devel] Intel NUC platform firmware -- no serial I/O support?

[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@redhat.com>
Sent: Thursday, April 7, 2022 10:12 AM
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: devel@edk2.groups.io; Ramesh R. <rameshr@ami.com>; Sivaraman Nainar <sivaramann@ami.com>; Manickavasakam Karpagavinayagam <manickavasakamk@ami.com>
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@redhat.com>
> Date:   Thu Apr 7 14:37:13 2022 +0200
>
>     add NucSerialPkg: build SerialDxe and TerminalDxe for the
> NUC8i3PNH
>
>     Signed-off-by: Laszlo Ersek <lersek@redhat.com>
>
> 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.

Re: [edk2-devel] Intel NUC platform firmware -- no serial I/O support?

[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@ami.com>; Sivaraman Nainar
> <sivaramann@ami.com>; KARPAGAVINAYAGAM, MANICKAVASAKAM
> <manickavasakamk@ami.com>
> 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
> 
> 
> 
> 
> 

Re: [edk2-devel] Intel NUC platform firmware -- no serial I/O support?

[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@redhat.com>
> Sent: Thursday, April 7, 2022 10:12 AM
> To: Gerd Hoffmann <kraxel@redhat.com>
> Cc: devel@edk2.groups.io; Ramesh R. <rameshr@ami.com>; Sivaraman Nainar <sivaramann@ami.com>; Manickavasakam Karpagavinayagam <manickavasakamk@ami.com>
> 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@redhat.com>
>> Date:   Thu Apr 7 14:37:13 2022 +0200
>>
>>     add NucSerialPkg: build SerialDxe and TerminalDxe for the
>> NUC8i3PNH
>>
>>     Signed-off-by: Laszlo Ersek <lersek@redhat.com>
>>
>> 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.
> 

Re: [edk2-devel] Intel NUC platform firmware -- no serial I/O support?

[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@ami.com>; Sivaraman Nainar
>> <sivaramann@ami.com>; KARPAGAVINAYAGAM, MANICKAVASAKAM
>> <manickavasakamk@ami.com>
>> 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

Re: [edk2-devel] Intel NUC platform firmware -- no serial I/O support?

[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

Re: [edk2-devel] Intel NUC platform firmware -- no serial I/O support?

[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

Re: [edk2-devel] Intel NUC platform firmware -- no serial I/O support?

[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@redhat.com>
Sent: Friday, April 8, 2022 5:20 AM
To: Manickavasakam Karpagavinayagam <manickavasakamk@ami.com>; Gerd Hoffmann <kraxel@redhat.com>; Srini Narayana <SriniN@ami.com>; KarenLee [李致瑤] <KarenLee@ami.com>; Harikrishna Doppalapudi <Harikrishnad@ami.com>
Cc: devel@edk2.groups.io; Ramesh R. <rameshr@ami.com>; Sivaraman Nainar <sivaramann@ami.com>
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@redhat.com>
> Sent: Thursday, April 7, 2022 10:12 AM
> To: Gerd Hoffmann <kraxel@redhat.com>
> Cc: devel@edk2.groups.io; Ramesh R. <rameshr@ami.com>; Sivaraman
> Nainar <sivaramann@ami.com>; Manickavasakam Karpagavinayagam
> <manickavasakamk@ami.com>
> 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@redhat.com>
>> Date:   Thu Apr 7 14:37:13 2022 +0200
>>
>>     add NucSerialPkg: build SerialDxe and TerminalDxe for the
>> NUC8i3PNH
>>
>>     Signed-off-by: Laszlo Ersek <lersek@redhat.com>
>>
>> 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.

Re: [edk2-devel] Intel NUC platform firmware -- no serial I/O support?

[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@redhat.com>
> Sent: Friday, April 8, 2022 5:20 AM
> To: Manickavasakam Karpagavinayagam <manickavasakamk@ami.com>; Gerd Hoffmann <kraxel@redhat.com>; Srini Narayana <SriniN@ami.com>; KarenLee [李致瑤] <KarenLee@ami.com>; Harikrishna Doppalapudi <Harikrishnad@ami.com>
> Cc: devel@edk2.groups.io; Ramesh R. <rameshr@ami.com>; Sivaraman Nainar <sivaramann@ami.com>
> 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@redhat.com>
>> Sent: Thursday, April 7, 2022 10:12 AM
>> To: Gerd Hoffmann <kraxel@redhat.com>
>> Cc: devel@edk2.groups.io; Ramesh R. <rameshr@ami.com>; Sivaraman
>> Nainar <sivaramann@ami.com>; Manickavasakam Karpagavinayagam
>> <manickavasakamk@ami.com>
>> 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@redhat.com>
>>> Date:   Thu Apr 7 14:37:13 2022 +0200
>>>
>>>     add NucSerialPkg: build SerialDxe and TerminalDxe for the
>>> NUC8i3PNH
>>>
>>>     Signed-off-by: Laszlo Ersek <lersek@redhat.com>
>>>
>>> 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.
> 

Re: [edk2-devel] Intel NUC platform firmware -- no serial I/O support?

[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