Re: Intel NUC platform firmware -- no serial I/O support?
Gerd Hoffmann
On Thu, Apr 07, 2022 at 12:49:38PM +0200, Laszlo Ersek wrote:
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,<magic-words-for-nonstandard-port-here>" 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).
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 ...
take care,
Gerd
The hardware I've used years ago had PCI devices. A 16550 forDisclaimer: Havn't used amt/vpro for a quite while. But possiblyHm... it boggles my mind a bit to think about this, but... considering
those drivers bind to the serial device which shows up when you enable
remote management and serial-over-lan support?
Serial-over-LAN, what that would do, I expect, is provide a SerialIo
protocol interface on top of *some* networking protocol (directly or
indirectly).
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,<magic-words-for-nonstandard-port-here>" 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 busYep.
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)
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