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