UEFI Plans / Shifts -- RFC

Fri Jun 22 18:18:11 UTC 2018

> 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-arch at freebsd.org> on behalf of Warner Losh <imp at bsdimp.com>
Date: 2018-06-22, Friday at 08:47
To: "freebsd-arch at freebsd.org" <arch at freebsd.org>
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
> _______________________________________________
> freebsd-arch at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"