PATH_BOOTABLE_TOKEN can be set to a non-standard
path that identifies a device as bootable.
Reviewed by: kevans, bcran
Differential Revision: https://reviews.freebsd.org/D22062
Since local UEFI console is implemented on top of framebuffer,
we need to avoid redrawing the whole screen ourselves, but let
Simple Text Mode to do the scroll for us.
Add settable variables to control teken default color attributes.
The supported colors are 0-7 or basic color names:
black, red, green, brown, blue, magenta, cyan, white.
The current implementation does add some duplication which will be addressed
later.
UEFI specification 2.7A, EFI_BLOCK_IO_PROTOCOL, page 566.
The ioalign property does define the alignment of data buffer.
If the alignment is required and our buffer is not aligned, or if
the data buffer is not multiple of Blocksize, we need to use bounce buffer
to perform the block IO. This is much like with BIOS version, except
there the INT13 needs buffer to be located in low memory.
Additionally, we need to handle disk writes properly.
Replace mini cons25 emulator with teken, this does enable us proper console
terminal for loader and will make it possible to implement different
back end callbacks to draw to screen.
At this time we still only "draw" in text mode.
The cd handles should be collected as list of partitions. Some systems also
provide base name for block device (like PciRoot(0x0)/Pci(0x5,0x0)), we need
to be careful about those.
To make out life a bit easier, we prepare not just an array of handles, but we
allocate pdinfo struct for each handle and devicepath, then we can simplify
our work to sort the devices.
Differential Revision: https://reviews.freebsd.org/D21187
Reduce the size of the EFI_STAGING area we allocate on arm to 32. On arm SBC
such as the NanoPi-NEOLTS the staging area allocation will fail on the 256MB
model with a staging size of 64.
Reviewed by: bcran, manu
Approved by: bz (mentor)
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D21016
We should support removing vdev from boot pool. Update loader zfs reader
to support com.delphix:removing.
Reviewed by: allanjude
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D18901
The chain command can be used to chain load another binary.
If veriexec is enabled we should verify it first.
Note that on EFI systems the verification was already done
through firmware, assuming that Secure Boot was enabled there.
Submitted by: Kornel Duleba <mindal@semihalf.com>
Reviewed by: sjg
MFC after: 1 week
Obtained from: Semihalf
Differential Revision: https://reviews.freebsd.org/D20952
The HandleProtocol() is deprecated interface and we should use OpenProtocol()
instead. Moreover, in some firmware implementation(s), the HandleProtocol()
does return device path using static storage, so we can not keep the value
returned there. With same firmware, the OpenProtocol() does return data we
do not need to clone.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D21162
Summary:
efi loader does not work with static network parameters. It always uses
BOOTP/DHCP and also uses RARP as a fallback. Problems with DHCP servers can
cause the loader to fail to populate network parameters.
Submitted by: Siddharth Tuli <siddharthtuli_gmail.com>
Reviewed by: imp
Sponsored by: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D20811
To avoid failures when the large 18MB nvidia.ko module is being loaded,
increase EFI_STAGING_SIZE from 64MB to 100MB on x64 systems.
Leave the other platforms at 64MB.
The code in efihttp.c was assuming that dv_open wouldn't be called if
dv_init failed. But the dv_init return value is currently ignored.
Add a new variable, `efihttp_init_done` and only proceed in dv_open if
it's true. This fixes the loader on systems without efi http support.
Add support for an HTTP "network filesystem" using the UEFI's HTTP
stack.
This also supports HTTPS, but TianoCore EDK2 implementations currently
crash while fetching loader files.
Only IPv4 is supported at the moment. IPv6 support is planned for a
follow-up changeset.
Note that we include some headers from the TianoCore EDK II project in
stand/efi/include/Protocol verbatim, including links to the license instead
of including the full text because that's their preferred way of
communicating it, despite not being normal FreeBSD project practice.
Submitted by: scottph
Reviewed by: imp, bcran
Differential Revision: https://reviews.freebsd.org/D20643
Don't commit to exclusive access to the network device handle by
efinet until the loader has decided to load something through the
network. This allows for the possibility of other users of the
network device.
Submitted by: scottph
Reviewed by: tsoome, emaste
Tested by: tsoome, bcran
Differential Revision: https://reviews.freebsd.org/D20642
Add the customary warnings to disable format checking on armv7. Code
move to new files, and the unconditional setting of WARNS to 6
provoked it on tinerbox...
This is a primary boot loader that is intended to implement the
gptboot partition selection algorithm just like we did for BIOS
booting. While the preferred method for UEFI is to use the UEFI Boot
Manager protocol, there are situations where that can't be done: some
BIOS makers interfere with the protocol in unhelpful ways, there's a
new standard for a zero variable write from the client OS, and finally
for USB drives that might be mobile between systems with multiple
partitions there needs to be a media stable way to select.
Reviewed by: tsoome, bcran
Differential Revision: https://reviews.freebsd.org/D20547
Segregate the disk probing and selection protocol from the rest of the
boot loader.
Reviewed by: tsoome, bcran
Differential Revision: https://reviews.freebsd.org/D20547
Simplify the code a bit and rework how we report the results
of the probing.
Reviewed by: tsoome@
Differential Revision: https://reviews.freebsd.org/D20537
BootServices AllocatePool/FreePool calls. They are simpler to use and
result in the same thing happening.
Reviewed by: tsoome@
Differential Revision: https://reviews.freebsd.org/D20540
This is like efi_devpath_match, but allows differing device media
paths. Those just specify the partition information.
Differential Revision: https://reviews.freebsd.org/D20513
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.
We're storing an EFI_HANDLE, not an pointer to a handle. Since
EFI_HANDLE is a void * anyway, this has little practical effect since
the conversion to / from void * and void ** is silent.
Small mis-merge from multiple WIP resulted in block io media handles getting
double-initialized. This resulted in some installations oddly landing at the
mountroot prompt.
Reported by: ler
Reviewed by: imp
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
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
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
illumos update: https://www.illumos.org/issues/10598
Add map-vdisk and unmap-vdisk commands to create virtual disk interface on top of file. This will allow to use disk image from file system to load and start the kernel.
By mapping file, we create vdiskX device, the device will be listed by lsdev [-v] and can be accessed directly as ls vdisk0p1:/path or can be used as value for currdev variable.
vdisk strategy function does not use bcache as we have bcache used with backing file. vdisk can be unmapped when all consumers have closed the open files.
In first iteration we do not support the zfs images because zfs pools do keep the device open (there is no "zpool export" mechanism). Adding zfs support is relatively simple, we just need to run zfs disk probe after mapping is done.
Differential Revision: https://reviews.freebsd.org/D19733
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.
When efi_autoload is called it will call fdt_setup_fdtp which setup the
dtb and overlays. If a user already loaded at dtb or overlays or just
printed the efi provided dtb, this will re-setup everything and also
re-applying the overlays.
Test that everything is setup before doing it again.
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D20059
Get the information from the image that we're booting and store it in
a global variable. Prefer using this to passing it around. Remove the
special case for zfs that set the preferred boot handle by having it
uses this global variable diretly.
Reviewed by: kevans@
Differential Revision: https://reviews.freebsd.org/D20015
There's no reason we can't setup the console first thing after the
arch flags are setup. We set it undconditionally to efi. This is a
good default, and will get us error messages to at least the efi
console no matter what. This will also prime the pump so that as other
variables are set, they will take effect and the console will be
correct as soon as those env vars are set. Also remove the redundant
setting of the console to efi when we know the console is efi.
Differential Revision: https://reviews.freebsd.org/D20014
There's a number of EFI_ZFS_BOOT #ifdefs that aren't needed, or can be
eliminated with some trivial #defines. Remove the EFI_ZFS_BOOT ifdefs
that aren't needed. Replace libzfs.h include which is not safe to
include without EFI_ZFS_BOOT with efizfs.h which is and now
conditionally included libzfs.h. Define efizfs_set_preferred away
and define efi_zfs_probe to NULL when ZFS is compiled out.
In anticipation of new functionality, create routines to convert char *
and a CHAR16 * to a EFI_DEVICE_PATH
EFI_DEVICE_PATH *efi_name_to_devpath(const char *path);
EFI_DEVICE_PATH *efi_name_to_devpath16(CHAR16 *path);
void efi_devpath_free(EFI_DEVICE_PATH *dp);
The first two return an EFI_DEVICE_PATH for the passed in paths. The
third frees up the storage the first two return when the caller is
done with it.
Differential Revision: https://reviews.freebsd.org/D19971
Add definitions from UEFI 2.7 Errata B standards doc for converting a
text string to a device path. Added clearly missing 'e' at the end of
Device to resolve mismatch in that document in
EFI_DEVICE_PATH_FROM_TEXT_PROTOCOL element names.
Differential Revision: https://reviews.freebsd.org/D19971
Newer interfaces take CONST parameters, so define CONST to minimize
differences between our headers and the standards docs.
Differential Revision: https://reviews.freebsd.org/D19971
It was pointed out that manually loading a .dtb to be used rather than
relying on platform-specific method for loading .dtb will result in overlays
not being applied. This was true because overlay loading was hacked into
fdt_platform_load_dtb, rather than done in a way more independent from how
the .dtb is loaded.
Instead, push overlay loading (for now) out into an
fdt_platform_load_overlays. This method easily allows ubldr to pull in any
fdt_overlays specified in the ub env, and omits overlay-checking on
platforms where they're not tested and/or not desired (e.g. powerpc). If we
eventually stop caring about fdt_overlays from ubenv (if we ever cared),
this method should get chopped out in favor of just calling
fdt_load_dtb_overlays() directly.
Reported by: Manuel Stühn (freebsdnewbie freenet de)
The values of the d_slice and d_partition fields of a disk_devdesc have a
few values with special meanings in the disk_open() routine. Through various
evolutions of the loader code over time, a d_partition value of -1 has
meant both "use the first ufs partition found in the bsd label" and "don't
open a bsd partition at all, open the raw slice."
This defines a new special value of -2 to mean open the raw slice, and it
gives symbolic names to all the special values used in d_slice and
d_partition, and adjusts all existing uses of those fields to use the new
constants.
The phab review for this timed out without being accepted, but I'm still
citing it below because there is useful commentary there.
Differential Revision: https://reviews.freebsd.org/D19262
UEFI related headers were copied from edk2.
A new build option "MK_LOADER_EFI_SECUREBOOT" was added to allow
loading of trusted anchors from UEFI.
Certificate revocation support is also introduced.
The forbidden certificates are loaded from dbx variable.
Verification fails in two cases:
There is a direct match between cert in dbx and the one in the chain.
The CA used to sign the chain is found in dbx.
One can also insert a hash of TBS section of a certificate into dbx.
In this case verifications fails only if a direct match with a
certificate in chain is found.
Submitted by: Kornel Duleba <mindal@semihalf.com>
Reviewed by: sjg
Obtained from: Semihalf
Sponsored by: Stormshield
Differential Revision: https://reviews.freebsd.org/D19093
The call to BS->AllocatePages can cause the memory map to become framented,
causing BS->GetMemoryMap to return EFI_BUFFER_TOO_SMALL more than once. For
example this can happen on the MinnowBoard Turbot, causing the boot to stop
with an error. Avoid this by calling GetMemoryMap in a loop.
Reviewed by: imp, tsoome, kevans
Differential Revision: https://reviews.freebsd.org/D19341
ExitBootServices terminates all boot services including console access.
Attempting to call printf afterwards can result in a crash, depending on the
implementation.
Move any printf statements to before we call bi_load, and remove any that
depend on calling bi_load first.
Reviewed by: imp, tsoome
Differential Revision: https://reviews.freebsd.org/D19374
r328169 removed the copy of bootinfo that would've made this somewhat
functional. However, this is irrelevant- earlier work in r292338 was done to
exit boot services in the MI bi_load() rather than having N copies of the
GetMemoryMap/ExitBootServices dance.
i386 never quite caught up to that; ldr_enter was still being called but
the prereq for that, ldr_bootinfo, was no longer. As a consequence, this
ExitBootServices() was being called with a mapkey=0, clearly bogus, and
reportedly breaking the boot in some instances.
Reported by: bcran
MFC after: 1 week
When loading bigger variables form UEFI it is necessary to know their
size beforehand, so that an appropriate amount of memory can be
allocated. The easiest way to do this is to try to read the variable
with buffer size equal 0, expecting EFI_BUFFER_TOO_SMALL error to be
returned. Allow such possible approach in efi_getenv routine.
Extracted from a bigger patch as suggested by imp.
Submitted by: Kornel Duleba <mindal@semihalf.com>
Obtained from: Semihalf
Sponsored by: Stormshield
Use recent best practices for Copyright form at the top of
the license:
1. Remove all the All Rights Reserved clauses on our stuff. Where we
piggybacked others, use a separate line to make things clear.
2. Use "Netflix, Inc." everywhere.
3. Use a single line for the copyright for grep friendliness.
4. Use date ranges in all places for our stuff.
Approved by: Netflix Legal (who gave me the form), adrian@ (pmc files)
This update does add diag and debug capabilities to interpret the efi
variables, configuration and protocols (lsefi).
The side effect is that we add/update bunch of related headers.
With the default Qemu parameters, only 128MB RAM gets given to a VM. This causes
the loader to be unable to allocate the 64MB it needs for the heap. This change
makes the cause of the error more obvious.
Differential Revision: https://reviews.freebsd.org/D17958
This fix is ported from illumos (issue #9970), the analysis and initial
implementation was done by John Levon.
See also: https://www.illumos.org/issues/9970
Currently, efi_cons_getchar() will wait for a key. While this seems to make
sense, the implementation of getchar() in common/console.c will loop across
getchar() for all consoles without doing ischar() first.
This means that if we've configured multiple consoles, we can't input into
the serial, as getchar() will be sat waiting for input only from efi_console.c
This patch does implement a bit more generic key buffer to support
translation of input keys, and we use generic efi_readkey() to reduce
duplication from calls from getchar() and poll().
Pointer math to find the size in bytes only works with char types.
Use correct pointer math to determine if we have enough of a header to
look at or not.
MFC After: 3 days
X-MFX-With: r339800
Noticed by: jhb@
Sponsored by: Netflix, Inc
its length. Some BIOSes pad the length of the device path to an even
amount. When we had a device path that was somehow an odd length, we'd
wind up having 1 byte left that we were bogusly interpreting as a full
device path. We'd then dereference 2 bytes into that to get a length
of the node, which had undefined (and quite undesired) effects.
Sponsored by: Netflix, Inc
MFC After: 3 days
Add poweroff command to make life a bit easier.
Reviewed by: imp, allanjude
Approved by: re (kib)
Differential Revision: https://reviews.freebsd.org/D17535
Lua has a few places where it allocates a large buffer on the stack. This
is normally fine, except there are a few places where there can be multiple
frames with this buffer. This can cause a stack overflow on some arm64 SoCs.
Fix this by allocating our own stack in loader.efi large enough for these
objects. The required size has been found by tracing how the stack pointer
changes in a virtual machine and found to be no larger than 50kB. A
larger stack is allocated to reduce the likelihood of overflow from future
changes.
Reviewed by: kevans
Approved by: re (kib)
Differential Revision: https://reviews.freebsd.org/D16886
manu found in the noted PR that overlays seemed to be clobbering the kenv
and killing the boot. Further inspection revealed that one can `fdt ls` at
the loader prompt for a successful boot, but autoboot breaks it.
In the autoboot case, first setup of FDT is happening in the middle of
bi_load, which triggers loading of the DTBO from /boot.
This is bad, bad, bad. Files in the loader are loaded somewhere in the
middle of the address space one after another. bi_load starts building the
needed kernel bootinfo immediately after the highest-addr loaded file. File
loads in the middle of bi_load suddenly clobber bootinfo and everything goes
off the rails.
The solution to this is to use take advantage of arch_autoload to setup FDT
in efiloader compiled with LOADER_FDT_SUPPORT. This matches how it works in
ubldr land, and is how it should have worked when overlay support was added
to efiloader since fdt_setup_fdtp now has the potential to load files
(courtesy of fdt_platform_load_dtb).
PR: 230804
Discussed with: imp
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D16858
Compiling FreeBSD/i386 with modern GCC triggers warnings for various
places that convert 64-bit EFI_ADDRs to pointers and vice versa.
- Cast pointers to uintptr_t rather than to uint64_t when assigning
to a 64-bit integer.
- Cast 64-bit integers to uintptr_t before a cast to a pointer.
Reviewed by: kevans
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D16586
Create loader_{4th,lua,simp}{,.efi}. All of these are installed by
default. Create LOADER_DEFAULT_INTERP to specify the default
interpreter when no other is specified. LOADER_INTERP is the current
interpreter language building. Turn building of lua on by default to
match 4th. simploader is a simplified loader build w/o any interpreter
language (but with a simple loader). This is the historic behavir you
got with WITHOUT_FORTH. Make a hard link to the default loader. This
has to be a hard link rather than the more desirable soft link because
older zfsboot blocks don't support symlinks.
RelNotes: Yes
Differential Revision: https://reviews.freebsd.org/D16705
efi-autoresizecons is currently executed for every boot. If it fails, we
risk failing the boot, and we really shouldn't do that unless we absolutely
must.
Not being able to locate GOP or UGA is not a significant enough failure to
kill the boot. We always have the option to fall back to resizing ConOut to
a higher text mode resolution (if available), so do that.
This was detected by Doug [1] while attempting a bhyve + UEFI + PXE boot.
This patch was effectively also submitted by Doug, but I expanded the
comment he had originally sent me a little bit to indicate why this is an OK
idea.
Reported by: Doug Ambrisko <ambrisko@ambrisko.com> [1]
If there are no block devices, there is no need to printout
error (ENOENT).
In case of netboot, our image path has no block device, no need to make
noise about it.
Note when we've found a 8250 PNP node. Only try to set hw.uart.console
if we see one (otherwise ignore serial hints). The 8250 is the only
one known to have I/O ports, so limit the guessing to when we've
positively seen one. And limit this to x86 since that's the only
platform where we have I/O ports. Otherwise, we'd set the serial port
to something crazy for the platform and fall off the cliff early in
boot.
Differential Revision: https://reviews.freebsd.org/D16463
Add some verbose debugging information to the loader's new
choices. I'll remove these / put them behind a DEBUG define at a later
time. This is to give additional information if there's any dangling
edge cases not contemplated by the code. r336789 had most of this
change, but had the wrong commit message. This refines it slightly.
nodes. These show up in default entries on SuperMicro motherboards and
elsewhere. Before, we couldn't find a block device associated with the
device path and return BAD_CHOICE which was an instant
failure. However, a VendHw node isn't specifc, so when we don't find a
media path, return NOT_SPECIFIC so that the rest of the algorithms
work.
Sponsored by: Netflix.
loading.
If we are booting in a conforming UEFI Boot Manager Environment, then
use the BootCurrent variable to find the BootXXXX we're using. Once we
find that, then if it contains more than one EFI_DEVICE_PATH in its
what to boot section, try to use the last one as the kernel to
load. This will also set the default root partition as well. If
there's only one path, or if there's an error along the way, assume
that nothing specific was specified and revert to the old
algorithm. If something was specified, but not found, then fail the
boot. Otherwise you that, specific thing. On FreeBSD, this can be set
using efibootmgr -l <loader> -k <kernel>. We try a few variations of
kernel to cope with the fact that UEFI comes from a DOS world where
paths might be upper case and/or contain back-slashes.
Note: In an ideal world, we'd work out where we are in chain loading
by looking at the passed-in image handle and doing name
matching. However, that's unreliable since at least boot1.efi booted
images don't have that, hence the assumption that loader.efi needs to
load the last thing on the list, if possible.
The reason we fail for something specific is so that we can fully
participate in the UEFI Boot Manager Protocol and fail over to the
next item in the list of BootOrder choices when something goes wrong
at this stage.
This implements was was talked about in freebsd-arch@ last year
https://docs.freebsd.org/cgi/getmsg.cgi?fetch=3576+0+archive/2017/freebsd-arch/20171022.freebsd-arch
and documented in full (after changed resulting from the discussion) in
https://docs.google.com/document/d/1aK9IqF-60JPEbUeSAUAkYjF2W_8EnmczFs6RqCT90Jg/edit#
although one or two minor details may have been modified in this
implementation to make it work, and the ZFS MEDIA PATH extension isn't
implemented. This does not yet move things to ESP:\efi\freebsd\loader.efi.
RelNotes: Yes
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D16403
Lookup a block device by it's device path. We use a 'loose' lookup
whereby we scan forward to the first Media Path portion of the device
path, then look at all our handles for one whose first Media Path
matches. This will also work if the device path pointed to has a
following file path (or paths) as that's ignored. It assumes that
there's only one media path node that describes the entire device,
which is true as of the latest UEFI spec (2.7 Errata A) as far as I've
been able to determine.
Sponsored by: Netflix
Returns true if the first node pointed to by devpath1 is identical to
the first node pointed to by devpath2, with care taken to not read
past the end of the valid parts of either devpath1 or
devpath2. Otherwise, returns false.
Sponsored by: Netflix
Takes a generic device path as its input. Scans through it to find the
first media_path node in it and returns a pointer to it. If none is
found, NULL is returned.
Sponsored by: Netflix
line args. I had thought console would be NULL, but it's efi. Set it
to efi (as a clue) before we initialize the console, then test it to
see if it changed on the command line to do the automatic
override. This gets my serial console back.
Setting rootdev in the enviornment should specify things
completely. If it is set, then have it override everything else.
PR: 229770
Differential Review: https://reviews.freebsd.org/D16322
up serial output. Setting the cursor position after every character is
inefficient, and causes all lines to be over-printed in the serial
console for the boot loader. Allow the terminal to do the emulation.
This isn't completely perfect when the size of the terminal attached
to the serial port isn't the same as 80x25 to match the viedoe console
(or whatever the video console is). While imperfect still, these
changes make it much better.
This makes the serial port useful with UEFI.
Differential Revision: https://reviews.freebsd.org/D16309
o Fix the parsing of the device path. a last minute change terminated
it too soon.
o Kill setting LINES. We don't need to do it, and even if we did hard
coding it to 24 is wrong.
o Now that the console is working again for the loader, adjust the
printfs to be more in line with other platforms.
note that r336270's commit message was slightly incorrect. It changed
the default setting of the console to honor the ConOut
variable. Overrides via the command line are still possible, and we
use the devices in ConOut to set the proper console. If, for example,
serial cosnole is specified, we'll set console to "efi" if ConOut has
a serial port list and to either "efi comconsole" or "comconsole efi"
if not depending on whether -D or -D -h was specified.
RelNotes: Yes
Sponsored by: Netflix
For server machines, ComOut is set to the set of devices that the efi
console suppots. Parse it to see if we have serial, video or both.
Make that take precidence over the command line args. boot1.efi parses
them, but loader.efi doesn't. It's not clear where to read boot.conf
from, so we don't do that. The command line args can still be set via
efibootmgr, which is more inline with the UEFI boot manager to replace
that. These args are typically used only to set serial vs video and
the com speed line. We can infer that from ComOut, so do so.
Remember the com speed and hw.uart.console to match.
RelNotes: yes
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D15917
This moves the bulk of the geli support from lib386/biosdisk.c into a new
geli/gelidev.c which implements a devsw-type device whose dv_strategy()
function handles geli decryption. Support for all arches comes from moving
the taste-and-attach code to the devopen() function in libsa.
After opening any DEVT_DISK device, devopen() calls the new function
geli_probe_and_attach(), which will "attach" the geli code to the open_file
struct by creating a geli_devdesc instance to replace the disk_devdesc
instance in the open_file. That routes all IO for the device through the
geli code.
A new public geli_add_key() function is added, to allow arch/vendor-specific
code to add keys obtained from custom hardware or other sources.
With these changes, geli support will be compiled into all variations of
loader(8) on all arches because the default is WITH_LOADER_GELI.
Relnotes: yes
Sponsored by: Microchip Technology Inc
Differential Revision: https://reviews.freebsd.org/D15743
Eliminate 4 of the copies of the arg parsing in /boot/laoder
by using boot_parse_cmdline.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D16205
Move the libzfs stuff into libsa. There's no need for it to be a
separate library. The separate library adds to the issues of build
ordering that we see from time to time. Move the filesystem support
into libsa, like all the other filesystem support rather than making
zfs the odd-duck out.
Discussed with: allanjude@
While in base we use it as a boolean (of the wrong spelling), there's
at least one out of tree user that needs it to be int since priorirty
is a small int, not a 0/1. In deference to the time it's wasted me and
my team, push this up into FreeBSD for whatever short life boot1 may
have in the tree.
table if we're just going to ignore it on arm, so expand, slightly,
the reach of the ifdef. Move the buffer to the inner block so we
don't have a separate #ifdef far away from these lines.
The issue on arm is that smbios_detect does unaligned accesses, which
in the u-boot implementing EFI context causes a crash.
is. We tell the ZFS code now, and it checks rather than having a
callback to do the checks.
This will allow us to have a more graceful fallback code. In the
future, it's anticipated that we may fallback to a more global search
(or implement a command to do so) when reqeusted by the user, or we
detect a violation of the UEFI Boot Manager protocol severe enough to
warrant this backstop. For now, it just allows us to get rid of img as
a global.
Sponsored by: Netflix
e.g. boot_mute, boot_single, boot_verbose, and friends; we checked for these
in multiple places, consolidate into common/ and allow a setting of "NO" for
any of these to turn them off. This allows systems with multiple
loader.conf(5) or loader.conf(5) overlay systems to easily turn off
variables in later processed files by setting it to NO.
Reported by: Nick Wolff @ iXsystems
Reviewed by: imp
If the check for a UFS partition at offset 0 on the disk fails, check
to see if there's a BSD disklabel at block 1 (standard) or at offset
512 (install images assume 512 sector size). If found, probe for UFS
on the 'a' partition.
This fixes UEFI booting images from a BSD labeled MBR slice when the
'a' partiton isn't at offset 0. This is a stop-gap fix since we plan
on removing boot1.efi in FreeBSD 12. We can't easily do that for 11.2,
however, hence the short MFC window.
Tested by: emaste@
MFC After: 3 days
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D15598
- We should be setting a known graphics mode on conout, but we aren't.
- We shouldn't be setting gop mode if we didn't find a good resolution to
set, but we were. This made efi_max_resolution=1x1 effectively worthless,
since it would always set gop mode 0 if nothing else.
Harry Schmalzbauer reports that some firmware, in his experience, trips
over the ESP we install due to the volume label. It has been theorized that
this is due to some confusion with the label and the path on the ESP to
boot1.efi.
Regardless, Harry found that renaming the label seems to fix it.
PR: 214282
MFC after: 3 days
Refactor the currdev setting to find the device we booted from. Limit
searching when we don't already have a reasonable currdev from that to
the same device only. Search a little harder for ZFS volumes as that's
needed for loader.efi to live on an ESP.
Sponsored by: Netflix
Differential Review: https://reviews.freebsd.org/D13784
If the network interface or the uefi implementation do not support the
ReceiveFilter interface do not return only and just print a message.
U-Boot doesn't support is and likely never will. Also even if this fails
it doesn't mean that network in EFI isn't supported.
UGA does not have the same kind of mode enumeration that GOP does. Implement
it instead as a call to text_autoresize so that firmwares with only UGA
present still get some kind of autoresizing behavior.
While here, rename a typo'd "gop" to "uga", although it will remain unused
for the time being.
Not all systems use efifb; pull hw.vga.textmode and choose a good console
mode instead if it's set to something non-zero. This is basically a revival
of the code that used to live in boot1, but instead rebased onto this
different way of doing mode selection in loader.efi.
Interestingly enough, the regression that was previously introduced where
GOP would not reflect the console setting does not seem to exist when
console mode selection is done here. I've not done any investigation as to
why this is the case. Nevertheless, boot1.efi is still not the best place to
do mode selection.
