Some systems may provide multiple GOP instances and not all are
bound to hardware. The current loader is picking up the first GOP,
which may not be usable. Instead we load the GOP handle array,
and test every handle to have registered ConOut protocol. If ConOut is
present, we can use this GOP handle to open GOP protocol.
We do select font based on desired terminal size, we do query
UEFI terminal size with conout->QueryMode(), but by mistake, the fallback
values are used.
Pass gfx_state to efi_find_framebuffer(), so we can pick between
GOP and UGA in efi_find_framebuffer(), also we can then
set up struct gen_fb in gfx_state from efifb and isolate efi fb data
processing into framebuffer.c.
This change does allow us to clean up efi_cons_init() and reduce
BS->LocateProtocol() calls.
A little downside is that we now need to translate gen_fb back to
efifb in bootinfo.c (for passing to kernel), and we need to add few
-I options to CFLAGS.
Draw console on efi.
Add vbe framebuffer for BIOS loader (vbe off, vbe on, vbe list,
vbe set xxx).
autoload font (/boot/fonts) based on resolution and font size.
Add command loadfont (set font by file) and
variable screen.font (set font by size). Pass loaded font to kernel.
Export variables:
screen.height
screen.width
screen.depth
Add gfx primitives to draw the screen and put png image on the screen.
Rework menu draw to iterate list of consoles to enamble device specific
output.
Probably something else I forgot...
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D27420
buildworld already runs the stand build in parallel[1], so make it easier to
identify ordering issues by properly establishing dependencies or adding
.WAIT where needed.
Everything in stand/ relies on libsa, either directly or indirectly, because
libsa build is where the stand headers get installed and it gets linked in
most places.
Interpreters depend on their libs, machine dirs usually depend on top-level
libs that are getting built and at least one of the interpreter flavors.
For i386, order btx/libi386/libfirewire before everything else using a
big-ol-.WAIT hammer. btx is the most common dependency, but the others are
used sporadically. This seems to be where the race reporting on the mailing
list is- AFAICT, the following sequence is happening:
1.) One of the loaders gets built based on stale btx/btxldr
2.) btx/btxldr gets rebuilt
3.) installworld triggers loader rebuild because btx was rebuilt after
This seems like the most plausible explanation, as they've verified system
time and timestamps.
While we're here, let's switch stand/ over to a completely parallel build so
we can work out these kinds of issues in isolation rather than in the middle
of a larger build.
Reviewed by: bdragon, sjg, tsoome
Tested by: bdragon (-j1024, no failures, significant speed improvement)
Differential Revision: https://reviews.freebsd.org/D23411
Without this we risk having the .interp section be placed earlier in the
file and mess with section offsets; in particular it has been seen to be
placed at the start of the file and cause the PE/COFF header to not be
at address 0. This is the same fix as was done for arm64 in r365578.
Reviewed by: mhorne, imp
Approved by: mhorne, imp
Differential Revision: https://reviews.freebsd.org/D27603
i386 and the rest of supported architectures by defining KERNLOAD in the
vmparam.h and getting rid of magic constant in the linker script, which albeit
documented via comment but isn't programmatically accessible at a compile time.
Use KERNLOAD to eliminate another (matching) magic constant 100 lines down
inside unremarkable TU "copy.c" 3 levels deep in the EFI loader tree.
Reviewed by: markj
Approved by: markj
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D27355
In some environments is difficult to access bootp/dhcp
configuration as "standard user". Add a command that allows to set
or display the URI of the network server used as "net:" device.
Currently only tftp and nfs protocols are supported.
Typical usage pattern is:
netserver tftp://192.168.168.1/path_to_obj_dir/arm.armv7/sys/GENERIC/
boot net:kernel
Reviewed by: imp, kevans
MFC after: 4 weeks
Differential Revision: https://reviews.freebsd.org/D26736
On startup the arm64 efi loaders need to know PC-relative addresses.
Previously we used the adr instruction to find this address, however this
instruction is limited to +/- 1MiB.
Switch to adrp to find the 4k page the address is within and an add to
set the bottom 12 bits. This lets us address +/- 4GiB which should be
large enough for now.
Reported by: imp
MFC after: 2 weeks
Sponsored by: Innovate UK
Add support to the _STANDALONE environment enough bits of the kernel
that we can compile it. We still have a small zstd_shim.c since there
were 3 items that were a bit hard to nail down and may be cleaned up
in the future. These go hand in hand with a number of commits to
sys/sys in the past weeks, should this need be MFCd.
Discussed with: mmacy (in review and on IRC/Slack)
Reviewed by: freqlabs (on openzfs repo)
Differential Revision: https://reviews.freebsd.org/D26218
This was causing build failures in CheriBSD where we were passing -pie
already by default.
Reviewed By: andrew
Differential Revision: https://reviews.freebsd.org/D24787
The video on PCI heuristic was broken. It was supposed to infer a
video device when the last element of the path was a PCI DEVICE PATH
node. However, the last node in the device path is an END node, so
this heuristic never fired.
This leads, among other things, to bhyve only producing output in the
serial connection once we leave the boot loader. This restores the
dual headed boot on bhyve + UEFI (as we did in 11.2), but will favor
serial in the absence of other config which may be a change from 11.2.
MFC After: 3 days
Differential Revision: https://reviews.freebsd.org/D26572
During devswitch probe, we pick boot pool based on boot disk, if the boot
disk happens to have multiple pools in freebsd-zfs partitions, the current
code does pick last pool from boot disk as boot pool. While there is no
way at that stage to test, the more logical approach would be to pick
first matching pool.
This patch is assuming we do pass pool guid pointer with guid value 0,
this will help us to determine, if the guid value is already set or not.
The general suggestion would be not to share disk between different pools.
Reported by: Alexander Leidinger
bootonce feature is temporary, one time boot, activated by
"bectl activate -t BE", "bectl activate -T BE" will reset the bootonce flag.
By default, the bootonce setting is reset on attempt to boot and the next
boot will use previously active BE.
By setting zfs_bootonce_activate="YES" in rc.conf, the bootonce BE will
be set permanently active.
bootonce dataset name is recorded in boot pool labels, bootenv area.
in case of nextboot, the nextboot_enable boolean variable is recorded in
freebsd:nvstore nvlist, also stored in boot pool label bootenv area.
On boot, the loader will process /boot/nextboot.conf if nextboot_enable
is "YES", and will set nextboot_enable to "NO", preventing /boot/nextboot.conf
processing on next boot.
bootonce and nextboot features are usable in both UEFI and BIOS boot.
To use bootonce/nextboot features, the boot loader needs to be updated on disk;
if loader.efi is stored on ESP, then ESP needs to be updated and
for BIOS boot, stage2 (zfsboot or gptzfsboot) needs to be updated
(gpart or other tools).
At this time, only lua loader is updated.
Sponsored by: Netflix, Klara Inc.
Differential Revision: https://reviews.freebsd.org/D25512
This would allow interested parties to do experimental runs with an
environment set appropriately to raise all the warnings throughout the
build; e.g. env WARNS=6 NO_WERROR=yes buildworld.
Not currently touching the numerous instances in ^/tools.
MFC after: 1 week
When building the loader an unneeded .interp section may be added. Move
this to the unused section region so offsets of used sections don't
change.
Obtained from: CheriBSD
Sponsored by: Innovate UK
A bug in the EFI HTTP driver of TianoCore EDK2 causes memory
corruption when an http instance that uses tls is reconfigured,
leading to a crash.
Work around this by forcing a new http instance for each request
instead of reconfiguring the existing one.
The upstream bug report is https://bugzilla.tianocore.org/show_bug.cgi?id=1917
Submitted by: bcran
Reviewed By: imp, kevans, tsoome
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D21281
The checkpoints are another way of keeping the state of ZFS.
During the rewind, the pool has to be exported.
This makes checkpoints unusable when using ZFS as root.
Add the option to rewind the ZFS checkpoint at the boot time.
If checkpoint exists, a new option for rewinding a checkpoint will appear in
the bootloader menu.
We fully support boot environments.
If the rewind option is selected, the boot loader will show a list of
boot environments that existed before the checkpoint.
Reviewed by: tsoome, allanjude, kevans (ok with high-level overview)
Differential Revision: https://reviews.freebsd.org/D24920
On RISC-V, Clang warns with:
cast to smaller integer type 'unsigned int' from 'void (*)(void *)'
Instead, use %p as the standard format specifier for printing pointers.
Whilst Arm's pointer size is the same as unsigned, it's still cleaner to
use the right thing there too.
Reviewed by: brooks (mentor), emaste
Approved by: brooks (mentor), emaste
Differential Revision: https://reviews.freebsd.org/D25718
This implementation doesn't have any major deviations from the other EFI
ports. I've copied the boilerplate from arm and arm64.
I've tested this with the following boot flows:
OpenSBI (M-mode) -> u-boot (S-mode) -> loader.efi -> FreeBSD
OpenSBI (M-mode) -> u-boot (S-mode) -> boot1.efi -> loader.efi -> FreeBSD
Due to the way that u-boot handles secondary CPUs, OpenSBI >= v0.7 is required,
as the HSM extension is needed to bring them up explicitly. Because of this,
using BBL as the SBI implementation will not be possible. Additionally, there
are a few recent u-boot changes that are required as well, all of which will be
present in the upcoming v2020.07 release.
Looks good: emaste
Differential Revision: https://reviews.freebsd.org/D25135
The zfs reader development did reach to the point where linking boot1,
we will get errors about duplicate symbols Malloc, Free, Calloc.
We can just use libsa version, just as loader.efi does. The only concern is,
libsa zalloc is using fixed size heap region, I did pick 64MB as other
stage instances are using, but this size is likely not optimal. In any case,
with limited memory setups, we should boot loader.efi directly.
Sponsored by: Netflix, Klara Inc.
These are picked out by the amd64-gcc6 build; time() is declared in <time.h>
and delay() is declared in <bootstrap.h>. These are the correct places for
these in stand/, so remove the duplicate declarations and make sure the
delay() consumer in libefi that depended on the extra delay() declaration
includes <bootstrap.h>.
MFC after: 1 week
We should have nextboot feature implemented in libsa zfs code.
To get there, I have created zfs_nextboot() implementation based on
two sources, our current simple textual string based approach with added
structured boot label PAD structure from OpenZFS.
Secondly, all nvlist details are moved to separate source file and
restructured a bit. This is done to provide base support to add nvlist
add/update feature in followup updates.
And finally, the zfsboot/gptzfsboot disk access functions are swapped to use
libi386 and libsa.
Sponsored by: Netflix, Klara Inc.
Differential Revision: https://reviews.freebsd.org/D25324
On some UEFI implementations the ConsOut EFI variable is not a device
path end type so we never move to the next node. Fix this by always
incrementing the device path node pointer, with a sanity check that
the node length is large enough so no two nodes overlap.
While here return failure on malloc failure rather than a NULL pointer
dereference.
Reviewed by: tsoome, imp (previous version)
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D25202
The u-boot EFI implementation of the ReadBlocks and WriteBlocks methods
requires that the provided buffer meet the IO alignment requirements of
the underlying disk. Unlike loader.efi, gptboot.efi doesn't check this
requirement, and therefore fails to perform a successful read. Adjust
secbuf's alignment to 4K in hopes that we will always meet this
requirement.
Reviewed by: imp
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D25111
Assume gcc is at least 6.4, the oldest xtoolchain in the ports tree.
Assume clang is at least 6, which was in 11.2-RELEASE. Drop conditions
for older compilers.
Reviewed by: imp (earlier version), emaste, jhb
MFC after: 2 weeks
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D24802
We need to ensure the buffers are aligned before passing them to ReadBlocks.
Assume 512 bytes is enough for now.
Reviewed by: imp
MFC after: 1 month
Sponsored by: Innovate UK
These mappings are never visible to userspace as they get replaced when
the amd64 pmap is bootstrapped, but there is no need to set PG_U in the
first place.
Reviewed by: alc, kib
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D24547
The efi console init is avoided since conin setup was moved to probe.
In case the console is re-initialized, we need to pick up colors
from environment.
we have crc32(const void *, size_t) in libsa. Unfortunately zlib has
crc32(long, const unigned char *, unsigned) and we have conflict.
Since we do build libsa with zlib, we can use zlib version instead.
Reviewed by: allanjude
Differential Revision: https://reviews.freebsd.org/D24068
The vectx API, computes the hash for verifying a file as it is read.
This avoids the overhead of reading files twice - once to verify, then
again to load.
For doing an install via loader, avoiding the need to rewind
large files is critical.
This API is only used for modules, kernel and mdimage as these are the
biggest files read by the loader.
The reduction in boot time depends on how expensive the I/O is
on any given platform. On a fast VM we see 6% improvement.
For install via loader the first file to be verified is likely to be the
kernel, so some of the prep work (finding manifest etc) done by
verify_file() needs to be factored so it can be reused for
vectx_open().
For missing or unrecognized fingerprint entries, we fail
in vectx_open() unless verifying is disabled.
Otherwise fingerprint check happens in vectx_close() and
since this API is only used for files which must be verified
(VE_MUST) we panic if we get an incorrect hash.
Reviewed by: imp,tsoome
MFC after: 1 week
Sponsored by: Juniper Networks
Differential Revision: https://reviews.freebsd.org//D23827
smbios used to be an i386 only kinda weird quirk to the x86
architecture. But UEFI picked it up, dusted it off and now it's many
other locations. Make it base technology by moving it to libsa and
fixing up the compliation. The code has issues with unaligned access
still, but that will be addressed in a followup commit.
Differential Revision: https://reviews.freebsd.org/D23660
Create a ptov() function. It's basically the same as the btx PTOV
macro, but works everywhere. smbios needs this to translate addresses,
but the translation differs between BIOS booting and EFI booting. Make
it a function so one smbios.o can be used everywhere. Provide
definitions for it in the two loaders affected.
Differential Revision: https://reviews.freebsd.org/D23660
We still need to set the hooks to prevent improper manipulations thereafter
at the loader prompt, but as it is we're actively preventing loaddev from
being set correctly in some circumstances (ZFS in particular) and doing more
work than needed with currdev -- that hook in particular validates it as a
correct device, which we can assume isn't needed in this context.
Reviewed by: imp, sigsys@gmail.com
Submitted/Diagnosed by: sigsys@gmail.com
Differential Revision: https://reviews.freebsd.org/D23390
From UEFI specification 2.8, page 434:
"It should also be noted that certain input devices may not be able to produce
shift or toggle state information, and in those cases the high order bit in
the respective Toggle and Shift state fields should not be active."
But we still need to check for ScanCode and UnicodeChar.
PR: 242660
Reported by: Trond Endrestol
MFC after: 1 week
Update a bunch of Makefile.depend files as
a result of adding Makefile.depend.options files
Reviewed by: bdrewery
MFC after: 1 week
Sponsored by: Juniper Networks
Differential Revision: https://reviews.freebsd.org/D22494
Just as disks can have nested partitions, the same happens with cd devices,
so we need to detect device paths and make sure we will not mix the handles.
To address this:
we fetch handle array and create linked list of block devices.
we walk the list and detect parent devices and set children pd_parent.
for {fd, cd, hd}, we walk device list and pick up our devices and store to
corresponding list. We make sure we store parent device first.
For sorting we use 3 steps: We check for floppy, we check for cd and then
everything else must be hd.
In general, it seems the floppy devices have no parent.
CD can have both parents and children (multiple boot entries, partitions
from the hybrid disk image).
Tested by: cross+freebsd@distal.com on Cisco UCS systems, C200 series (C220M5, C240M4).
Also on MBP with UEFI 1.10
Reported by: Chriss Ross
MFC after: 1w
Differential Revision: https://reviews.freebsd.org/D22553
RB_MULTIPLE without RB_SERIAL set is valid, and means 'Video first, then serial'
to the kernel (so kernel messages go to both, but /etc/rc uses video console
(this should be fixed, btw, but another day)). Check for RB_MULTIPLE as well as
RB_SERIAL where we want to to serial things. This means we'll use the old code
for emulation in these situations, which is likely best since we're outputing to
both and the old code is ligher weight allowing both to keep up w/o weird
scrolling things.
With a very large kernel or module the staging area may be too small to
hold it. When this is the case try to allocate more space before failing
in the efi copyin/copyout/readin functions.
Reviewed by: imp, tsoome
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D22569
In the EFI implementation in U-Boot no ConOut efi variable is created,
this cause loader to fallback to TERM_EMU implementation which is very
very very slow (and uses the ConOut device in the system table anyway).
The UEFI spec aren't clear as if this variable needs to exists or not.
Reviewed by: imp, kevans
UEFI 1.10 on macs does not seem to provide devpath to name translation,
provide our own (limited) version, so we can get information about commmon
devices.
MFC after: 1 week
The macos does create Vendor Media devices on top of APFS container
(like partition table inside the partition), so we need to collect such
devices into respective device tree.
MFC after: 1 week
Port illumos change: https://www.illumos.org/issues/11667
Move lz4.c out of zfs tree to opensolaris/common/lz4, adjust it to be
usable from kernel/stand/userland builds, so we can use just one single
source. Add lz4.h to declare lz4_compress() and lz4_decompress().
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D22037
In case of efi console having serial backend (video + serial or only serial),
we need to stick with old emulator till we can draw console.
Eventually we would need to get console terminal emulator to be removed
from serial console because the serial link already has the terminal.
However, we need to implement comconsole on all efi platforms first, then
we need the ability to draw console, so we do not have to use SimpleTextOutput
protocol (which will write both on video and serial in case of multiplexed
ComOut).
Differential Revision: https://reviews.freebsd.org/D22161
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
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.
