2010-04-07 18:16:05 +00:00
|
|
|
/*-
|
|
|
|
* Copyright (c) 2008-2010 Rui Paulo
|
|
|
|
* Copyright (c) 2006 Marcel Moolenaar
|
|
|
|
* All rights reserved.
|
|
|
|
*
|
2019-04-25 20:23:13 +00:00
|
|
|
* Copyright (c) 2016-2019 Netflix, Inc. written by M. Warner Losh
|
2019-02-04 21:28:25 +00:00
|
|
|
*
|
2010-04-07 18:16:05 +00:00
|
|
|
* Redistribution and use in source and binary forms, with or without
|
|
|
|
* modification, are permitted provided that the following conditions
|
|
|
|
* are met:
|
|
|
|
*
|
|
|
|
* 1. Redistributions of source code must retain the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer.
|
|
|
|
* 2. Redistributions in binary form must reproduce the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer in the
|
|
|
|
* documentation and/or other materials provided with the distribution.
|
|
|
|
*
|
|
|
|
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
|
|
|
|
* IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
|
|
|
|
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
|
|
|
|
* IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
|
|
|
|
* INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
|
|
|
|
* NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
|
|
|
|
* DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
|
|
|
|
* THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
|
|
|
|
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
|
|
|
|
* THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <sys/cdefs.h>
|
|
|
|
__FBSDID("$FreeBSD$");
|
|
|
|
|
2018-07-13 16:43:29 +00:00
|
|
|
#include <stand.h>
|
|
|
|
|
loader: zfs reader should check all labels
The current zfs reader is only checking first label from each device, however,
we do have 4 labels on device and we should check all 4 to be protected
against disk failures and incomplete label updates.
The difficulty is about the fact that 2 label copies are in front of the
pool data, and 2 are at the end, which means, we have to know the size of
the pool data area.
Since we have now the mechanism from common/disk.c to use the partition
information, it does help us in this task; however, there are still some
corner cases.
Namely, if the pool is created without partition, directly on the disk,
and firmware will give us the wrong size for the disk, we only can check
the first two label copies.
Reviewed by: allanjude
Differential Revision: https://reviews.freebsd.org/D10203
2017-04-06 18:17:29 +00:00
|
|
|
#include <sys/disk.h>
|
2016-01-15 01:22:36 +00:00
|
|
|
#include <sys/param.h>
|
2016-01-26 06:26:46 +00:00
|
|
|
#include <sys/reboot.h>
|
2018-07-13 16:43:29 +00:00
|
|
|
#include <sys/boot.h>
|
2017-12-05 21:38:04 +00:00
|
|
|
#include <stdint.h>
|
2010-04-07 18:16:05 +00:00
|
|
|
#include <string.h>
|
|
|
|
#include <setjmp.h>
|
2017-02-06 09:18:47 +00:00
|
|
|
#include <disk.h>
|
2010-04-07 18:16:05 +00:00
|
|
|
|
|
|
|
#include <efi.h>
|
|
|
|
#include <efilib.h>
|
Finalize the boot manager protocol support for next-stage boot
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
2018-07-23 20:36:59 +00:00
|
|
|
#include <efichar.h>
|
2010-04-07 18:16:05 +00:00
|
|
|
|
2016-05-17 21:25:20 +00:00
|
|
|
#include <uuid.h>
|
|
|
|
|
2010-04-07 18:16:05 +00:00
|
|
|
#include <bootstrap.h>
|
2015-04-06 06:55:47 +00:00
|
|
|
#include <smbios.h>
|
|
|
|
|
2017-08-04 04:20:06 +00:00
|
|
|
#include "efizfs.h"
|
2016-01-15 02:33:47 +00:00
|
|
|
|
2015-04-01 08:30:40 +00:00
|
|
|
#include "loader_efi.h"
|
2010-04-07 18:16:05 +00:00
|
|
|
|
|
|
|
struct arch_switch archsw; /* MI/MD interface boundary */
|
|
|
|
|
|
|
|
EFI_GUID acpi = ACPI_TABLE_GUID;
|
|
|
|
EFI_GUID acpi20 = ACPI_20_TABLE_GUID;
|
|
|
|
EFI_GUID devid = DEVICE_PATH_PROTOCOL;
|
|
|
|
EFI_GUID imgid = LOADED_IMAGE_PROTOCOL;
|
|
|
|
EFI_GUID mps = MPS_TABLE_GUID;
|
|
|
|
EFI_GUID netid = EFI_SIMPLE_NETWORK_PROTOCOL;
|
|
|
|
EFI_GUID smbios = SMBIOS_TABLE_GUID;
|
2018-01-25 20:09:51 +00:00
|
|
|
EFI_GUID smbios3 = SMBIOS3_TABLE_GUID;
|
2015-02-05 07:19:30 +00:00
|
|
|
EFI_GUID dxe = DXE_SERVICES_TABLE_GUID;
|
|
|
|
EFI_GUID hoblist = HOB_LIST_TABLE_GUID;
|
2018-01-25 20:09:51 +00:00
|
|
|
EFI_GUID lzmadecomp = LZMA_DECOMPRESSION_GUID;
|
|
|
|
EFI_GUID mpcore = ARM_MP_CORE_INFO_TABLE_GUID;
|
|
|
|
EFI_GUID esrt = ESRT_TABLE_GUID;
|
2015-02-05 07:19:30 +00:00
|
|
|
EFI_GUID memtype = MEMORY_TYPE_INFORMATION_TABLE_GUID;
|
|
|
|
EFI_GUID debugimg = DEBUG_IMAGE_INFO_TABLE_GUID;
|
2015-05-05 11:07:43 +00:00
|
|
|
EFI_GUID fdtdtb = FDT_TABLE_GUID;
|
2016-02-08 19:34:17 +00:00
|
|
|
EFI_GUID inputid = SIMPLE_TEXT_INPUT_PROTOCOL;
|
2010-04-07 18:16:05 +00:00
|
|
|
|
2018-04-11 19:46:24 +00:00
|
|
|
/*
|
|
|
|
* Number of seconds to wait for a keystroke before exiting with failure
|
|
|
|
* in the event no currdev is found. -2 means always break, -1 means
|
|
|
|
* never break, 0 means poll once and then reboot, > 0 means wait for
|
|
|
|
* that many seconds. "fail_timeout" can be set in the environment as
|
|
|
|
* well.
|
|
|
|
*/
|
|
|
|
static int fail_timeout = 5;
|
|
|
|
|
Finalize the boot manager protocol support for next-stage boot
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
2018-07-23 20:36:59 +00:00
|
|
|
/*
|
|
|
|
* Current boot variable
|
|
|
|
*/
|
|
|
|
UINT16 boot_current;
|
|
|
|
|
2019-04-22 18:40:24 +00:00
|
|
|
/*
|
|
|
|
* Image that we booted from.
|
|
|
|
*/
|
|
|
|
EFI_LOADED_IMAGE *boot_img;
|
|
|
|
|
2018-06-15 19:07:06 +00:00
|
|
|
static bool
|
2016-02-08 19:34:17 +00:00
|
|
|
has_keyboard(void)
|
|
|
|
{
|
|
|
|
EFI_STATUS status;
|
|
|
|
EFI_DEVICE_PATH *path;
|
|
|
|
EFI_HANDLE *hin, *hin_end, *walker;
|
|
|
|
UINTN sz;
|
2018-06-15 19:07:06 +00:00
|
|
|
bool retval = false;
|
2017-08-04 04:20:06 +00:00
|
|
|
|
2016-02-08 19:34:17 +00:00
|
|
|
/*
|
|
|
|
* Find all the handles that support the SIMPLE_TEXT_INPUT_PROTOCOL and
|
|
|
|
* do the typical dance to get the right sized buffer.
|
|
|
|
*/
|
|
|
|
sz = 0;
|
|
|
|
hin = NULL;
|
|
|
|
status = BS->LocateHandle(ByProtocol, &inputid, 0, &sz, 0);
|
|
|
|
if (status == EFI_BUFFER_TOO_SMALL) {
|
|
|
|
hin = (EFI_HANDLE *)malloc(sz);
|
|
|
|
status = BS->LocateHandle(ByProtocol, &inputid, 0, &sz,
|
|
|
|
hin);
|
|
|
|
if (EFI_ERROR(status))
|
|
|
|
free(hin);
|
|
|
|
}
|
|
|
|
if (EFI_ERROR(status))
|
|
|
|
return retval;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Look at each of the handles. If it supports the device path protocol,
|
|
|
|
* use it to get the device path for this handle. Then see if that
|
|
|
|
* device path matches either the USB device path for keyboards or the
|
|
|
|
* legacy device path for keyboards.
|
|
|
|
*/
|
|
|
|
hin_end = &hin[sz / sizeof(*hin)];
|
|
|
|
for (walker = hin; walker < hin_end; walker++) {
|
|
|
|
status = BS->HandleProtocol(*walker, &devid, (VOID **)&path);
|
|
|
|
if (EFI_ERROR(status))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
while (!IsDevicePathEnd(path)) {
|
|
|
|
/*
|
|
|
|
* Check for the ACPI keyboard node. All PNP3xx nodes
|
|
|
|
* are keyboards of different flavors. Note: It is
|
|
|
|
* unclear of there's always a keyboard node when
|
|
|
|
* there's a keyboard controller, or if there's only one
|
|
|
|
* when a keyboard is detected at boot.
|
|
|
|
*/
|
|
|
|
if (DevicePathType(path) == ACPI_DEVICE_PATH &&
|
|
|
|
(DevicePathSubType(path) == ACPI_DP ||
|
|
|
|
DevicePathSubType(path) == ACPI_EXTENDED_DP)) {
|
|
|
|
ACPI_HID_DEVICE_PATH *acpi;
|
|
|
|
|
|
|
|
acpi = (ACPI_HID_DEVICE_PATH *)(void *)path;
|
|
|
|
if ((EISA_ID_TO_NUM(acpi->HID) & 0xff00) == 0x300 &&
|
|
|
|
(acpi->HID & 0xffff) == PNP_EISA_ID_CONST) {
|
2018-06-15 19:07:06 +00:00
|
|
|
retval = true;
|
2016-02-08 19:34:17 +00:00
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
/*
|
|
|
|
* Check for USB keyboard node, if present. Unlike a
|
|
|
|
* PS/2 keyboard, these definitely only appear when
|
|
|
|
* connected to the system.
|
|
|
|
*/
|
|
|
|
} else if (DevicePathType(path) == MESSAGING_DEVICE_PATH &&
|
|
|
|
DevicePathSubType(path) == MSG_USB_CLASS_DP) {
|
|
|
|
USB_CLASS_DEVICE_PATH *usb;
|
2017-08-04 04:20:06 +00:00
|
|
|
|
2016-02-08 19:34:17 +00:00
|
|
|
usb = (USB_CLASS_DEVICE_PATH *)(void *)path;
|
|
|
|
if (usb->DeviceClass == 3 && /* HID */
|
|
|
|
usb->DeviceSubClass == 1 && /* Boot devices */
|
|
|
|
usb->DeviceProtocol == 1) { /* Boot keyboards */
|
2018-06-15 19:07:06 +00:00
|
|
|
retval = true;
|
2016-02-08 19:34:17 +00:00
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
path = NextDevicePathNode(path);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
out:
|
|
|
|
free(hin);
|
|
|
|
return retval;
|
|
|
|
}
|
|
|
|
|
2018-07-18 22:45:26 +00:00
|
|
|
static void
|
|
|
|
set_currdev(const char *devname)
|
|
|
|
{
|
|
|
|
|
|
|
|
env_setenv("currdev", EV_VOLATILE, devname, efi_setcurrdev, env_nounset);
|
|
|
|
env_setenv("loaddev", EV_VOLATILE, devname, env_noset, env_nounset);
|
|
|
|
}
|
|
|
|
|
2017-02-06 09:18:47 +00:00
|
|
|
static void
|
2018-04-11 19:46:24 +00:00
|
|
|
set_currdev_devdesc(struct devdesc *currdev)
|
|
|
|
{
|
|
|
|
const char *devname;
|
|
|
|
|
|
|
|
devname = efi_fmtdev(currdev);
|
|
|
|
printf("Setting currdev to %s\n", devname);
|
2018-07-18 22:45:26 +00:00
|
|
|
set_currdev(devname);
|
2018-04-11 19:46:24 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
set_currdev_devsw(struct devsw *dev, int unit)
|
2017-02-06 09:18:47 +00:00
|
|
|
{
|
|
|
|
struct devdesc currdev;
|
|
|
|
|
|
|
|
currdev.d_dev = dev;
|
|
|
|
currdev.d_unit = unit;
|
2018-04-11 19:46:24 +00:00
|
|
|
|
|
|
|
set_currdev_devdesc(&currdev);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
set_currdev_pdinfo(pdinfo_t *dp)
|
|
|
|
{
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Disks are special: they have partitions. if the parent
|
|
|
|
* pointer is non-null, we're a partition not a full disk
|
|
|
|
* and we need to adjust currdev appropriately.
|
|
|
|
*/
|
|
|
|
if (dp->pd_devsw->dv_type == DEVT_DISK) {
|
|
|
|
struct disk_devdesc currdev;
|
|
|
|
|
|
|
|
currdev.dd.d_dev = dp->pd_devsw;
|
|
|
|
if (dp->pd_parent == NULL) {
|
|
|
|
currdev.dd.d_unit = dp->pd_unit;
|
2019-03-24 18:51:52 +00:00
|
|
|
currdev.d_slice = D_SLICENONE;
|
|
|
|
currdev.d_partition = D_PARTNONE;
|
2018-04-11 19:46:24 +00:00
|
|
|
} else {
|
|
|
|
currdev.dd.d_unit = dp->pd_parent->pd_unit;
|
|
|
|
currdev.d_slice = dp->pd_unit;
|
2019-03-24 18:51:52 +00:00
|
|
|
currdev.d_partition = D_PARTISGPT; /* XXX Assumes GPT */
|
2018-04-11 19:46:24 +00:00
|
|
|
}
|
|
|
|
set_currdev_devdesc((struct devdesc *)&currdev);
|
|
|
|
} else {
|
|
|
|
set_currdev_devsw(dp->pd_devsw, dp->pd_unit);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool
|
|
|
|
sanity_check_currdev(void)
|
|
|
|
{
|
|
|
|
struct stat st;
|
|
|
|
|
2018-06-17 01:26:57 +00:00
|
|
|
return (stat("/boot/defaults/loader.conf", &st) == 0 ||
|
|
|
|
stat("/boot/kernel/kernel", &st) == 0);
|
2018-04-11 19:46:24 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
#ifdef EFI_ZFS_BOOT
|
|
|
|
static bool
|
|
|
|
probe_zfs_currdev(uint64_t guid)
|
|
|
|
{
|
|
|
|
char *devname;
|
|
|
|
struct zfs_devdesc currdev;
|
|
|
|
|
|
|
|
currdev.dd.d_dev = &zfs_dev;
|
|
|
|
currdev.dd.d_unit = 0;
|
|
|
|
currdev.pool_guid = guid;
|
|
|
|
currdev.root_guid = 0;
|
|
|
|
set_currdev_devdesc((struct devdesc *)&currdev);
|
2017-02-06 09:18:47 +00:00
|
|
|
devname = efi_fmtdev(&currdev);
|
2018-04-11 19:46:24 +00:00
|
|
|
init_zfs_bootenv(devname);
|
2017-02-06 09:18:47 +00:00
|
|
|
|
2018-04-11 19:46:24 +00:00
|
|
|
return (sanity_check_currdev());
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
static bool
|
|
|
|
try_as_currdev(pdinfo_t *hd, pdinfo_t *pp)
|
|
|
|
{
|
|
|
|
uint64_t guid;
|
|
|
|
|
|
|
|
#ifdef EFI_ZFS_BOOT
|
|
|
|
/*
|
|
|
|
* If there's a zpool on this device, try it as a ZFS
|
|
|
|
* filesystem, which has somewhat different setup than all
|
|
|
|
* other types of fs due to imperfect loader integration.
|
|
|
|
* This all stems from ZFS being both a device (zpool) and
|
|
|
|
* a filesystem, plus the boot env feature.
|
|
|
|
*/
|
|
|
|
if (efizfs_get_guid_by_handle(pp->pd_handle, &guid))
|
|
|
|
return (probe_zfs_currdev(guid));
|
|
|
|
#endif
|
|
|
|
/*
|
|
|
|
* All other filesystems just need the pdinfo
|
|
|
|
* initialized in the standard way.
|
|
|
|
*/
|
|
|
|
set_currdev_pdinfo(pp);
|
|
|
|
return (sanity_check_currdev());
|
2017-02-06 09:18:47 +00:00
|
|
|
}
|
|
|
|
|
Finalize the boot manager protocol support for next-stage boot
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
2018-07-23 20:36:59 +00:00
|
|
|
/*
|
|
|
|
* Sometimes we get filenames that are all upper case
|
|
|
|
* and/or have backslashes in them. Filter all this out
|
|
|
|
* if it looks like we need to do so.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
fix_dosisms(char *p)
|
|
|
|
{
|
|
|
|
while (*p) {
|
|
|
|
if (isupper(*p))
|
|
|
|
*p = tolower(*p);
|
|
|
|
else if (*p == '\\')
|
|
|
|
*p = '/';
|
|
|
|
p++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-10-26 23:44:50 +00:00
|
|
|
#define SIZE(dp, edp) (size_t)((intptr_t)(void *)edp - (intptr_t)(void *)dp)
|
|
|
|
|
Finalize the boot manager protocol support for next-stage boot
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
2018-07-23 20:36:59 +00:00
|
|
|
enum { BOOT_INFO_OK = 0, BAD_CHOICE = 1, NOT_SPECIFIC = 2 };
|
|
|
|
static int
|
2019-04-22 18:40:24 +00:00
|
|
|
match_boot_info(char *boot_info, size_t bisz)
|
Finalize the boot manager protocol support for next-stage boot
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
2018-07-23 20:36:59 +00:00
|
|
|
{
|
|
|
|
uint32_t attr;
|
|
|
|
uint16_t fplen;
|
|
|
|
size_t len;
|
|
|
|
char *walker, *ep;
|
|
|
|
EFI_DEVICE_PATH *dp, *edp, *first_dp, *last_dp;
|
|
|
|
pdinfo_t *pp;
|
|
|
|
CHAR16 *descr;
|
|
|
|
char *kernel = NULL;
|
|
|
|
FILEPATH_DEVICE_PATH *fp;
|
|
|
|
struct stat st;
|
2018-07-27 22:00:00 +00:00
|
|
|
CHAR16 *text;
|
Finalize the boot manager protocol support for next-stage boot
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
2018-07-23 20:36:59 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* FreeBSD encodes it's boot loading path into the boot loader
|
|
|
|
* BootXXXX variable. We look for the last one in the path
|
|
|
|
* and use that to load the kernel. However, if we only fine
|
|
|
|
* one DEVICE_PATH, then there's nothing specific and we should
|
|
|
|
* fall back.
|
|
|
|
*
|
|
|
|
* In an ideal world, we'd look at the image handle we were
|
|
|
|
* passed, match up with the loader we are and then return the
|
|
|
|
* next one in the path. This would be most flexible and cover
|
|
|
|
* many chain booting scenarios where you need to use this
|
|
|
|
* boot loader to get to the next boot loader. However, that
|
|
|
|
* doesn't work. We rarely have the path to the image booted
|
|
|
|
* (just the device) so we can't count on that. So, we do the
|
|
|
|
* enxt best thing, we look through the device path(s) passed
|
|
|
|
* in the BootXXXX varaible. If there's only one, we return
|
|
|
|
* NOT_SPECIFIC. Otherwise, we look at the last one and try to
|
|
|
|
* load that. If we can, we return BOOT_INFO_OK. Otherwise we
|
|
|
|
* return BAD_CHOICE for the caller to sort out.
|
|
|
|
*/
|
|
|
|
if (bisz < sizeof(attr) + sizeof(fplen) + sizeof(CHAR16))
|
|
|
|
return NOT_SPECIFIC;
|
|
|
|
walker = boot_info;
|
|
|
|
ep = walker + bisz;
|
|
|
|
memcpy(&attr, walker, sizeof(attr));
|
|
|
|
walker += sizeof(attr);
|
|
|
|
memcpy(&fplen, walker, sizeof(fplen));
|
|
|
|
walker += sizeof(fplen);
|
|
|
|
descr = (CHAR16 *)(intptr_t)walker;
|
|
|
|
len = ucs2len(descr);
|
|
|
|
walker += (len + 1) * sizeof(CHAR16);
|
|
|
|
last_dp = first_dp = dp = (EFI_DEVICE_PATH *)walker;
|
|
|
|
edp = (EFI_DEVICE_PATH *)(walker + fplen);
|
|
|
|
if ((char *)edp > ep)
|
|
|
|
return NOT_SPECIFIC;
|
2018-10-26 23:44:50 +00:00
|
|
|
while (dp < edp && SIZE(dp, edp) > sizeof(EFI_DEVICE_PATH)) {
|
2018-07-27 22:00:00 +00:00
|
|
|
text = efi_devpath_name(dp);
|
|
|
|
if (text != NULL) {
|
|
|
|
printf(" BootInfo Path: %S\n", text);
|
|
|
|
efi_free_devpath_name(text);
|
|
|
|
}
|
Finalize the boot manager protocol support for next-stage boot
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
2018-07-23 20:36:59 +00:00
|
|
|
last_dp = dp;
|
|
|
|
dp = (EFI_DEVICE_PATH *)((char *)dp + efi_devpath_length(dp));
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If there's only one item in the list, then nothing was
|
2018-07-26 05:08:58 +00:00
|
|
|
* specified. Or if the last path doesn't have a media
|
|
|
|
* path in it. Those show up as various VenHw() nodes
|
|
|
|
* which are basically opaque to us. Don't count those
|
|
|
|
* as something specifc.
|
Finalize the boot manager protocol support for next-stage boot
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
2018-07-23 20:36:59 +00:00
|
|
|
*/
|
2018-07-27 22:00:00 +00:00
|
|
|
if (last_dp == first_dp) {
|
2018-07-27 22:29:20 +00:00
|
|
|
printf("Ignoring Boot%04x: Only one DP found\n", boot_current);
|
Finalize the boot manager protocol support for next-stage boot
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
2018-07-23 20:36:59 +00:00
|
|
|
return NOT_SPECIFIC;
|
2018-07-27 22:00:00 +00:00
|
|
|
}
|
2018-07-27 22:29:20 +00:00
|
|
|
if (efi_devpath_to_media_path(last_dp) == NULL) {
|
|
|
|
printf("Ignoring Boot%04x: No Media Path\n", boot_current);
|
2018-07-26 05:08:58 +00:00
|
|
|
return NOT_SPECIFIC;
|
2018-07-27 22:00:00 +00:00
|
|
|
}
|
Finalize the boot manager protocol support for next-stage boot
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
2018-07-23 20:36:59 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* OK. At this point we either have a good path or a bad one.
|
|
|
|
* Let's check.
|
|
|
|
*/
|
|
|
|
pp = efiblk_get_pdinfo_by_device_path(last_dp);
|
2018-07-27 22:00:00 +00:00
|
|
|
if (pp == NULL) {
|
2018-07-27 22:29:20 +00:00
|
|
|
printf("Ignoring Boot%04x: Device Path not found\n", boot_current);
|
Finalize the boot manager protocol support for next-stage boot
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
2018-07-23 20:36:59 +00:00
|
|
|
return BAD_CHOICE;
|
2018-07-27 22:00:00 +00:00
|
|
|
}
|
Finalize the boot manager protocol support for next-stage boot
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
2018-07-23 20:36:59 +00:00
|
|
|
set_currdev_pdinfo(pp);
|
2018-07-27 22:31:38 +00:00
|
|
|
if (!sanity_check_currdev()) {
|
2018-07-27 22:29:20 +00:00
|
|
|
printf("Ignoring Boot%04x: sanity check failed\n", boot_current);
|
Finalize the boot manager protocol support for next-stage boot
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
2018-07-23 20:36:59 +00:00
|
|
|
return BAD_CHOICE;
|
2018-07-27 22:00:00 +00:00
|
|
|
}
|
Finalize the boot manager protocol support for next-stage boot
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
2018-07-23 20:36:59 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* OK. We've found a device that matches, next we need to check the last
|
|
|
|
* component of the path. If it's a file, then we set the default kernel
|
|
|
|
* to that. Otherwise, just use this as the default root.
|
|
|
|
*
|
|
|
|
* Reminder: we're running very early, before we've parsed the defaults
|
|
|
|
* file, so we may need to have a hack override.
|
|
|
|
*/
|
|
|
|
dp = efi_devpath_last_node(last_dp);
|
|
|
|
if (DevicePathType(dp) != MEDIA_DEVICE_PATH ||
|
2018-07-27 22:00:00 +00:00
|
|
|
DevicePathSubType(dp) != MEDIA_FILEPATH_DP) {
|
2018-07-27 22:29:20 +00:00
|
|
|
printf("Using Boot%04x for root partition\n", boot_current);
|
Finalize the boot manager protocol support for next-stage boot
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
2018-07-23 20:36:59 +00:00
|
|
|
return (BOOT_INFO_OK); /* use currdir, default kernel */
|
2018-07-27 22:00:00 +00:00
|
|
|
}
|
Finalize the boot manager protocol support for next-stage boot
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
2018-07-23 20:36:59 +00:00
|
|
|
fp = (FILEPATH_DEVICE_PATH *)dp;
|
|
|
|
ucs2_to_utf8(fp->PathName, &kernel);
|
2018-07-27 22:00:00 +00:00
|
|
|
if (kernel == NULL) {
|
2018-07-27 22:29:20 +00:00
|
|
|
printf("Not using Boot%04x: can't decode kernel\n", boot_current);
|
Finalize the boot manager protocol support for next-stage boot
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
2018-07-23 20:36:59 +00:00
|
|
|
return (BAD_CHOICE);
|
2018-07-27 22:00:00 +00:00
|
|
|
}
|
Finalize the boot manager protocol support for next-stage boot
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
2018-07-23 20:36:59 +00:00
|
|
|
if (*kernel == '\\' || isupper(*kernel))
|
|
|
|
fix_dosisms(kernel);
|
|
|
|
if (stat(kernel, &st) != 0) {
|
|
|
|
free(kernel);
|
2018-07-27 22:29:20 +00:00
|
|
|
printf("Not using Boot%04x: can't find %s\n", boot_current,
|
|
|
|
kernel);
|
Finalize the boot manager protocol support for next-stage boot
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
2018-07-23 20:36:59 +00:00
|
|
|
return (BAD_CHOICE);
|
|
|
|
}
|
|
|
|
setenv("kernel", kernel, 1);
|
|
|
|
free(kernel);
|
2018-07-27 22:00:00 +00:00
|
|
|
text = efi_devpath_name(last_dp);
|
|
|
|
if (text) {
|
2018-07-27 22:35:07 +00:00
|
|
|
printf("Using Boot%04x %S + %s\n", boot_current, text,
|
2018-07-27 22:29:20 +00:00
|
|
|
kernel);
|
2018-07-27 22:00:00 +00:00
|
|
|
efi_free_devpath_name(text);
|
|
|
|
}
|
Finalize the boot manager protocol support for next-stage boot
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
2018-07-23 20:36:59 +00:00
|
|
|
|
|
|
|
return (BOOT_INFO_OK);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Look at the passed-in boot_info, if any. If we find it then we need
|
|
|
|
* to see if we can find ourselves in the boot chain. If we can, and
|
|
|
|
* there's another specified thing to boot next, assume that the file
|
|
|
|
* is loaded from / and use that for the root filesystem. If can't
|
|
|
|
* find the specified thing, we must fail the boot. If we're last on
|
|
|
|
* the list, then we fallback to looking for the first available /
|
|
|
|
* candidate (ZFS, if there's a bootable zpool, otherwise a UFS
|
|
|
|
* partition that has either /boot/defaults/loader.conf on it or
|
|
|
|
* /boot/kernel/kernel (the default kernel) that we can use.
|
|
|
|
*
|
|
|
|
* We always fail if we can't find the right thing. However, as
|
|
|
|
* a concession to buggy UEFI implementations, like u-boot, if
|
|
|
|
* we have determined that the host is violating the UEFI boot
|
|
|
|
* manager protocol, we'll signal the rest of the program that
|
|
|
|
* a drop to the OK boot loader prompt is possible.
|
|
|
|
*/
|
Fix unit number of EFI net interfaces and ignore psuedo network interfaces.
In r277943, the efinet_match() routine was changed to use an off by one
when matching network interfaces. The effect was that using "net1"
actually used the device attached to "net0".
Digging into the hardware that needed this workaround more, I found that
UEFI was creating two simple network protocol devices for each physical
NIC. The first device was a "raw" Ethernet device and the second device
was a "IP" device that used the IP protocol on top of the underlying
"raw" device. The PXE code in the firmware used the "IP" device to pull
across the loader.efi, so currdev was set to "net1" when booting from the
physical interface "net0". (The loaded image's device handle referenced
the "IP" device that "net1" claimed.)
However, the IP device isn't suitable for doing raw packet I/O (and the
current code to open devices exclusively actually turns the "IP" devices
off on these systems).
To fix, change the efinet driver to only attach to "raw" devices. This
is determined by fetching the DEVICE_PATH for each handle which supports
the simple network protocol and examining the last node in the path. If
the last node in the path is a MAC address, the device is assumed to be
a "raw" device and is added as a 'netX' device. If the last node is not
a MAC address, the device is ignored.
However, this causes a new problem as the device handle associated with
the loaded image no longer matches any of the handles enumerated by
efinet for systems that load the image via the "IP" device. To handle
this case, expand the logic that resolves currdev from the loaded image
in main(). First, the existing logic of looking for a handle that
matches the loaded image's handle is tried. If that fails, the device
path of the handle that loaded the loaded image is fetched via
efi_lookup_image_devpath(). This device path is then walked from the
end up to the beginning using efi_handle_lookup() to fetch the handle
associated with a path. If the handle is found and is a known handle,
then that is used as currdev. The effect for machines that load the
image via the "IP" device is that the first lookup fails (the handle
for the "IP" device isn't claimed by efinet), but walking up the
image's device path finds the handle of the raw MAC device which is used
as currdev.
With these fixes in place, the hack to subtract 1 from the unit can now
be removed, so that setting currdev to 'net0' actually uses 'net0'.
PR: 202097
Tested by: ambrisko
Sponsored by: Cisco Systems
2016-05-26 23:32:28 +00:00
|
|
|
static int
|
2019-04-22 18:40:24 +00:00
|
|
|
find_currdev(bool do_bootmgr, bool is_last,
|
Finalize the boot manager protocol support for next-stage boot
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
2018-07-23 20:36:59 +00:00
|
|
|
char *boot_info, size_t boot_info_sz)
|
Fix unit number of EFI net interfaces and ignore psuedo network interfaces.
In r277943, the efinet_match() routine was changed to use an off by one
when matching network interfaces. The effect was that using "net1"
actually used the device attached to "net0".
Digging into the hardware that needed this workaround more, I found that
UEFI was creating two simple network protocol devices for each physical
NIC. The first device was a "raw" Ethernet device and the second device
was a "IP" device that used the IP protocol on top of the underlying
"raw" device. The PXE code in the firmware used the "IP" device to pull
across the loader.efi, so currdev was set to "net1" when booting from the
physical interface "net0". (The loaded image's device handle referenced
the "IP" device that "net1" claimed.)
However, the IP device isn't suitable for doing raw packet I/O (and the
current code to open devices exclusively actually turns the "IP" devices
off on these systems).
To fix, change the efinet driver to only attach to "raw" devices. This
is determined by fetching the DEVICE_PATH for each handle which supports
the simple network protocol and examining the last node in the path. If
the last node in the path is a MAC address, the device is assumed to be
a "raw" device and is added as a 'netX' device. If the last node is not
a MAC address, the device is ignored.
However, this causes a new problem as the device handle associated with
the loaded image no longer matches any of the handles enumerated by
efinet for systems that load the image via the "IP" device. To handle
this case, expand the logic that resolves currdev from the loaded image
in main(). First, the existing logic of looking for a handle that
matches the loaded image's handle is tried. If that fails, the device
path of the handle that loaded the loaded image is fetched via
efi_lookup_image_devpath(). This device path is then walked from the
end up to the beginning using efi_handle_lookup() to fetch the handle
associated with a path. If the handle is found and is a known handle,
then that is used as currdev. The effect for machines that load the
image via the "IP" device is that the first lookup fails (the handle
for the "IP" device isn't claimed by efinet), but walking up the
image's device path finds the handle of the raw MAC device which is used
as currdev.
With these fixes in place, the hack to subtract 1 from the unit can now
be removed, so that setting currdev to 'net0' actually uses 'net0'.
PR: 202097
Tested by: ambrisko
Sponsored by: Cisco Systems
2016-05-26 23:32:28 +00:00
|
|
|
{
|
2017-02-06 09:18:47 +00:00
|
|
|
pdinfo_t *dp, *pp;
|
Fix unit number of EFI net interfaces and ignore psuedo network interfaces.
In r277943, the efinet_match() routine was changed to use an off by one
when matching network interfaces. The effect was that using "net1"
actually used the device attached to "net0".
Digging into the hardware that needed this workaround more, I found that
UEFI was creating two simple network protocol devices for each physical
NIC. The first device was a "raw" Ethernet device and the second device
was a "IP" device that used the IP protocol on top of the underlying
"raw" device. The PXE code in the firmware used the "IP" device to pull
across the loader.efi, so currdev was set to "net1" when booting from the
physical interface "net0". (The loaded image's device handle referenced
the "IP" device that "net1" claimed.)
However, the IP device isn't suitable for doing raw packet I/O (and the
current code to open devices exclusively actually turns the "IP" devices
off on these systems).
To fix, change the efinet driver to only attach to "raw" devices. This
is determined by fetching the DEVICE_PATH for each handle which supports
the simple network protocol and examining the last node in the path. If
the last node in the path is a MAC address, the device is assumed to be
a "raw" device and is added as a 'netX' device. If the last node is not
a MAC address, the device is ignored.
However, this causes a new problem as the device handle associated with
the loaded image no longer matches any of the handles enumerated by
efinet for systems that load the image via the "IP" device. To handle
this case, expand the logic that resolves currdev from the loaded image
in main(). First, the existing logic of looking for a handle that
matches the loaded image's handle is tried. If that fails, the device
path of the handle that loaded the loaded image is fetched via
efi_lookup_image_devpath(). This device path is then walked from the
end up to the beginning using efi_handle_lookup() to fetch the handle
associated with a path. If the handle is found and is a known handle,
then that is used as currdev. The effect for machines that load the
image via the "IP" device is that the first lookup fails (the handle
for the "IP" device isn't claimed by efinet), but walking up the
image's device path finds the handle of the raw MAC device which is used
as currdev.
With these fixes in place, the hack to subtract 1 from the unit can now
be removed, so that setting currdev to 'net0' actually uses 'net0'.
PR: 202097
Tested by: ambrisko
Sponsored by: Cisco Systems
2016-05-26 23:32:28 +00:00
|
|
|
EFI_DEVICE_PATH *devpath, *copy;
|
|
|
|
EFI_HANDLE h;
|
2018-04-11 19:46:24 +00:00
|
|
|
CHAR16 *text;
|
2017-02-06 09:18:47 +00:00
|
|
|
struct devsw *dev;
|
|
|
|
int unit;
|
|
|
|
uint64_t extra;
|
Finalize the boot manager protocol support for next-stage boot
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
2018-07-23 20:36:59 +00:00
|
|
|
int rv;
|
2018-07-18 22:45:26 +00:00
|
|
|
char *rootdev;
|
|
|
|
|
Finalize the boot manager protocol support for next-stage boot
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
2018-07-23 20:36:59 +00:00
|
|
|
/*
|
|
|
|
* First choice: if rootdev is already set, use that, even if
|
|
|
|
* it's wrong.
|
|
|
|
*/
|
2018-07-18 22:45:26 +00:00
|
|
|
rootdev = getenv("rootdev");
|
|
|
|
if (rootdev != NULL) {
|
2019-04-29 05:02:50 +00:00
|
|
|
printf(" Setting currdev to configured rootdev %s\n",
|
|
|
|
rootdev);
|
2018-07-18 22:45:26 +00:00
|
|
|
set_currdev(rootdev);
|
|
|
|
return (0);
|
|
|
|
}
|
2017-02-06 09:18:47 +00:00
|
|
|
|
Finalize the boot manager protocol support for next-stage boot
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
2018-07-23 20:36:59 +00:00
|
|
|
/*
|
2019-04-29 05:02:50 +00:00
|
|
|
* Second choice: If uefi_rootdev is set, translate that UEFI device
|
|
|
|
* path to the loader's internal name and use that.
|
|
|
|
*/
|
|
|
|
do {
|
|
|
|
rootdev = getenv("uefi_rootdev");
|
|
|
|
if (rootdev == NULL)
|
|
|
|
break;
|
|
|
|
devpath = efi_name_to_devpath(rootdev);
|
|
|
|
if (devpath == NULL)
|
|
|
|
break;
|
|
|
|
dp = efiblk_get_pdinfo_by_device_path(devpath);
|
|
|
|
efi_devpath_free(devpath);
|
|
|
|
if (dp == NULL)
|
|
|
|
break;
|
|
|
|
printf(" Setting currdev to UEFI path %s\n",
|
|
|
|
rootdev);
|
|
|
|
set_currdev_pdinfo(dp);
|
|
|
|
return (0);
|
|
|
|
} while (0);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Third choice: If we can find out image boot_info, and there's
|
Finalize the boot manager protocol support for next-stage boot
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
2018-07-23 20:36:59 +00:00
|
|
|
* a follow-on boot image in that boot_info, use that. In this
|
|
|
|
* case root will be the partition specified in that image and
|
|
|
|
* we'll load the kernel specified by the file path. Should there
|
|
|
|
* not be a filepath, we use the default. This filepath overrides
|
|
|
|
* loader.conf.
|
|
|
|
*/
|
|
|
|
if (do_bootmgr) {
|
2019-04-22 18:40:24 +00:00
|
|
|
rv = match_boot_info(boot_info, boot_info_sz);
|
Finalize the boot manager protocol support for next-stage boot
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
2018-07-23 20:36:59 +00:00
|
|
|
switch (rv) {
|
|
|
|
case BOOT_INFO_OK: /* We found it */
|
|
|
|
return (0);
|
|
|
|
case BAD_CHOICE: /* specified file not found -> error */
|
|
|
|
/* XXX do we want to have an escape hatch for last in boot order? */
|
|
|
|
return (ENOENT);
|
|
|
|
} /* Nothing specified, try normal match */
|
|
|
|
}
|
|
|
|
|
2017-02-06 10:57:54 +00:00
|
|
|
#ifdef EFI_ZFS_BOOT
|
2018-04-11 19:46:24 +00:00
|
|
|
/*
|
|
|
|
* Did efi_zfs_probe() detect the boot pool? If so, use the zpool
|
|
|
|
* it found, if it's sane. ZFS is the only thing that looks for
|
|
|
|
* disks and pools to boot. This may change in the future, however,
|
|
|
|
* if we allow specifying which pool to boot from via UEFI variables
|
|
|
|
* rather than the bootenv stuff that FreeBSD uses today.
|
|
|
|
*/
|
2017-02-06 09:18:47 +00:00
|
|
|
if (pool_guid != 0) {
|
2018-04-11 19:46:24 +00:00
|
|
|
printf("Trying ZFS pool\n");
|
|
|
|
if (probe_zfs_currdev(pool_guid))
|
2017-02-06 09:18:47 +00:00
|
|
|
return (0);
|
|
|
|
}
|
2018-04-11 19:46:24 +00:00
|
|
|
#endif /* EFI_ZFS_BOOT */
|
2017-02-06 09:18:47 +00:00
|
|
|
|
2018-04-11 19:46:24 +00:00
|
|
|
/*
|
|
|
|
* Try to find the block device by its handle based on the
|
|
|
|
* image we're booting. If we can't find a sane partition,
|
|
|
|
* search all the other partitions of the disk. We do not
|
|
|
|
* search other disks because it's a violation of the UEFI
|
|
|
|
* boot protocol to do so. We fail and let UEFI go on to
|
|
|
|
* the next candidate.
|
|
|
|
*/
|
2019-04-22 18:40:24 +00:00
|
|
|
dp = efiblk_get_pdinfo_by_handle(boot_img->DeviceHandle);
|
2018-04-11 19:46:24 +00:00
|
|
|
if (dp != NULL) {
|
|
|
|
text = efi_devpath_name(dp->pd_devpath);
|
|
|
|
if (text != NULL) {
|
|
|
|
printf("Trying ESP: %S\n", text);
|
|
|
|
efi_free_devpath_name(text);
|
2017-02-06 09:18:47 +00:00
|
|
|
}
|
2018-04-11 19:46:24 +00:00
|
|
|
set_currdev_pdinfo(dp);
|
|
|
|
if (sanity_check_currdev())
|
2017-02-06 09:18:47 +00:00
|
|
|
return (0);
|
2018-04-11 19:46:24 +00:00
|
|
|
if (dp->pd_parent != NULL) {
|
2018-07-27 22:00:00 +00:00
|
|
|
pdinfo_t *espdp = dp;
|
2018-04-11 19:46:24 +00:00
|
|
|
dp = dp->pd_parent;
|
|
|
|
STAILQ_FOREACH(pp, &dp->pd_part, pd_link) {
|
2018-07-27 22:00:00 +00:00
|
|
|
/* Already tried the ESP */
|
|
|
|
if (espdp == pp)
|
|
|
|
continue;
|
2018-04-11 19:46:24 +00:00
|
|
|
/*
|
|
|
|
* Roll up the ZFS special case
|
|
|
|
* for those partitions that have
|
Finalize the boot manager protocol support for next-stage boot
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
2018-07-23 20:36:59 +00:00
|
|
|
* zpools on them.
|
2018-04-11 19:46:24 +00:00
|
|
|
*/
|
2018-07-27 22:00:00 +00:00
|
|
|
text = efi_devpath_name(pp->pd_devpath);
|
|
|
|
if (text != NULL) {
|
|
|
|
printf("Trying: %S\n", text);
|
|
|
|
efi_free_devpath_name(text);
|
|
|
|
}
|
2018-04-11 19:46:24 +00:00
|
|
|
if (try_as_currdev(dp, pp))
|
|
|
|
return (0);
|
|
|
|
}
|
2017-02-06 09:18:47 +00:00
|
|
|
}
|
|
|
|
}
|
Fix unit number of EFI net interfaces and ignore psuedo network interfaces.
In r277943, the efinet_match() routine was changed to use an off by one
when matching network interfaces. The effect was that using "net1"
actually used the device attached to "net0".
Digging into the hardware that needed this workaround more, I found that
UEFI was creating two simple network protocol devices for each physical
NIC. The first device was a "raw" Ethernet device and the second device
was a "IP" device that used the IP protocol on top of the underlying
"raw" device. The PXE code in the firmware used the "IP" device to pull
across the loader.efi, so currdev was set to "net1" when booting from the
physical interface "net0". (The loaded image's device handle referenced
the "IP" device that "net1" claimed.)
However, the IP device isn't suitable for doing raw packet I/O (and the
current code to open devices exclusively actually turns the "IP" devices
off on these systems).
To fix, change the efinet driver to only attach to "raw" devices. This
is determined by fetching the DEVICE_PATH for each handle which supports
the simple network protocol and examining the last node in the path. If
the last node in the path is a MAC address, the device is assumed to be
a "raw" device and is added as a 'netX' device. If the last node is not
a MAC address, the device is ignored.
However, this causes a new problem as the device handle associated with
the loaded image no longer matches any of the handles enumerated by
efinet for systems that load the image via the "IP" device. To handle
this case, expand the logic that resolves currdev from the loaded image
in main(). First, the existing logic of looking for a handle that
matches the loaded image's handle is tried. If that fails, the device
path of the handle that loaded the loaded image is fetched via
efi_lookup_image_devpath(). This device path is then walked from the
end up to the beginning using efi_handle_lookup() to fetch the handle
associated with a path. If the handle is found and is a known handle,
then that is used as currdev. The effect for machines that load the
image via the "IP" device is that the first lookup fails (the handle
for the "IP" device isn't claimed by efinet), but walking up the
image's device path finds the handle of the raw MAC device which is used
as currdev.
With these fixes in place, the hack to subtract 1 from the unit can now
be removed, so that setting currdev to 'net0' actually uses 'net0'.
PR: 202097
Tested by: ambrisko
Sponsored by: Cisco Systems
2016-05-26 23:32:28 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Try the device handle from our loaded image first. If that
|
|
|
|
* fails, use the device path from the loaded image and see if
|
|
|
|
* any of the nodes in that path match one of the enumerated
|
2018-04-11 19:46:24 +00:00
|
|
|
* handles. Currently, this handle list is only for netboot.
|
Fix unit number of EFI net interfaces and ignore psuedo network interfaces.
In r277943, the efinet_match() routine was changed to use an off by one
when matching network interfaces. The effect was that using "net1"
actually used the device attached to "net0".
Digging into the hardware that needed this workaround more, I found that
UEFI was creating two simple network protocol devices for each physical
NIC. The first device was a "raw" Ethernet device and the second device
was a "IP" device that used the IP protocol on top of the underlying
"raw" device. The PXE code in the firmware used the "IP" device to pull
across the loader.efi, so currdev was set to "net1" when booting from the
physical interface "net0". (The loaded image's device handle referenced
the "IP" device that "net1" claimed.)
However, the IP device isn't suitable for doing raw packet I/O (and the
current code to open devices exclusively actually turns the "IP" devices
off on these systems).
To fix, change the efinet driver to only attach to "raw" devices. This
is determined by fetching the DEVICE_PATH for each handle which supports
the simple network protocol and examining the last node in the path. If
the last node in the path is a MAC address, the device is assumed to be
a "raw" device and is added as a 'netX' device. If the last node is not
a MAC address, the device is ignored.
However, this causes a new problem as the device handle associated with
the loaded image no longer matches any of the handles enumerated by
efinet for systems that load the image via the "IP" device. To handle
this case, expand the logic that resolves currdev from the loaded image
in main(). First, the existing logic of looking for a handle that
matches the loaded image's handle is tried. If that fails, the device
path of the handle that loaded the loaded image is fetched via
efi_lookup_image_devpath(). This device path is then walked from the
end up to the beginning using efi_handle_lookup() to fetch the handle
associated with a path. If the handle is found and is a known handle,
then that is used as currdev. The effect for machines that load the
image via the "IP" device is that the first lookup fails (the handle
for the "IP" device isn't claimed by efinet), but walking up the
image's device path finds the handle of the raw MAC device which is used
as currdev.
With these fixes in place, the hack to subtract 1 from the unit can now
be removed, so that setting currdev to 'net0' actually uses 'net0'.
PR: 202097
Tested by: ambrisko
Sponsored by: Cisco Systems
2016-05-26 23:32:28 +00:00
|
|
|
*/
|
2019-04-22 18:40:24 +00:00
|
|
|
if (efi_handle_lookup(boot_img->DeviceHandle, &dev, &unit, &extra) == 0) {
|
2018-04-11 19:46:24 +00:00
|
|
|
set_currdev_devsw(dev, unit);
|
|
|
|
if (sanity_check_currdev())
|
|
|
|
return (0);
|
2017-02-06 09:18:47 +00:00
|
|
|
}
|
Fix unit number of EFI net interfaces and ignore psuedo network interfaces.
In r277943, the efinet_match() routine was changed to use an off by one
when matching network interfaces. The effect was that using "net1"
actually used the device attached to "net0".
Digging into the hardware that needed this workaround more, I found that
UEFI was creating two simple network protocol devices for each physical
NIC. The first device was a "raw" Ethernet device and the second device
was a "IP" device that used the IP protocol on top of the underlying
"raw" device. The PXE code in the firmware used the "IP" device to pull
across the loader.efi, so currdev was set to "net1" when booting from the
physical interface "net0". (The loaded image's device handle referenced
the "IP" device that "net1" claimed.)
However, the IP device isn't suitable for doing raw packet I/O (and the
current code to open devices exclusively actually turns the "IP" devices
off on these systems).
To fix, change the efinet driver to only attach to "raw" devices. This
is determined by fetching the DEVICE_PATH for each handle which supports
the simple network protocol and examining the last node in the path. If
the last node in the path is a MAC address, the device is assumed to be
a "raw" device and is added as a 'netX' device. If the last node is not
a MAC address, the device is ignored.
However, this causes a new problem as the device handle associated with
the loaded image no longer matches any of the handles enumerated by
efinet for systems that load the image via the "IP" device. To handle
this case, expand the logic that resolves currdev from the loaded image
in main(). First, the existing logic of looking for a handle that
matches the loaded image's handle is tried. If that fails, the device
path of the handle that loaded the loaded image is fetched via
efi_lookup_image_devpath(). This device path is then walked from the
end up to the beginning using efi_handle_lookup() to fetch the handle
associated with a path. If the handle is found and is a known handle,
then that is used as currdev. The effect for machines that load the
image via the "IP" device is that the first lookup fails (the handle
for the "IP" device isn't claimed by efinet), but walking up the
image's device path finds the handle of the raw MAC device which is used
as currdev.
With these fixes in place, the hack to subtract 1 from the unit can now
be removed, so that setting currdev to 'net0' actually uses 'net0'.
PR: 202097
Tested by: ambrisko
Sponsored by: Cisco Systems
2016-05-26 23:32:28 +00:00
|
|
|
|
|
|
|
copy = NULL;
|
|
|
|
devpath = efi_lookup_image_devpath(IH);
|
|
|
|
while (devpath != NULL) {
|
|
|
|
h = efi_devpath_handle(devpath);
|
|
|
|
if (h == NULL)
|
|
|
|
break;
|
|
|
|
|
2017-01-15 20:03:13 +00:00
|
|
|
free(copy);
|
|
|
|
copy = NULL;
|
|
|
|
|
2017-02-06 09:18:47 +00:00
|
|
|
if (efi_handle_lookup(h, &dev, &unit, &extra) == 0) {
|
2018-04-11 19:46:24 +00:00
|
|
|
set_currdev_devsw(dev, unit);
|
|
|
|
if (sanity_check_currdev())
|
|
|
|
return (0);
|
2017-02-06 09:18:47 +00:00
|
|
|
}
|
Fix unit number of EFI net interfaces and ignore psuedo network interfaces.
In r277943, the efinet_match() routine was changed to use an off by one
when matching network interfaces. The effect was that using "net1"
actually used the device attached to "net0".
Digging into the hardware that needed this workaround more, I found that
UEFI was creating two simple network protocol devices for each physical
NIC. The first device was a "raw" Ethernet device and the second device
was a "IP" device that used the IP protocol on top of the underlying
"raw" device. The PXE code in the firmware used the "IP" device to pull
across the loader.efi, so currdev was set to "net1" when booting from the
physical interface "net0". (The loaded image's device handle referenced
the "IP" device that "net1" claimed.)
However, the IP device isn't suitable for doing raw packet I/O (and the
current code to open devices exclusively actually turns the "IP" devices
off on these systems).
To fix, change the efinet driver to only attach to "raw" devices. This
is determined by fetching the DEVICE_PATH for each handle which supports
the simple network protocol and examining the last node in the path. If
the last node in the path is a MAC address, the device is assumed to be
a "raw" device and is added as a 'netX' device. If the last node is not
a MAC address, the device is ignored.
However, this causes a new problem as the device handle associated with
the loaded image no longer matches any of the handles enumerated by
efinet for systems that load the image via the "IP" device. To handle
this case, expand the logic that resolves currdev from the loaded image
in main(). First, the existing logic of looking for a handle that
matches the loaded image's handle is tried. If that fails, the device
path of the handle that loaded the loaded image is fetched via
efi_lookup_image_devpath(). This device path is then walked from the
end up to the beginning using efi_handle_lookup() to fetch the handle
associated with a path. If the handle is found and is a known handle,
then that is used as currdev. The effect for machines that load the
image via the "IP" device is that the first lookup fails (the handle
for the "IP" device isn't claimed by efinet), but walking up the
image's device path finds the handle of the raw MAC device which is used
as currdev.
With these fixes in place, the hack to subtract 1 from the unit can now
be removed, so that setting currdev to 'net0' actually uses 'net0'.
PR: 202097
Tested by: ambrisko
Sponsored by: Cisco Systems
2016-05-26 23:32:28 +00:00
|
|
|
|
|
|
|
devpath = efi_lookup_devpath(h);
|
|
|
|
if (devpath != NULL) {
|
|
|
|
copy = efi_devpath_trim(devpath);
|
|
|
|
devpath = copy;
|
|
|
|
}
|
|
|
|
}
|
2017-01-15 20:03:13 +00:00
|
|
|
free(copy);
|
Fix unit number of EFI net interfaces and ignore psuedo network interfaces.
In r277943, the efinet_match() routine was changed to use an off by one
when matching network interfaces. The effect was that using "net1"
actually used the device attached to "net0".
Digging into the hardware that needed this workaround more, I found that
UEFI was creating two simple network protocol devices for each physical
NIC. The first device was a "raw" Ethernet device and the second device
was a "IP" device that used the IP protocol on top of the underlying
"raw" device. The PXE code in the firmware used the "IP" device to pull
across the loader.efi, so currdev was set to "net1" when booting from the
physical interface "net0". (The loaded image's device handle referenced
the "IP" device that "net1" claimed.)
However, the IP device isn't suitable for doing raw packet I/O (and the
current code to open devices exclusively actually turns the "IP" devices
off on these systems).
To fix, change the efinet driver to only attach to "raw" devices. This
is determined by fetching the DEVICE_PATH for each handle which supports
the simple network protocol and examining the last node in the path. If
the last node in the path is a MAC address, the device is assumed to be
a "raw" device and is added as a 'netX' device. If the last node is not
a MAC address, the device is ignored.
However, this causes a new problem as the device handle associated with
the loaded image no longer matches any of the handles enumerated by
efinet for systems that load the image via the "IP" device. To handle
this case, expand the logic that resolves currdev from the loaded image
in main(). First, the existing logic of looking for a handle that
matches the loaded image's handle is tried. If that fails, the device
path of the handle that loaded the loaded image is fetched via
efi_lookup_image_devpath(). This device path is then walked from the
end up to the beginning using efi_handle_lookup() to fetch the handle
associated with a path. If the handle is found and is a known handle,
then that is used as currdev. The effect for machines that load the
image via the "IP" device is that the first lookup fails (the handle
for the "IP" device isn't claimed by efinet), but walking up the
image's device path finds the handle of the raw MAC device which is used
as currdev.
With these fixes in place, the hack to subtract 1 from the unit can now
be removed, so that setting currdev to 'net0' actually uses 'net0'.
PR: 202097
Tested by: ambrisko
Sponsored by: Cisco Systems
2016-05-26 23:32:28 +00:00
|
|
|
|
|
|
|
return (ENOENT);
|
|
|
|
}
|
|
|
|
|
2018-04-11 19:46:24 +00:00
|
|
|
static bool
|
|
|
|
interactive_interrupt(const char *msg)
|
|
|
|
{
|
|
|
|
time_t now, then, last;
|
|
|
|
|
|
|
|
last = 0;
|
|
|
|
now = then = getsecs();
|
|
|
|
printf("%s\n", msg);
|
|
|
|
if (fail_timeout == -2) /* Always break to OK */
|
|
|
|
return (true);
|
|
|
|
if (fail_timeout == -1) /* Never break to OK */
|
|
|
|
return (false);
|
|
|
|
do {
|
|
|
|
if (last != now) {
|
|
|
|
printf("press any key to interrupt reboot in %d seconds\r",
|
|
|
|
fail_timeout - (int)(now - then));
|
|
|
|
last = now;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* XXX no pause or timeout wait for char */
|
|
|
|
if (ischar())
|
|
|
|
return (true);
|
|
|
|
now = getsecs();
|
|
|
|
} while (now - then < fail_timeout);
|
|
|
|
return (false);
|
|
|
|
}
|
|
|
|
|
2018-07-14 00:40:38 +00:00
|
|
|
static int
|
|
|
|
parse_args(int argc, CHAR16 *argv[])
|
2010-04-07 18:16:05 +00:00
|
|
|
{
|
2018-06-14 06:41:22 +00:00
|
|
|
int i, j, howto;
|
|
|
|
bool vargood;
|
2018-06-15 19:07:31 +00:00
|
|
|
char var[128];
|
A new implementation of the loader block cache
The block cache implementation in loader has proven to be almost useless, and in worst case even slowing down the disk reads due to insufficient cache size and extra memory copy.
Also the current cache implementation does not cache reads from CDs, or work with zfs built on top of multiple disks.
Instead of an LRU, this code uses a simple hash (O(1) read from cache), and instead of a single global cache, a separate cache per block device.
The cache also implements limited read-ahead to increase performance.
To simplify read ahead management, the read ahead will not wrap over bcache end, so in worst case, single block physical read will be performed to fill the last block in bcache.
Booting from a virtual CD over IPMI:
0ms latency, before: 27 second, after: 7 seconds
60ms latency, before: over 12 minutes, after: under 5 minutes.
Submitted by: Toomas Soome <tsoome@me.com>
Reviewed by: delphij (previous version), emaste (previous version)
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D4713
2016-04-18 23:09:22 +00:00
|
|
|
|
2015-12-22 03:07:38 +00:00
|
|
|
/*
|
2016-01-26 06:26:46 +00:00
|
|
|
* Parse the args to set the console settings, etc
|
|
|
|
* boot1.efi passes these in, if it can read /boot.config or /boot/config
|
2018-04-11 19:46:24 +00:00
|
|
|
* or iPXE may be setup to pass these in. Or the optional argument in the
|
|
|
|
* boot environment was used to pass these arguments in (in which case
|
|
|
|
* neither /boot.config nor /boot/config are consulted).
|
2016-01-26 06:26:46 +00:00
|
|
|
*
|
2015-12-22 03:07:38 +00:00
|
|
|
* Loop through the args, and for each one that contains an '=' that is
|
|
|
|
* not the first character, add it to the environment. This allows
|
|
|
|
* loader and kernel env vars to be passed on the command line. Convert
|
2018-04-11 19:46:24 +00:00
|
|
|
* args from UCS-2 to ASCII (16 to 8 bit) as they are copied (though this
|
|
|
|
* method is flawed for non-ASCII characters).
|
2015-12-22 03:07:38 +00:00
|
|
|
*/
|
2016-01-26 06:26:46 +00:00
|
|
|
howto = 0;
|
2015-12-22 03:07:38 +00:00
|
|
|
for (i = 1; i < argc; i++) {
|
2018-07-13 16:43:23 +00:00
|
|
|
cpy16to8(argv[i], var, sizeof(var));
|
|
|
|
howto |= boot_parse_arg(var);
|
2015-12-22 03:07:38 +00:00
|
|
|
}
|
2018-07-13 16:43:23 +00:00
|
|
|
|
2018-06-15 19:07:31 +00:00
|
|
|
return (howto);
|
|
|
|
}
|
|
|
|
|
2018-07-28 19:44:20 +00:00
|
|
|
static void
|
|
|
|
setenv_int(const char *key, int val)
|
|
|
|
{
|
|
|
|
char buf[20];
|
|
|
|
|
|
|
|
snprintf(buf, sizeof(buf), "%d", val);
|
|
|
|
setenv(key, buf, 1);
|
|
|
|
}
|
|
|
|
|
2018-07-14 00:40:38 +00:00
|
|
|
/*
|
|
|
|
* Parse ConOut (the list of consoles active) and see if we can find a
|
|
|
|
* serial port and/or a video port. It would be nice to also walk the
|
|
|
|
* ACPI name space to map the UID for the serial port to a port. The
|
|
|
|
* latter is especially hard.
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
parse_uefi_con_out(void)
|
|
|
|
{
|
|
|
|
int how, rv;
|
|
|
|
int vid_seen = 0, com_seen = 0, seen = 0;
|
|
|
|
size_t sz;
|
|
|
|
char buf[4096], *ep;
|
|
|
|
EFI_DEVICE_PATH *node;
|
|
|
|
ACPI_HID_DEVICE_PATH *acpi;
|
|
|
|
UART_DEVICE_PATH *uart;
|
|
|
|
bool pci_pending;
|
|
|
|
|
|
|
|
how = 0;
|
|
|
|
sz = sizeof(buf);
|
|
|
|
rv = efi_global_getenv("ConOut", buf, &sz);
|
|
|
|
if (rv != EFI_SUCCESS)
|
|
|
|
goto out;
|
|
|
|
ep = buf + sz;
|
|
|
|
node = (EFI_DEVICE_PATH *)buf;
|
2018-07-14 06:43:37 +00:00
|
|
|
while ((char *)node < ep) {
|
2018-07-14 00:40:38 +00:00
|
|
|
pci_pending = false;
|
|
|
|
if (DevicePathType(node) == ACPI_DEVICE_PATH &&
|
|
|
|
DevicePathSubType(node) == ACPI_DP) {
|
|
|
|
/* Check for Serial node */
|
|
|
|
acpi = (void *)node;
|
2018-07-28 19:44:20 +00:00
|
|
|
if (EISA_ID_TO_NUM(acpi->HID) == 0x501) {
|
|
|
|
setenv_int("efi_8250_uid", acpi->UID);
|
2018-07-14 00:40:38 +00:00
|
|
|
com_seen = ++seen;
|
2018-07-28 19:44:20 +00:00
|
|
|
}
|
2018-07-14 00:40:38 +00:00
|
|
|
} else if (DevicePathType(node) == MESSAGING_DEVICE_PATH &&
|
|
|
|
DevicePathSubType(node) == MSG_UART_DP) {
|
|
|
|
|
|
|
|
uart = (void *)node;
|
2018-07-28 19:44:20 +00:00
|
|
|
setenv_int("efi_com_speed", uart->BaudRate);
|
2018-07-14 00:40:38 +00:00
|
|
|
} else if (DevicePathType(node) == ACPI_DEVICE_PATH &&
|
|
|
|
DevicePathSubType(node) == ACPI_ADR_DP) {
|
|
|
|
/* Check for AcpiAdr() Node for video */
|
|
|
|
vid_seen = ++seen;
|
|
|
|
} else if (DevicePathType(node) == HARDWARE_DEVICE_PATH &&
|
|
|
|
DevicePathSubType(node) == HW_PCI_DP) {
|
|
|
|
/*
|
|
|
|
* Note, vmware fusion has a funky console device
|
|
|
|
* PciRoot(0x0)/Pci(0xf,0x0)
|
|
|
|
* which we can only detect at the end since we also
|
|
|
|
* have to cope with:
|
|
|
|
* PciRoot(0x0)/Pci(0x1f,0x0)/Serial(0x1)
|
|
|
|
* so only match it if it's last.
|
|
|
|
*/
|
|
|
|
pci_pending = true;
|
|
|
|
}
|
|
|
|
node = NextDevicePathNode(node); /* Skip the end node */
|
|
|
|
}
|
|
|
|
if (pci_pending && vid_seen == 0)
|
|
|
|
vid_seen = ++seen;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Truth table for RB_MULTIPLE | RB_SERIAL
|
|
|
|
* Value Result
|
|
|
|
* 0 Use only video console
|
|
|
|
* RB_SERIAL Use only serial console
|
|
|
|
* RB_MULTIPLE Use both video and serial console
|
|
|
|
* (but video is primary so gets rc messages)
|
|
|
|
* both Use both video and serial console
|
|
|
|
* (but serial is primary so gets rc messages)
|
|
|
|
*
|
|
|
|
* Try to honor this as best we can. If only one of serial / video
|
|
|
|
* found, then use that. Otherwise, use the first one we found.
|
|
|
|
* This also implies if we found nothing, default to video.
|
|
|
|
*/
|
|
|
|
how = 0;
|
|
|
|
if (vid_seen && com_seen) {
|
|
|
|
how |= RB_MULTIPLE;
|
|
|
|
if (com_seen < vid_seen)
|
|
|
|
how |= RB_SERIAL;
|
|
|
|
} else if (com_seen)
|
|
|
|
how |= RB_SERIAL;
|
|
|
|
out:
|
|
|
|
return (how);
|
|
|
|
}
|
2018-06-15 19:07:31 +00:00
|
|
|
|
2019-04-29 05:02:25 +00:00
|
|
|
void
|
|
|
|
parse_loader_efi_config(EFI_HANDLE h, const char *env_fn)
|
|
|
|
{
|
|
|
|
pdinfo_t *dp;
|
|
|
|
struct stat st;
|
|
|
|
int fd = -1;
|
|
|
|
char *env = NULL;
|
|
|
|
|
|
|
|
dp = efiblk_get_pdinfo_by_handle(h);
|
|
|
|
if (dp == NULL)
|
|
|
|
return;
|
|
|
|
set_currdev_pdinfo(dp);
|
|
|
|
if (stat(env_fn, &st) != 0)
|
|
|
|
return;
|
|
|
|
fd = open(env_fn, O_RDONLY);
|
|
|
|
if (fd == -1)
|
|
|
|
return;
|
|
|
|
env = malloc(st.st_size + 1);
|
|
|
|
if (env == NULL)
|
|
|
|
goto out;
|
|
|
|
if (read(fd, env, st.st_size) != st.st_size)
|
|
|
|
goto out;
|
|
|
|
env[st.st_size] = '\0';
|
|
|
|
boot_parse_cmdline(env);
|
|
|
|
out:
|
|
|
|
free(env);
|
|
|
|
close(fd);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
read_loader_env(const char *name, char *def_fn, bool once)
|
|
|
|
{
|
|
|
|
UINTN len;
|
|
|
|
char *fn, *freeme = NULL;
|
|
|
|
|
|
|
|
len = 0;
|
|
|
|
fn = def_fn;
|
|
|
|
if (efi_freebsd_getenv(name, NULL, &len) == EFI_BUFFER_TOO_SMALL) {
|
|
|
|
freeme = fn = malloc(len + 1);
|
|
|
|
if (fn != NULL) {
|
|
|
|
if (efi_freebsd_getenv(name, fn, &len) != EFI_SUCCESS) {
|
|
|
|
free(fn);
|
|
|
|
fn = NULL;
|
|
|
|
printf(
|
|
|
|
"Can't fetch FreeBSD::%s we know is there\n", name);
|
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* if tagged as 'once' delete the env variable so we
|
|
|
|
* only use it once.
|
|
|
|
*/
|
|
|
|
if (once)
|
|
|
|
efi_freebsd_delenv(name);
|
|
|
|
/*
|
|
|
|
* We malloced 1 more than len above, then redid the call.
|
|
|
|
* so now we have room at the end of the string to NUL terminate
|
|
|
|
* it here, even if the typical idium would have '- 1' here to
|
|
|
|
* not overflow. len should be the same on return both times.
|
|
|
|
*/
|
|
|
|
fn[len] = '\0';
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
printf(
|
|
|
|
"Can't allocate %d bytes to fetch FreeBSD::%s env var\n",
|
|
|
|
len, name);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (fn) {
|
|
|
|
printf(" Reading loader env vars from %s\n", fn);
|
|
|
|
parse_loader_efi_config(boot_img->DeviceHandle, fn);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-06-15 19:07:31 +00:00
|
|
|
EFI_STATUS
|
|
|
|
main(int argc, CHAR16 *argv[])
|
|
|
|
{
|
|
|
|
EFI_GUID *guid;
|
2018-07-14 00:40:38 +00:00
|
|
|
int howto, i, uhowto;
|
2018-06-15 19:07:31 +00:00
|
|
|
UINTN k;
|
Finalize the boot manager protocol support for next-stage boot
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
2018-07-23 20:36:59 +00:00
|
|
|
bool has_kbd, is_last;
|
2018-06-15 19:07:31 +00:00
|
|
|
char *s;
|
|
|
|
EFI_DEVICE_PATH *imgpath;
|
|
|
|
CHAR16 *text;
|
Finalize the boot manager protocol support for next-stage boot
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
2018-07-23 20:36:59 +00:00
|
|
|
EFI_STATUS rv;
|
|
|
|
size_t sz, bosz = 0, bisz = 0;
|
2018-06-15 19:07:31 +00:00
|
|
|
UINT16 boot_order[100];
|
Finalize the boot manager protocol support for next-stage boot
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
2018-07-23 20:36:59 +00:00
|
|
|
char boot_info[4096];
|
|
|
|
char buf[32];
|
|
|
|
bool uefi_boot_mgr;
|
2018-06-15 19:07:31 +00:00
|
|
|
|
|
|
|
archsw.arch_autoload = efi_autoload;
|
|
|
|
archsw.arch_getdev = efi_getdev;
|
|
|
|
archsw.arch_copyin = efi_copyin;
|
|
|
|
archsw.arch_copyout = efi_copyout;
|
|
|
|
archsw.arch_readin = efi_readin;
|
|
|
|
archsw.arch_zfs_probe = efi_zfs_probe;
|
|
|
|
|
|
|
|
/* Get our loaded image protocol interface structure. */
|
2019-04-22 18:40:24 +00:00
|
|
|
BS->HandleProtocol(IH, &imgid, (VOID**)&boot_img);
|
2018-06-15 19:07:31 +00:00
|
|
|
|
2019-04-22 18:33:32 +00:00
|
|
|
/*
|
|
|
|
* Chicken-and-egg problem; we want to have console output early, but
|
|
|
|
* some console attributes may depend on reading from eg. the boot
|
|
|
|
* device, which we can't do yet. We can use printf() etc. once this is
|
|
|
|
* done. So, we set it to the efi console, then call console init. This
|
|
|
|
* gets us printf early, but also primes the pump for all future console
|
|
|
|
* changes to take effect, regardless of where they come from.
|
|
|
|
*/
|
|
|
|
setenv("console", "efi", 1);
|
|
|
|
cons_probe();
|
|
|
|
|
2018-06-15 19:07:31 +00:00
|
|
|
/* Init the time source */
|
|
|
|
efi_time_init();
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Initialise the block cache. Set the upper limit.
|
|
|
|
*/
|
|
|
|
bcache_init(32768, 512);
|
|
|
|
|
2019-04-25 20:10:02 +00:00
|
|
|
/*
|
|
|
|
* Scan the BLOCK IO MEDIA handles then
|
|
|
|
* march through the device switch probing for things.
|
|
|
|
*/
|
|
|
|
i = efipart_inithandles();
|
|
|
|
if (i != 0 && i != ENOENT) {
|
|
|
|
printf("efipart_inithandles failed with ERRNO %d, expect "
|
|
|
|
"failures\n", i);
|
|
|
|
}
|
|
|
|
|
|
|
|
for (i = 0; devsw[i] != NULL; i++)
|
|
|
|
if (devsw[i]->dv_init != NULL)
|
|
|
|
(devsw[i]->dv_init)();
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Detect console settings two different ways: one via the command
|
|
|
|
* args (eg -h) or via the UEFI ConOut variable.
|
|
|
|
*/
|
|
|
|
has_kbd = has_keyboard();
|
2018-07-14 00:40:38 +00:00
|
|
|
howto = parse_args(argc, argv);
|
|
|
|
if (!has_kbd && (howto & RB_PROBE))
|
|
|
|
howto |= RB_SERIAL | RB_MULTIPLE;
|
|
|
|
howto &= ~RB_PROBE;
|
|
|
|
uhowto = parse_uefi_con_out();
|
2018-04-11 19:46:24 +00:00
|
|
|
|
2019-04-29 05:02:25 +00:00
|
|
|
/*
|
|
|
|
* Scan the BLOCK IO MEDIA handles then
|
|
|
|
* march through the device switch probing for things.
|
|
|
|
*/
|
|
|
|
i = efipart_inithandles();
|
|
|
|
if (i != 0 && i != ENOENT) {
|
|
|
|
printf("efipart_inithandles failed with ERRNO %d, expect "
|
|
|
|
"failures\n", i);
|
|
|
|
}
|
|
|
|
|
|
|
|
for (i = 0; devsw[i] != NULL; i++)
|
|
|
|
if (devsw[i]->dv_init != NULL)
|
|
|
|
(devsw[i]->dv_init)();
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Read additional environment variables from the boot device's
|
|
|
|
* "LoaderEnv" file. Any boot loader environment variable may be set
|
|
|
|
* there, which are subtly different than loader.conf variables. Only
|
|
|
|
* the 'simple' ones may be set so things like foo_load="YES" won't work
|
|
|
|
* for two reasons. First, the parser is simplistic and doesn't grok
|
|
|
|
* quotes. Second, because the variables that cause an action to happen
|
|
|
|
* are parsed by the lua, 4th or whatever code that's not yet
|
|
|
|
* loaded. This is relative to the root directory when loader.efi is
|
|
|
|
* loaded off the UFS root drive (when chain booted), or from the ESP
|
|
|
|
* when directly loaded by the BIOS.
|
|
|
|
*
|
|
|
|
* We also read in NextLoaderEnv if it was specified. This allows next boot
|
|
|
|
* functionality to be implemented and to override anything in LoaderEnv.
|
|
|
|
*/
|
|
|
|
read_loader_env("LoaderEnv", "/efi/freebsd/loader.env", false);
|
|
|
|
read_loader_env("NextLoaderEnv", NULL, true);
|
|
|
|
|
2018-04-11 19:46:24 +00:00
|
|
|
/*
|
2018-07-14 00:40:38 +00:00
|
|
|
* We now have two notions of console. howto should be viewed as
|
2018-07-18 22:45:45 +00:00
|
|
|
* overrides. If console is already set, don't set it again.
|
2018-04-11 19:46:24 +00:00
|
|
|
*/
|
2018-07-14 00:40:38 +00:00
|
|
|
#define VIDEO_ONLY 0
|
|
|
|
#define SERIAL_ONLY RB_SERIAL
|
|
|
|
#define VID_SER_BOTH RB_MULTIPLE
|
|
|
|
#define SER_VID_BOTH (RB_SERIAL | RB_MULTIPLE)
|
|
|
|
#define CON_MASK (RB_SERIAL | RB_MULTIPLE)
|
2018-07-23 06:38:48 +00:00
|
|
|
if (strcmp(getenv("console"), "efi") == 0) {
|
2018-07-18 22:45:45 +00:00
|
|
|
if ((howto & CON_MASK) == 0) {
|
|
|
|
/* No override, uhowto is controlling and efi cons is perfect */
|
|
|
|
howto = howto | (uhowto & CON_MASK);
|
|
|
|
} else if ((howto & CON_MASK) == (uhowto & CON_MASK)) {
|
|
|
|
/* override matches what UEFI told us, efi console is perfect */
|
|
|
|
} else if ((uhowto & (CON_MASK)) != 0) {
|
|
|
|
/*
|
|
|
|
* We detected a serial console on ConOut. All possible
|
|
|
|
* overrides include serial. We can't really override what efi
|
|
|
|
* gives us, so we use it knowing it's the best choice.
|
|
|
|
*/
|
2019-04-22 18:33:32 +00:00
|
|
|
/* Do nothing */
|
2018-07-18 22:45:45 +00:00
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* We detected some kind of serial in the override, but ConOut
|
|
|
|
* has no serial, so we have to sort out which case it really is.
|
|
|
|
*/
|
|
|
|
switch (howto & CON_MASK) {
|
|
|
|
case SERIAL_ONLY:
|
|
|
|
setenv("console", "comconsole", 1);
|
|
|
|
break;
|
|
|
|
case VID_SER_BOTH:
|
|
|
|
setenv("console", "efi comconsole", 1);
|
|
|
|
break;
|
|
|
|
case SER_VID_BOTH:
|
|
|
|
setenv("console", "comconsole efi", 1);
|
|
|
|
break;
|
|
|
|
/* case VIDEO_ONLY can't happen -- it's the first if above */
|
|
|
|
}
|
2018-07-14 00:40:38 +00:00
|
|
|
}
|
|
|
|
}
|
2018-07-27 22:00:00 +00:00
|
|
|
|
2018-07-14 00:40:38 +00:00
|
|
|
/*
|
|
|
|
* howto is set now how we want to export the flags to the kernel, so
|
|
|
|
* set the env based on it.
|
|
|
|
*/
|
|
|
|
boot_howto_to_env(howto);
|
2018-07-18 22:45:26 +00:00
|
|
|
|
2015-04-01 08:30:40 +00:00
|
|
|
if (efi_copy_init()) {
|
Support UEFI booting on amd64 via loader.efi
This is largely the work from the projects/uefi branch, with some
additional refinements. This is derived from (and replaces) the
original i386 efi implementation; i386 support will be restored later.
Specific revisions of note from projects/uefi:
r247380:
Adjust our load device when we boot from CD under UEFI.
The process for booting from a CD under UEFI involves adding a FAT
filesystem containing your loader code as an El Torito boot image.
When UEFI detects this, it provides a block IO instance that points at
the FAT filesystem as a child of the device that represents the CD
itself. The problem being that the CD device is flagged as a "raw
device" while the boot image is flagged as a "logical partition". The
existing EFI partition code only looks for logical partitions and so
the CD filesystem was rendered invisible.
To fix this, check the type of each block IO device. If it's found to
be a CD, and thus an El Torito boot image, look up its parent device
and add that instead so that the loader will then load the kernel from
the CD filesystem. This is done by using the handle for the boot
filesystem as an alias.
Something similar to this will be required for booting from other
media as well as the loader will live in the EFI system partition, not
on the partition containing the kernel.
r246231:
Add necessary code to hand off from loader to an amd64 kernel.
r246335:
Grab the EFI memory map and store it as module metadata on the kernel.
This is the same approach used to provide the BIOS SMAP to the kernel.
r246336:
Pass the ACPI table metadata via hints so the kernel ACPI code can
find them.
r246608:
Rework copy routines to ensure we always use memory allocated via EFI.
The previous code assumed it could copy wherever it liked. This is not
the case. The approach taken by this code is pretty ham-fisted in that
it simply allocates a large (32MB) buffer area and stages into that,
then copies the whole area into place when it's time to execute. A more
elegant solution could be used but this works for now.
r247214:
Fix a number of problems preventing proper handover to the kernel.
There were two issues at play here. Firstly, there was nothing
preventing UEFI from placing the loader code above 1GB in RAM. This
meant that when we switched in the page tables the kernel expects to
be running on, we are suddenly unmapped and things no longer work. We
solve this by making our trampoline code not dependent on being at any
given position and simply copying it to a "safe" location before
calling it.
Secondly, UEFI could allocate our stack wherever it wants. As it
happened on my PC, that was right where I was copying the kernel to.
This did not cause happiness. The solution to this was to also switch
to a temporary stack in a safe location before performing the final
copy of the loaded kernel.
r246231:
Add necessary code to hand off from loader to an amd64 kernel.
r246335:
Grab the EFI memory map and store it as module metadata on the kernel.
This is the same approach used to provide the BIOS SMAP to the kernel.
r246336:
Pass the ACPI table metadata via hints so the kernel ACPI code can
find them.
r246608:
Rework copy routines to ensure we always use memory allocated via EFI.
The previous code assumed it could copy wherever it liked. This is not
the case. The approach taken by this code is pretty ham-fisted in that
it simply allocates a large (32MB) buffer area and stages into that,
then copies the whole area into place when it's time to execute. A more
elegant solution could be used but this works for now.
r247214:
Fix a number of problems preventing proper handover to the kernel.
There were two issues at play here. Firstly, there was nothing
preventing UEFI from placing the loader code above 1GB in RAM. This
meant that when we switched in the page tables the kernel expects to
be running on, we are suddenly unmapped and things no longer work. We
solve this by making our trampoline code not dependent on being at any
given position and simply copying it to a "safe" location before
calling it.
Secondly, UEFI could allocate our stack wherever it wants. As it
happened on my PC, that was right where I was copying the kernel to.
This did not cause happiness. The solution to this was to also switch
to a temporary stack in a safe location before performing the final
copy of the loaded kernel.
r247216:
Use the UEFI Graphics Output Protocol to get the parameters of the
framebuffer.
Sponsored by: The FreeBSD Foundation
2014-04-04 00:16:46 +00:00
|
|
|
printf("failed to allocate staging area\n");
|
|
|
|
return (EFI_BUFFER_TOO_SMALL);
|
|
|
|
}
|
|
|
|
|
2018-04-11 19:46:24 +00:00
|
|
|
if ((s = getenv("fail_timeout")) != NULL)
|
|
|
|
fail_timeout = strtol(s, NULL, 10);
|
|
|
|
|
2018-07-14 06:43:37 +00:00
|
|
|
printf("%s\n", bootprog_info);
|
|
|
|
printf(" Command line arguments:");
|
2016-05-20 19:37:46 +00:00
|
|
|
for (i = 0; i < argc; i++)
|
|
|
|
printf(" %S", argv[i]);
|
2016-01-15 01:22:36 +00:00
|
|
|
printf("\n");
|
|
|
|
|
2018-07-14 06:43:37 +00:00
|
|
|
printf(" EFI version: %d.%02d\n", ST->Hdr.Revision >> 16,
|
2010-04-07 18:16:05 +00:00
|
|
|
ST->Hdr.Revision & 0xffff);
|
2018-07-14 06:43:37 +00:00
|
|
|
printf(" EFI Firmware: %S (rev %d.%02d)\n", ST->FirmwareVendor,
|
2016-05-17 21:25:20 +00:00
|
|
|
ST->FirmwareRevision >> 16, ST->FirmwareRevision & 0xffff);
|
2018-07-27 22:29:15 +00:00
|
|
|
printf(" Console: %s (%#x)\n", getenv("console"), howto);
|
|
|
|
|
2018-04-11 19:46:24 +00:00
|
|
|
/* Determine the devpath of our image so we can prefer it. */
|
2019-04-22 18:40:24 +00:00
|
|
|
text = efi_devpath_name(boot_img->FilePath);
|
2018-03-12 21:40:24 +00:00
|
|
|
if (text != NULL) {
|
|
|
|
printf(" Load Path: %S\n", text);
|
|
|
|
efi_setenv_freebsd_wcs("LoaderPath", text);
|
|
|
|
efi_free_devpath_name(text);
|
|
|
|
}
|
|
|
|
|
2019-04-22 18:40:24 +00:00
|
|
|
rv = BS->HandleProtocol(boot_img->DeviceHandle, &devid, (void **)&imgpath);
|
Finalize the boot manager protocol support for next-stage boot
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
2018-07-23 20:36:59 +00:00
|
|
|
if (rv == EFI_SUCCESS) {
|
2018-03-12 21:40:24 +00:00
|
|
|
text = efi_devpath_name(imgpath);
|
|
|
|
if (text != NULL) {
|
|
|
|
printf(" Load Device: %S\n", text);
|
|
|
|
efi_setenv_freebsd_wcs("LoaderDev", text);
|
|
|
|
efi_free_devpath_name(text);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Finalize the boot manager protocol support for next-stage boot
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
2018-07-23 20:36:59 +00:00
|
|
|
uefi_boot_mgr = true;
|
2018-03-12 21:40:24 +00:00
|
|
|
boot_current = 0;
|
|
|
|
sz = sizeof(boot_current);
|
Finalize the boot manager protocol support for next-stage boot
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
2018-07-23 20:36:59 +00:00
|
|
|
rv = efi_global_getenv("BootCurrent", &boot_current, &sz);
|
|
|
|
if (rv == EFI_SUCCESS)
|
|
|
|
printf(" BootCurrent: %04x\n", boot_current);
|
|
|
|
else {
|
|
|
|
boot_current = 0xffff;
|
|
|
|
uefi_boot_mgr = false;
|
|
|
|
}
|
2018-03-12 21:40:24 +00:00
|
|
|
|
|
|
|
sz = sizeof(boot_order);
|
Finalize the boot manager protocol support for next-stage boot
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
2018-07-23 20:36:59 +00:00
|
|
|
rv = efi_global_getenv("BootOrder", &boot_order, &sz);
|
|
|
|
if (rv == EFI_SUCCESS) {
|
|
|
|
printf(" BootOrder:");
|
|
|
|
for (i = 0; i < sz / sizeof(boot_order[0]); i++)
|
|
|
|
printf(" %04x%s", boot_order[i],
|
|
|
|
boot_order[i] == boot_current ? "[*]" : "");
|
|
|
|
printf("\n");
|
|
|
|
is_last = boot_order[(sz / sizeof(boot_order[0])) - 1] == boot_current;
|
|
|
|
bosz = sz;
|
|
|
|
} else if (uefi_boot_mgr) {
|
|
|
|
/*
|
|
|
|
* u-boot doesn't set BootOrder, but otherwise participates in the
|
|
|
|
* boot manager protocol. So we fake it here and don't consider it
|
|
|
|
* a failure.
|
|
|
|
*/
|
|
|
|
bosz = sizeof(boot_order[0]);
|
|
|
|
boot_order[0] = boot_current;
|
|
|
|
is_last = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Next, find the boot info structure the UEFI boot manager is
|
|
|
|
* supposed to setup. We need this so we can walk through it to
|
|
|
|
* find where we are in the booting process and what to try to
|
|
|
|
* boot next.
|
|
|
|
*/
|
|
|
|
if (uefi_boot_mgr) {
|
|
|
|
snprintf(buf, sizeof(buf), "Boot%04X", boot_current);
|
|
|
|
sz = sizeof(boot_info);
|
|
|
|
rv = efi_global_getenv(buf, &boot_info, &sz);
|
|
|
|
if (rv == EFI_SUCCESS)
|
|
|
|
bisz = sz;
|
|
|
|
else
|
|
|
|
uefi_boot_mgr = false;
|
|
|
|
}
|
2018-03-12 21:40:24 +00:00
|
|
|
|
2010-04-07 18:16:05 +00:00
|
|
|
/*
|
|
|
|
* Disable the watchdog timer. By default the boot manager sets
|
|
|
|
* the timer to 5 minutes before invoking a boot option. If we
|
|
|
|
* want to return to the boot manager, we have to disable the
|
|
|
|
* watchdog timer and since we're an interactive program, we don't
|
|
|
|
* want to wait until the user types "quit". The timer may have
|
|
|
|
* fired by then. We don't care if this fails. It does not prevent
|
|
|
|
* normal functioning in any way...
|
|
|
|
*/
|
|
|
|
BS->SetWatchdogTimer(0, 0, 0, NULL);
|
|
|
|
|
2019-03-06 06:39:42 +00:00
|
|
|
/*
|
|
|
|
* Initialize the trusted/forbidden certificates from UEFI.
|
|
|
|
* They will be later used to verify the manifest(s),
|
|
|
|
* which should contain hashes of verified files.
|
|
|
|
* This needs to be initialized before any configuration files
|
|
|
|
* are loaded.
|
|
|
|
*/
|
|
|
|
#ifdef EFI_SECUREBOOT
|
|
|
|
ve_efi_init();
|
|
|
|
#endif
|
|
|
|
|
2018-04-11 19:46:24 +00:00
|
|
|
/*
|
|
|
|
* Try and find a good currdev based on the image that was booted.
|
|
|
|
* It might be desirable here to have a short pause to allow falling
|
|
|
|
* through to the boot loader instead of returning instantly to follow
|
|
|
|
* the boot protocol and also allow an escape hatch for users wishing
|
|
|
|
* to try something different.
|
|
|
|
*/
|
2019-04-22 18:40:24 +00:00
|
|
|
if (find_currdev(uefi_boot_mgr, is_last, boot_info, bisz) != 0)
|
2018-04-11 19:46:24 +00:00
|
|
|
if (!interactive_interrupt("Failed to find bootable partition"))
|
|
|
|
return (EFI_NOT_FOUND);
|
2016-01-15 01:22:36 +00:00
|
|
|
|
2017-02-01 08:46:59 +00:00
|
|
|
efi_init_environment();
|
Support UEFI booting on amd64 via loader.efi
This is largely the work from the projects/uefi branch, with some
additional refinements. This is derived from (and replaces) the
original i386 efi implementation; i386 support will be restored later.
Specific revisions of note from projects/uefi:
r247380:
Adjust our load device when we boot from CD under UEFI.
The process for booting from a CD under UEFI involves adding a FAT
filesystem containing your loader code as an El Torito boot image.
When UEFI detects this, it provides a block IO instance that points at
the FAT filesystem as a child of the device that represents the CD
itself. The problem being that the CD device is flagged as a "raw
device" while the boot image is flagged as a "logical partition". The
existing EFI partition code only looks for logical partitions and so
the CD filesystem was rendered invisible.
To fix this, check the type of each block IO device. If it's found to
be a CD, and thus an El Torito boot image, look up its parent device
and add that instead so that the loader will then load the kernel from
the CD filesystem. This is done by using the handle for the boot
filesystem as an alias.
Something similar to this will be required for booting from other
media as well as the loader will live in the EFI system partition, not
on the partition containing the kernel.
r246231:
Add necessary code to hand off from loader to an amd64 kernel.
r246335:
Grab the EFI memory map and store it as module metadata on the kernel.
This is the same approach used to provide the BIOS SMAP to the kernel.
r246336:
Pass the ACPI table metadata via hints so the kernel ACPI code can
find them.
r246608:
Rework copy routines to ensure we always use memory allocated via EFI.
The previous code assumed it could copy wherever it liked. This is not
the case. The approach taken by this code is pretty ham-fisted in that
it simply allocates a large (32MB) buffer area and stages into that,
then copies the whole area into place when it's time to execute. A more
elegant solution could be used but this works for now.
r247214:
Fix a number of problems preventing proper handover to the kernel.
There were two issues at play here. Firstly, there was nothing
preventing UEFI from placing the loader code above 1GB in RAM. This
meant that when we switched in the page tables the kernel expects to
be running on, we are suddenly unmapped and things no longer work. We
solve this by making our trampoline code not dependent on being at any
given position and simply copying it to a "safe" location before
calling it.
Secondly, UEFI could allocate our stack wherever it wants. As it
happened on my PC, that was right where I was copying the kernel to.
This did not cause happiness. The solution to this was to also switch
to a temporary stack in a safe location before performing the final
copy of the loaded kernel.
r246231:
Add necessary code to hand off from loader to an amd64 kernel.
r246335:
Grab the EFI memory map and store it as module metadata on the kernel.
This is the same approach used to provide the BIOS SMAP to the kernel.
r246336:
Pass the ACPI table metadata via hints so the kernel ACPI code can
find them.
r246608:
Rework copy routines to ensure we always use memory allocated via EFI.
The previous code assumed it could copy wherever it liked. This is not
the case. The approach taken by this code is pretty ham-fisted in that
it simply allocates a large (32MB) buffer area and stages into that,
then copies the whole area into place when it's time to execute. A more
elegant solution could be used but this works for now.
r247214:
Fix a number of problems preventing proper handover to the kernel.
There were two issues at play here. Firstly, there was nothing
preventing UEFI from placing the loader code above 1GB in RAM. This
meant that when we switched in the page tables the kernel expects to
be running on, we are suddenly unmapped and things no longer work. We
solve this by making our trampoline code not dependent on being at any
given position and simply copying it to a "safe" location before
calling it.
Secondly, UEFI could allocate our stack wherever it wants. As it
happened on my PC, that was right where I was copying the kernel to.
This did not cause happiness. The solution to this was to also switch
to a temporary stack in a safe location before performing the final
copy of the loaded kernel.
r247216:
Use the UEFI Graphics Output Protocol to get the parameters of the
framebuffer.
Sponsored by: The FreeBSD Foundation
2014-04-04 00:16:46 +00:00
|
|
|
|
2018-06-15 19:07:37 +00:00
|
|
|
#if !defined(__arm__)
|
2016-01-12 02:17:39 +00:00
|
|
|
for (k = 0; k < ST->NumberOfTableEntries; k++) {
|
|
|
|
guid = &ST->ConfigurationTable[k].VendorGuid;
|
2015-04-06 06:55:47 +00:00
|
|
|
if (!memcmp(guid, &smbios, sizeof(EFI_GUID))) {
|
2018-06-15 19:07:37 +00:00
|
|
|
char buf[40];
|
|
|
|
|
2016-10-14 17:10:53 +00:00
|
|
|
snprintf(buf, sizeof(buf), "%p",
|
|
|
|
ST->ConfigurationTable[k].VendorTable);
|
|
|
|
setenv("hint.smbios.0.mem", buf, 1);
|
2016-01-12 02:17:39 +00:00
|
|
|
smbios_detect(ST->ConfigurationTable[k].VendorTable);
|
2015-04-06 06:55:47 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
2018-06-15 19:07:37 +00:00
|
|
|
#endif
|
2015-04-06 06:55:47 +00:00
|
|
|
|
2017-12-19 04:05:55 +00:00
|
|
|
interact(); /* doesn't return */
|
2010-04-07 18:16:05 +00:00
|
|
|
|
|
|
|
return (EFI_SUCCESS); /* keep compiler happy */
|
|
|
|
}
|
|
|
|
|
2018-10-12 16:24:49 +00:00
|
|
|
COMMAND_SET(poweroff, "poweroff", "power off the system", command_poweroff);
|
|
|
|
|
|
|
|
static int
|
|
|
|
command_poweroff(int argc __unused, char *argv[] __unused)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; devsw[i] != NULL; ++i)
|
|
|
|
if (devsw[i]->dv_cleanup != NULL)
|
|
|
|
(devsw[i]->dv_cleanup)();
|
|
|
|
|
|
|
|
RS->ResetSystem(EfiResetShutdown, EFI_SUCCESS, 0, NULL);
|
|
|
|
|
|
|
|
/* NOTREACHED */
|
|
|
|
return (CMD_ERROR);
|
|
|
|
}
|
|
|
|
|
2010-04-07 18:16:05 +00:00
|
|
|
COMMAND_SET(reboot, "reboot", "reboot the system", command_reboot);
|
|
|
|
|
|
|
|
static int
|
|
|
|
command_reboot(int argc, char *argv[])
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; devsw[i] != NULL; ++i)
|
|
|
|
if (devsw[i]->dv_cleanup != NULL)
|
|
|
|
(devsw[i]->dv_cleanup)();
|
|
|
|
|
2017-05-01 16:56:34 +00:00
|
|
|
RS->ResetSystem(EfiResetCold, EFI_SUCCESS, 0, NULL);
|
2010-04-07 18:16:05 +00:00
|
|
|
|
|
|
|
/* NOTREACHED */
|
|
|
|
return (CMD_ERROR);
|
|
|
|
}
|
|
|
|
|
|
|
|
COMMAND_SET(quit, "quit", "exit the loader", command_quit);
|
|
|
|
|
|
|
|
static int
|
|
|
|
command_quit(int argc, char *argv[])
|
|
|
|
{
|
|
|
|
exit(0);
|
|
|
|
return (CMD_OK);
|
|
|
|
}
|
|
|
|
|
|
|
|
COMMAND_SET(memmap, "memmap", "print memory map", command_memmap);
|
|
|
|
|
|
|
|
static int
|
2019-01-03 09:03:58 +00:00
|
|
|
command_memmap(int argc __unused, char *argv[] __unused)
|
2010-04-07 18:16:05 +00:00
|
|
|
{
|
|
|
|
UINTN sz;
|
|
|
|
EFI_MEMORY_DESCRIPTOR *map, *p;
|
|
|
|
UINTN key, dsz;
|
|
|
|
UINT32 dver;
|
|
|
|
EFI_STATUS status;
|
|
|
|
int i, ndesc;
|
2016-11-08 06:50:18 +00:00
|
|
|
char line[80];
|
2010-04-07 18:16:05 +00:00
|
|
|
|
|
|
|
sz = 0;
|
|
|
|
status = BS->GetMemoryMap(&sz, 0, &key, &dsz, &dver);
|
|
|
|
if (status != EFI_BUFFER_TOO_SMALL) {
|
|
|
|
printf("Can't determine memory map size\n");
|
2016-01-06 19:18:43 +00:00
|
|
|
return (CMD_ERROR);
|
2010-04-07 18:16:05 +00:00
|
|
|
}
|
|
|
|
map = malloc(sz);
|
|
|
|
status = BS->GetMemoryMap(&sz, map, &key, &dsz, &dver);
|
|
|
|
if (EFI_ERROR(status)) {
|
|
|
|
printf("Can't read memory map\n");
|
2016-01-06 19:18:43 +00:00
|
|
|
return (CMD_ERROR);
|
2010-04-07 18:16:05 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
ndesc = sz / dsz;
|
2016-11-08 06:50:18 +00:00
|
|
|
snprintf(line, sizeof(line), "%23s %12s %12s %8s %4s\n",
|
2016-01-06 19:18:43 +00:00
|
|
|
"Type", "Physical", "Virtual", "#Pages", "Attr");
|
2016-11-08 06:50:18 +00:00
|
|
|
pager_open();
|
|
|
|
if (pager_output(line)) {
|
|
|
|
pager_close();
|
|
|
|
return (CMD_OK);
|
|
|
|
}
|
Support UEFI booting on amd64 via loader.efi
This is largely the work from the projects/uefi branch, with some
additional refinements. This is derived from (and replaces) the
original i386 efi implementation; i386 support will be restored later.
Specific revisions of note from projects/uefi:
r247380:
Adjust our load device when we boot from CD under UEFI.
The process for booting from a CD under UEFI involves adding a FAT
filesystem containing your loader code as an El Torito boot image.
When UEFI detects this, it provides a block IO instance that points at
the FAT filesystem as a child of the device that represents the CD
itself. The problem being that the CD device is flagged as a "raw
device" while the boot image is flagged as a "logical partition". The
existing EFI partition code only looks for logical partitions and so
the CD filesystem was rendered invisible.
To fix this, check the type of each block IO device. If it's found to
be a CD, and thus an El Torito boot image, look up its parent device
and add that instead so that the loader will then load the kernel from
the CD filesystem. This is done by using the handle for the boot
filesystem as an alias.
Something similar to this will be required for booting from other
media as well as the loader will live in the EFI system partition, not
on the partition containing the kernel.
r246231:
Add necessary code to hand off from loader to an amd64 kernel.
r246335:
Grab the EFI memory map and store it as module metadata on the kernel.
This is the same approach used to provide the BIOS SMAP to the kernel.
r246336:
Pass the ACPI table metadata via hints so the kernel ACPI code can
find them.
r246608:
Rework copy routines to ensure we always use memory allocated via EFI.
The previous code assumed it could copy wherever it liked. This is not
the case. The approach taken by this code is pretty ham-fisted in that
it simply allocates a large (32MB) buffer area and stages into that,
then copies the whole area into place when it's time to execute. A more
elegant solution could be used but this works for now.
r247214:
Fix a number of problems preventing proper handover to the kernel.
There were two issues at play here. Firstly, there was nothing
preventing UEFI from placing the loader code above 1GB in RAM. This
meant that when we switched in the page tables the kernel expects to
be running on, we are suddenly unmapped and things no longer work. We
solve this by making our trampoline code not dependent on being at any
given position and simply copying it to a "safe" location before
calling it.
Secondly, UEFI could allocate our stack wherever it wants. As it
happened on my PC, that was right where I was copying the kernel to.
This did not cause happiness. The solution to this was to also switch
to a temporary stack in a safe location before performing the final
copy of the loaded kernel.
r246231:
Add necessary code to hand off from loader to an amd64 kernel.
r246335:
Grab the EFI memory map and store it as module metadata on the kernel.
This is the same approach used to provide the BIOS SMAP to the kernel.
r246336:
Pass the ACPI table metadata via hints so the kernel ACPI code can
find them.
r246608:
Rework copy routines to ensure we always use memory allocated via EFI.
The previous code assumed it could copy wherever it liked. This is not
the case. The approach taken by this code is pretty ham-fisted in that
it simply allocates a large (32MB) buffer area and stages into that,
then copies the whole area into place when it's time to execute. A more
elegant solution could be used but this works for now.
r247214:
Fix a number of problems preventing proper handover to the kernel.
There were two issues at play here. Firstly, there was nothing
preventing UEFI from placing the loader code above 1GB in RAM. This
meant that when we switched in the page tables the kernel expects to
be running on, we are suddenly unmapped and things no longer work. We
solve this by making our trampoline code not dependent on being at any
given position and simply copying it to a "safe" location before
calling it.
Secondly, UEFI could allocate our stack wherever it wants. As it
happened on my PC, that was right where I was copying the kernel to.
This did not cause happiness. The solution to this was to also switch
to a temporary stack in a safe location before performing the final
copy of the loaded kernel.
r247216:
Use the UEFI Graphics Output Protocol to get the parameters of the
framebuffer.
Sponsored by: The FreeBSD Foundation
2014-04-04 00:16:46 +00:00
|
|
|
|
2010-04-07 18:16:05 +00:00
|
|
|
for (i = 0, p = map; i < ndesc;
|
|
|
|
i++, p = NextMemoryDescriptor(p, dsz)) {
|
2019-01-03 09:03:58 +00:00
|
|
|
snprintf(line, sizeof(line), "%23s %012jx %012jx %08jx ",
|
|
|
|
efi_memory_type(p->Type), (uintmax_t)p->PhysicalStart,
|
|
|
|
(uintmax_t)p->VirtualStart, (uintmax_t)p->NumberOfPages);
|
|
|
|
if (pager_output(line))
|
|
|
|
break;
|
|
|
|
|
2016-01-06 19:18:43 +00:00
|
|
|
if (p->Attribute & EFI_MEMORY_UC)
|
|
|
|
printf("UC ");
|
|
|
|
if (p->Attribute & EFI_MEMORY_WC)
|
|
|
|
printf("WC ");
|
|
|
|
if (p->Attribute & EFI_MEMORY_WT)
|
|
|
|
printf("WT ");
|
|
|
|
if (p->Attribute & EFI_MEMORY_WB)
|
|
|
|
printf("WB ");
|
|
|
|
if (p->Attribute & EFI_MEMORY_UCE)
|
|
|
|
printf("UCE ");
|
|
|
|
if (p->Attribute & EFI_MEMORY_WP)
|
|
|
|
printf("WP ");
|
|
|
|
if (p->Attribute & EFI_MEMORY_RP)
|
|
|
|
printf("RP ");
|
|
|
|
if (p->Attribute & EFI_MEMORY_XP)
|
|
|
|
printf("XP ");
|
2019-01-03 09:03:58 +00:00
|
|
|
if (p->Attribute & EFI_MEMORY_NV)
|
|
|
|
printf("NV ");
|
|
|
|
if (p->Attribute & EFI_MEMORY_MORE_RELIABLE)
|
|
|
|
printf("MR ");
|
|
|
|
if (p->Attribute & EFI_MEMORY_RO)
|
|
|
|
printf("RO ");
|
2016-11-08 06:50:18 +00:00
|
|
|
if (pager_output("\n"))
|
|
|
|
break;
|
2010-04-07 18:16:05 +00:00
|
|
|
}
|
|
|
|
|
2016-11-08 06:50:18 +00:00
|
|
|
pager_close();
|
2016-01-06 19:18:43 +00:00
|
|
|
return (CMD_OK);
|
2010-04-07 18:16:05 +00:00
|
|
|
}
|
|
|
|
|
2016-01-06 19:18:43 +00:00
|
|
|
COMMAND_SET(configuration, "configuration", "print configuration tables",
|
|
|
|
command_configuration);
|
2010-04-07 18:16:05 +00:00
|
|
|
|
|
|
|
static int
|
|
|
|
command_configuration(int argc, char *argv[])
|
|
|
|
{
|
2016-01-12 02:17:39 +00:00
|
|
|
UINTN i;
|
2019-01-03 20:27:50 +00:00
|
|
|
char *name;
|
2010-04-07 18:16:05 +00:00
|
|
|
|
2019-01-03 20:27:50 +00:00
|
|
|
printf("NumberOfTableEntries=%lu\n",
|
2016-01-12 02:17:39 +00:00
|
|
|
(unsigned long)ST->NumberOfTableEntries);
|
2016-11-08 06:50:18 +00:00
|
|
|
|
2010-04-07 18:16:05 +00:00
|
|
|
for (i = 0; i < ST->NumberOfTableEntries; i++) {
|
|
|
|
EFI_GUID *guid;
|
|
|
|
|
|
|
|
printf(" ");
|
|
|
|
guid = &ST->ConfigurationTable[i].VendorGuid;
|
2019-01-03 20:27:50 +00:00
|
|
|
|
|
|
|
if (efi_guid_to_name(guid, &name) == true) {
|
|
|
|
printf(name);
|
|
|
|
free(name);
|
|
|
|
} else {
|
|
|
|
printf("Error while translating UUID to name");
|
|
|
|
}
|
|
|
|
printf(" at %p\n", ST->ConfigurationTable[i].VendorTable);
|
2010-04-07 18:16:05 +00:00
|
|
|
}
|
|
|
|
|
2016-01-06 19:18:43 +00:00
|
|
|
return (CMD_OK);
|
Support UEFI booting on amd64 via loader.efi
This is largely the work from the projects/uefi branch, with some
additional refinements. This is derived from (and replaces) the
original i386 efi implementation; i386 support will be restored later.
Specific revisions of note from projects/uefi:
r247380:
Adjust our load device when we boot from CD under UEFI.
The process for booting from a CD under UEFI involves adding a FAT
filesystem containing your loader code as an El Torito boot image.
When UEFI detects this, it provides a block IO instance that points at
the FAT filesystem as a child of the device that represents the CD
itself. The problem being that the CD device is flagged as a "raw
device" while the boot image is flagged as a "logical partition". The
existing EFI partition code only looks for logical partitions and so
the CD filesystem was rendered invisible.
To fix this, check the type of each block IO device. If it's found to
be a CD, and thus an El Torito boot image, look up its parent device
and add that instead so that the loader will then load the kernel from
the CD filesystem. This is done by using the handle for the boot
filesystem as an alias.
Something similar to this will be required for booting from other
media as well as the loader will live in the EFI system partition, not
on the partition containing the kernel.
r246231:
Add necessary code to hand off from loader to an amd64 kernel.
r246335:
Grab the EFI memory map and store it as module metadata on the kernel.
This is the same approach used to provide the BIOS SMAP to the kernel.
r246336:
Pass the ACPI table metadata via hints so the kernel ACPI code can
find them.
r246608:
Rework copy routines to ensure we always use memory allocated via EFI.
The previous code assumed it could copy wherever it liked. This is not
the case. The approach taken by this code is pretty ham-fisted in that
it simply allocates a large (32MB) buffer area and stages into that,
then copies the whole area into place when it's time to execute. A more
elegant solution could be used but this works for now.
r247214:
Fix a number of problems preventing proper handover to the kernel.
There were two issues at play here. Firstly, there was nothing
preventing UEFI from placing the loader code above 1GB in RAM. This
meant that when we switched in the page tables the kernel expects to
be running on, we are suddenly unmapped and things no longer work. We
solve this by making our trampoline code not dependent on being at any
given position and simply copying it to a "safe" location before
calling it.
Secondly, UEFI could allocate our stack wherever it wants. As it
happened on my PC, that was right where I was copying the kernel to.
This did not cause happiness. The solution to this was to also switch
to a temporary stack in a safe location before performing the final
copy of the loaded kernel.
r246231:
Add necessary code to hand off from loader to an amd64 kernel.
r246335:
Grab the EFI memory map and store it as module metadata on the kernel.
This is the same approach used to provide the BIOS SMAP to the kernel.
r246336:
Pass the ACPI table metadata via hints so the kernel ACPI code can
find them.
r246608:
Rework copy routines to ensure we always use memory allocated via EFI.
The previous code assumed it could copy wherever it liked. This is not
the case. The approach taken by this code is pretty ham-fisted in that
it simply allocates a large (32MB) buffer area and stages into that,
then copies the whole area into place when it's time to execute. A more
elegant solution could be used but this works for now.
r247214:
Fix a number of problems preventing proper handover to the kernel.
There were two issues at play here. Firstly, there was nothing
preventing UEFI from placing the loader code above 1GB in RAM. This
meant that when we switched in the page tables the kernel expects to
be running on, we are suddenly unmapped and things no longer work. We
solve this by making our trampoline code not dependent on being at any
given position and simply copying it to a "safe" location before
calling it.
Secondly, UEFI could allocate our stack wherever it wants. As it
happened on my PC, that was right where I was copying the kernel to.
This did not cause happiness. The solution to this was to also switch
to a temporary stack in a safe location before performing the final
copy of the loaded kernel.
r247216:
Use the UEFI Graphics Output Protocol to get the parameters of the
framebuffer.
Sponsored by: The FreeBSD Foundation
2014-04-04 00:16:46 +00:00
|
|
|
}
|
2010-04-07 18:16:05 +00:00
|
|
|
|
|
|
|
|
2015-04-04 04:30:37 +00:00
|
|
|
COMMAND_SET(mode, "mode", "change or display EFI text modes", command_mode);
|
2010-04-07 18:16:05 +00:00
|
|
|
|
|
|
|
static int
|
|
|
|
command_mode(int argc, char *argv[])
|
|
|
|
{
|
2014-03-31 14:12:27 +00:00
|
|
|
UINTN cols, rows;
|
|
|
|
unsigned int mode;
|
2010-04-07 18:16:05 +00:00
|
|
|
int i;
|
|
|
|
char *cp;
|
|
|
|
char rowenv[8];
|
|
|
|
EFI_STATUS status;
|
|
|
|
SIMPLE_TEXT_OUTPUT_INTERFACE *conout;
|
2016-01-06 15:38:39 +00:00
|
|
|
extern void HO(void);
|
2010-04-07 18:16:05 +00:00
|
|
|
|
|
|
|
conout = ST->ConOut;
|
|
|
|
|
|
|
|
if (argc > 1) {
|
|
|
|
mode = strtol(argv[1], &cp, 0);
|
|
|
|
if (cp[0] != '\0') {
|
|
|
|
printf("Invalid mode\n");
|
|
|
|
return (CMD_ERROR);
|
|
|
|
}
|
|
|
|
status = conout->QueryMode(conout, mode, &cols, &rows);
|
|
|
|
if (EFI_ERROR(status)) {
|
|
|
|
printf("invalid mode %d\n", mode);
|
|
|
|
return (CMD_ERROR);
|
|
|
|
}
|
|
|
|
status = conout->SetMode(conout, mode);
|
|
|
|
if (EFI_ERROR(status)) {
|
|
|
|
printf("couldn't set mode %d\n", mode);
|
|
|
|
return (CMD_ERROR);
|
|
|
|
}
|
2014-04-04 13:35:36 +00:00
|
|
|
sprintf(rowenv, "%u", (unsigned)rows);
|
2010-04-07 18:16:05 +00:00
|
|
|
setenv("LINES", rowenv, 1);
|
2016-01-06 15:38:39 +00:00
|
|
|
HO(); /* set cursor */
|
2010-04-07 18:16:05 +00:00
|
|
|
return (CMD_OK);
|
|
|
|
}
|
|
|
|
|
2016-01-04 17:22:06 +00:00
|
|
|
printf("Current mode: %d\n", conout->Mode->Mode);
|
|
|
|
for (i = 0; i <= conout->Mode->MaxMode; i++) {
|
2010-04-07 18:16:05 +00:00
|
|
|
status = conout->QueryMode(conout, i, &cols, &rows);
|
|
|
|
if (EFI_ERROR(status))
|
2016-01-04 17:22:06 +00:00
|
|
|
continue;
|
2014-04-04 13:35:36 +00:00
|
|
|
printf("Mode %d: %u columns, %u rows\n", i, (unsigned)cols,
|
|
|
|
(unsigned)rows);
|
2010-04-07 18:16:05 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (i != 0)
|
2015-04-04 04:30:37 +00:00
|
|
|
printf("Select a mode with the command \"mode <number>\"\n");
|
2010-04-07 18:16:05 +00:00
|
|
|
|
|
|
|
return (CMD_OK);
|
|
|
|
}
|
|
|
|
|
2019-01-03 20:27:50 +00:00
|
|
|
COMMAND_SET(lsefi, "lsefi", "list EFI handles", command_lsefi);
|
|
|
|
|
|
|
|
static int
|
|
|
|
command_lsefi(int argc __unused, char *argv[] __unused)
|
|
|
|
{
|
|
|
|
char *name;
|
|
|
|
EFI_HANDLE *buffer = NULL;
|
|
|
|
EFI_HANDLE handle;
|
|
|
|
UINTN bufsz = 0, i, j;
|
|
|
|
EFI_STATUS status;
|
2019-04-07 14:07:28 +00:00
|
|
|
int ret = 0;
|
2019-01-03 20:27:50 +00:00
|
|
|
|
|
|
|
status = BS->LocateHandle(AllHandles, NULL, NULL, &bufsz, buffer);
|
|
|
|
if (status != EFI_BUFFER_TOO_SMALL) {
|
|
|
|
snprintf(command_errbuf, sizeof (command_errbuf),
|
|
|
|
"unexpected error: %lld", (long long)status);
|
|
|
|
return (CMD_ERROR);
|
|
|
|
}
|
|
|
|
if ((buffer = malloc(bufsz)) == NULL) {
|
|
|
|
sprintf(command_errbuf, "out of memory");
|
|
|
|
return (CMD_ERROR);
|
|
|
|
}
|
|
|
|
|
|
|
|
status = BS->LocateHandle(AllHandles, NULL, NULL, &bufsz, buffer);
|
|
|
|
if (EFI_ERROR(status)) {
|
|
|
|
free(buffer);
|
|
|
|
snprintf(command_errbuf, sizeof (command_errbuf),
|
|
|
|
"LocateHandle() error: %lld", (long long)status);
|
|
|
|
return (CMD_ERROR);
|
|
|
|
}
|
|
|
|
|
|
|
|
pager_open();
|
|
|
|
for (i = 0; i < (bufsz / sizeof (EFI_HANDLE)); i++) {
|
|
|
|
UINTN nproto = 0;
|
|
|
|
EFI_GUID **protocols = NULL;
|
|
|
|
|
|
|
|
handle = buffer[i];
|
|
|
|
printf("Handle %p", handle);
|
|
|
|
if (pager_output("\n"))
|
|
|
|
break;
|
|
|
|
/* device path */
|
|
|
|
|
|
|
|
status = BS->ProtocolsPerHandle(handle, &protocols, &nproto);
|
|
|
|
if (EFI_ERROR(status)) {
|
|
|
|
snprintf(command_errbuf, sizeof (command_errbuf),
|
|
|
|
"ProtocolsPerHandle() error: %lld",
|
|
|
|
(long long)status);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (j = 0; j < nproto; j++) {
|
|
|
|
if (efi_guid_to_name(protocols[j], &name) == true) {
|
|
|
|
printf(" %s", name);
|
|
|
|
free(name);
|
|
|
|
} else {
|
|
|
|
printf("Error while translating UUID to name");
|
|
|
|
}
|
|
|
|
if ((ret = pager_output("\n")) != 0)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
BS->FreePool(protocols);
|
|
|
|
if (ret != 0)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
pager_close();
|
|
|
|
free(buffer);
|
|
|
|
return (CMD_OK);
|
|
|
|
}
|
|
|
|
|
2015-04-05 18:37:39 +00:00
|
|
|
#ifdef LOADER_FDT_SUPPORT
|
|
|
|
extern int command_fdt_internal(int argc, char *argv[]);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Since proper fdt command handling function is defined in fdt_loader_cmd.c,
|
|
|
|
* and declaring it as extern is in contradiction with COMMAND_SET() macro
|
|
|
|
* (which uses static pointer), we're defining wrapper function, which
|
|
|
|
* calls the proper fdt handling routine.
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
command_fdt(int argc, char *argv[])
|
|
|
|
{
|
|
|
|
|
|
|
|
return (command_fdt_internal(argc, argv));
|
|
|
|
}
|
|
|
|
|
|
|
|
COMMAND_SET(fdt, "fdt", "flattened device tree handling", command_fdt);
|
|
|
|
#endif
|
2016-01-15 02:33:47 +00:00
|
|
|
|
2017-06-16 20:08:44 +00:00
|
|
|
/*
|
|
|
|
* Chain load another efi loader.
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
command_chain(int argc, char *argv[])
|
|
|
|
{
|
|
|
|
EFI_GUID LoadedImageGUID = LOADED_IMAGE_PROTOCOL;
|
|
|
|
EFI_HANDLE loaderhandle;
|
|
|
|
EFI_LOADED_IMAGE *loaded_image;
|
|
|
|
EFI_STATUS status;
|
|
|
|
struct stat st;
|
|
|
|
struct devdesc *dev;
|
|
|
|
char *name, *path;
|
|
|
|
void *buf;
|
|
|
|
int fd;
|
|
|
|
|
|
|
|
if (argc < 2) {
|
|
|
|
command_errmsg = "wrong number of arguments";
|
|
|
|
return (CMD_ERROR);
|
|
|
|
}
|
|
|
|
|
|
|
|
name = argv[1];
|
|
|
|
|
|
|
|
if ((fd = open(name, O_RDONLY)) < 0) {
|
|
|
|
command_errmsg = "no such file";
|
|
|
|
return (CMD_ERROR);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (fstat(fd, &st) < -1) {
|
|
|
|
command_errmsg = "stat failed";
|
|
|
|
close(fd);
|
|
|
|
return (CMD_ERROR);
|
|
|
|
}
|
|
|
|
|
|
|
|
status = BS->AllocatePool(EfiLoaderCode, (UINTN)st.st_size, &buf);
|
|
|
|
if (status != EFI_SUCCESS) {
|
|
|
|
command_errmsg = "failed to allocate buffer";
|
|
|
|
close(fd);
|
|
|
|
return (CMD_ERROR);
|
|
|
|
}
|
|
|
|
if (read(fd, buf, st.st_size) != st.st_size) {
|
|
|
|
command_errmsg = "error while reading the file";
|
|
|
|
(void)BS->FreePool(buf);
|
|
|
|
close(fd);
|
|
|
|
return (CMD_ERROR);
|
|
|
|
}
|
|
|
|
close(fd);
|
|
|
|
status = BS->LoadImage(FALSE, IH, NULL, buf, st.st_size, &loaderhandle);
|
|
|
|
(void)BS->FreePool(buf);
|
|
|
|
if (status != EFI_SUCCESS) {
|
|
|
|
command_errmsg = "LoadImage failed";
|
|
|
|
return (CMD_ERROR);
|
|
|
|
}
|
|
|
|
status = BS->HandleProtocol(loaderhandle, &LoadedImageGUID,
|
|
|
|
(void **)&loaded_image);
|
|
|
|
|
|
|
|
if (argc > 2) {
|
|
|
|
int i, len = 0;
|
|
|
|
CHAR16 *argp;
|
|
|
|
|
|
|
|
for (i = 2; i < argc; i++)
|
|
|
|
len += strlen(argv[i]) + 1;
|
|
|
|
|
|
|
|
len *= sizeof (*argp);
|
|
|
|
loaded_image->LoadOptions = argp = malloc (len);
|
|
|
|
loaded_image->LoadOptionsSize = len;
|
|
|
|
for (i = 2; i < argc; i++) {
|
|
|
|
char *ptr = argv[i];
|
|
|
|
while (*ptr)
|
|
|
|
*(argp++) = *(ptr++);
|
|
|
|
*(argp++) = ' ';
|
|
|
|
}
|
|
|
|
*(--argv) = 0;
|
|
|
|
}
|
|
|
|
|
2017-09-10 13:53:42 +00:00
|
|
|
if (efi_getdev((void **)&dev, name, (const char **)&path) == 0) {
|
2017-09-11 07:38:53 +00:00
|
|
|
#ifdef EFI_ZFS_BOOT
|
2017-09-10 13:53:42 +00:00
|
|
|
struct zfs_devdesc *z_dev;
|
2017-09-11 07:38:53 +00:00
|
|
|
#endif
|
2017-09-10 13:53:42 +00:00
|
|
|
struct disk_devdesc *d_dev;
|
|
|
|
pdinfo_t *hd, *pd;
|
|
|
|
|
2018-03-12 21:39:59 +00:00
|
|
|
switch (dev->d_dev->dv_type) {
|
2017-09-11 07:38:53 +00:00
|
|
|
#ifdef EFI_ZFS_BOOT
|
2017-09-10 13:53:42 +00:00
|
|
|
case DEVT_ZFS:
|
|
|
|
z_dev = (struct zfs_devdesc *)dev;
|
|
|
|
loaded_image->DeviceHandle =
|
|
|
|
efizfs_get_handle_by_guid(z_dev->pool_guid);
|
|
|
|
break;
|
2017-09-11 07:38:53 +00:00
|
|
|
#endif
|
2017-09-10 13:53:42 +00:00
|
|
|
case DEVT_NET:
|
|
|
|
loaded_image->DeviceHandle =
|
|
|
|
efi_find_handle(dev->d_dev, dev->d_unit);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
hd = efiblk_get_pdinfo(dev);
|
|
|
|
if (STAILQ_EMPTY(&hd->pd_part)) {
|
|
|
|
loaded_image->DeviceHandle = hd->pd_handle;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
d_dev = (struct disk_devdesc *)dev;
|
|
|
|
STAILQ_FOREACH(pd, &hd->pd_part, pd_link) {
|
|
|
|
/*
|
|
|
|
* d_partition should be 255
|
|
|
|
*/
|
2017-09-22 07:29:26 +00:00
|
|
|
if (pd->pd_unit == (uint32_t)d_dev->d_slice) {
|
2017-09-10 13:53:42 +00:00
|
|
|
loaded_image->DeviceHandle =
|
|
|
|
pd->pd_handle;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
2017-06-16 20:08:44 +00:00
|
|
|
|
|
|
|
dev_cleanup();
|
|
|
|
status = BS->StartImage(loaderhandle, NULL, NULL);
|
|
|
|
if (status != EFI_SUCCESS) {
|
|
|
|
command_errmsg = "StartImage failed";
|
|
|
|
free(loaded_image->LoadOptions);
|
|
|
|
loaded_image->LoadOptions = NULL;
|
|
|
|
status = BS->UnloadImage(loaded_image);
|
|
|
|
return (CMD_ERROR);
|
|
|
|
}
|
|
|
|
|
|
|
|
return (CMD_ERROR); /* not reached */
|
|
|
|
}
|
|
|
|
|
|
|
|
COMMAND_SET(chain, "chain", "chain load file", command_chain);
|