freebsd-dev/sys/boot/efi/loader/main.c

1111 lines
27 KiB
C
Raw Normal View History

/*-
* Copyright (c) 2008-2010 Rui Paulo
* Copyright (c) 2006 Marcel Moolenaar
* All rights reserved.
*
* 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$");
#include <sys/param.h>
#include <sys/reboot.h>
#include <sys/boot.h>
#include <inttypes.h>
#include <stand.h>
#include <string.h>
#include <setjmp.h>
#include <efi.h>
#include <efilib.h>
#include <uuid.h>
#include <bootstrap.h>
#include <smbios.h>
#ifdef EFI_ZFS_BOOT
#include <libzfs.h>
#endif
#include "loader_efi.h"
extern char bootprog_info[];
#ifdef BOOT_FORTH
2016-10-25 14:42:09 +00:00
/*
* Normally, efi.o from libefi.a would be brought in due to a function we call
* there that's defined there. However, none of its functions are callable from
* here since it just adds words to the FORTH environment or implement those
* words. So, add a reference to a symbol in efi.o to force it to be be brought
* in so the init function there gets added to the "compile" linker set happens
* correctly.
*
* This assumes there's no global analysys that notices dummy1 isn't used
* anywhere and tries to eliminate it.
*/
extern int efi_variable_support;
int *dummy1 = &efi_variable_support;
#endif
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;
EFI_GUID dxe = DXE_SERVICES_TABLE_GUID;
EFI_GUID hoblist = HOB_LIST_TABLE_GUID;
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;
EFI_GUID inputid = SIMPLE_TEXT_INPUT_PROTOCOL;
#ifdef EFI_ZFS_BOOT
static void efi_zfs_probe(void);
#endif
2016-05-20 19:37:54 +00:00
/*
* cpy8to16 copies a traditional C string into a CHAR16 string and
* 0 terminates it. len is the size of *dst in bytes.
*/
static void
cpy8to16(const char *src, CHAR16 *dst, size_t len)
{
len <<= 1; /* Assume CHAR16 is 2 bytes */
while (len > 0 && *src) {
*dst++ = *src++;
len--;
}
*dst++ = (CHAR16)0;
}
static void
2016-05-20 19:37:54 +00:00
cpy16to8(const CHAR16 *src, char *dst, size_t len)
{
size_t i;
for (i = 0; i < len && src[i]; i++)
dst[i] = (char)src[i];
2016-05-20 19:37:46 +00:00
if (i < len)
dst[i] = '\0';
}
static int
has_keyboard(void)
{
EFI_STATUS status;
EFI_DEVICE_PATH *path;
EFI_HANDLE *hin, *hin_end, *walker;
UINTN sz;
int retval = 0;
/*
* 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) {
retval = 1;
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;
usb = (USB_CLASS_DEVICE_PATH *)(void *)path;
if (usb->DeviceClass == 3 && /* HID */
usb->DeviceSubClass == 1 && /* Boot devices */
usb->DeviceProtocol == 1) { /* Boot keyboards */
retval = 1;
goto out;
}
}
path = NextDevicePathNode(path);
}
}
out:
free(hin);
return retval;
}
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
find_currdev(EFI_LOADED_IMAGE *img, struct devsw **dev, int *unit,
uint64_t *extra)
{
EFI_DEVICE_PATH *devpath, *copy;
EFI_HANDLE h;
/*
* 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
* handles.
*/
if (efi_handle_lookup(img->DeviceHandle, dev, unit, extra) == 0)
return (0);
copy = NULL;
devpath = efi_lookup_image_devpath(IH);
while (devpath != NULL) {
h = efi_devpath_handle(devpath);
if (h == NULL)
break;
if (efi_handle_lookup(h, dev, unit, extra) == 0) {
if (copy != NULL)
free(copy);
return (0);
}
if (copy != NULL)
free(copy);
devpath = efi_lookup_devpath(h);
if (devpath != NULL) {
copy = efi_devpath_trim(devpath);
devpath = copy;
}
}
/* Try to fallback on first device */
if (devsw[0] != NULL) {
*dev = devsw[0];
return (0);
}
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);
}
EFI_STATUS
main(int argc, CHAR16 *argv[])
{
char var[128];
EFI_LOADED_IMAGE *img;
EFI_GUID *guid;
int i, j, vargood, unit, howto;
struct devsw *dev;
uint64_t pool_guid;
UINTN k;
int has_kbd;
In UEFI mode expose the SMBIOS anchor base address via kenv so the kernel etc. can find out where the SMBIOS entry point is located. In pure UEFI mode the BIOS is not mapped into the standard address space so the SMBIOS table might not appear between 0xf0000 and 0xfffff. The UEFI environment can report this the location of the anchor. If it is reported then expose it as hint.smbios.0.mem. This can then be used by other tools. However, we should make smbios(4) useful and have it take this value and provide accesor function so ipmi(4) etc. don't have to parse and figure things about the SMBIOS table. I have some simple patches to smbios(4) to expose this address as sysctl and for ipmi(4) to get the base address. However, the real fix is to have ipmi(4) ask smbios(4) for what it wants and have smbios(4) parse it out and return it. This would make smbios(4) useful and reduce duplicated code. If this address doesn't point to the anchor then finding SMBIOS info. will fail as if this didn't exist. So there should be no harm. With this change and the following hack, dmidecode works on a bunch of UEFI machines that I tested: if kenv hint.smbios.0.mem > /dev/null then mkdir -p /sys/firmware/efi mount -t tmpfs -o size=8k tmpfs /sys/firmware/efi echo "SMBIOS=`kenv hint.smbios.0.mem`" > /sys/firmware/efi/systab fi Linux exposes this information via the /sys/firmware/efi/systab file which dmidecode looks at. We should update dmidecode to do this the FreeBSD way when we determine what that is! Reviewed by: jhb
2016-10-14 17:10:53 +00:00
char buf[40];
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;
#ifdef EFI_ZFS_BOOT
/* Note this needs to be set before ZFS init. */
archsw.arch_zfs_probe = efi_zfs_probe;
#endif
/* Init the time source */
efi_time_init();
has_kbd = has_keyboard();
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
/*
* XXX 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.
*/
cons_probe();
/*
* Initialise the block cache. Set the upper limit.
*/
bcache_init(32768, 512);
/*
* Parse the args to set the console settings, etc
* boot1.efi passes these in, if it can read /boot.config or /boot/config
* or iPXE may be setup to pass these in.
*
* 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
* args from UCS-2 to ASCII (16 to 8 bit) as they are copied.
*/
howto = 0;
for (i = 1; i < argc; i++) {
if (argv[i][0] == '-') {
for (j = 1; argv[i][j] != 0; j++) {
int ch;
ch = argv[i][j];
switch (ch) {
case 'a':
howto |= RB_ASKNAME;
break;
case 'd':
howto |= RB_KDB;
break;
case 'D':
howto |= RB_MULTIPLE;
break;
case 'h':
howto |= RB_SERIAL;
break;
case 'm':
howto |= RB_MUTE;
break;
case 'p':
howto |= RB_PAUSE;
break;
case 'P':
if (!has_kbd)
howto |= RB_SERIAL | RB_MULTIPLE;
break;
case 'r':
howto |= RB_DFLTROOT;
break;
case 's':
howto |= RB_SINGLE;
break;
case 'S':
if (argv[i][j + 1] == 0) {
if (i + 1 == argc) {
setenv("comconsole_speed", "115200", 1);
} else {
2016-05-20 19:37:54 +00:00
cpy16to8(&argv[i + 1][0], var,
sizeof(var));
setenv("comconsole_speedspeed", var, 1);
}
i++;
break;
} else {
2016-05-20 19:37:54 +00:00
cpy16to8(&argv[i][j + 1], var,
sizeof(var));
setenv("comconsole_speed", var, 1);
break;
}
case 'v':
howto |= RB_VERBOSE;
break;
}
}
} else {
vargood = 0;
for (j = 0; argv[i][j] != 0; j++) {
if (j == sizeof(var)) {
vargood = 0;
break;
}
if (j > 0 && argv[i][j] == '=')
vargood = 1;
var[j] = (char)argv[i][j];
}
if (vargood) {
var[j] = 0;
putenv(var);
}
}
}
for (i = 0; howto_names[i].ev != NULL; i++)
if (howto & howto_names[i].mask)
setenv(howto_names[i].ev, "YES", 1);
if (howto & RB_MULTIPLE) {
if (howto & RB_SERIAL)
setenv("console", "comconsole efi" , 1);
else
setenv("console", "efi comconsole" , 1);
} else if (howto & RB_SERIAL) {
setenv("console", "comconsole" , 1);
}
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);
}
/*
* March through the device switch probing for things.
*/
for (i = 0; devsw[i] != NULL; i++)
if (devsw[i]->dv_init != NULL)
(devsw[i]->dv_init)();
/* Get our loaded image protocol interface structure. */
BS->HandleProtocol(IH, &imgid, (VOID**)&img);
printf("Command line arguments:");
2016-05-20 19:37:46 +00:00
for (i = 0; i < argc; i++)
printf(" %S", argv[i]);
printf("\n");
printf("Image base: 0x%lx\n", (u_long)img->ImageBase);
printf("EFI version: %d.%02d\n", ST->Hdr.Revision >> 16,
ST->Hdr.Revision & 0xffff);
printf("EFI Firmware: %S (rev %d.%02d)\n", ST->FirmwareVendor,
ST->FirmwareRevision >> 16, ST->FirmwareRevision & 0xffff);
printf("\n%s", bootprog_info);
/*
* 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);
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
if (find_currdev(img, &dev, &unit, &pool_guid) != 0)
return (EFI_NOT_FOUND);
switch (dev->dv_type) {
#ifdef EFI_ZFS_BOOT
case DEVT_ZFS: {
struct zfs_devdesc currdev;
currdev.d_dev = dev;
currdev.d_unit = unit;
currdev.d_type = currdev.d_dev->dv_type;
currdev.d_opendata = NULL;
currdev.pool_guid = pool_guid;
currdev.root_guid = 0;
env_setenv("currdev", EV_VOLATILE, efi_fmtdev(&currdev),
efi_setcurrdev, env_nounset);
env_setenv("loaddev", EV_VOLATILE, efi_fmtdev(&currdev), env_noset,
env_nounset);
init_zfs_bootenv(zfs_fmtdev(&currdev));
break;
}
#endif
default: {
struct devdesc currdev;
currdev.d_dev = dev;
currdev.d_unit = unit;
currdev.d_opendata = NULL;
currdev.d_type = currdev.d_dev->dv_type;
env_setenv("currdev", EV_VOLATILE, efi_fmtdev(&currdev),
efi_setcurrdev, env_nounset);
env_setenv("loaddev", EV_VOLATILE, efi_fmtdev(&currdev), env_noset,
env_nounset);
break;
}
}
snprintf(var, sizeof(var), "%d.%02d", ST->Hdr.Revision >> 16,
ST->Hdr.Revision & 0xffff);
env_setenv("efi-version", EV_VOLATILE, var, env_noset, env_nounset);
setenv("LINES", "24", 1); /* optional */
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
for (k = 0; k < ST->NumberOfTableEntries; k++) {
guid = &ST->ConfigurationTable[k].VendorGuid;
if (!memcmp(guid, &smbios, sizeof(EFI_GUID))) {
In UEFI mode expose the SMBIOS anchor base address via kenv so the kernel etc. can find out where the SMBIOS entry point is located. In pure UEFI mode the BIOS is not mapped into the standard address space so the SMBIOS table might not appear between 0xf0000 and 0xfffff. The UEFI environment can report this the location of the anchor. If it is reported then expose it as hint.smbios.0.mem. This can then be used by other tools. However, we should make smbios(4) useful and have it take this value and provide accesor function so ipmi(4) etc. don't have to parse and figure things about the SMBIOS table. I have some simple patches to smbios(4) to expose this address as sysctl and for ipmi(4) to get the base address. However, the real fix is to have ipmi(4) ask smbios(4) for what it wants and have smbios(4) parse it out and return it. This would make smbios(4) useful and reduce duplicated code. If this address doesn't point to the anchor then finding SMBIOS info. will fail as if this didn't exist. So there should be no harm. With this change and the following hack, dmidecode works on a bunch of UEFI machines that I tested: if kenv hint.smbios.0.mem > /dev/null then mkdir -p /sys/firmware/efi mount -t tmpfs -o size=8k tmpfs /sys/firmware/efi echo "SMBIOS=`kenv hint.smbios.0.mem`" > /sys/firmware/efi/systab fi Linux exposes this information via the /sys/firmware/efi/systab file which dmidecode looks at. We should update dmidecode to do this the FreeBSD way when we determine what that is! Reviewed by: jhb
2016-10-14 17:10:53 +00:00
snprintf(buf, sizeof(buf), "%p",
ST->ConfigurationTable[k].VendorTable);
setenv("hint.smbios.0.mem", buf, 1);
smbios_detect(ST->ConfigurationTable[k].VendorTable);
break;
}
}
interact(NULL); /* doesn't return */
return (EFI_SUCCESS); /* keep compiler happy */
}
/* XXX move to lib stand ? */
static int
wcscmp(CHAR16 *a, CHAR16 *b)
{
while (*a && *b && *a == *b) {
a++;
b++;
}
return *a - *b;
}
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)();
RS->ResetSystem(EfiResetCold, EFI_SUCCESS, 23,
(CHAR16 *)"Reboot from the loader");
/* 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
command_memmap(int argc, char *argv[])
{
UINTN sz;
EFI_MEMORY_DESCRIPTOR *map, *p;
UINTN key, dsz;
UINT32 dver;
EFI_STATUS status;
int i, ndesc;
char line[80];
static char *types[] = {
"Reserved",
"LoaderCode",
"LoaderData",
"BootServicesCode",
"BootServicesData",
"RuntimeServicesCode",
"RuntimeServicesData",
"ConventionalMemory",
"UnusableMemory",
"ACPIReclaimMemory",
"ACPIMemoryNVS",
"MemoryMappedIO",
"MemoryMappedIOPortSpace",
"PalCode"
};
sz = 0;
status = BS->GetMemoryMap(&sz, 0, &key, &dsz, &dver);
if (status != EFI_BUFFER_TOO_SMALL) {
printf("Can't determine memory map size\n");
return (CMD_ERROR);
}
map = malloc(sz);
status = BS->GetMemoryMap(&sz, map, &key, &dsz, &dver);
if (EFI_ERROR(status)) {
printf("Can't read memory map\n");
return (CMD_ERROR);
}
ndesc = sz / dsz;
snprintf(line, sizeof(line), "%23s %12s %12s %8s %4s\n",
"Type", "Physical", "Virtual", "#Pages", "Attr");
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
for (i = 0, p = map; i < ndesc;
i++, p = NextMemoryDescriptor(p, dsz)) {
printf("%23s %012jx %012jx %08jx ", types[p->Type],
(uintmax_t)p->PhysicalStart, (uintmax_t)p->VirtualStart,
(uintmax_t)p->NumberOfPages);
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 ");
if (pager_output("\n"))
break;
}
pager_close();
return (CMD_OK);
}
COMMAND_SET(configuration, "configuration", "print configuration tables",
command_configuration);
static const char *
guid_to_string(EFI_GUID *guid)
{
static char buf[40];
sprintf(buf, "%08x-%04x-%04x-%02x%02x-%02x%02x%02x%02x%02x%02x",
guid->Data1, guid->Data2, guid->Data3, guid->Data4[0],
guid->Data4[1], guid->Data4[2], guid->Data4[3], guid->Data4[4],
guid->Data4[5], guid->Data4[6], guid->Data4[7]);
return (buf);
}
static int
command_configuration(int argc, char *argv[])
{
char line[80];
UINTN i;
snprintf(line, sizeof(line), "NumberOfTableEntries=%lu\n",
(unsigned long)ST->NumberOfTableEntries);
pager_open();
if (pager_output(line)) {
pager_close();
return (CMD_OK);
}
for (i = 0; i < ST->NumberOfTableEntries; i++) {
EFI_GUID *guid;
printf(" ");
guid = &ST->ConfigurationTable[i].VendorGuid;
if (!memcmp(guid, &mps, sizeof(EFI_GUID)))
printf("MPS Table");
else if (!memcmp(guid, &acpi, sizeof(EFI_GUID)))
printf("ACPI Table");
else if (!memcmp(guid, &acpi20, sizeof(EFI_GUID)))
printf("ACPI 2.0 Table");
else if (!memcmp(guid, &smbios, sizeof(EFI_GUID)))
In UEFI mode expose the SMBIOS anchor base address via kenv so the kernel etc. can find out where the SMBIOS entry point is located. In pure UEFI mode the BIOS is not mapped into the standard address space so the SMBIOS table might not appear between 0xf0000 and 0xfffff. The UEFI environment can report this the location of the anchor. If it is reported then expose it as hint.smbios.0.mem. This can then be used by other tools. However, we should make smbios(4) useful and have it take this value and provide accesor function so ipmi(4) etc. don't have to parse and figure things about the SMBIOS table. I have some simple patches to smbios(4) to expose this address as sysctl and for ipmi(4) to get the base address. However, the real fix is to have ipmi(4) ask smbios(4) for what it wants and have smbios(4) parse it out and return it. This would make smbios(4) useful and reduce duplicated code. If this address doesn't point to the anchor then finding SMBIOS info. will fail as if this didn't exist. So there should be no harm. With this change and the following hack, dmidecode works on a bunch of UEFI machines that I tested: if kenv hint.smbios.0.mem > /dev/null then mkdir -p /sys/firmware/efi mount -t tmpfs -o size=8k tmpfs /sys/firmware/efi echo "SMBIOS=`kenv hint.smbios.0.mem`" > /sys/firmware/efi/systab fi Linux exposes this information via the /sys/firmware/efi/systab file which dmidecode looks at. We should update dmidecode to do this the FreeBSD way when we determine what that is! Reviewed by: jhb
2016-10-14 17:10:53 +00:00
printf("SMBIOS Table %p",
ST->ConfigurationTable[i].VendorTable);
else if (!memcmp(guid, &dxe, sizeof(EFI_GUID)))
printf("DXE Table");
else if (!memcmp(guid, &hoblist, sizeof(EFI_GUID)))
printf("HOB List Table");
else if (!memcmp(guid, &memtype, sizeof(EFI_GUID)))
printf("Memory Type Information Table");
else if (!memcmp(guid, &debugimg, sizeof(EFI_GUID)))
printf("Debug Image Info Table");
2015-05-05 11:07:43 +00:00
else if (!memcmp(guid, &fdtdtb, sizeof(EFI_GUID)))
printf("FDT Table");
else
printf("Unknown Table (%s)", guid_to_string(guid));
snprintf(line, sizeof(line), " at %p\n",
ST->ConfigurationTable[i].VendorTable);
if (pager_output(line))
break;
}
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
}
COMMAND_SET(mode, "mode", "change or display EFI text modes", command_mode);
static int
command_mode(int argc, char *argv[])
{
UINTN cols, rows;
unsigned int mode;
int i;
char *cp;
char rowenv[8];
EFI_STATUS status;
SIMPLE_TEXT_OUTPUT_INTERFACE *conout;
extern void HO(void);
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);
}
sprintf(rowenv, "%u", (unsigned)rows);
setenv("LINES", rowenv, 1);
HO(); /* set cursor */
return (CMD_OK);
}
printf("Current mode: %d\n", conout->Mode->Mode);
for (i = 0; i <= conout->Mode->MaxMode; i++) {
status = conout->QueryMode(conout, i, &cols, &rows);
if (EFI_ERROR(status))
continue;
printf("Mode %d: %u columns, %u rows\n", i, (unsigned)cols,
(unsigned)rows);
}
if (i != 0)
printf("Select a mode with the command \"mode <number>\"\n");
return (CMD_OK);
}
#ifdef EFI_ZFS_BOOT
COMMAND_SET(lszfs, "lszfs", "list child datasets of a zfs dataset",
command_lszfs);
static int
command_lszfs(int argc, char *argv[])
{
int err;
if (argc != 2) {
command_errmsg = "wrong number of arguments";
return (CMD_ERROR);
}
err = zfs_list(argv[1]);
if (err != 0) {
command_errmsg = strerror(err);
return (CMD_ERROR);
}
return (CMD_OK);
}
COMMAND_SET(reloadbe, "reloadbe", "refresh the list of ZFS Boot Environments",
command_reloadbe);
static int
command_reloadbe(int argc, char *argv[])
{
int err;
char *root;
if (argc > 2) {
command_errmsg = "wrong number of arguments";
return (CMD_ERROR);
}
if (argc == 2) {
err = zfs_bootenv(argv[1]);
} else {
root = getenv("zfs_be_root");
if (root == NULL) {
return (CMD_OK);
}
err = zfs_bootenv(root);
}
if (err != 0) {
command_errmsg = strerror(err);
return (CMD_ERROR);
}
return (CMD_OK);
}
#endif
COMMAND_SET(efishow, "efi-show", "print some or all EFI variables", command_efi_show);
static int
efi_print_var(CHAR16 *varnamearg, EFI_GUID *matchguid, int lflag)
{
UINTN datasz, i;
EFI_STATUS status;
UINT32 attr;
CHAR16 *data;
char *str;
uint32_t uuid_status;
int is_ascii;
datasz = 0;
status = RS->GetVariable(varnamearg, matchguid, &attr,
&datasz, NULL);
if (status != EFI_BUFFER_TOO_SMALL) {
printf("Can't get the variable: error %#lx\n", status);
return (CMD_ERROR);
}
data = malloc(datasz);
status = RS->GetVariable(varnamearg, matchguid, &attr,
&datasz, data);
if (status != EFI_SUCCESS) {
printf("Can't get the variable: error %#lx\n", status);
return (CMD_ERROR);
}
uuid_to_string((uuid_t *)matchguid, &str, &uuid_status);
if (lflag) {
printf("%s 0x%x %S", str, attr, varnamearg);
} else {
printf("%s 0x%x %S=", str, attr, varnamearg);
is_ascii = 1;
free(str);
str = (char *)data;
for (i = 0; i < datasz - 1; i++) {
/* Quick hack to see if this ascii-ish string printable range plus tab, cr and lf */
if ((str[i] < 32 || str[i] > 126) && str[i] != 9 && str[i] != 10 && str[i] != 13) {
is_ascii = 0;
break;
}
}
if (str[datasz - 1] != '\0')
is_ascii = 0;
if (is_ascii)
printf("%s", str);
else {
for (i = 0; i < datasz / 2; i++) {
if (isalnum(data[i]) || isspace(data[i]))
printf("%c", data[i]);
else
printf("\\x%02x", data[i]);
}
}
}
free(data);
if (pager_output("\n"))
return (CMD_WARN);
return (CMD_OK);
}
static int
command_efi_show(int argc, char *argv[])
{
/*
* efi-show [-a]
* print all the env
* efi-show -u UUID
* print all the env vars tagged with UUID
* efi-show -v var
* search all the env vars and print the ones matching var
* eif-show -u UUID -v var
* eif-show UUID var
* print all the env vars that match UUID and var
*/
/* NB: We assume EFI_GUID is the same as uuid_t */
int aflag = 0, gflag = 0, lflag = 0, vflag = 0;
int ch, rv;
unsigned i;
EFI_STATUS status;
EFI_GUID varguid = { 0,0,0,{0,0,0,0,0,0,0,0} };
EFI_GUID matchguid = { 0,0,0,{0,0,0,0,0,0,0,0} };
uint32_t uuid_status;
CHAR16 *varname;
CHAR16 *newnm;
CHAR16 varnamearg[128];
UINTN varalloc;
UINTN varsz;
while ((ch = getopt(argc, argv, "ag:lv:")) != -1) {
switch (ch) {
case 'a':
aflag = 1;
break;
case 'g':
gflag = 1;
uuid_from_string(optarg, (uuid_t *)&matchguid,
&uuid_status);
if (uuid_status != uuid_s_ok) {
printf("uid %s could not be parsed\n", optarg);
return (CMD_ERROR);
}
break;
case 'l':
lflag = 1;
break;
case 'v':
vflag = 1;
if (strlen(optarg) >= nitems(varnamearg)) {
printf("Variable %s is longer than %zd characters\n",
optarg, nitems(varnamearg));
return (CMD_ERROR);
}
for (i = 0; i < strlen(optarg); i++)
varnamearg[i] = optarg[i];
varnamearg[i] = 0;
break;
default:
printf("Invalid argument %c\n", ch);
return (CMD_ERROR);
}
}
if (aflag && (gflag || vflag)) {
printf("-a isn't compatible with -v or -u\n");
return (CMD_ERROR);
}
if (aflag && optind < argc) {
printf("-a doesn't take any args");
return (CMD_ERROR);
}
if (optind == argc)
aflag = 1;
argc -= optind;
argv += optind;
pager_open();
if (vflag && gflag) {
rv = efi_print_var(varnamearg, &matchguid, lflag);
pager_close();
return (rv);
}
if (argc == 2) {
optarg = argv[0];
if (strlen(optarg) >= nitems(varnamearg)) {
printf("Variable %s is longer than %zd characters\n",
optarg, nitems(varnamearg));
pager_close();
return (CMD_ERROR);
}
for (i = 0; i < strlen(optarg); i++)
varnamearg[i] = optarg[i];
varnamearg[i] = 0;
optarg = argv[1];
uuid_from_string(optarg, (uuid_t *)&matchguid,
&uuid_status);
if (uuid_status != uuid_s_ok) {
printf("uid %s could not be parsed\n", optarg);
pager_close();
return (CMD_ERROR);
}
rv = efi_print_var(varnamearg, &matchguid, lflag);
pager_close();
return (rv);
}
if (argc > 0) {
printf("Too many args %d\n", argc);
pager_close();
return (CMD_ERROR);
}
/*
* Initiate the search -- note the standard takes pain
* to specify the initial call must be a poiner to a NULL
* character.
*/
varalloc = 1024;
varname = malloc(varalloc);
if (varname == NULL) {
printf("Can't allocate memory to get variables\n");
pager_close();
return (CMD_ERROR);
}
varname[0] = 0;
while (1) {
varsz = varalloc;
status = RS->GetNextVariableName(&varsz, varname, &varguid);
if (status == EFI_BUFFER_TOO_SMALL) {
varalloc = varsz;
newnm = malloc(varalloc);
if (newnm == NULL) {
printf("Can't allocate memory to get variables\n");
free(varname);
pager_close();
return (CMD_ERROR);
}
memcpy(newnm, varname, varsz);
free(varname);
varname = newnm;
continue; /* Try again with bigger buffer */
}
if (status != EFI_SUCCESS)
break;
if (aflag) {
if (efi_print_var(varname, &varguid, lflag) != CMD_OK)
break;
continue;
}
if (vflag) {
if (wcscmp(varnamearg, varname) == 0) {
if (efi_print_var(varname, &varguid, lflag) != CMD_OK)
break;
continue;
}
}
if (gflag) {
if (memcmp(&varguid, &matchguid, sizeof(varguid)) == 0) {
if (efi_print_var(varname, &varguid, lflag) != CMD_OK)
break;
continue;
}
}
}
free(varname);
pager_close();
return (CMD_OK);
}
COMMAND_SET(efiset, "efi-set", "set EFI variables", command_efi_set);
static int
command_efi_set(int argc, char *argv[])
{
2016-05-20 19:37:54 +00:00
char *uuid, *var, *val;
CHAR16 wvar[128];
EFI_GUID guid;
uint32_t status;
EFI_STATUS err;
if (argc != 4) {
printf("efi-set uuid var new-value\n");
return (CMD_ERROR);
}
uuid = argv[1];
var = argv[2];
val = argv[3];
uuid_from_string(uuid, (uuid_t *)&guid, &status);
if (status != uuid_s_ok) {
printf("Invalid uuid %s %d\n", uuid, status);
2016-05-20 19:37:54 +00:00
return (CMD_ERROR);
}
cpy8to16(var, wvar, sizeof(wvar));
err = RS->SetVariable(wvar, &guid,
EFI_VARIABLE_NON_VOLATILE | EFI_VARIABLE_RUNTIME_ACCESS | EFI_VARIABLE_BOOTSERVICE_ACCESS,
2016-05-20 19:37:54 +00:00
strlen(val) + 1, val);
if (EFI_ERROR(err)) {
printf("Failed to set variable: error %lu\n", EFI_ERROR_CODE(err));
2016-05-20 19:37:54 +00:00
return (CMD_ERROR);
}
return (CMD_OK);
}
COMMAND_SET(efiunset, "efi-unset", "delete / unset EFI variables", command_efi_unset);
static int
command_efi_unset(int argc, char *argv[])
{
2016-05-20 19:37:54 +00:00
char *uuid, *var;
CHAR16 wvar[128];
EFI_GUID guid;
uint32_t status;
EFI_STATUS err;
if (argc != 3) {
printf("efi-unset uuid var\n");
return (CMD_ERROR);
}
uuid = argv[1];
var = argv[2];
uuid_from_string(uuid, (uuid_t *)&guid, &status);
if (status != uuid_s_ok) {
printf("Invalid uuid %s\n", uuid);
return (CMD_ERROR);
}
cpy8to16(var, wvar, sizeof(wvar));
err = RS->SetVariable(wvar, &guid, 0, 0, NULL);
if (EFI_ERROR(err)) {
printf("Failed to unset variable: error %lu\n", EFI_ERROR_CODE(err));
2016-05-20 19:37:54 +00:00
return (CMD_ERROR);
}
return (CMD_OK);
}
#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
#ifdef EFI_ZFS_BOOT
static void
efi_zfs_probe(void)
{
EFI_HANDLE h;
u_int unit;
int i;
char dname[SPECNAMELEN + 1];
uint64_t guid;
unit = 0;
h = efi_find_handle(&efipart_dev, 0);
for (i = 0; h != NULL; h = efi_find_handle(&efipart_dev, ++i)) {
snprintf(dname, sizeof(dname), "%s%d:", efipart_dev.dv_name, i);
if (zfs_probe_dev(dname, &guid) == 0)
(void)efi_handle_update_dev(h, &zfs_dev, unit++, guid);
}
}
#endif