uefi stand: Guess the console better

[imp]

Summary

For server machines, ComOut is set to the set of devices that the efi
console suppots. Parse it to see if we have serial, video or both.
Make that take precidence over the command line args. boot1.efi parses
them, but loader.efi doesn't. It's not clear where to read boot.conf
from, so we don't do that. The command line args can still be set via
efibootmgr, which is more inline with the UEFI boot manager to replace
that. These args are typically used only to set serial vs video and
the com speed line. We can infer that from ComOut, so do so.

RelNotes: yes

[kevans]

stand/efi/loader/main.c

586

Are we eventually going to do something with the com_speed, other than write to it just for printf sake?

[imp]

stand/efi/loader/main.c

586

I hope so. We should set hw.uart.console based on this. However, we're missing bits to do that. If comconsole_pcidev is set, we need to find it one way. If we have comconsole_port set, we know directly. Trouble is, both of these variables are set later so we can't count on them here. And they are only set for comconsole, console not efi console. We could get this information from ACPI, but that's a tree walk, and I'm not really keen to include that.

We likely could do something in the EFI console to export this information, since I think it's set late enough to peek at these variables. But even that looks to be tricky w/o some careful study.

So, enshrine the code here for now, and work on exporting it in a follow on commit.

[imp]

I've updated things to be better. We set the baud rate in the environment, and then just before we boot, and we're a EFI console, we get it and some other things to try to piece together the right hw.uart.console value to set if we're booting serial and we are the EFI console.

[kevans]

stand/efi/loader/main.c

75

This seems to have snuck in unused

[imp]

stand/efi/loader/main.c

75

Yea, it's a merge error from a later patch.

[jhb]

stand/efi/loader/main.c

599

I think setting both means that serial is preferred which may be surprising for folks if a normal desktop box advertises both serial and video as the console as this will effectively turn off the video console post-boot.

(See shenanigans related to RB_SERIAL handling in stand/boot/i386/libi386/bootinfo.c where RB_SERIAL is turned off if "vidconsole" is first)

664

Debug?

689

Perhaps rather than RB_RESERVED1 have parse_uefi_con_out() return a boolean and accept howto by reference:

if (parse_uefi_con_out(&howto)) {
    setenv("console", "efi", 1);
} else {
    /* existing code to set "console" */
}
bootenv_set(howto);

This would move the merging into parse_uefi_con_out() by having it construct the temporary it already does and then do the merge stuff before 'return (true)' or the like. I think the code flow would be simpler and read better (and avoid abusing RB_RESERVED1).

743

Unrelated?

[imp]

stand/efi/loader/main.c

599

Correct. However, there's no way to know which is first at this point...

This does, however, make the kernel messages actually appear on both, which is what we want in this case.

The real solution, however, is to support a real /dev/constty that is the union of all the active ttys.

664

yea...

689

I'd dispute it's an abuse: it's supposed to be fore a boot loader defined purpose :)

But it wouldn't be a bad restructure.

743

Yes and no. We never should have set this.

[imp]

Review feedback and fix overrides

[jhb]

I think this is ok as far as I can tell.

stand/efi/loader/main.c

663

Mix of '#define<space>' vs '#define<tab>' (style(9) is to use tab)?

[imp]

Style changes from john, collapse if statement one layer

[imp]

last cleanup... Will put through it's paces in a new couple places then commit.

stand/efi/loader/main.c

663

Fixed.