From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mx.groups.io with SMTP id smtpd.web12.7018.1649340738233156604 for ; Thu, 07 Apr 2022 07:12:18 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=gxXQNhQ0; spf=pass (domain: redhat.com, ip: 170.10.129.124, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1649340737; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ZbD2C+cPBaIAwBEnL1PyJLrp+bOnTxpUh52KHWpCQlM=; b=gxXQNhQ0EqNpk0m72D+wlORyvamd9GYJII0JbI6PhNSGSP+1Ra4bIH7HOAh4LBbHZGCjUM slG5lsKHAIX5W2LjKWTlbDp1/Eh1Wy2y1pyy2xbch8kxK5vxqn/j4CzoC21YV1dk7k16hB qtPcc33shIm10JSl84PZA3y8qTV6jPs= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-197-xrKsUgKcPx2IqVwqU1-FyA-1; Thu, 07 Apr 2022 10:12:16 -0400 X-MC-Unique: xrKsUgKcPx2IqVwqU1-FyA-1 Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id D63D51C068FB; Thu, 7 Apr 2022 14:12:15 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (unknown [10.39.192.23]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C8128401DB1; Thu, 7 Apr 2022 14:12:14 +0000 (UTC) Subject: Re: [edk2-devel] Intel NUC platform firmware -- no serial I/O support? To: Gerd Hoffmann Cc: devel@edk2.groups.io, "Ramesh R." , Sivaraman Nainar , manickavasakam karpagavinayagam References: <4c8d982a-97b0-654c-c6db-9a55b95330b5@redhat.com> <20220407080008.o2qmtum4sxzw5zfo@sirius.home.kraxel.org> <20220407125015.bkz5e755mpvzdm3g@sirius.home.kraxel.org> From: "Laszlo Ersek" Message-ID: Date: Thu, 7 Apr 2022 16:12:13 +0200 MIME-Version: 1.0 In-Reply-To: <20220407125015.bkz5e755mpvzdm3g@sirius.home.kraxel.org> X-Scanned-By: MIMEDefang 2.85 on 10.11.54.10 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=lersek@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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 -> 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 > Date: Thu Apr 7 14:37:13 2022 +0200 > > add NucSerialPkg: build SerialDxe and TerminalDxe for the NUC8i3PNH > > Signed-off-by: Laszlo Ersek > > 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 - 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 ? - - - - 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