Date: Wed, 18 Mar 2020 19:29:45 +0200 From: Toomas Soome <tsoome@me.com> To: Ruslan Garipov <brigadir15@gmail.com> Cc: junchoon@dec.sakura.ne.jp, svn-src-head@freebsd.org Subject: Re: svn commit: r358989 - in head/stand/efi: libefi loader loader/arch/arm loader/arch/arm64 Message-ID: <EFDD40A1-3583-489A-9F4A-50BD19B5049E@me.com> In-Reply-To: <55b1f91b-6157-bfee-cd74-124ed50bc663@gmail.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>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 18. Mar 2020, at 18:40, Ruslan Garipov <brigadir15@gmail.com> = wrote: >=20 > On 3/17/2020 5:16 PM, Tomoaki AOKI wrote: >> Hi! Thanks for your respond. >>=20 >> Unfortunately, no. >> I'm running on ThinkPad P52, which has no com connector installed. >> No USB serial interface connected. >>=20 >> `efi-show -g global -v ConOut` on loader prompt shows >>=20 >> global NV,BS,RS ConOut =3D >> PciRoot(0,0)/Pci((0x1,oxo)/Pci(0x0,0x0)/AcpiAdr(0x80010100) >>=20 >> Moreover, my previous idea didn't help. >>=20 >> Neither >> console=3D"vidconsole" >> console=3D"eficonsole" >> console=3D"efi_console" >> nor >> console=3D"efi" >> in /boot/loader.conf works. >>=20 >> Defining / undefining TERM_EMU on build are untested. >>=20 >> Is there any setting for /boot/loader.conf to control the behavior? >>=20 >>=20 >> Regards. >>=20 >>=20 >> On Mon, 16 Mar 2020 08:26:56 +0200 >> Toomas Soome <tsoome@me.com> wrote: >>=20 >>> Hi! >>>=20 >>> This means, your system has UART serial device =E3=80=93 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? >>>=20 >>> rgds, >>> toomas >>>=20 >>>> On 15. Mar 2020, at 17:17, Tomoaki AOKI <junchoon@dec.sakura.ne.jp> = wrote: >>>>=20 >>>> Hi. >>>>=20 >>>> 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. >>>>=20 >>>> Reverting this fixes the issue. > I got the same issue with loader menu when was upgrading from r358827 = to > r359028 (x86-64). >=20 > 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.'' >=20 > The virtual guests don't have any UART (even USB) serial devices in > their settings. efi-show prints result similar to what Tomoaki got: >=20 > OK efi-show -g global -v CounOut > global NV,BS,RS ConOut =3D = PciRoot(0x0)/Pci(0x2,0x0)/AcpiAdr(0x80014310) >=20 > 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. >=20 > Reverting this revision fix booting (and menu, of course). >=20 > FreeBSD on physical hardware boots just fine with this revision, but = has > corrupted loader menu. >=20 > 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=E2=80=99d like to get to the bottom of this. 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.=20= rgds, toomas >=20 > [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/> >>>>=20 >>>> 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. >>>>=20 >>>>=20 >>>>> Author: tsoome >>>>> Date: Sat Mar 14 06:36:03 2020 >>>>> New Revision: 358989 >>>>> URL: https://svnweb.freebsd.org/changeset/base/358989 >>>>>=20 >>>>> Log: >>>>> loader: add comconsole implementation on top of SIO protocol >>>>>=20 >>>>> Provide comconsole on top of SIO for arm platforms (x86 does use = bios >>>> version). >>>>>=20 >>>>> 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 >>>>>=20 >>>>> Modified: head/stand/efi/libefi/efi_console.c >>>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>> --- 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 >>>>> { >>>>> } >>>>>=20 >>>>> +/* >>>>> + * Set up conin/conout/coninex to make sure we have input ready. >>>>> + */ >>>>> static void >>>>> efi_cons_probe(struct console *cp) >>>>> { >>>>> + EFI_STATUS status; >>>>> + >>>>> + conout =3D ST->ConOut; >>>>> + conin =3D ST->ConIn; >>>>> + >>>>> + status =3D BS->OpenProtocol(ST->ConsoleInHandle, >>>> &simple_input_ex_guid, >>>>> + (void **)&coninex, IH, NULL, >>>> EFI_OPEN_PROTOCOL_GET_PROTOCOL); >>>>> + if (status !=3D EFI_SUCCESS) >>>>> + coninex =3D NULL; >>>>> + >>>>> cp->c_flags |=3D C_PRESENTIN | C_PRESENTOUT; >>>>> } >>>>>=20 >>>>> @@ -889,15 +902,7 @@ efi_cons_init(int arg) >>>>> if (conin !=3D NULL) >>>>> return (0); >>>>>=20 >>>>> - conout =3D ST->ConOut; >>>>> - conin =3D ST->ConIn; >>>>> - >>>>> conout->EnableCursor(conout, TRUE); >>>>> - status =3D BS->OpenProtocol(ST->ConsoleInHandle, >>>> &simple_input_ex_guid, >>>>> - (void **)&coninex, IH, NULL, >>>> EFI_OPEN_PROTOCOL_GET_PROTOCOL); >>>>> - if (status !=3D EFI_SUCCESS) >>>>> - coninex =3D NULL; >>>>> - >>>>> if (efi_cons_update_mode()) >>>>> return (0); >>>>>=20 >>>>>=20 >>>>> Modified: head/stand/efi/loader/arch/arm/Makefile.inc >>>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>> --- 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$ >>>>>=20 >>>>> SRCS+=3D exec.c \ >>>>> + efiserialio.c \ >>>>> start.S >>>>>=20 >>>>> HAVE_FDT=3Dyes >>>>=20 >>>> (Snip) >>>>=20 >>>>> @@ -930,7 +936,6 @@ main(int argc, CHAR16 *argv[]) >>>>> if (!has_kbd && (howto & RB_PROBE)) >>>>> howto |=3D RB_SERIAL | RB_MULTIPLE; >>>>> howto &=3D ~RB_PROBE; >>>>> - uhowto =3D parse_uefi_con_out(); >>>>>=20 >>>>> /* >>>>> * Read additional environment variables from the boot device's >>>>=20 >>>> --=20 >>>> Tomoaki AOKI <junchoon@dec.sakura.ne.jp>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?EFDD40A1-3583-489A-9F4A-50BD19B5049E>