UEFI Plans / Shifts -- RFC

[Konstantin Belousov]

On Mon, Jun 25, 2018 at 11:25:53AM -0600, Warner Losh wrote:
> On Mon, Jun 25, 2018 at 9:47 AM, Konstantin Belousov <kostikbel at gmail.com>
> wrote:
> 
> > On Mon, Jun 25, 2018 at 07:37:19AM -0600, Warner Losh wrote:
> > > On Mon, Jun 25, 2018 at 3:18 AM, Konstantin Belousov <
> > kostikbel at gmail.com>
> > > wrote:
> > >
> > > > On Mon, Jun 25, 2018 at 09:01:34AM +0000, Poul-Henning Kamp wrote:
> > > > > --------
> > > > > In message <CANCZdfoMZXJu2nRbAtLTPc1B4YWWb
> > xsHQjX31zOo+8mDwMAQuA at mail.
> > > > gmail.com>
> > > > > , Warner Losh writes:
> > > > >
> > > > > >So here's my open questions:
> > > > > >(1) Do I need to parse boot.conf?
> > > > >
> > > > > I can't see how it would add any value on top of UEFI and reading it
> > > > > will just keeping old workarounds alive another decade for no good
> > > > reason.
> > > >
> > > > An obvious values is to have serial console earlier than loader.conf is
> > > > parsed.  At least on typical desktop motherboards which do not have
> > > > serial bios redirection, this is important.
> > > >
> > >
> > > This won't work until AFTER we add ACPI to the boot loader.
> >
> > Why ?
> >
> 
> Because often (very often in my experience) the redirected serial port is
> not at COM1 address, but COM2 or COM3. The only way to set that is via
> comconsole_port. That's not parsed until after we read in loader.conf when
> we kick the different language interpreters off. So, any output before that
> will be lost. This happens when we call interact, which is after all the
> initial boot stuff has happened.
Machines which have BIOS redirection usually double the output to the
video device (framebuffer or vga), and to the serial, exactly as you note
in the decoding of the sample below.

On the other hand, desktop-class boards almost never have either serial
redirection nor the double-output, only have one serial port (COM1)
and this is where the early switch to the serial is most useful.
It is fine to only support ISA COM1 for that.

> 
> The UEFI boot variable ConOut gives us a device which rendered to human
> readable form looks something like:
> PciRoot(0x0)/Pci(0x1c,0x2)/Pci(0x0,0x0)/Pci(0x0,0x0)/AcpiAdr(0x80010100),/PciRoot(0x0)/Pci(0x1f,0x0)/Serial(0x1)/Uart(115200,8,N,1)/UartFlowCtrl(Hardware)/VenVt100Plus()
> 
> which tells us a lot. There's two devices. First one listed is a video card
> whose ACPI _ADR is 0x80010100. The second one is the Serial Port with
> _UID=1 running at 115200 baud and that supports Vt100-ish escape sequences.
> What the boot loader doesn't know is what the port address of UID=1 is with
> any certainty. On my specific system, it maps to:
>     uart1 pnpinfo _HID=PNP0501 _UID=1 at handle=\_SB_.PCI0.LPC0.UAR2
> uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0
> which is actually COM2. Now, there's some text in the ACPI standard that
> says suggests that _UID=0 should be COM1, 1 COM2 etc, but it appears to be
> mostly a suggestion not an absolute requirement. The only requirement is
> that _UID=X is the same from boot to boot. I'd thought about putting in
> some fallback code for this, but a sampling of systems suggests this might
> be a bit optimistic. Here's a sampling of a couple of systems I have:
> 
> Supermicro X11 based:
>     uart0 pnpinfo _HID=PNP0501 _UID=0 at handle=\_SB_.PC00.LPC0.UAR1
>     uart2 pnpinfo _HID=PNP0501 _UID=1 at handle=\_SB_.PC00.LPC0.UAR2
> Supermicro X10 based:
>     uart0 pnpinfo _HID=PNP0501 _UID=0 at handle=\_SB_.PCI0.LPC0.UAR1
>     uart1 pnpinfo _HID=PNP0501 _UID=1 at handle=\_SB_.PCI0.LPC0.UAR2
> Supermicro X9 based:
>     uart0 pnpinfo _HID=PNP0501 _UID=1 at handle=\_SB_.PCI0.LPCB.UAR1
>     unknown pnpinfo _HID=PNP0501 _UID=2 at handle=\_SB_.PCI0.LPCB.UAR2
> (disabled)
>     uart2 pnpinfo _HID=PNP0501 _UID=3 at handle=\_SB_.PCI0.LPCB.UAR3
> Freefall:
>     uart0 pnpinfo _HID=PNP0501 _UID=1 at handle=\_SB_.PCI0.LPCB.UAR1
>     uart1 pnpinfo _HID=PNP0501 _UID=2 at handle=\_SB_.PCI0.LPCB.UAR2
>     uart2 pnpinfo _HID=PNP0501 _UID=3 at handle=\_SB_.PCI0.LPCB.UR12
> 
> So UID=1 could mean COM1, COM2 or COM3, and that's just on SuperMicro
> hardware from the last few years....
> 
> Adding ACPI (to the UEFI-only boot loader, nothing else) would allow us to
> go search the UEFI tree for the PNP0501 node with the right _UID. It's
> kinda a heavy lift though.
> 
> I thought about adding something that would set a FreeBSD-specific env var
> that would give the loader.efi a hint to make things work on the second
> boot (the first boot setting it in rc.d somewhere). But that's a fragile
> solution at best, and wouldn't solve the serial installer issues.
> 
> Warner