public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Laszlo Ersek" <lersek@redhat.com>
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: Re: [edk2-devel] Intel NUC platform firmware -- no serial I/O support?
Date: Thu, 7 Apr 2022 16:12:13 +0200	[thread overview]
Message-ID: <e3c82adc-6fde-460e-dedc-4f10dca1776a@redhat.com> (raw)
In-Reply-To: <20220407125015.bkz5e755mpvzdm3g@sirius.home.kraxel.org>

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


  reply	other threads:[~2022-04-07 14:12 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-07  7:46 Intel NUC platform firmware -- no serial I/O support? Laszlo Ersek
2022-04-07  8:00 ` [edk2-devel] " Gerd Hoffmann
2022-04-07 10:49   ` Laszlo Ersek
2022-04-07 12:50     ` Gerd Hoffmann
2022-04-07 14:12       ` Laszlo Ersek [this message]
2022-04-07 17:04         ` manickavasakam karpagavinayagam
2022-04-08  9:19           ` Laszlo Ersek
2022-04-12 18:40             ` manickavasakam karpagavinayagam
2022-04-13  6:06               ` Laszlo Ersek
2022-04-08  9:48         ` Gerd Hoffmann
2022-04-08 11:01           ` Laszlo Ersek
2022-10-06 15:07     ` Laszlo Ersek
2022-04-07 22:16 ` Nate DeSimone
2022-04-08  9:32   ` Laszlo Ersek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e3c82adc-6fde-460e-dedc-4f10dca1776a@redhat.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox