From owner-freebsd-arch@freebsd.org Fri Jun 22 18:18:11 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 04B791023562 for ; Fri, 22 Jun 2018 18:18:11 +0000 (UTC) (envelope-from rpokala@freebsd.org) 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 8D0577AB03 for ; Fri, 22 Jun 2018 18:18:10 +0000 (UTC) (envelope-from rpokala@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 46FF4102355F; Fri, 22 Jun 2018 18:18:10 +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 222B5102355E for ; Fri, 22 Jun 2018 18:18:10 +0000 (UTC) (envelope-from rpokala@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CB30A7AB00; Fri, 22 Jun 2018 18:18:09 +0000 (UTC) (envelope-from rpokala@freebsd.org) Received: from [172.17.133.41] (unknown [12.202.168.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: rpokala) by smtp.freebsd.org (Postfix) with ESMTPSA id 5AC1511C65; Fri, 22 Jun 2018 18:18:09 +0000 (UTC) (envelope-from rpokala@freebsd.org) User-Agent: Microsoft-MacOutlook/10.e.1.180613 Date: Fri, 22 Jun 2018 11:18:06 -0700 Subject: Re: UEFI Plans / Shifts -- RFC From: Ravi Pokala To: Warner Losh , "freebsd-arch@freebsd.org" Message-ID: <44C1725E-95E6-4654-994E-DF80E45E24EE@panasas.com> Thread-Topic: UEFI Plans / Shifts -- RFC References: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable 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 18:18:11 -0000 > To work around this, people with non-standard console ports (which everyb= ody with a BMC likely has), What makes you say that? On most (all?) systems with IPMI that I've seen, the motherboard console po= rt is a normal UART. It just so happens that the UART isn't connected to a D= B9 header, but rather to the serial port on the BMC. The firmware on the BMC= (somehow -- reading the BIOS/UEFI settings directly?) knows the configurati= on of the motherboard console port, and configures its side to match. And th= ere you go: a serial connection between the motherboard console port and the= BMC. What the BMC then does with it -- reflect it over the network using Serial-= Over-LAN, expose it via a web interface, etc. -- is a separate matter entire= ly. -Ravi (rpokala@) =EF=BB=BF-----Original Message----- From: on behalf of Warner Losh Date: 2018-06-22, Friday at 08:47 To: "freebsd-arch@freebsd.org" Subject: UEFI Plans / Shifts -- RFC > Greetings, >=20 > As I've documented before, I'll be making some addition UEFI changes. >=20 > 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 >=20 > 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. >=20 > 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 whateve= r > 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 mak= e > things match the variable so the kernel messages would work. There is > another vector to pass arguments to /boot/loader.efi, and that's efibootm= gr > can set args to use that are passed to main w/o needing to read boot.conf > at all. >=20 > 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 pass= ed > in. >=20 > 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_SERIA= L. > If we find a video card in the list, we'll use it. If we find serial in t= he > 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 s= et > comconsole_speed. > 3. We'll parse loader.conf > 4. Just before we boot, if we have the 'efi' console set and serial was s= et > in the ConOut variable, we'll set hw.uart.console to reflect the speed an= d > the value of comconsole_port[*]. >=20 > 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 ju= st > 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 n= o > 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'l= l > 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 no= t > investigated doing that in any more detail than to see there's no quick, > easy shortcuts. >=20 > 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 comman= d > 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 bo= th > video and serial? Or should we only set RB_MULTIPLE? Or should we check t= he > 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 wher= e > 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. >=20 > My current code is up at https://reviews.freebsd.org/D15917 if you want t= o > 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. >=20 > Warner >=20 > Warner > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"