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]:
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.
FreeBSD-13.1-RELEASE-amd64-memstick.img.xz behaves the same way.
kenv | grep cons shows: comconsole_pcidev="" comconsole_port="1016" comconsole_speed="9600" console="efi"
Similar issue was reported on the mailing list last year: https://lists.freebsd.org/archives/freebsd-stable/2021-October/000249.html
# 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) #
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
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.
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) {
See imp's https://reviews.freebsd.org/D36299
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
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.
(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.
(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
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