Quiet boot option

[miczyg1]

The problem you're addressing (if any)
Currently Dasharo firmware prints strings on the screen indicating the menu prompt.

Describe the solution you'd like
Add a "Quiet boot" option to disable the strings during POST.

Where is the value to a user, and who might that user be?
These strings are not necessary and some people may not like it. There should be an option to disable them.

Describe alternatives you've considered
None

Additional context
None

[wessel-novacustom]

After almost two years, I haven't heard any user that is interested in this feature. I would close it without implementing.

[miczyg1]

@wessel-novacustom maybe not for the laptops, but I personally want this.

[mkopec]

I also would like this, with quiet boot we could eliminate the logo flicker that happens when clearing the strings before handing off to OS :)

[wessel-novacustom]

This, plus skipping things like searching for boot options, so you will have a quiet-fast boot option. Maybe there are more elements that can be skipped during boot to realise a faster boot time.

[pietrushnic]

Any boot time optimization should start with measurement. What is the current firmware boot time, precisely?

[miczyg1]

While quiet boot is a simple modification, fast boot isn't. Also fast boot and quiet boot are two different things and should not be mixed.

plus skipping things like searching for boot options

If we do that, everything will fall apart most likely. The drivers still need to initialize the storage to load the OS bootloader. It is not the boot option searching that takes most of the time, but I/O device enumeration and initialization from my experience. Searching for boot options is actually not that time consuming.

We could skip drivers that initialize everything else than SATA and NVMe, but then there is no way to enter setup during boot nor to have any input, if the USB and PS/2 drivers would not be loaded. I'm not aware of any good public reference for a fastboot option, thus I have no ideas how to approach it properly and not cause problems for device owners. Slimbootloader has fast boot but it essentially skips the graphics initialization, measured boot and verified boot (so basically strips security and output device initialization).

[wessel-novacustom]

While quiet boot is a simple modification, fast boot isn't. Also fast boot and quiet boot are two different things and should not be mixed.

plus skipping things like searching for boot options

If we do that, everything will fall apart most likely. The drivers still need to initialize the storage to load the OS bootloader. It is not the boot option searching that takes most of the time, but I/O device enumeration and initialization from my experience. Searching for boot options is actually not that time consuming.

We could skip drivers that initialize everything else than SATA and NVMe, but then there is no way to enter setup during boot nor to have any input, if the USB and PS/2 drivers would not be loaded. I'm not aware of any good public reference for a fastboot option, thus I have no ideas how to approach it properly and not cause problems for device owners. Slimbootloader has fast boot but it essentially skips the graphics initialization, measured boot and verified boot (so basically strips security and output device initialization).

Thank you for the technical feedback on this.

Do you see any other option to reduce boot times?

[miczyg1]

Do you see any other option to reduce boot times?

Like @pietrushnic said, measurements first. Then we can talk what we can improve. I/O device enumeration is what takes the most time from my experience, but it varies from platform to platform.

[pietrushnic]

IMHO, we should have reliable boot time measurements. I'm pretty sure we are doing it as part of testing, but do we have information on how much time each phase takes?

[Firminator]

@miczyg1 "prints strings on the screen indicating the menu prompt"
Are you refering to the 3 line menu on the upper left (DEL for Setup, F11 for Boot Menu, ENTER for Boot)? If not a screenshot would be helpful for context.

Other (proprietary) BIOS I have seen in the past have a "full screen boot logo" option. Dell devices, Lenovo laptops, and even the stock MSI Z690 I believe has it. This option sounds similar to what you like to achieve (just show the boot logo with no text).

Either way I agree measurement first before trying to optimize.

[miczyg1]

Are you refering to the 3 line menu on the upper left (DEL for Setup, F11 for Boot Menu, ENTER for Boot)? If not a screenshot would be helpful for context.

Yes, these ones. There are also extra liens with firmware version and EC version printed on laptops too.

Other (proprietary) BIOS I have seen in the past have a "full screen boot logo" option. Dell devices, Lenovo laptops, and even the stock MSI Z690 I believe has it. This option sounds similar to what you like to achieve (just show the boot logo with no text).

Full screen boot logo? No, that's not it. Boot logo does not have to be stretched to the whole screen. Quiet boot just means that nothing is printed on the screen except logo.

There is still open question what to do about warnings like vboot, battery, etc. Those should still remain IMO.

IMHO, we should have reliable boot time measurements. I'm pretty sure we are doing it as part of testing, but do we have information on how much time each phase takes?

@pietrushnic coreboot has detailed timestamps at each initialization point. EDK2 seems to measure many events too based on the source code. However in Linux we can only see:
bootloader_launch_ns bootloader_load_ns exitbootservice_end_ns exitbootservice_start_ns firmware_start_ns in the sysfs of FPDT ACPI table. It looks like some kind of summarized info on the boot performance. But there should be more detailed records of the UEFI Payload execution. I just have to find it (and parse).

[miczyg1]

UEFI Shell has a command dp which displays the performance measurements. Sample output from MSI platform:

boot_perf.log

It probably also includes the actions I have taken to dump these (i.e entering setup, then UEFI shell, then typing the command and redirecting the output to a file in a fielsystem). But as suspected, the most notable are the consoles, device enumeration and partitions/filesystem drivers, screenshot driver. And the I/O devices in general (mainly PS/2 keyboard).

[pietrushnic]

This is a lovely dump we should get every time we release. The key question is what can be optimized. PS/2 timing looks crazy.

[Firminator]

