f28eb485 | 06-May-2019 |
Warner Losh <imp@FreeBSD.org> |
We only ever need one devinfo per handle. So allocate it outside of looping over the filesystem modules rather than doing a malloc + free each time through the loop. In addition, nothing changes from
We only ever need one devinfo per handle. So allocate it outside of looping over the filesystem modules rather than doing a malloc + free each time through the loop. In addition, nothing changes from loop to loop, so setup the new devinfo outside the loop as well.
show more ...
|
4ecd512f | 29-Apr-2019 |
Warner Losh <imp@FreeBSD.org> |
Implement uefi_ignore_boot_mgr env variable.
When set, we ignore all the hints that the UEFI boot manager has set for us. We also always fail back to the OK prompt when we can't find the right thing
Implement uefi_ignore_boot_mgr env variable.
When set, we ignore all the hints that the UEFI boot manager has set for us. We also always fail back to the OK prompt when we can't find the right thing to boot rather than failing back to the UEFI boot manager. This has the side effect of also expanding the cases where we fail back to the OK prompt to include when we're booted under UEFI, but UEFI::BootCurrent isn't set in the environment and we can't find a proper place to boot from.
Reviewed by: bcran Differential Revision: https://reviews.freebsd.org/D20016
show more ...
|
bc6053b3 | 29-Apr-2019 |
Warner Losh <imp@FreeBSD.org> |
Implement uefi_rootdev
If uefi_rootdev is set in the environment, then treat it like a device path. Convert the string to a device path and see if we can find a device that matches. If so, use that
Implement uefi_rootdev
If uefi_rootdev is set in the environment, then treat it like a device path. Convert the string to a device path and see if we can find a device that matches. If so, use that device at our root dev no matter what. If it's bad in any way, the boot will fail.
Reviewed by: bcran Differential Revision: https://reviews.freebsd.org/D20016
show more ...
|
8ac2d6f5 | 29-Apr-2019 |
Warner Losh <imp@FreeBSD.org> |
Read in and parse /efi/freebsd/loader.env from the boot device's partition as if it were on the command line.
Fetch FreeBSD-LoaderEnv UEFI enviornment variable. If set, read in loader environment va
Read in and parse /efi/freebsd/loader.env from the boot device's partition as if it were on the command line.
Fetch FreeBSD-LoaderEnv UEFI enviornment variable. If set, read in loader environment variables from it. Otherwise read in /efi/freebsd/loader.env. Both are read relative to the device loader.efi loaded from (they aren't full UEFI device paths)
Next fetch FreeBSD-NextLoaderEnv UEFI environment variable. If present, read the file it points to in as above and delete the UEFI environment variable so it only happens once.
This lets one set environment variables in the bootloader. Unfortunately, we don't have all the mechanisms in place to parse the file, nor do we have the magic pattern matching in place that loader.conf has. Variables are of the form foo=bar. No quotes are supported, so spaces aren't allowed, for example. Also, variables like foo_load=yes are intercepted when we parse the loader.conf file and things are done based on that. Since those aren't done here, variables that cause an action to happen won't work.
Reviewed by: bcran Differential Revision: https://reviews.freebsd.org/D20016
show more ...
|
8c914c57 | 25-Apr-2019 |
Warner Losh <imp@FreeBSD.org> |
Move initialization of the block device handles earlier (we're just snagging them from UEFI BIOS). Call the device type init routines earlier as well, as they don't depend on how the console is setup
Move initialization of the block device handles earlier (we're just snagging them from UEFI BIOS). Call the device type init routines earlier as well, as they don't depend on how the console is setup. This will allow us to read files earlier in boot, so any rare error messages that this might move only to the EFI console will be an acceptable price to pay. Also tweak the order of has_kbd so it resides next to the rest of the console code. It needs to be after we initialize the buffer cache.
show more ...
|