Bug 265980 - memstick image defaults to serial console on Asus PRIME Z690-P D4 / i7-12700 system - EFI FW does not set ConOut variable
Summary: memstick image defaults to serial console on Asus PRIME Z690-P D4 / i7-12700 ...
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: misc (show other bugs)
Version: 13.1-RELEASE
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-bugs (Nobody)
URL:
Keywords: uefi
Depends on:
Blocks:
 
Reported: 2022-08-21 17:19 UTC by Ed Maste
Modified: 2023-05-17 23:38 UTC (History)
6 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ed Maste freebsd_committer 2022-08-21 17:19:43 UTC
I acquired a Intel i7-12700 and Asus PRIME Z690-P D4 motherboard for P/E core experimentation, and tried installing from a memstick snapshot image
FreeBSD-14.0-CURRENT-amd64-20220819-545db925c3d-257513-memstick.img.xz

On my first attempt I see the screen blank after the loader, and then a short while later a block cursor appear in the upper left hand corner.  Nothing else happens.

The port has an onboard COM header but I had no cable. After acquiring one I see that the system defaulted to a primary serial console at 115200. The video console was unresponsive because the serial console was waiting at:

Welcome to FreeBSD!

Please choose the appropriate terminal type for your system.
Common console types are:
   ansi     Standard ANSI terminal
   vt100    VT100 or compatible terminal
   xterm    xterm terminal emulator (or compatible)
   cons25w  cons25w terminal

Console type [vt100]:
Comment 1 Ed Maste freebsd_committer 2022-08-21 17:21:38 UTC
Also, if I manually run "console=comconsole" from the loader I get a console at 9600 baud, for both the loader and kernel.

If I don't interact with the loader at all the serial port has no activity until the kernel starts, and the serial console is at 115200.
Comment 2 Ed Maste freebsd_committer 2022-08-21 17:26:07 UTC
FreeBSD-13.1-RELEASE-amd64-memstick.img.xz behaves the same way.
Comment 3 Ed Maste freebsd_committer 2022-08-21 17:30:20 UTC
kenv | grep cons shows:

comconsole_pcidev=""
comconsole_port="1016"
comconsole_speed="9600"
console="efi"
Comment 4 Ed Maste freebsd_committer 2022-08-21 17:58:58 UTC
Similar issue was reported on the mailing list last year:
https://lists.freebsd.org/archives/freebsd-stable/2021-October/000249.html
Comment 5 Ed Maste freebsd_committer 2022-08-21 18:01:19 UTC
# efivar | grep -- -Con | xargs efivar --device-path
8be4df61-93ca-11d2-aa0d-00e098032b8c-ConIn
: PciRoot(0x0)/Pci(0x1f,0x0)/Acpi(PNP0303,0x0),/PciRoot(0x0)/Pci(0x14,0x0)/USB(0x5,0x1),/PciRoot(0x0)/Pci(0x14,0x0)/USB(0x8,0x0),/PciRoot(0x0)/Pci(0x14,0x0)/USB(0x8,0x1)

8be4df61-93ca-11d2-aa0d-00e098032b8c-ConInDev
: PciRoot(0x0)/Pci(0x1f,0x0)/Acpi(PNP0303,0x0),/PciRoot(0x0)/Pci(0x14,0x0)/USB(0x5,0x1),/PciRoot(0x0)/Pci(0x14,0x0)/USB(0x8,0x0),/PciRoot(0x0)/Pci(0x14,0x0)/USB(0x8,0x1)

#
Comment 6 Ed Maste freebsd_committer 2022-08-21 18:17:49 UTC
If I disable the UART in the firmware settings the kernel output is visible on the monitor, but the system hangs after (boot -v):

pcib0: allocated type 4 (0x3f8-0x3f8) for rid 0 of uart0
Comment 7 Ed Maste freebsd_committer 2022-08-21 19:57:43 UTC
Discussed with manu on IRC, suggested path forward is to look for GOP modes and default to serial only in the case that there is no ConOut and the mode list is empty.
Comment 8 Ed Maste freebsd_committer 2022-08-21 23:04:57 UTC
Related commit:

commit 14fb9485a4dc9c8212bfae6c2049cb4930f4b8e5
Author: Emmanuel Vadot <manu@FreeBSD.org>
Date:   Fri Nov 8 20:08:44 2019 +0000

    loader.efi: Default to serial if we don't have a ConOut variable
    
    In the EFI implementation in U-Boot no ConOut efi variable is created,
    this cause loader to fallback to TERM_EMU implementation which is very
    very very slow (and uses the ConOut device in the system table anyway).
    The UEFI spec aren't clear as if this variable needs to exists or not.
    
    Reviewed by:    imp, kevans

