On 3/18/2020 10:29 PM, Toomas Soome via svn-src-head wrote: > > >> On 18. Mar 2020, at 18:40, Ruslan Garipov <brigadi...@gmail.com> wrote: >> >> On 3/17/2020 5:16 PM, Tomoaki AOKI wrote: >>> Hi! Thanks for your respond. >>> >>> Unfortunately, no. >>> I'm running on ThinkPad P52, which has no com connector installed. >>> No USB serial interface connected. >>> >>> `efi-show -g global -v ConOut` on loader prompt shows >>> >>> global NV,BS,RS ConOut = >>> PciRoot(0,0)/Pci((0x1,oxo)/Pci(0x0,0x0)/AcpiAdr(0x80010100) >>> >>> Moreover, my previous idea didn't help. >>> >>> Neither >>> console="vidconsole" >>> console="eficonsole" >>> console="efi_console" >>> nor >>> console="efi" >>> in /boot/loader.conf works. >>> >>> Defining / undefining TERM_EMU on build are untested. >>> >>> Is there any setting for /boot/loader.conf to control the behavior? >>> >>> >>> Regards. >>> >>> >>> On Mon, 16 Mar 2020 08:26:56 +0200 >>> Toomas Soome <tso...@me.com> wrote: >>> >>>> Hi! >>>> >>>> This means, your system has UART serial device 〓 you can check this from >>>> loader prompt: efi-show -g global -v ConOut or with efivar from running >>>> system. This w ould trigger efi console driver to use >>>> TERM_EMU, which can be turned off by user and doing that would cause ESC >>>> sequences to be passed directly to console. Might that be true in your >>>> case? >>>> >>>> rgds, >>>> toomas >>>> >>>>> On 15. Mar 2020, at 17:17, Tomoaki AOKI <junch...@dec.sakura.ne.jp> wrote: >>>>> >>>>> Hi. >>>>> >>>>> This broke loader menu display on efifb. At least on amd64. >>>>> ESC sequences without ESC character are shown. >>>>> Key input (at least 1, 2 and enter) works OK. >>>>> I suspect outputs for SIO is sent to efifb and ESC codes are ignored. >>>>> >>>>> Reverting this fixes the issue. >> I got the same issue with loader menu when was upgrading from r358827 to >> r359028 (x86-64). >> >> But unfortunately the broken menu is just a part of my problem. The >> real pain is that a FreeBSD 13.0-CURRENT system hosted by VMware ESXi or >> Workstation doesn't boot anymore after r358989. An ugly workaround[1] >> (exiting from the loader menu into the loader prompt, running ls or >> show, scrolling the result down and then executing boot) I found some >> time ago doesn't work anymore. After running boot/boot -s/selecting >> menu item, a hypervisor just shuts session down with the following >> message: ``The firmware encountered an unexpected exception. The virtual >> machine cannot boot.'' >> >> The virtual guests don't have any UART (even USB) serial devices in >> their settings. efi-show prints result similar to what Tomoaki got: >> >> OK efi-show -g global -v CounOut >> global NV,BS,RS ConOut = PciRoot(0x0)/Pci(0x2,0x0)/AcpiAdr(0x80014310) >> >> Undefining TERM_EMU doesn't help. I had completely removed CFLAGS >> assignment with TERM_EMU from stand/efi/libefi/Makefile and rebuilt >> kernel/world -- nothing changed. I don't define TERM_EMU in my >> make.conf or/and src.conf. >> >> Reverting this revision fix booting (and menu, of course). >> >> FreeBSD on physical hardware boots just fine with this revision, but has >> corrupted loader menu. >> >> Toomas, please help us to fix this. I can live with the broken menu, >> but I don't want to revert this revision every time I will upgrade my >> virtual machines after r359028 now. > > > Hi! > > The build, are you doing build with -DNO_CLEAN? or can you run make clean in > stand and then build it again? Otherwise, if you can poke me on irc, I’d like > to get to the bottom of this. Hello!
I'm sorry, currently I have no access to either IRC, nor my build machine. Therefore, I can't show you the build log. NO_CLEAN -- no, I don't use it. What I've actually done regarding to testing TERM_EMU: I removed `CFLAGS+= -DTERM_EMU` (and the .if condition wrapping this line) from the Makefile, removed /usr/obj directory, and buildworld and buildkernel then. And then install rebuilt kernel/userland on a target machine. Nothing changed, but it should? > > Regarding the issue with vm, I am afraid the roots are going much deeper > there. I have not got to the exact cause (and therefore a fix), but the > problem is not about this specific patch. The problem is about memory map, > specifically one just before and after we switch off Boot Services. That's a very bad news for me. Looking at HEAD's commit list I hope that's a known problem? Or should I open a PR on bugs.FreeBSD.org? Moreover, I believe the next snapshot of the CURRENT (which will be made after r358989) made by the release team will be unbootable on VMware hypervisors. > > rgds, > toomas > > >> >> [1] >> https://old.reddit.com/r/freebsd/comments/drxqlm/failed_to_do_efi_boot_on_a_vmware_virtual_machine/f6om6p2/ >> >> <https://old.reddit.com/r/freebsd/comments/drxqlm/failed_to_do_efi_boot_on_a_vmware_virtual_machine/f6om6p2/> >>>>> >>>>> Not tried (not enough time for now as I'm mainly using stable/12), >>>>> but possibly calling efi_cons_probe() from efi_cons_init() would be >>>>> needed, as ome codes are moved from the latter to the former. >>>>> >>>>> >>>>>> Author: tsoome >>>>>> Date: Sat Mar 14 06:36:03 2020 >>>>>> New Revision: 358989 >>>>>> URL: https://svnweb.freebsd.org/changeset/base/358989 >>>>>> >>>>>> Log: >>>>>> loader: add comconsole implementation on top of SIO protocol >>>>>> >>>>>> Provide comconsole on top of SIO for arm platforms (x86 does use bios >>>>> version). >>>>>> >>>>>> Added: >>>>>> head/stand/efi/loader/efiserialio.c (contents, props changed) >>>>>> Modified: >>>>>> head/stand/efi/libefi/efi_console.c >>>>>> head/stand/efi/loader/arch/arm/Makefile.inc >>>>>> head/stand/efi/loader/arch/arm64/Makefile.inc >>>>>> head/stand/efi/loader/conf.c >>>>>> head/stand/efi/loader/main.c >>>>>> >>>>>> Modified: head/stand/efi/libefi/efi_console.c >>>>>> ============================================================================== >>>>>> --- head/stand/efi/libefi/efi_console.c Sat Mar 14 05:57:22 >>>>> 2020 (r358988) >>>>>> +++ head/stand/efi/libefi/efi_console.c >>>>> Sat Mar 14 06:36:03 2020 (r358989) >>>>>> @@ -377,9 +377,22 @@ efi_cons_respond(void *s __unused, const void *buf >>>>>> __u >>>>>> { >>>>>> } >>>>>> >>>>>> +/* >>>>>> + * Set up conin/conout/coninex to make sure we have input ready. >>>>>> + */ >>>>>> static void >>>>>> efi_cons_probe(struct console *cp) >>>>>> { >>>>>> + EFI_STATUS status; >>>>>> + >>>>>> + conout = ST->ConOut; >>>>>> + conin = ST->ConIn; >>>>>> + >>>>>> + status = BS->OpenProtocol(ST->ConsoleInHandle, >>>>> &simple_input_ex_guid, >>>>>> + (void **)&coninex, IH, NULL, >>>>> EFI_OPEN_PROTOCOL_GET_PROTOCOL); >>>>>> + if (status != EFI_SUCCESS) >>>>>> + coninex = NULL; >>>>>> + >>>>>> cp->c_flags |= C_PRESENTIN | C_PRESENTOUT; >>>>>> } >>>>>> >>>>>> @@ -889,15 +902,7 @@ efi_cons_init(int arg) >>>>>> if (conin != NULL) >>>>>> return (0); >>>>>> >>>>>> - conout = ST->ConOut; >>>>>> - conin = ST->ConIn; >>>>>> - >>>>>> conout->EnableCursor(conout, TRUE); >>>>>> - status = BS->OpenProtocol(ST->ConsoleInHandle, >>>>> &simple_input_ex_guid, >>>>>> - (void **)&coninex, IH, NULL, >>>>> EFI_OPEN_PROTOCOL_GET_PROTOCOL); >>>>>> - if (status != EFI_SUCCESS) >>>>>> - coninex = NULL; >>>>>> - >>>>>> if (efi_cons_update_mode()) >>>>>> return (0); >>>>>> >>>>>> >>>>>> Modified: head/stand/efi/loader/arch/arm/Makefile.inc >>>>>> ============================================================================== >>>>>> --- head/stand/efi/loader/arch/arm/Makefile.inc Sat Mar 14 >>>>> 05:57:22 2020 (r358988) >>>>>> +++ head/stand/efi/loader/arch/arm/Makefile.inc Sat Mar 14 06:36:03 >>>>> 2020 (r358989) >>>>>> @@ -1,6 +1,7 @@ >>>>>> # $FreeBSD$ >>>>>> >>>>>> SRCS+= exec.c \ >>>>>> + efiserialio.c \ >>>>>> start.S >>>>>> >>>>>> HAVE_FDT=yes >>>>> >>>>> (Snip) >>>>> >>>>>> @@ -930,7 +936,6 @@ main(int argc, CHAR16 *argv[]) >>>>>> if (!has_kbd && (howto & RB_PROBE)) >>>>>> howto |= RB_SERIAL | RB_MULTIPLE; >>>>>> howto &= ~RB_PROBE; >>>>>> - uhowto = parse_uefi_con_out(); >>>>>> >>>>>> /* >>>>>> * Read additional environment variables from the boot device's >>>>> >>>>> -- >>>>> Tomoaki AOKI <junch...@dec.sakura.ne.jp> _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
