UEFI Plans / Shifts -- RFC

[Warner Losh]

Greetings,

As I've documented before, I'll be making some addition UEFI changes.

To recap, the plan:
1. Remove boot1.efi
2. Enhance loader.efi so it can live on ESP
3. Enhance loader.efi so it can do ping-pong booting

1 is still the plan, but there's some bits left to do. Most of step 2 is
done. However, there's some issues that I'd like to work through. 3 is my
next task. There's other installer and installworld tasks that are needed
before 1 can be done.

In the past boot1.efi chose the /, read /boot/config or /boot.config and
passed those args to /boot/loader.efi. This was always an imperfect match
to UEFI, since we selected video/serial/both and other things for the
kernel, but used the EFI conout function which sent the output to whatever
the UEFI ConOut variable was set to. In fact, we totally ignored that
variable and people had to manually hack together something to try to make
things match the variable so the kernel messages would work. There is
another vector to pass arguments to /boot/loader.efi, and that's efibootmgr
can set args to use that are passed to main w/o needing to read boot.conf
at all.

So, now that loader.efi is starting up, and we'd like to have verbose
output before we select the root filesystem from which we could get the
boot.conf to know where to send this output, I'd like to shift things a
little. Since we already have almost all the information we need from the
uefi boot variable, I'd like to stop parsing boot.conf and shift to using
that. I'd like to make the ConOut variable override the command args passed
in.

So, the new process will be:
1. Parse the args. Get a tentative howto.
2. Look at ConOut. If it's set, then we mask off RB_MULTIPLE and RB_SERIAL.
If we find a video card in the list, we'll use it. If we find serial in the
list, we'll use that and set RB_SERIAL. If we find both, we'll set
RB_MUTLIPLE and RB_SERIAL. If we find serial, and it has a speed, we'll set
comconsole_speed.
3. We'll parse loader.conf
4. Just before we boot, if we have the 'efi' console set and serial was set
in the ConOut variable, we'll set hw.uart.console to reflect the speed and
the value of comconsole_port[*].

This will result in serial consoles just working almost all the time w/o
needing to do anything. The 'almost' part here is because to find the
serial port, we have to walk the ACPI name space to find the _CRS that
matches the _HID for the serial port. We're given the _UID, but that's just
a number whose meaning varies to the point of it being random. While we
know that _UID X will refer to the same port from boot to boot, we have no
clue what that is on any given board. To work around this, people with
non-standard console ports (which everybody with a BMC likely has), you'll
need to set comconsole_port in loader.conf. Of course, you'll have had to
do that today to make this setup work, so that's nothing new. In the
fullness of time, but not for 12, we should just parse ACPI in the UEFI
boot loader. This is somewhat non-trivial since we have to write the OS
glue for the ACPICA code to have it work in the UEFI environment. I've not
investigated doing that in any more detail than to see there's no quick,
easy shortcuts.

So here's my open questions:
(1) Do I need to parse boot.conf? If so, do I violate POLA by parsing the
one that's on the ESP or the one in the / we hope to boot from. What if I
don't find a /? I am leaning to a 'hard no' on this question because the
efibootmgr provides a vector to get command line args to loader.efi that's
much better. boot.conf was a hack around the fact you couldn't set command
line args in the legacy bios.
(2) Should the command line args passed in take precedence? Or should
ConOut? Or should ConOut be used first with the command line args
augmenting it?
(3) Should we set RB_MULTIPLE | RB_SERIAL unconditionally with we have both
video and serial? Or should we only set RB_MULTIPLE? Or should we check the
command line args and only set RB_SERIAL in this case when -h is on the
command line, like we do today. The downstream effect of this choses where
THE console of the kernel goes until someone writes a some ttymux code to
allow it to go to all the consoles requested by the boot loader.

My current code is up at https://reviews.freebsd.org/D15917 if you want to
look. As always, what to do comments should likely go here, while 'this
code sucks, here's how to make it better' type comments should go on the
review.

Warner

Warner

[Ravi Pokala]

To work around this, people with non-standard console ports (which everybody with a BMC likely has),

What makes you say that?