Thanks @miczyg1 for figuring this out. After all those years I'm glad to see there is now measurable data on boot/initialization performance when disabling unused devices and controllers. I've been disabling the PS/2 and IDE/ATA and/or SATA controllers for years in my various builds in best faith that I can shave off a few milliseconds of boot time. Being able to measure this with DP is huge.
The Screenshot driver timings are off the chart. The screenshot functionality could be exposed in the Setup menu for the user to be able to enable-on-demand for when reporting an issue, but else keep it disabled by default.

@miczyg1 How do redirec the dp -v output to a USB flash drive?

[mkopec]

The screenshot delay is even more annoying, it's just stalling to display a status indicator in the screen corner :\ Can be removed or hidden behind a build option for our purposes IMO. Other than this delay it shouldn't take up any meaningful amount of time

[miczyg1]

@miczyg1 How do redirec the dp -v output to a USB flash drive?

@Firminator When entering the UEFI Shell, it will print available filesystems. You can redirect the output like on any other Linux. E.g.

Shell> FS0:
FS0> dp > boot_perf.log

[miczyg1]

This is a lovely dump we should get every time we release. The key question is what can be optimized. PS/2 timing looks crazy.

We can't if we want to remove the UEFI Shell from builds. I recall we wanted to get rid of the internal UEFI Shell because of Secure Boot. So we would have to think first about adding an option to boot UEFI Shell from an external filesystem, subject to Secure Boot verification, if anything.

[pietrushnic]

Yes, we should carefully consider that. I hoped the Zarhus Team (@artur-rs cc) would update their UEFI Secure Boot tests. The best course of action is to create a Shell signed with robot-made keys, then those keys are provisioned, and we can do other tests like a Suite Prep procedure.

[miczyg1]

Yes, we should carefully consider that. I hoped the Zarhus Team (@artur-rs cc) would update their UEFI Secure Boot tests. The best course of action is to create a Shell signed with robot-made keys, then those keys are provisioned, and we can do other tests like a Suite Prep procedure.

Tests may run UEFI Shell with Secure Boot disabled, no need to go to such lengths to sign the Shell binary. I think we have separate tests for testing the signing and the verification.

[pietrushnic]

Yeah, it makes much more sense. I think just secure boot-related tests that rely on the uefi shell should be changed, but it is out of the scope of this issue.

[wessel-novacustom]

This is a lovely dump we should get every time we release. The key question is what can be optimized. PS/2 timing looks crazy.

We can't if we want to remove the UEFI Shell from builds. I recall we wanted to get rid of the internal UEFI Shell because of Secure Boot. So we would have to think first about adding an option to boot UEFI Shell from an external filesystem, subject to Secure Boot verification, if anything.

|￣￣￣￣￣￣￣￣￣￣￣￣￣￣| 
|    Make UEFI shell    | 
| disabled by default!  | 
|＿＿＿＿＿＿＿＿＿＿＿＿＿＿| 
     \          / 
      \ (•◡•)  /
       \      / 
        ——————
        |    | 
        |_   |_

[mkopec]

If we really need UEFI shell for some tests, we can simply put in on the ESP instead of including it in firmware. Then we could remove the builtin shell or build a stripped down version (MIN_SHELL)

This way we keep the tests working and become compliant with secure boot.

[miczyg1]

If we really need UEFI shell for some tests, we can simply put in on the ESP instead of including it in firmware. Then we could remove the builtin shell or build a stripped down version (MIN_SHELL)

That's exactly what I meant by UEFI Shell launched from external filesystem. It may either be an option in the boot menu (which scans all filesystems in search of /Shell.efi and boots it), or you can name Shell.efi as /EFI/BOOT/BOOTX64.EFI as a last resort.

[miczyg1]

After the analysis of sources and the performance report pasted in the issue, the plan may look as follows:

1. Use PcdConInConnectOnDemand when fastboot enabled, to limit the console handling time and connect console input only when it is needed. OS bootloader may try to read keystrokes and it will trigger connecting the consoles, e.g. GRUB. Firmware will not set up console input before loading the OS bootloader. One may also request entering the FW setup from the OS itself:

• Windows: through Windows Recovery Environment - Microsoft Support (enter UEFI firmware settings)
• Linux: by executing command systemctl reboot --firmware
  Once FW enters UI, it will connect all consoles and input will work.

2. Do not load/launch extra filesystem drivers on fastboot.
3. CrScreenshotDxe, get rid of status check in this line and 500ms stall: CrScreenshotDxe/CrScreenshotDxe.c at master · LongSoft/CrScreenshotDxe (fork most likely)
4. Only run VGA OptionROMs on fastboot.
5. Boot Timeout should be 0 on fastboot.

Of course adding 2 checkboxes in menu. I think the best place is Boot Mainetnance Manager, where the timeout lives. So:

Enable Fast Boot [] (default disabled)
Enable Quiet Boot [] (default disabled)

Enabling fastboot will case:

• boot timeout 0s (not updated in the menu, to avoid keeping the previous value in UEFI variables and occupying extra space), in short if fastboot then Timeout = 0 else ReadVar(Timeout)
• quiet boot (not updated in the menu, to avoid keeping the previous value in UEFI variables and occupying extra space), in short do not print prompts and progress bar if fastboot or quietboot

I think fastboot and quiet boot variable may be exposed to OS, so that anybody can disable it when needed.

Plus documenting new options, writing new tests specification.

BTW: we have an issue for fastboot: #115

[miczyg1]

PR: Dasharo/edk2#204

[Firminator]

Will this fix (shaving off the 500ms from the Screenshot UEFI driver) be made available for the Z690?