Date: Fri, 22 Jun 2018 09:47:14 -0600 From: Warner Losh <imp@bsdimp.com> To: "freebsd-arch@freebsd.org" <arch@freebsd.org> Subject: UEFI Plans / Shifts -- RFC Message-ID: <CANCZdfoMZXJu2nRbAtLTPc1B4YWWbxsHQjX31zOo%2B8mDwMAQuA@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfoMZXJu2nRbAtLTPc1B4YWWbxsHQjX31zOo%2B8mDwMAQuA>