On most (all?) systems with IPMI that I've seen, the motherboard console port is a normal UART. It just so happens that the UART isn't connected to a DB9 header, but rather to the serial port on the BMC. The firmware on the BMC (somehow -- reading the BIOS/UEFI settings directly?) knows the configuration of the motherboard console port, and configures its side to match. And there you go: a serial connection between the motherboard console port and the BMC.

What the BMC then does with it -- reflect it over the network using Serial-Over-LAN, expose it via a web interface, etc. -- is a separate matter entirely.

-Ravi (rpokala@)

-----Original Message-----
From: <owner-freebsd-***@freebsd.org> on behalf of Warner Losh <***@bsdimp.com>
Date: 2018-06-22, Friday at 08:47
To: "freebsd-***@freebsd.org" <***@freebsd.org>
Subject: UEFI Plans / Shifts -- RFC

Greetings,
As I've documented before, I'll be making some addition UEFI changes.
1. Remove boot1.efi
2. Enhance loader.efi so it can live on ESP
3. Enhance loader.efi so it can do ping-pong booting
1 is still the plan, but there's some bits left to do. Most of step 2 is
done. However, there's some issues that I'd like to work through. 3 is my
next task. There's other installer and installworld tasks that are needed
before 1 can be done.
In the past boot1.efi chose the /, read /boot/config or /boot.config and
passed those args to /boot/loader.efi. This was always an imperfect match
to UEFI, since we selected video/serial/both and other things for the
kernel, but used the EFI conout function which sent the output to whatever
the UEFI ConOut variable was set to. In fact, we totally ignored that
variable and people had to manually hack together something to try to make
things match the variable so the kernel messages would work. There is
another vector to pass arguments to /boot/loader.efi, and that's efibootmgr
can set args to use that are passed to main w/o needing to read boot.conf
at all.
So, now that loader.efi is starting up, and we'd like to have verbose
output before we select the root filesystem from which we could get the
boot.conf to know where to send this output, I'd like to shift things a
little. Since we already have almost all the information we need from the
uefi boot variable, I'd like to stop parsing boot.conf and shift to using
that. I'd like to make the ConOut variable override the command args passed
in.
1. Parse the args. Get a tentative howto.
2. Look at ConOut. If it's set, then we mask off RB_MULTIPLE and RB_SERIAL.
If we find a video card in the list, we'll use it. If we find serial in the
list, we'll use that and set RB_SERIAL. If we find both, we'll set
RB_MUTLIPLE and RB_SERIAL. If we find serial, and it has a speed, we'll set
comconsole_speed.
3. We'll parse loader.conf
4. Just before we boot, if we have the 'efi' console set and serial was set
in the ConOut variable, we'll set hw.uart.console to reflect the speed and
the value of comconsole_port[*].
This will result in serial consoles just working almost all the time w/o
needing to do anything. The 'almost' part here is because to find the
serial port, we have to walk the ACPI name space to find the _CRS that
matches the _HID for the serial port. We're given the _UID, but that's just
a number whose meaning varies to the point of it being random. While we
know that _UID X will refer to the same port from boot to boot, we have no
clue what that is on any given board. To work around this, people with
non-standard console ports (which everybody with a BMC likely has), you'll
need to set comconsole_port in loader.conf. Of course, you'll have had to
do that today to make this setup work, so that's nothing new. In the
fullness of time, but not for 12, we should just parse ACPI in the UEFI
boot loader. This is somewhat non-trivial since we have to write the OS
glue for the ACPICA code to have it work in the UEFI environment. I've not
investigated doing that in any more detail than to see there's no quick,
easy shortcuts.
(1) Do I need to parse boot.conf? If so, do I violate POLA by parsing the
one that's on the ESP or the one in the / we hope to boot from. What if I
don't find a /? I am leaning to a 'hard no' on this question because the
efibootmgr provides a vector to get command line args to loader.efi that's
much better. boot.conf was a hack around the fact you couldn't set command
line args in the legacy bios.
(2) Should the command line args passed in take precedence? Or should
ConOut? Or should ConOut be used first with the command line args
augmenting it?
(3) Should we set RB_MULTIPLE | RB_SERIAL unconditionally with we have both
video and serial? Or should we only set RB_MULTIPLE? Or should we check the
command line args and only set RB_SERIAL in this case when -h is on the
command line, like we do today. The downstream effect of this choses where
THE console of the kernel goes until someone writes a some ttymux code to
allow it to go to all the consoles requested by the boot loader.
My current code is up at https://reviews.freebsd.org/D15917 if you want to
look. As always, what to do comments should likely go here, while 'this
code sucks, here's how to make it better' type comments should go on the
review.
Warner
Warner
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-arch

