public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Laszlo Ersek" <lersek@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>, devel@edk2.groups.io
Cc: "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 12:49:38 +0200	[thread overview]
Message-ID: <d57aaf9c-4a6c-e41b-871e-3c7c79065753@redhat.com> (raw)
In-Reply-To: <20220407080008.o2qmtum4sxzw5zfo@sirius.home.kraxel.org>

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


  reply	other threads:[~2022-04-07 10:49 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 [this message]
2022-04-07 12:50     ` Gerd Hoffmann
2022-04-07 14:12       ` Laszlo Ersek
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=d57aaf9c-4a6c-e41b-871e-3c7c79065753@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