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

[Ruslan Garipov]

On 3/19/2020 5:55 PM, Toomas Soome via svn-src-head wrote:
> 
> 
>> On 19. Mar 2020, at 14:33, Tomoaki AOKI <junchoon at dec.sakura.ne.jp> wrote:
>>
>> On Thu, 19 Mar 2020 00:28:59 +0200
>> Toomas Soome <tsoome at me.com <mailto:tsoome at me.com>> wrote:
>>
>>>
>>>
>>>> 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 would 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.
Thanks, this fixed loader menu.  At least on virtual machines.  I
couldn't check it on a physical one, because I failed to install
graphics/drm-current-kmod kernel module from ports.  But I think it will
be ok there.

>>
>> Many thanks! Worked fine for me, at least buildworld after `make clean`
>> on /usr/src/stand.
>>
>>
>> A bit details:
>> Cleaning /usr/src/stand before building itself didn't help.
>> Updating to r359099 and later was mandatory.
>> No VMs are tested, as I'm currently not running any VMs.
>>
>>
>> For your further investigation, kenv output is like this:
> 
> 
> This output is not from patched loader, is it? Could you mail me from latest — specifically, I’m expecting to see LINES and COLUMNS values. 
FreeBSD 13.0-CURRENT r359117 (VMware ESXi guest) shows:
$ kenv | egrep "COLUMNS|LINES"
COLUMNS="80"
LINES="25"

FreeBSD 13.0-CURRENT r359028 (physical machine) doesn't have that rows
in kenv output at all.