[Warner Losh]

Post by Warner Losh

To work around this, people with non-standard console ports (which

everybody with a BMC likely has),
What makes you say that?
On most (all?) systems with IPMI that I've seen, the motherboard console
port is a normal UART. It just so happens that the UART isn't connected to
a DB9 header, but rather to the serial port on the BMC. The firmware on the
BMC (somehow -- reading the BIOS/UEFI settings directly?) knows the
configuration of the motherboard console port, and configures its side to
match. And there you go: a serial connection between the motherboard
console port and the BMC.
What the BMC then does with it -- reflect it over the network using
Serial-Over-LAN, expose it via a web interface, etc. -- is a separate
matter entirely.

I mean that the BMC is almost never connected to COM1, at least for the
sampling of motherboards I've had to deal with in the past 5 years. The
standard port is COM1 for debugging. Everything else you have to set an
address for.

Warner

Post by Warner Losh
-----Original Message-----
Date: 2018-06-22, Friday at 08:47
Subject: UEFI Plans / Shifts -- RFC

Greetings,
As I've documented before, I'll be making some addition UEFI changes.
1. Remove boot1.efi
2. Enhance loader.efi so it can live on ESP
3. Enhance loader.efi so it can do ping-pong booting
1 is still the plan, but there's some bits left to do. Most of step 2 is
done. However, there's some issues that I'd like to work through. 3 is my
next task. There's other installer and installworld tasks that are needed
before 1 can be done.
In the past boot1.efi chose the /, read /boot/config or /boot.config and
passed those args to /boot/loader.efi. This was always an imperfect match
to UEFI, since we selected video/serial/both and other things for the
kernel, but used the EFI conout function which sent the output to

whatever

the UEFI ConOut variable was set to. In fact, we totally ignored that
variable and people had to manually hack together something to try to

make

things match the variable so the kernel messages would work. There is
another vector to pass arguments to /boot/loader.efi, and that's

efibootmgr

can set args to use that are passed to main w/o needing to read boot.conf
at all.
So, now that loader.efi is starting up, and we'd like to have verbose
output before we select the root filesystem from which we could get the
boot.conf to know where to send this output, I'd like to shift things a
little. Since we already have almost all the information we need from the
uefi boot variable, I'd like to stop parsing boot.conf and shift to using
that. I'd like to make the ConOut variable override the command args

passed

in.
1. Parse the args. Get a tentative howto.
2. Look at ConOut. If it's set, then we mask off RB_MULTIPLE and

RB_SERIAL.

If we find a video card in the list, we'll use it. If we find serial in

the

list, we'll use that and set RB_SERIAL. If we find both, we'll set
RB_MUTLIPLE and RB_SERIAL. If we find serial, and it has a speed, we'll

set

comconsole_speed.
3. We'll parse loader.conf
4. Just before we boot, if we have the 'efi' console set and serial was

set

in the ConOut variable, we'll set hw.uart.console to reflect the speed

and

the value of comconsole_port[*].
This will result in serial consoles just working almost all the time w/o
needing to do anything. The 'almost' part here is because to find the
serial port, we have to walk the ACPI name space to find the _CRS that
matches the _HID for the serial port. We're given the _UID, but that's

just

a number whose meaning varies to the point of it being random. While we
know that _UID X will refer to the same port from boot to boot, we have

no

clue what that is on any given board. To work around this, people with
non-standard console ports (which everybody with a BMC likely has),

you'll

