From owner-freebsd-arch@freebsd.org Fri Jun 22 18:33:32 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 9517F1023F74 for ; Fri, 22 Jun 2018 18:33:32 +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 2589D7BCB1 for ; Fri, 22 Jun 2018 18:33:32 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id D89291023F73; Fri, 22 Jun 2018 18:33:31 +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 A2B501023F72 for ; Fri, 22 Jun 2018 18:33:31 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (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 31B5A7BCAC for ; Fri, 22 Jun 2018 18:33:31 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22a.google.com with SMTP id v83-v6so4198054itc.3 for ; Fri, 22 Jun 2018 11:33:31 -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=n9Lx4LQGkk/W75KyYl+LbxXLn4dpTgTTn2TcWfyDJEc=; b=HZEvPg4Owgf0Kvm4ee3mNodu+i22R9LRPCtQ/rE3WNQMEwe/Pidawd2cFTzvIks+VR G0zDwQwOnFO8aCrhsbXOFf9zJtDJCxcvLIUW7H4MPsM0GjlWK9uYrclIy5O0IJIM3Tne XvTzpsu4Vjef1Obw0HnxklXtwBc3BxVq8XzgCPPWw0uJvAlV+6hK20ih9GzxP5GQM6vO j7nOtcTQlhoArS0rW79BOFz7autd3EcceYPYWtfn0T5Jw1zBDmr1ZC+MyxpUC1tCBtXa fcVQi+fWGeSPh08tHytlK4OuFavpdEDO2PJKWOodsTQLdkwZBCxak4LpoHhHuJmZI4/y vU0A== 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=n9Lx4LQGkk/W75KyYl+LbxXLn4dpTgTTn2TcWfyDJEc=; b=JnYBLsia0ur/pFsHqGQxgJjMZ15o+rW2YyB+kTs3Alz8tsB0c8oY4N4lgHklORYL7r hPJR0v2LGPfBG66AFF0ljQ48It4OzkkMCicalRYMDUAxXDl5iYEe/x00cEgRKQ39NjW3 8lKgJt5iVHQ7uwhIOjHM0E/GqS8hlURrZoI423qI0dara3MnglpsEOqKW8oljiLarbXd NUg2NhK4ytRLWI9gfvA2Sv3rphTGRQSql5qwMPgVYvIijjSO0knqRDg2W/qDRhNCMiuV mpfXDnUExdKJxyPLD6SZFq0HT6wPEniUzhx1gIzi4Xxjnf+KoRZsUdtSGx5cgtuSwhgR Op9w== X-Gm-Message-State: APt69E050MJdMBhg0+tZFgcag1VYHlNNN3lxJ9nsyiOBX6kEH/MxAMO/ XxtdwwAeEiZBr5DBlG6XJQjL3iFRK3Aano9x5XSqPw== X-Google-Smtp-Source: AAOMgpf7uh9YmdL5rGDQ2mzj/nhefheY4e1tBsH1sQuEsKDNPWCWTGBFQpiWgqgXfnNxpMQAHcQiNfkvKKZk66tcP2g= X-Received: by 2002:a24:64ce:: with SMTP id t197-v6mr2479965itc.36.1529692410506; Fri, 22 Jun 2018 11:33:30 -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 11:33:29 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <44C1725E-95E6-4654-994E-DF80E45E24EE@panasas.com> References: <44C1725E-95E6-4654-994E-DF80E45E24EE@panasas.com> From: Warner Losh Date: Fri, 22 Jun 2018 12:33:29 -0600 X-Google-Sender-Auth: pGP3WBhlgDrYSLOzvd2g6C_Covg Message-ID: Subject: Re: UEFI Plans / Shifts -- RFC To: Ravi Pokala Cc: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 18:33:33 -0000 On Fri, Jun 22, 2018 at 12:18 PM, Ravi Pokala wrote: > > To work around this, people with non-standard console ports (which > everybody with a BMC likely has), > > What makes you say that? > > On most (all?) systems with IPMI that I've seen, the motherboard console > port is a normal UART. It just so happens that the UART isn't connected t= o > a DB9 header, but rather to the serial port on the BMC. The firmware on t= he > BMC (somehow -- reading the BIOS/UEFI settings directly?) knows the > configuration of the motherboard console port, and configures its side to > match. And there 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 entirely. > I mean that the BMC is almost never connected to COM1, at least for the sampling of motherboards I've had to deal with in the past 5 years. The standard port is COM1 for debugging. Everything else you have to set an address for. Warner > -Ravi (rpokala@) > > =EF=BB=BF-----Original Message----- > From: on behalf of Warner Losh < > imp@bsdimp.com> > Date: 2018-06-22, Friday at 08:47 > To: "freebsd-arch@freebsd.org" > Subject: UEFI Plans / Shifts -- RFC > > > 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 i= s > > 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 need= ed > > before 1 can be done. > > > > In the past boot1.efi chose the /, read /boot/config or /boot.config an= d > > passed those args to /boot/loader.efi. This was always an imperfect mat= ch > > 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.co= nf > > 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 t= he > > uefi boot variable, I'd like to stop parsing boot.conf and shift to usi= ng > > 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 t= he > > 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 th= e > > 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 th= e > > review. > > > > Warner > > > > 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" > > >