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
next prev parent 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