Notes:
    svn path=/head/; revision=354559

diff --git a/stand/efi/loader/main.c b/stand/efi/loader/main.c
index c5d664dce65e..641cc7154f13 100644
--- a/stand/efi/loader/main.c
+++ b/stand/efi/loader/main.c
@@ -703,8 +703,11 @@ parse_uefi_con_out(void)
        how = 0;
        sz = sizeof(buf);
        rv = efi_global_getenv("ConOut", buf, &sz);
-       if (rv != EFI_SUCCESS)
+       if (rv != EFI_SUCCESS) {
+               /* If we don't have any ConOut default to serial */
+               how = RB_SERIAL;
                goto out;
+       }
        ep = buf + sz;
        node = (EFI_DEVICE_PATH *)buf;
        while ((char *)node < ep) {
Comment 9 Ed Maste freebsd_committer 2022-08-23 15:09:20 UTC
See imp's https://reviews.freebsd.org/D36299
Comment 10 Ed Maste freebsd_committer 2022-09-16 13:54:41 UTC
commit df065f699f1ff819bb9607c44a6754275ab335ed
Author: Warner Losh <imp@FreeBSD.org>
Date:   Fri Aug 26 15:46:33 2022 -0600

    stand: More sensible defaults when ConOut is missing
    
    When ConOut is missing, we used to default to serial. Except we did it
    in the worst way possible by just setting the howto bits and not
    updating the console setting, which lead to weird behavior where we'd
    get some things on the video port, others on serial.
    
    Instead, set console to "efi,comconsole" for this case. Also set
    RB_MULTIPLE always (so we get dual consoles from the kernel) and or in
    RB_SERIAL when we can't find GOPs that suggest the precense of a video
    console. This will put output in the most places and have a sensible
    default for 'primary' console.
    
    Sponsored by:           Netflix
    Reviewed by:            emaste, manu
    Differential Revision:  https://reviews.freebsd.org/D36299
Comment 11 Ed Maste freebsd_committer 2022-09-16 13:56:29 UTC
Warner discussed a potentially better approach: we could check ConIn next, and leave the RB_MULTIPLE / RB_MULTIPLE | RB_SERIAL fallback only for the case that neither lets us determine the proper console.
Comment 12 Warner Losh freebsd_committer 2022-09-16 17:34:31 UTC
(In reply to Ed Maste from comment #11)

Yes. My plan is to implement that once I have $COOL_HARDWARE working on a different project.
Comment 13 Michael Gmelin freebsd_committer 2022-10-17 10:06:48 UTC
(In reply to Ed Maste from comment #11)

I was hit by this the other way round (a system that was provided with the serial port disabled and I was scratching my head, why booting got stuck at uart0). So this PR was very helpful to me.

I wonder if it would be possible to change things, so booting with the serial port disabled would work? (I tried something like hint.uart.0.disabled=1, which made the boot process continue just a little bit further).

See also: https://github.com/depenguin-me/mfsbsd-13.1-script/issues/57#issuecomment-1280604676
Comment 14 Ed Maste freebsd_committer 2023-02-24 21:11:59 UTC
stable/13

commit f80cdedebe9f10fe0e7cb0548c1ead0237c37d06
Author: Warner Losh <imp@FreeBSD.org>
Date:   Fri Aug 26 15:46:33 2022 -0600

    stand: More sensible defaults when ConOut is missing
    
    When ConOut is missing, we used to default to serial. Except we did it
    in the worst way possible by just setting the howto bits and not
    updating the console setting, which lead to weird behavior where we'd
    get some things on the video port, others on serial.
    
    Instead, set console to "efi,comconsole" for this case. Also set
    RB_MULTIPLE always (so we get dual consoles from the kernel) and or in
    RB_SERIAL when we can't find GOPs that suggest the precense of a video
    console. This will put output in the most places and have a sensible
    default for 'primary' console.
    
    Sponsored by:           Netflix
    Reviewed by:            emaste, manu
    Differential Revision:  https://reviews.freebsd.org/D36299
    
    (cherry picked from commit df065f699f1ff819bb9607c44a6754275ab335ed)

and is included in 13.2