Date: Fri, 22 Jun 2018 12:33:29 -0600 From: Warner Losh <imp@bsdimp.com> To: Ravi Pokala <rpokala@freebsd.org> Cc: "freebsd-arch@freebsd.org" <arch@freebsd.org> Subject: Re: UEFI Plans / Shifts -- RFC Message-ID: <CANCZdfpr5sVhSxSV8zB7TvG49-iDhyZrSfemFA11GjNYsAB5TA@mail.gmail.com> In-Reply-To: <44C1725E-95E6-4654-994E-DF80E45E24EE@panasas.com> References: <CANCZdfoMZXJu2nRbAtLTPc1B4YWWbxsHQjX31zOo%2B8mDwMAQuA@mail.gmail.com> <44C1725E-95E6-4654-994E-DF80E45E24EE@panasas.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jun 22, 2018 at 12:18 PM, Ravi Pokala <rpokala@freebsd.org> 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: <owner-freebsd-arch@freebsd.org> on behalf of Warner Losh < > imp@bsdimp.com> > Date: 2018-06-22, Friday at 08:47 > To: "freebsd-arch@freebsd.org" <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" > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfpr5sVhSxSV8zB7TvG49-iDhyZrSfemFA11GjNYsAB5TA>