Date: Wed, 18 Mar 2020 23:41:49 +0500 From: Ruslan Garipov <brigadir15@gmail.com> To: Toomas Soome <tsoome@me.com> Cc: svn-src-head@freebsd.org, junchoon@dec.sakura.ne.jp Subject: Re: svn commit: r358989 - in head/stand/efi: libefi loader loader/arch/arm loader/arch/arm64 Message-ID: <944c641f-b570-1420-6b63-96374217d795@gmail.com> In-Reply-To: <EFDD40A1-3583-489A-9F4A-50BD19B5049E@me.com> References: <20200316001745.07df62f72d647b924b657d86@dec.sakura.ne.jp> <746EE981-536F-49AD-9B76-F9F103ECB1F9@me.com> <20200317211614.bbe1b18a32d7863941fffbe8@dec.sakura.ne.jp> <55b1f91b-6157-bfee-cd74-124ed50bc663@gmail.com> <EFDD40A1-3583-489A-9F4A-50BD19B5049E@me.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 3/18/2020 10:29 PM, Toomas Soome via svn-src-head wrote: > > >> On 18. Mar 2020, at 18:40, Ruslan Garipov <brigadir15@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 <tsoome@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 <junchoon@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 <junchoon@dec.sakura.ne.jp>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?944c641f-b570-1420-6b63-96374217d795>