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.5103.1649328588524472738 for ; Thu, 07 Apr 2022 03:49:48 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=InCaetfP; 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=1649328587; 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=E1r/Zs8i+EDuD0S0WYgvs9i8QhxL2hvXBzHCB+SGqvs=; b=InCaetfPqdQDNYLtCPkivspI2C1GQSs0plK1MpPedhrTbGTVtaXdnM2KP1PuxV+eWwwLY4 cRbdEwNA2GQ7MxFYIZmjf1Npqdqbf4LGP6snWJpAtQ1M/Dfwd85O0NbVy2UD/Jb1WPkjhF 2nlDaavWTA+oILSqR0GxnhwkK+cYOVk= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-649--hHE76NFO2egYeTXJv71vQ-1; Thu, 07 Apr 2022 06:49:46 -0400 X-MC-Unique: -hHE76NFO2egYeTXJv71vQ-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 4206585A5A8; Thu, 7 Apr 2022 10:49:41 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (unknown [10.39.192.23]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 20829401DB1; Thu, 7 Apr 2022 10:49:39 +0000 (UTC) Subject: Re: [edk2-devel] Intel NUC platform firmware -- no serial I/O support? To: Gerd Hoffmann , devel@edk2.groups.io Cc: "Ramesh R." , Sivaraman Nainar , manickavasakam karpagavinayagam References: <4c8d982a-97b0-654c-c6db-9a55b95330b5@redhat.com> <20220407080008.o2qmtum4sxzw5zfo@sirius.home.kraxel.org> From: "Laszlo Ersek" Message-ID: Date: Thu, 7 Apr 2022 12:49:38 +0200 MIME-Version: 1.0 In-Reply-To: <20220407080008.o2qmtum4sxzw5zfo@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 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