stand: Cut over to using the EDK2 files

Remove the old EFI SDK files that we've been nursing along for too many
years. Replace them with files from EDK2 edk2-stable202502 and tweak the
interfaces we

stand: Cut over to using the EDK2 files

Remove the old EFI SDK files that we've been nursing along for too many
years. Replace them with files from EDK2 edk2-stable202502 and tweak the
interfaces we need to tweak. Mostly include different things or change
the names of the protocols that no longer have old-school compat names.

I gave up in the middle of env.c, too damn tedious to find all those new
GUIDs. Also, many of the guids were mystery meat, most likely from the
EDK2 sources, but just not the Include subdirectory. Need to investigate
those. And the memory info? Is it just an oboslete thing, or embedded
knowledge of EDK2.

Delete the now-redundant copies of things in Guid and Protocol. I
debated keeping ZeroGuid.h, but EDK2 has moved on from when I snagged it
years ago (or maybe I just invented it out of whole cloth: edk2 does
radically different things today and I didn't do the git deep-dive to
find out).

Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D53655

show more ...

stand: Rename EFI_ERROR_CODE to DECODE_ERROR to avoid Edk2 Clash

This follows what Illumos has done.

Sponsored by: Netflix
Reviewed by: tsoome
Differential Revision: https://reviews.freebsd.org/D

stand: Rename EFI_ERROR_CODE to DECODE_ERROR to avoid Edk2 Clash

This follows what Illumos has done.

Sponsored by: Netflix
Reviewed by: tsoome
Differential Revision: https://reviews.freebsd.org/D53656

show more ...

loader/libefi: Fix trivial trailing whitespace

Sponsored by: Netflix

libsa: Remove redundant sys/cdefs.h

Sponsored by: Netflix

Remove $FreeBSD$: one-line .c pattern

Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/

libefi: add efi_devpath_next_instance()

UEFI device path may be path to one device, or concatenated list of instances
to different devices (textually represented as comma separated list).

Provide g

libefi: add efi_devpath_next_instance()

UEFI device path may be path to one device, or concatenated list of instances
to different devices (textually represented as comma separated list).

Provide generic function to get next instance from device path.
Returns next instance or end node.

The use case is like:

EFI_DEVICE_PATH *node = (EFI_DEVICE_PATH *)buf;
while (!IsDevicePathEnd(node)) {
process(node);
node = efi_devpath_next_instance(node);
}

Where buf is pointing to either single device path or
concatenated list of device paths (such as from ConIn or ConOut).

Reviewers: imp
Differential Revision: https://reviews.freebsd.org/D40081

show more ...

stand: libefi: swap /Pci() printing around

Printing device followed by interface matches, e.g., edk2. Note that
this is only a fallback, many firmware implementations will provide the
protocol that

stand: libefi: swap /Pci() printing around

Printing device followed by interface matches, e.g., edk2. Note that
this is only a fallback, many firmware implementations will provide the
protocol that we'll use to format device paths.

Reviewed by: imp, tsoome
Sponsored by: Ampere Computing
Submitted by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D34539

show more ...

loader.efi: efipart needs better support detecting nested partitions

Just as disks can have nested partitions, the same happens with cd devices,
so we need to detect device paths and make sure we wi

loader.efi: efipart needs better support detecting nested partitions

Just as disks can have nested partitions, the same happens with cd devices,
so we need to detect device paths and make sure we will not mix the handles.

To address this:

we fetch handle array and create linked list of block devices.
we walk the list and detect parent devices and set children pd_parent.
for {fd, cd, hd}, we walk device list and pick up our devices and store to
corresponding list. We make sure we store parent device first.

For sorting we use 3 steps: We check for floppy, we check for cd and then
everything else must be hd.

In general, it seems the floppy devices have no parent.
CD can have both parents and children (multiple boot entries, partitions
from the hybrid disk image).

Tested by: cross+freebsd@distal.com on Cisco UCS systems, C200 series (C220M5, C240M4).
Also on MBP with UEFI 1.10

Reported by: Chriss Ross
MFC after: 1w
Differential Revision: https://reviews.freebsd.org/D22553

show more ...

loader: implement fallback efi_devpath_to_name()

UEFI 1.10 on macs does not seem to provide devpath to name translation,
provide our own (limited) version, so we can get information about commmon
de

loader: implement fallback efi_devpath_to_name()

UEFI 1.10 on macs does not seem to provide devpath to name translation,
provide our own (limited) version, so we can get information about commmon
devices.

MFC after: 1 week

show more ...

loader.efi: replace HandleProtocol() with OpenProtocol()

The HandleProtocol() is deprecated interface and we should use OpenProtocol()
instead. Moreover, in some firmware implementation(s), the Hand

loader.efi: replace HandleProtocol() with OpenProtocol()

