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.web10.3810.1649410377622970184 for ; Fri, 08 Apr 2022 02:32:57 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=NgrMh+oi; 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=1649410376; 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=IQY/c3wDfueFD6iYsiJ7L0a3byIGY8ve1Ge/p7MySCY=; b=NgrMh+oiX6GSluoStPtW+myLoo7HXrxk2O+FeTvHwlTIBOB9DAncMRqp187FBLK6GxRSMd YVFgHNYqLBI0GcZg+CZ8A4Fka5fndzHdFhoKsVd8SAOC+9e6GYkZGtkAzWMPEa9KGWMjVv pnmGiXrNt+s6pzcKLz+kBI8YcgjNy9M= 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-661-l3o6fjMqMNSSxmL8VFaulA-1; Fri, 08 Apr 2022 05:32:53 -0400 X-MC-Unique: l3o6fjMqMNSSxmL8VFaulA-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 0A2761014A66; Fri, 8 Apr 2022 09:32:53 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (unknown [10.39.195.116]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 2246D2166BA3; Fri, 8 Apr 2022 09:32:51 +0000 (UTC) Subject: Re: [edk2-devel] Intel NUC platform firmware -- no serial I/O support? To: "Desimone, Nathaniel L" , "devel@edk2.groups.io" Cc: "r, ramesh" , Sivaraman Nainar , "KARPAGAVINAYAGAM, MANICKAVASAKAM" References: <4c8d982a-97b0-654c-c6db-9a55b95330b5@redhat.com> From: "Laszlo Ersek" Message-ID: <7a04a7b0-a5c0-487d-d963-3411ec9e992f@redhat.com> Date: Fri, 8 Apr 2022 11:32:50 +0200 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 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/08/22 00:16, Desimone, Nathaniel L wrote: > Hi Laszlo, > >> -----Original Message----- >> From: devel@edk2.groups.io On Behalf Of Laszlo >> Ersek >> Sent: Thursday, April 7, 2022 12:46 AM >> To: edk2-devel-groups-io >> Cc: r, ramesh ; Sivaraman Nainar >> ; KARPAGAVINAYAGAM, MANICKAVASAKAM >> >> Subject: [edk2-devel] Intel NUC platform firmware -- no serial I/O support? >> >> Hi List, >> >> my toolbox has been extended with an Intel NUC, the base kit model being >> NUC8i3PNH. The NUC has a serial port connector on the back, and indeed >> Serial I/O works fine once an OS starts. >> >> 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.) > > Yeah you are right the Super I/O stuff is barrels of fun. However it is actually a spec defined protocol, it is just in the PI spec not the UEFI spec. The PI spec also counts for addition to MdePkg. On the MinPlatform side we built a small/simple Super I/O bus driver for UARTs and PS/2 keyboard/mouse: https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel/BoardModulePkg/LegacySioDxe > > Volume 5, Chapter 14 of the PI spec waxes rather poetic about how to build a full ISA plug-and-play capable DXE driver stack for a system that incorporates both a Super I/O and physical ISA slots. I always forget that the PI spec can very well define protocols to be used by UEFI drivers... > I can say is that the NUC team has opted to build their systems with AMI Aptio instead of starting with the Intel reference UEFI firmware. I'm not privy to the conversation there. Accordingly, there might be some Aptio specific drivers as you note in your listing of the driver handle database. I'm afraid I have as much knowledge about how that driver stack works as you do. Thanks for responding! Yesterday I played a bit more with the NUC. I placed the UEFI shell as EFI\BOOT\BOOTX64.EFI on a USB stick, together with SerialDxe.efi, TerminalDxe.efi, and a "startup.nsh" script that loads SerialDxe and TerminalDxe using the "consistent shell drive names" scheme. This way, when I boot the NUC off the stick, I get a shell on serial at once. Another experiment I tried was "bcfg driver". Unfortunately, the platform BDS on the NUC seems to ignore Driver#### and DriverOrder. Then I build UiApp.efi in separation too, and started it from the shell -- it was then really strange to see the "Front Page" tab in the graphical setup TUI :) Now, while that was somewhat useful (as it extended the NUC's setup UI with some nifty features that I'd become used to with OVMF), I actually wanted the inverse: to get all the original NUC setup stuff exposed over serial. But I guess for that, I'd have to replace (override) the graphical setup browser and/or the display engine DXE drivers of the platform firmware... I guess I'll have to give up there. Thanks! Laszlo