need to set comconsole_port in loader.conf. Of course, you'll have had to
do that today to make this setup work, so that's nothing new. In the
fullness of time, but not for 12, we should just parse ACPI in the UEFI
boot loader. This is somewhat non-trivial since we have to write the OS
glue for the ACPICA code to have it work in the UEFI environment. I've

not

investigated doing that in any more detail than to see there's no quick,
easy shortcuts.
(1) Do I need to parse boot.conf? If so, do I violate POLA by parsing the
one that's on the ESP or the one in the / we hope to boot from. What if I
don't find a /? I am leaning to a 'hard no' on this question because the
efibootmgr provides a vector to get command line args to loader.efi

that's

much better. boot.conf was a hack around the fact you couldn't set

command

line args in the legacy bios.
(2) Should the command line args passed in take precedence? Or should
ConOut? Or should ConOut be used first with the command line args
augmenting it?
(3) Should we set RB_MULTIPLE | RB_SERIAL unconditionally with we have

both

video and serial? Or should we only set RB_MULTIPLE? Or should we check

the

command line args and only set RB_SERIAL in this case when -h is on the
command line, like we do today. The downstream effect of this choses

where

THE console of the kernel goes until someone writes a some ttymux code to
allow it to go to all the consoles requested by the boot loader.
My current code is up at https://reviews.freebsd.org/D15917 if you want

to

look. As always, what to do comments should likely go here, while 'this
code sucks, here's how to make it better' type comments should go on the
review.
Warner
Warner
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-arch

[Poul-Henning Kamp]

--------

Post by Warner Losh
(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.

[Konstantin Belousov]

Post by Poul-Henning Kamp
--------

Post by Warner Losh
(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.

[Warner Losh]

Post by Poul-Henning Kamp
--------

gmail.com>

Post by Poul-Henning Kamp

Post by Warner Losh
(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.

Warner

[Konstantin Belousov]

Post by Warner Losh

Post by Poul-Henning Kamp
--------

gmail.com>

Post by Poul-Henning Kamp

Post by Warner Losh
(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 ?

[Warner Losh]

On Mon, Jun 25, 2018 at 3:18 AM, Konstantin Belousov <

Post by Poul-Henning Kamp
--------
In message <CANCZdfoMZXJu2nRbAtLTPc1B4YWWb

gmail.com>

Post by Poul-Henning Kamp

Post by Warner Losh
(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

[Poul-Henning Kamp]

--------

Post by Warner Losh
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.

In the very special case of the installer, how hard would it be to
give loader.efi a compiletime option of "All serial ports and video" ?

[Warner Losh]

Post by Poul-Henning Kamp
--------
gmail.com>

Post by Warner Losh
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.

In the very special case of the installer, how hard would it be to
give loader.efi a compiletime option of "All serial ports and video" ?

There's much diversity here. There's 4 choices at standard addresses, plus
PCI options and a few non-standard choices (though some of those are really
PCI). And people often connect other things to their serial ports, so
blasting all of them may be unwise if you have a 'sealed box' that you then
do a serial install on. Is it possible? Sure. I'm just not sure it's wise.
We tried something similar recently with the GELI boot blocks and it broke
a lot of people.

Warner

[Konstantin Belousov]

Post by Warner Losh

On Mon, Jun 25, 2018 at 3:18 AM, Konstantin Belousov <

Post by Poul-Henning Kamp
--------
In message <CANCZdfoMZXJu2nRbAtLTPc1B4YWWb

gmail.com>

Post by Poul-Henning Kamp

Post by Warner Losh
(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.

Post by Warner Losh
The UEFI boot variable ConOut gives us a device which rendered to human
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
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
uart0 pnpinfo _HID=PNP0501 _UID=0 at handle=\_SB_.PC00.LPC0.UAR1
uart2 pnpinfo _HID=PNP0501 _UID=1 at handle=\_SB_.PC00.LPC0.UAR2
uart0 pnpinfo _HID=PNP0501 _UID=0 at handle=\_SB_.PCI0.LPC0.UAR1
uart1 pnpinfo _HID=PNP0501 _UID=1 at handle=\_SB_.PCI0.LPC0.UAR2
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
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