The HandleProtocol() is deprecated interface and we should use OpenProtocol()
instead. Moreover, in some firmware implementation(s), the HandleProtocol()
does return device path using static storage, so we can not keep the value
returned there. With same firmware, the OpenProtocol() does return data we
do not need to clone.

Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D21162

show more ...

MFHead @348740

Sponsored by: The FreeBSD Foundation

Introduce efi_devpath_same_disk

This is like efi_devpath_match, but allows differing device media
paths. Those just specify the partition information.

Differential Revision: https://reviews.freebsd

Introduce efi_devpath_same_disk

This is like efi_devpath_match, but allows differing device media
paths. Those just specify the partition information.

Differential Revision: https://reviews.freebsd.org/D20513

show more ...

MFHead @347527

Sponsored by: The FreeBSD Foundation

Abstract out efi_devpath_to_handle to search for a handle that matches
the desired devpath.

Add wrapper functions to convert strings to EFI_DEVICE_PATH

In anticipation of new functionality, create routines to convert char *
and a CHAR16 * to a EFI_DEVICE_PATH
EFI_DEVICE_PATH *efi_name_to_

Add wrapper functions to convert strings to EFI_DEVICE_PATH

In anticipation of new functionality, create routines to convert char *
and a CHAR16 * to a EFI_DEVICE_PATH
EFI_DEVICE_PATH *efi_name_to_devpath(const char *path);
EFI_DEVICE_PATH *efi_name_to_devpath16(CHAR16 *path);
void efi_devpath_free(EFI_DEVICE_PATH *dp);
The first two return an EFI_DEVICE_PATH for the passed in paths. The
third frees up the storage the first two return when the caller is
done with it.

Differential Revision: https://reviews.freebsd.org/D19971

show more ...

MFHead@r345275

MFhead@r344996

Drop "All rights reserved" from my copyright statements.

Reviewed by: rgrimes
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D19485

stand: Cut over to using the EDK2 files

Remove the old EFI SDK files that we've been nursing along for too many
years. Replace them with files from EDK2 edk2-stable202502 and tweak the
interfaces we

stand: Cut over to using the EDK2 files

Remove the old EFI SDK files that we've been nursing along for too many
years. Replace them with files from EDK2 edk2-stable202502 and tweak the
interfaces we need to tweak. Mostly include different things or change
the names of the protocols that no longer have old-school compat names.

I gave up in the middle of env.c, too damn tedious to find all those new
GUIDs. Also, many of the guids were mystery meat, most likely from the
EDK2 sources, but just not the Include subdirectory. Need to investigate
those. And the memory info? Is it just an oboslete thing, or embedded
knowledge of EDK2.

Delete the now-redundant copies of things in Guid and Protocol. I
debated keeping ZeroGuid.h, but EDK2 has moved on from when I snagged it
years ago (or maybe I just invented it out of whole cloth: edk2 does
radically different things today and I didn't do the git deep-dive to
find out).

Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D53655

show more ...

stand: Rename EFI_ERROR_CODE to DECODE_ERROR to avoid Edk2 Clash

This follows what Illumos has done.

Sponsored by: Netflix
Reviewed by: tsoome
Differential Revision: https://reviews.freebsd.org/D

stand: Rename EFI_ERROR_CODE to DECODE_ERROR to avoid Edk2 Clash

This follows what Illumos has done.

Sponsored by: Netflix
Reviewed by: tsoome
Differential Revision: https://reviews.freebsd.org/D53656

show more ...

loader/libefi: Fix trivial trailing whitespace

Sponsored by: Netflix

libsa: Remove redundant sys/cdefs.h

Sponsored by: Netflix

Remove $FreeBSD$: one-line .c pattern

Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/

libefi: add efi_devpath_next_instance()

UEFI device path may be path to one device, or concatenated list of instances
to different devices (textually represented as comma separated list).

Provide g

libefi: add efi_devpath_next_instance()

UEFI device path may be path to one device, or concatenated list of instances
to different devices (textually represented as comma separated list).

Provide generic function to get next instance from device path.
Returns next instance or end node.

The use case is like:

EFI_DEVICE_PATH *node = (EFI_DEVICE_PATH *)buf;
while (!IsDevicePathEnd(node)) {
process(node);
node = efi_devpath_next_instance(node);
}

Where buf is pointing to either single device path or
concatenated list of device paths (such as from ConIn or ConOut).

Reviewers: imp
Differential Revision: https://reviews.freebsd.org/D40081

show more ...

stand: libefi: swap /Pci() printing around

Printing device followed by interface matches, e.g., edk2. Note that
this is only a fallback, many firmware implementations will provide the
protocol that

stand: libefi: swap /Pci() printing around

Printing device followed by interface matches, e.g., edk2. Note that
this is only a fallback, many firmware implementations will provide the
protocol that we'll use to format device paths.

Reviewed by: imp, tsoome
Sponsored by: Ampere Computing
Submitted by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D34539

show more ...