From owner-svn-src-head@freebsd.org Fri Mar 20 15:09:35 2020 Return-Path: Delivered-To: svn-src-head@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DD8DD269EE2 for ; Fri, 20 Mar 2020 15:09:35 +0000 (UTC) (envelope-from brigadir15@gmail.com) Received: from mail-lf1-f68.google.com (mail-lf1-f68.google.com [209.85.167.68]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48kRyR1F0rz4P2f for ; Fri, 20 Mar 2020 15:09:34 +0000 (UTC) (envelope-from brigadir15@gmail.com) Received: by mail-lf1-f68.google.com with SMTP id j15so4824773lfk.6 for ; Fri, 20 Mar 2020 08:09:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=R73J27MO/CrdOGEU1QUzYOOtnNd5uES1Jy2bh4uydvg=; b=hiKHssr1XOkBmJ7fY2tDqjrafz+exDi309tsdVf3XLL7SWoTITN4BfejNGBMOSE8Tt 0VVojGIrr27vKu8p+7h6hDMAJWHV0i9IsNmWcMOXoXboPWga17OnoslhJAjYMdxg8g/o IhFjWSjhluX2eE6pPfQy2aNzufwKqesJ2QbLlTWNcR0525vRf//18qHEwABXrtripUUk OqLyWUpbjhXL7YVGvjFjm11Unzds6S/M0sIwttJ7WdMgXFHYgAdqkc1uTrRBuxSzInI/ WaYQ9xmel0zE5SxOYE67ZzONriyxS+qcD8B1QGobaJmszDwWiWb8kTQgjpsBhhOovGbR yBow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=R73J27MO/CrdOGEU1QUzYOOtnNd5uES1Jy2bh4uydvg=; b=eov8Lh3QoUZJV6ijuhy7teCDjnyfOiXMUzvzqBPU7wjC5bVnxX8Qnqpw3KdR9pLmro 0pYdbCTK+hMqSUkonU3io4Z6NJWGI4XstYLqbxyiU+SIxSVF3FsB19DsObVeY81U73QG 45MtrvxaJtj7gprd6cu+v421RyGQfRweh7DbO3KE00hC+mfOmfKTC9G+B25gBG4xIUOh AMIWcu1mW2eOEK0z/jF7H6M+cLxzSM0OHJOxXF8E6wobzzUqDItiamwLL/HlpxTFkqlR 0nFLOTW2JbF6DGy/FNuCZYYchn7eA7nCQW0pE9WQUPuyWpzohSnw8ZWD905tGoQxo6pT L0nA== X-Gm-Message-State: ANhLgQ3hfUAVsKuBU3uB9kk3V5ifNs62cOnWH4G+5SFhRkucUjdxrYCu 047UGjSCz7t7TZGahc7uhT0= X-Google-Smtp-Source: ADFU+vszb2m80Oly1n5QFVB5ycpUUF39Irjh91cxCD1MLvUTLZBosFSfY51P2IRMPvMThC1sscgJrg== X-Received: by 2002:a05:6512:3191:: with SMTP id i17mr5635472lfe.33.1584716969374; Fri, 20 Mar 2020 08:09:29 -0700 (PDT) Received: from [192.168.1.3] ([46.48.69.183]) by smtp.gmail.com with ESMTPSA id q6sm3613183ljp.21.2020.03.20.08.09.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 20 Mar 2020 08:09:28 -0700 (PDT) Subject: Re: svn commit: r358989 - in head/stand/efi: libefi loader loader/arch/arm loader/arch/arm64 To: Toomas Soome , junchoon@dec.sakura.ne.jp Cc: svn-src-head@freebsd.org, Ruslan Garipov 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> <944c641f-b570-1420-6b63-96374217d795@gmail.com> <4ABF87AE-948F-43A8-940A-744FC2F4DE4D@me.com> <20200319213329.f354314a9a72e1419d76d2ba@dec.sakura.ne.jp> From: Ruslan Garipov Message-ID: <750368ad-3815-d7e7-a283-f29feb38b35c@gmail.com> Date: Fri, 20 Mar 2020 20:09:26 +0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 48kRyR1F0rz4P2f X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=hiKHssr1; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of brigadir15@gmail.com designates 209.85.167.68 as permitted sender) smtp.mailfrom=brigadir15@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FREEMAIL_TO(0.00)[me.com]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(0.00)[ip: (-2.64), ipnet: 209.85.128.0/17(-2.89), asn: 15169(-1.23), country: US(-0.05)]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[svn-src-head@freebsd.org]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[68.167.85.209.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[68.167.85.209.rep.mailspike.net : 127.0.0.17]; RCVD_TLS_ALL(0.00)[] X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2020 15:09:35 -0000 On 3/19/2020 5:55 PM, Toomas Soome via svn-src-head wrote: > > >> On 19. Mar 2020, at 14:33, Tomoaki AOKI wrote: >> >> On Thu, 19 Mar 2020 00:28:59 +0200 >> Toomas Soome > wrote: >> >>> >>> >>>> On 18. Mar 2020, at 20:41, Ruslan Garipov wrote: >>>> >>>> On 3/18/2020 10:29 PM, Toomas Soome via svn-src-head wrote: >>>>> >>>>> >>>>>> On 18. Mar 2020, at 18:40, Ruslan Garipov 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 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 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 ="atkbdc" >> hint.atkbd.0.irq="1" >> hint.atkbdc.0.at ="isa" >> hint.atkbdc.0.port="0x060" >> hint.atrtc.0.at ="isa" >> hint.atrtc.0.irq="8" >> hint.atrtc.0.port="0x70" >> hint.attimer.0.at ="isa" >> hint.attimer.0.irq="0" >> hint.attimer.0.port="0x40" >> hint.fd.0.at ="fdc0" >> hint.fd.0.drive="0" >> hint.fd.1.at ="fdc0" >> hint.fd.1.drive="1" >> 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 ="isa" >> hint.ppc.0.irq="7" >> hint.psm.0.at ="atkbdc" >> hint.psm.0.irq="12" >> hint.sc.0.at ="isa" >> hint.sc.0.flags="0x100" >> hint.smbios.0.mem="0x4d580000" >> hint.uart.0.at ="isa" >> hint.uart.0.flags="0x10" >> hint.uart.0.irq="4" >> hint.uart.0.port="0x3F8" >> 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 >? >>> >>> >>> 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/ >>> >>>>>>>>> >>>>>>>>> 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 >>> >> >> >> -- >> Tomoaki AOKI > > > _______________________________________________ > 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-unsubscribe@freebsd.org" >