> 
> What seems to be the cause is, we allocate screen buffer for text, if that allocation does fail, we did abort efi_cons_init() and the putchar did switch to direct output without interpreting the esc sequences. Now the question would be, why we failed to allocate the buffer - we do have 64MB heap as default  and console is initialized early…
> 
> thanks,
> toomas
> 
>>
>> === `kenv` output except hardware serial No. and UUID below ===
>>
>> acpi.oem="LENOVO"
>> acpi.revision="2"
>> acpi.rsdp="0x000000004fd0e014"
>> acpi.rsdt="0x000000004fd0c0c4"
>> acpi.xsdt="0x000000004fd0c188"
>> acpi.xsdt_length="36"
>> bootenv_autolist="YES"
>> bootenvs[0]="zfs:zsysS05/ROOT/head-r359007-boot1Rev6TA3"
>> bootenvs[10]="zfs:zsysS05/ROOT/head-r358565-boot1Rev6TA3"
>> bootenvs[11]="zfs:zsysS05/ROOT/"
>> bootenvs[1]="zfs:zsysS05/ROOT/head-r359005-boot1Rev6TA3"
>> bootenvs[2]="zfs:zsysS05/ROOT/head-r358989-boot1Rev6TA3"
>> bootenvs[3]="zfs:zsysS05/ROOT/head-r358906-boot1Rev6TA3"
>> bootenvs[4]="zfs:zsysS05/ROOT/head-r358872-boot1Rev6TA3"
>> bootenvs[5]="zfs:zsysS05/ROOT/head-r358865-boot1Rev6TA3-2"
>> bootenvs[6]="zfs:zsysS05/ROOT/head-r358827-boot1Rev6TA3"
>> bootenvs[7]="zfs:zsysS05/ROOT/head-r358734-boot1Rev6TA3"
>> bootenvs[8]="zfs:zsysS05/ROOT/head-r358729-boot1Rev6TA3"
>> bootenvs[9]="zfs:zsysS05/ROOT/head-r358669-boot1Rev6TA3"
>> bootenvs_count="12"
>> bootfile="kernel"
>> comconsole_pcidev=""
>> comconsole_port="1016"
>> comconsole_speed="9600"
>> console="efi"
>> currdev="zfs:zsysS05/ROOT/default:"
>> efi-version="2.60"
>> efi_max_resolution="2160p"
>> hint.acpi.0.oem="LENOVO"
>> hint.acpi.0.revision="2"
>> hint.acpi.0.rsdp="0x000000004fd0e014"
>> hint.acpi.0.rsdt="0x000000004fd0c0c4"
>> hint.acpi.0.xsdt="0x000000004fd0c188"
>> hint.acpi.0.xsdt_length="36"
>> hint.acpi_throttle.0.disabled="1"
>> hint.atkbd.0.at <http://hint.atkbd.0.at/>="atkbdc"
>> hint.atkbd.0.irq="1"
>> hint.atkbdc.0.at <http://hint.atkbdc.0.at/>="isa"
>> hint.atkbdc.0.port="0x060"
>> hint.atrtc.0.at <http://hint.atrtc.0.at/>="isa"
>> hint.atrtc.0.irq="8"
>> hint.atrtc.0.port="0x70"
>> hint.attimer.0.at <http://hint.attimer.0.at/>="isa"
>> hint.attimer.0.irq="0"
>> hint.attimer.0.port="0x40"
>> hint.fd.0.at <http://hint.fd.0.at/>="fdc0"
>> hint.fd.0.drive="0"
>> hint.fd.1.at <http://hint.fd.1.at/>="fdc0"
>> hint.fd.1.drive="1"
>> hint.fdc.0.at <http://hint.fdc.0.at/>="isa"
>> hint.fdc.0.drq="2"
>> hint.fdc.0.irq="6"
>> hint.fdc.0.port="0x3F0"
>> hint.p4tcc.0.disabled="1"
>> hint.ppc.0.at <http://hint.ppc.0.at/>="isa"
>> hint.ppc.0.irq="7"
>> hint.psm.0.at <http://hint.psm.0.at/>="atkbdc"
>> hint.psm.0.irq="12"
>> hint.sc.0.at <http://hint.sc.0.at/>="isa"
>> hint.sc.0.flags="0x100"
>> hint.smbios.0.mem="0x4d580000"
>> hint.uart.0.at <http://hint.uart.0.at/>="isa"
>> hint.uart.0.flags="0x10"
>> hint.uart.0.irq="4"
>> hint.uart.0.port="0x3F8"
>> hint.uart.1.at <http://hint.uart.1.at/>="isa"
>> hint.uart.1.irq="3"
>> hint.uart.1.port="0x2F8"
>> hw.ata.atapi_dma="1"
>> hw.ibrs_disable="0"
>> hw.pci.allow_unsupported_io_range="1"
>> hw.psm.elantech_support="1"
>> hw.psm.trackpoint_support="1"
>> kern.hz="8192"
>> kern.ipc.semmni="40"
>> kern.ipc.semmns="300"
>> kern.ipc.shm_use_phys="1"
>> kern.ipc.shmmni="1024"
>> kern.ipc.shmseg="1024"
>> kern.maxfiles="250000"
>> kern.vty="vt"
>> kernel="kernel"
>> kernel_options=""
>> kernel_path="/boot/kernel"
>> kernelname="/boot/kernel/kernel"
>> kernels="kernel kernel.old"
>> kernels_autodetect="YES"
>> loaddev="zfs:zsysS05/ROOT/default:"
>> loader_conf_files="/boot/device.hints /boot/loader.conf /boot/loader.conf.local"
>> machdep.mitigations.taa.enable="3"
>> module_blacklist="drm drm2 radeonkms i915kms amdgpu"
>> module_path="/boot/kernel;/boot/modules;/boot/dtb;/boot/dtb/overlays"
>> net.graph.maxdata="65536"
>> nextboot_conf="/boot/nextboot.conf"
>> nextboot_enable="NO"
>> script.lang="lua"
>> smbios.bios.reldate="11/04/2019"
>> smbios.bios.vendor="LENOVO"
>> smbios.bios.version="N2CET48W (1.31 )"
>> smbios.chassis.maker="LENOVO"
>> smbios.chassis.serial="********"
>> smbios.chassis.tag="No Asset Information"
>> smbios.chassis.version="None"
>> smbios.memory.enabled="33554432"
>> smbios.planar.location="Not Available"
>> smbios.planar.maker="LENOVO"
>> smbios.planar.product="20M9CTO1WW"
>> smbios.planar.serial="***********"
>> smbios.planar.tag="Not Available"
>> smbios.planar.version="SDK0J40697 WIN"
>> smbios.socket.enabled="1"
>> smbios.socket.populated="1"
>> smbios.system.family="ThinkPad P52"
>> smbios.system.maker="LENOVO"
>> smbios.system.product="20M9CTO1WW"
>> smbios.system.serial="********"
>> smbios.system.sku="LENOVO_MT_20M9_BU_Think_FM_ThinkPad P52"
>> smbios.system.uuid="********-****-****-****-************"
>> smbios.system.version="ThinkPad P52"
>> smbios.version="3.1"
>> twiddle_divisor="1"
>> verbose_loading="NO"
>> vfs.root.mountfrom="zfs:zsysS05/ROOT/default"
>> vfs.zfs.abd_chunk_size="1024"
>> vfs.zfs.prefetch_disable="1"
>> vm.pmap.pti="1"
>> zfs_be_active="zfs:zsysS05/ROOT/default"
>> zfs_be_currpage="1"
>> zfs_be_root="zsysS05/ROOT"
>>
>>
>> === `kenv` output except hardware serial No and UUID above ===
>>
>>
>>>
>>>
>>>>
>>>>>
>>>>> 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/><http://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.
Francis Dupont created PR 244906 yesterday:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244906

I just added a comment there.

>>>
>>>
>>>>
>>>> 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/>><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>
>>>
>>
>>
>> -- 
>> Tomoaki AOKI    <junchoon at dec.sakura.ne.jp <mailto:junchoon at dec.sakura.ne.jp>>
> 
> _______________________________________________
> svn-src-head at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/svn-src-head
> To unsubscribe, send any mail to "svn-src-head-unsubscribe at freebsd.org"
>