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.133.124]) by mx.groups.io with SMTP id smtpd.web09.6125.1649335821789711696 for ; Thu, 07 Apr 2022 05:50:22 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=IYlZwkdo; spf=pass (domain: redhat.com, ip: 170.10.133.124, mailfrom: kraxel@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1649335821; 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: in-reply-to:in-reply-to:references:references; bh=uXe+3vj4hUv/6SS1/RO7du8wdIyT6e6BFROs1Ff2UJg=; b=IYlZwkdoBzxvn7f1XqNO+lOm0+qDPuw/LbTv6aLppT6E74n1mWWwJk+CjcKmG8aDjicglE s1gC7pPKY9oeFJbJoXez+TB4kry0D4t7NG0Xe9oEDu3Ko5tJAE5Xso1yODccW4645hkrTj SLejDsMl+datqVfIeRvHtYRx3Jz7GfI= 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-388-VGt0k_a8OpCxCOqHdLE7rQ-1; Thu, 07 Apr 2022 08:50:17 -0400 X-MC-Unique: VGt0k_a8OpCxCOqHdLE7rQ-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 65A7180159B; Thu, 7 Apr 2022 12:50:17 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.192.9]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 34C1A404729D; Thu, 7 Apr 2022 12:50:17 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id E636F18000B3; Thu, 7 Apr 2022 14:50:15 +0200 (CEST) Date: Thu, 7 Apr 2022 14:50:15 +0200 From: "Gerd Hoffmann" To: Laszlo Ersek Cc: devel@edk2.groups.io, "Ramesh R." , Sivaraman Nainar , manickavasakam karpagavinayagam Subject: Re: [edk2-devel] Intel NUC platform firmware -- no serial I/O support? Message-ID: <20220407125015.bkz5e755mpvzdm3g@sirius.home.kraxel.org> References: <4c8d982a-97b0-654c-c6db-9a55b95330b5@redhat.com> <20220407080008.o2qmtum4sxzw5zfo@sirius.home.kraxel.org> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.84 on 10.11.54.2 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=kraxel@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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," 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