UEFI Plans / Shifts -- RFC

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: UEFI Plans / Shifts -- RFC

Ravi Pokala-3
> 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: <[hidden email]> on behalf of Warner Losh <[hidden email]>
Date: 2018-06-22, Friday at 08:47
To: "[hidden email]" <[hidden email]>
Subject: UEFI Plans / Shifts -- RFC

> 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
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "[hidden email]"


_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: UEFI Plans / Shifts -- RFC

Warner Losh
On Fri, Jun 22, 2018 at 12:18 PM, Ravi Pokala <[hidden email]> wrote:

> > 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


> -Ravi (rpokala@)
>
> -----Original Message-----
> From: <[hidden email]> on behalf of Warner Losh <
> [hidden email]>
> Date: 2018-06-22, Friday at 08:47
> To: "[hidden email]" <[hidden email]>
> Subject: UEFI Plans / Shifts -- RFC
>
> > 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
> > _______________________________________________
> > [hidden email] mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-arch
> > To unsubscribe, send any mail to "[hidden email]"
>
>
>
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: UEFI Plans / Shifts -- RFC

Poul-Henning Kamp
In reply to this post by Warner Losh
--------
In message <[hidden email]>
, 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.

--
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[hidden email]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: UEFI Plans / Shifts -- RFC

Konstantin Belousov
On Mon, Jun 25, 2018 at 09:01:34AM +0000, Poul-Henning Kamp wrote:
> --------
> In message <[hidden email]>
> , 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.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: UEFI Plans / Shifts -- RFC

Warner Losh
On Mon, Jun 25, 2018 at 3:18 AM, Konstantin Belousov <[hidden email]>
wrote:

> On Mon, Jun 25, 2018 at 09:01:34AM +0000, Poul-Henning Kamp wrote:
> > --------
> > In message <CANCZdfoMZXJu2nRbAtLTPc1B4YWWbxsHQjX31zOo+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.

Warner
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: UEFI Plans / Shifts -- RFC

Konstantin Belousov
On Mon, Jun 25, 2018 at 07:37:19AM -0600, Warner Losh wrote:

> On Mon, Jun 25, 2018 at 3:18 AM, Konstantin Belousov <[hidden email]>
> wrote:
>
> > On Mon, Jun 25, 2018 at 09:01:34AM +0000, Poul-Henning Kamp wrote:
> > > --------
> > > In message <CANCZdfoMZXJu2nRbAtLTPc1B4YWWbxsHQjX31zOo+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 ?
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: UEFI Plans / Shifts -- RFC

Warner Losh
On Mon, Jun 25, 2018 at 9:47 AM, Konstantin Belousov <[hidden email]>
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 <
> [hidden email]>
> > 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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: UEFI Plans / Shifts -- RFC

Poul-Henning Kamp
--------
In message <[hidden email]>
, Warner Losh writes:

>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" ?

--
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[hidden email]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: UEFI Plans / Shifts -- RFC

Warner Losh
On Mon, Jun 25, 2018 at 11:40 AM, Poul-Henning Kamp <[hidden email]>
wrote:

> --------
> In message <CANCZdfrHfJ23QEbtDb0VVSeakabyUKJyn_6nkGwObr2K_+YYzA@mail.
> gmail.com>
> , Warner Losh writes:
>
> >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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: UEFI Plans / Shifts -- RFC

Konstantin Belousov
In reply to this post by Warner Losh
On Mon, Jun 25, 2018 at 11:25:53AM -0600, Warner Losh wrote:

> On Mon, Jun 25, 2018 at 9:47 AM, Konstantin Belousov <[hidden email]>
> 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 <
> > [hidden email]>
> > > 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.
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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"