stand: add EFI support for mmio serial consoles

[• franco_opnsense.org]

Summary

When no legacy serial is found, we may be looking at a non-legacy mmio
serial device mapping, in which case the efi_devpath_name() for name
ConOutDev looks like this:

VenHw(XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX,0090DCFE00000000)/Uart(115200,8,N,1)/VenVt100()

Which should tell the kernel to attach a console to 0xfedc9000
(little endian 64 bit value). The value is stored behind the
VENDOR_DEVICE_PATH struct as a byte stream hence we need to check
if said address is appended behind the node. Also enforce use for
uart by requiring the console speed read from the same device.

There is no scientific process for "rs:2" derivation, but evidence would
indicate that this is the correct setting for existing MMIO EFI consoles.

See also: http://bsdimp.blogspot.com/2018/07/how-to-get-memory-mapped-serial-console.html

[imp]

stand/efi/loader/main.c

814

This needs a UUID check. VendHw is a generic thing to expand stuff, and each UUID has its own encoding.

[• franco_opnsense.org]

stand/efi/loader/main.c

814

I thought we read only ConOut or ConOutDev. The loop certainly never checks GUID here for same type of lookups?

[imp]

stand/efi/loader/main.c

814

Sorry, the GUID I'm talking about is in the VendHW first field, not the GUID of the env variable. VendHw is a generic thing that says 'Somebody defined this standard, identified by GUID, and here's the data for that standard'. There's several different VendHw that I've seen, each encoding different things. Bonus points for a pointer to a document that 'Somebody' published about it, but I'll not insist on that.

[• franco_opnsense.org]

stand/efi/loader/main.c

814

Ok, I'm looking at VenHw(e76fd4e9-0a30-4ca9-9540-d799534cc4ff,0090dcfe00000000) here specifically on this hardware. It's difficult to follow the code on the premise of hidden byte stream data in VendorDefinedData up until now already. If "someone" could point me to a relevant LOC to check the UUID properly I'm happy to chase it down. For the time being, parse_uefi_con_out() scope is likely not sufficient which what this code aimed to achieve to extend. Suffice to say the serial console works so I'm hoping this is only for general code sanity's sake to extend. :)

[imp]

stand/efi/loader/main.c

814

OK. I'll try code up something later in the week to show how to check.

What hardware / vendor / BIOS / etc did you encounter this on?

[jlduran]

Thank you!
I can offer this HW info:

# sysctl hw.model 
hw.model: Intel(R) Atom(TM) Processor E3950 @ 1.60GHz

# efivar -n 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOutDev -d
8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOutDev
: VenHw(32d1497b-288c-440a-9fc3-651a14efc7b4,00180201)/Uart(115200,8,N,1)/UartFlowCtrl(Hardware)/VenUft8()

# pciconf -ll
drv	selector	class    rev  hdr  vendor device subven subdev
...
none1@pci0:0:24:0:	118000   0b   00   8086   5abc   8086   7270
none2@pci0:0:24:1:	118000   0b   00   8086   5abe   8086   7270
none3@pci0:0:24:2:	118000   0b   00   8086   5ac0   8086   7270
none4@pci0:0:24:3:	118000   0b   00   8086   5aee   8086   7270
...

# pciconf -lb pci0:0:24:2
none0@pci0:0:24:2:	class=0x118000 rev=0x0b hdr=0x00 vendor=0x8086 device=0x5ac0 subvendor=0x8086 subdevice=0x7270
    bar   [10] = type Memory, range 64, base 0xfea10000, size 4096, enabled
    bar   [18] = type Memory, range 64, base 0, size 4096, enabled

In /boot/loader.conf:

hw.uart.console="mm:0xfea10000,rs:2"

(Vaguely related to: D33033).

[markj]

stand/efi/loader/main.c

814

I've been looking at this a bit. It'd indeed be good to know what kind of hardware this is and understand why more standard methods of encoding this info aren't available--I can't find any code which tries to infer configuration parameters from VenHw. Does acpidump -T SPCR show anything?

[imp]

stand/efi/loader/main.c

814

We've started decoding SPCR in the interim and have also started decoding all the versions...
And also the vendor nodes should always have a UUID check at the very leas, so this hasn't landed because of that...
But I really don't want to be in the business of decoding VenHw since it's too niche.

[markj]

stand/efi/loader/main.c

814

Yeah, decoding VenHw seems like the wrong way to go.

I guess you're referring to commit 70253b538f68f. Is there some reason you didn't MFC it to stable/14? It applies and builds cleanly.

[imp]

stand/efi/loader/main.c

814

Yea. No reason. I often will let changes build up then do a huge, bulk MFC for the driver since testing it is such a pain. IIRC, there's more than one commit needed, but there's nothing wrong with MFCing them if they just apply. The problem starts when you have to tweak something in the MFC process: that means conflicts when I do my bulk one.