From owner-freebsd-arch@freebsd.org Fri Jun 22 15:47:18 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 E5A1A101F335 for ; Fri, 22 Jun 2018 15:47:17 +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 6EA4374F2D for ; Fri, 22 Jun 2018 15:47:17 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id 29E77101F332; Fri, 22 Jun 2018 15:47:17 +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 074BE101F330 for ; Fri, 22 Jun 2018 15:47:17 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (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 8CDFA74F2B for ; Fri, 22 Jun 2018 15:47:16 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x233.google.com with SMTP id j135-v6so3528903itj.1 for ; Fri, 22 Jun 2018 08:47:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:from:date:message-id:subject:to; bh=T3gFL0RlTIfEW+Y5MO8jwMIGJBOFD6+KsQwbtoU5PC0=; b=kj/g2bnYhWAa1z3Xz5dVwD3wJE7CS3kje3LzCfiu40A1UVcS/DCve2Y1W08lYt46rw dWDznGh/cVoAt4sXysiPNRlUJtHvK9eZ3MkDMmRhTW8LKY4OjI8UZQDsC0s6i7znrbqI RC0pP4Jlb4bLPnCv5dZzbowyjPNsKyc/QEJHQwYdHmQiSivXQPQurOVx9WyuWWxD26m1 Y0L2yPP7DZMLQxV8q23QyVXfhDY7KcJTe+ohaBQb8nw0Y1I8Cg7vRoVA6Tad6T3u8uv0 w3psg7oBH5EF0Nv1YyrW1DW5X8XkyJEmJJUZwnooSSzPZvysi1LSZflZzYg6PYX9Nr+F jrKw== 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:from:date:message-id:subject :to; bh=T3gFL0RlTIfEW+Y5MO8jwMIGJBOFD6+KsQwbtoU5PC0=; b=StpVN50TFFLZ7dOb1sldd1NOvc6hoXDoM/V/KmnNhnQ1l6LqyGJG8cTtlwStQgEjMC FyMxEIaWtONc+1O2aMoIpdfX+Kt/9fQOqV8RixoCrnXQk4e9rdXo9xnAsy17ryHKRTba N47Wr6CrwvQDhxuDDuff1OECnex15795vOpnhnquvg2Q/Z3zwrS83l8PKFpIFmbTRMXs uyTUOKy3AHI/Nn6jphHfV5qCcNL/EqPcpFTrzx1eKXMAcGCUWjWR+/LShtVt++A2qIeX Y6vsFK8UXWe8pT5PyS2gXNn3IB6UkIIanQi5MZXmfOxTJUXNgb/pZS+1buZvHiOMceNM 6W1g== X-Gm-Message-State: APt69E1qU1S7Zk8dgeU1QGYEsMA+iSLHyOUm+pDkfQALY5tb5h+IyYp5 dwvQvB9ECxfFlmr1ZPj0l3ad7Be9/aEuanI4IfwdjPlp X-Google-Smtp-Source: AAOMgpfIm8IXrsBS2P/vyY8ZygbPsIuypBHLOoMGDf1pTQacBvZ8BJ9gWwAJbMxEWNS+0U4Mf5FC77g1wlvHCnUNCOQ= X-Received: by 2002:a24:64ce:: with SMTP id t197-v6mr1987733itc.36.1529682435411; Fri, 22 Jun 2018 08:47:15 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:5945:0:0:0:0:0 with HTTP; Fri, 22 Jun 2018 08:47:14 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] From: Warner Losh Date: Fri, 22 Jun 2018 09:47:14 -0600 X-Google-Sender-Auth: NEg1erIF2ClqAys25ZRVeeMeQuY Message-ID: Subject: UEFI Plans / Shifts -- RFC To: "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: Fri, 22 Jun 2018 15:47:18 -0000 Greetings, As I've documented before, I'll be making some addition UEFI changes. To recap, the plan: 1. Remove boot1.efi 2. Enhance loader.efi so it can live on ESP 3. Enhance loader.efi so it can do ping-pong booting 1 is still the plan, but there's some bits left to do. Most of step 2 is done. However, there's some issues that I'd like to work through. 3 is my next task. There's other installer and installworld tasks that are needed before 1 can be done. In the past boot1.efi chose the /, read /boot/config or /boot.config and passed those args to /boot/loader.efi. This was always an imperfect match to UEFI, since we selected video/serial/both and other things for the kernel, but used the EFI conout function which sent the output to whatever the UEFI ConOut variable was set to. In fact, we totally ignored that variable and people had to manually hack together something to try to make things match the variable so the kernel messages would work. There is another vector to pass arguments to /boot/loader.efi, and that's efibootmgr can set args to use that are passed to main w/o needing to read boot.conf at all. So, now that loader.efi is starting up, and we'd like to have verbose output before we select the root filesystem from which we could get the boot.conf to know where to send this output, I'd like to shift things a little. Since we already have almost all the information we need from the uefi boot variable, I'd like to stop parsing boot.conf and shift to using that. I'd like to make the ConOut variable override the command args passed in. So, the new process will be: 1. Parse the args. Get a tentative howto. 2. Look at ConOut. If it's set, then we mask off RB_MULTIPLE and RB_SERIAL. If we find a video card in the list, we'll use it. If we find serial in the list, we'll use that and set RB_SERIAL. If we find both, we'll set RB_MUTLIPLE and RB_SERIAL. If we find serial, and it has a speed, we'll set comconsole_speed. 3. We'll parse loader.conf 4. Just before we boot, if we have the 'efi' console set and serial was set in the ConOut variable, we'll set hw.uart.console to reflect the speed and the value of comconsole_port[*]. This will result in serial consoles just working almost all the time w/o needing to do anything. The 'almost' part here is because to find the serial port, we have to walk the ACPI name space to find the _CRS that matches the _HID for the serial port. We're given the _UID, but that's just a number whose meaning varies to the point of it being random. While we know that _UID X will refer to the same port from boot to boot, we have no clue what that is on any given board. To work around this, people with non-standard console ports (which everybody with a BMC likely has), you'll need to set comconsole_port in loader.conf. Of course, you'll have had to do that today to make this setup work, so that's nothing new. In the fullness of time, but not for 12, we should just parse ACPI in the UEFI boot loader. This is somewhat non-trivial since we have to write the OS glue for the ACPICA code to have it work in the UEFI environment. I've not investigated doing that in any more detail than to see there's no quick, easy shortcuts. So here's my open questions: (1) Do I need to parse boot.conf? If so, do I violate POLA by parsing the one that's on the ESP or the one in the / we hope to boot from. What if I don't find a /? I am leaning to a 'hard no' on this question because the efibootmgr provides a vector to get command line args to loader.efi that's much better. boot.conf was a hack around the fact you couldn't set command line args in the legacy bios. (2) Should the command line args passed in take precedence? Or should ConOut? Or should ConOut be used first with the command line args augmenting it? (3) Should we set RB_MULTIPLE | RB_SERIAL unconditionally with we have both video and serial? Or should we only set RB_MULTIPLE? Or should we check the command line args and only set RB_SERIAL in this case when -h is on the command line, like we do today. The downstream effect of this choses where THE console of the kernel goes until someone writes a some ttymux code to allow it to go to all the consoles requested by the boot loader. My current code is up at https://reviews.freebsd.org/D15917 if you want to look. As always, what to do comments should likely go here, while 'this code sucks, here's how to make it better' type comments should go on the review. Warner Warner