svn commit: r358989 - in head/stand/efi: libefi loader loader/arch/arm loader/arch/arm64

Wed Mar 18 22:29:12 UTC 2020

> On 18. Mar 2020, at 20:41, Ruslan Garipov <brigadir15 at gmail.com> wrote:
> 
> On 3/18/2020 10:29 PM, Toomas Soome via svn-src-head wrote:
>> 
>> 
>>> On 18. Mar 2020, at 18:40, Ruslan Garipov <brigadir15 at 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 at 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 at 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?

Please try r359099.

> 
>> 
>> 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 <http://bugs.freebsd.org/>?

PR is always good idea. Finding the exact cause and getting sure fix is question of time. I have done quite amount of investigation, but I can not yet point the finger even as there is one known issue identified. *IF* I am correct about the issue, the fix will take some time as it is not too trivial.

> 
> 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.

BIOS version is ok.

rgds,
toomas

> 
>> 
>> 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/><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 at dec.sakura.ne.jp>