Date: Mon, 25 Jun 2018 11:25:53 -0600 From: Warner Losh <imp@bsdimp.com> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, "freebsd-arch@freebsd.org" <arch@freebsd.org> Subject: Re: UEFI Plans / Shifts -- RFC Message-ID: <CANCZdfrHfJ23QEbtDb0VVSeakabyUKJyn_6nkGwObr2K_%2BYYzA@mail.gmail.com> In-Reply-To: <20180625154740.GF2430@kib.kiev.ua> References: <CANCZdfoMZXJu2nRbAtLTPc1B4YWWbxsHQjX31zOo%2B8mDwMAQuA@mail.gmail.com> <19341.1529917294@critter.freebsd.dk> <20180625091844.GC2430@kib.kiev.ua> <CANCZdfoSGa%2BuO0Q6z2FOt_0=vSn2F9N%2BdCdysWHLrtpYFV22Tw@mail.gmail.com> <20180625154740.GF2430@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jun 25, 2018 at 9:47 AM, Konstantin Belousov <kostikbel@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@gmail.com>
> > wrote:
> >
> > > On Mon, Jun 25, 2018 at 09:01:34AM +0000, Poul-Henning Kamp wrote:
> > > > --------
> > > > In message <CANCZdfoMZXJu2nRbAtLTPc1B4YWWb
> xsHQjX31zOo+8mDwMAQuA@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.
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfrHfJ23QEbtDb0VVSeakabyUKJyn_6nkGwObr2K_%2BYYzA>