From owner-freebsd-arch@freebsd.org Mon Jun 25 17:25:57 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CDED61017BCD for ; Mon, 25 Jun 2018 17:25:56 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 424C885BD3 for ; Mon, 25 Jun 2018 17:25:56 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id F34F71017BCB; Mon, 25 Jun 2018 17:25:55 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CD4841017BCA for ; Mon, 25 Jun 2018 17:25:55 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3D18F85BD2 for ; Mon, 25 Jun 2018 17:25:55 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22c.google.com with SMTP id e15-v6so13304647iog.1 for ; Mon, 25 Jun 2018 10:25:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=xj9/2JkTuE4EpF3Q2WDqvomueS9YnI25gr53RnZpow4=; b=IZrmrungcYfyAcMugz88aRGgr7ibS0+jsJ1IeoIqtw0ZsGfoE4Zn8Kt+IuI7Jg3za2 p78WG7IeYxQ95BGx+hdFhS7TyGCt6gQIzXHZQVUJdSehX8EsP2uJs8k4gUVD9e0cTX2/ wSCztsYKepHeQt8Trlg4Wo5J5M6+vOENtBZOh9MBONyQX2Vc9sxubUuGPQIdQJ24NBkg m15/aDfgvtDjrdTNxhLeRpzo00WjBHC/C+zNB/O9XKKU1UgWBl4dCDLbJDot53mT41qd 3PhaIvo1/4u04QUcgckZ0fSgJrp52gY12zTKKD2nLnEi+ga3ur+b7wNi9xX+Naf2WzoD 8OYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=xj9/2JkTuE4EpF3Q2WDqvomueS9YnI25gr53RnZpow4=; b=W5c3HjBCKPCmrHpmbQ720yLdFZlJvGGB9oF0oQYcOT18DAd9cIFLKQzdwTeETme1fq ND216U1Hf15dB2QBbZJjOGnl6x/vUJx1oCNgeo4wwWZDzJTpSI6+J0uMxbdgFIg2AJ8Z LJwU0wVHwGljqbnksP5yACNzXEQoBvASuKk+KnZso6viKzs3WCJUC8zgcpn98KyEWQtA ASbFk4kILjtbZFz9wVkZFWLDaz0DYzFa9h4ayGAPb2x/cvFcgKrQsFu0xDi5YZ9DSlzw YhDP9/ivIG4PwfHn29cPmdzw4uk/YRpqxN7+B9i6UklbvwSkcc6jiy3WzCFCnktB1e9d I0LA== X-Gm-Message-State: APt69E2ZpgLyporr/qxLEOXuzZxL6YXYXB4jgshl8mxsEgW1jCkkO14Y UnIFR9CjZMu6Wr67vbgHyvqpRSVi49uxIfi1yJxXjA== X-Google-Smtp-Source: AAOMgpflXMG9wjXL2W90VB+BdX0EJhJ+saKFfsCDUOi5rnjDxInUYaMXVCidEdTaNQPsCpwSjflyxDl03xbCiZNgNN4= X-Received: by 2002:a6b:280a:: with SMTP id o10-v6mr1801804ioo.168.1529947554496; Mon, 25 Jun 2018 10:25:54 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:5945:0:0:0:0:0 with HTTP; Mon, 25 Jun 2018 10:25:53 -0700 (PDT) X-Originating-IP: [50.227.106.226] In-Reply-To: <20180625154740.GF2430@kib.kiev.ua> References: <19341.1529917294@critter.freebsd.dk> <20180625091844.GC2430@kib.kiev.ua> <20180625154740.GF2430@kib.kiev.ua> From: Warner Losh Date: Mon, 25 Jun 2018 11:25:53 -0600 X-Google-Sender-Auth: onBU_WPneEHxx_c7r0lIZW5Zseo Message-ID: Subject: Re: UEFI Plans / Shifts -- RFC To: Konstantin Belousov Cc: Poul-Henning Kamp , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2018 17:25:57 -0000 On Mon, Jun 25, 2018 at 9:47 AM, Konstantin Belousov wrote: > On Mon, Jun 25, 2018 at 07:37:19AM -0600, Warner Losh wrote: > > On Mon, Jun 25, 2018 at 3:18 AM, Konstantin Belousov < > kostikbel@gmail.com> > > wrote: > > > > > On Mon, Jun 25, 2018 at 09:01:34AM +0000, Poul-Henning Kamp wrote: > > > > -------- > > > > In message xsHQjX31zOo+8mDwMAQuA@mail. > > > gmail.com> > > > > , Warner Losh writes: > > > > > > > > >So here's my open questions: > > > > >(1) Do I need to parse boot.conf? > > > > > > > > I can't see how it would add any value on top of UEFI and reading it > > > > will just keeping old workarounds alive another decade for no good > > > reason. > > > > > > An obvious values is to have serial console earlier than loader.conf is > > > parsed. At least on typical desktop motherboards which do not have > > > serial bios redirection, this is important. > > > > > > > This won't work until AFTER we add ACPI to the boot loader. > > Why ? > Because often (very often in my experience) the redirected serial port is not at COM1 address, but COM2 or COM3. The only way to set that is via comconsole_port. That's not parsed until after we read in loader.conf when we kick the different language interpreters off. So, any output before that will be lost. This happens when we call interact, which is after all the initial boot stuff has happened. The UEFI boot variable ConOut gives us a device which rendered to human readable form looks something like: PciRoot(0x0)/Pci(0x1c,0x2)/Pci(0x0,0x0)/Pci(0x0,0x0)/AcpiAdr(0x80010100),/PciRoot(0x0)/Pci(0x1f,0x0)/Serial(0x1)/Uart(115200,8,N,1)/UartFlowCtrl(Hardware)/VenVt100Plus() which tells us a lot. There's two devices. First one listed is a video card whose ACPI _ADR is 0x80010100. The second one is the Serial Port with _UID=1 running at 115200 baud and that supports Vt100-ish escape sequences. What the boot loader doesn't know is what the port address of UID=1 is with any certainty. On my specific system, it maps to: uart1 pnpinfo _HID=PNP0501 _UID=1 at handle=\_SB_.PCI0.LPC0.UAR2 uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 which is actually COM2. Now, there's some text in the ACPI standard that says suggests that _UID=0 should be COM1, 1 COM2 etc, but it appears to be mostly a suggestion not an absolute requirement. The only requirement is that _UID=X is the same from boot to boot. I'd thought about putting in some fallback code for this, but a sampling of systems suggests this might be a bit optimistic. Here's a sampling of a couple of systems I have: Supermicro X11 based: uart0 pnpinfo _HID=PNP0501 _UID=0 at handle=\_SB_.PC00.LPC0.UAR1 uart2 pnpinfo _HID=PNP0501 _UID=1 at handle=\_SB_.PC00.LPC0.UAR2 Supermicro X10 based: uart0 pnpinfo _HID=PNP0501 _UID=0 at handle=\_SB_.PCI0.LPC0.UAR1 uart1 pnpinfo _HID=PNP0501 _UID=1 at handle=\_SB_.PCI0.LPC0.UAR2 Supermicro X9 based: uart0 pnpinfo _HID=PNP0501 _UID=1 at handle=\_SB_.PCI0.LPCB.UAR1 unknown pnpinfo _HID=PNP0501 _UID=2 at handle=\_SB_.PCI0.LPCB.UAR2 (disabled) uart2 pnpinfo _HID=PNP0501 _UID=3 at handle=\_SB_.PCI0.LPCB.UAR3 Freefall: uart0 pnpinfo _HID=PNP0501 _UID=1 at handle=\_SB_.PCI0.LPCB.UAR1 uart1 pnpinfo _HID=PNP0501 _UID=2 at handle=\_SB_.PCI0.LPCB.UAR2 uart2 pnpinfo _HID=PNP0501 _UID=3 at handle=\_SB_.PCI0.LPCB.UR12 So UID=1 could mean COM1, COM2 or COM3, and that's just on SuperMicro hardware from the last few years.... Adding ACPI (to the UEFI-only boot loader, nothing else) would allow us to go search the UEFI tree for the PNP0501 node with the right _UID. It's kinda a heavy lift though. I thought about adding something that would set a FreeBSD-specific env var that would give the loader.efi a hint to make things work on the second boot (the first boot setting it in rc.d somewhere). But that's a fragile solution at best, and wouldn't solve the serial installer issues. Warner