summaryrefslogtreecommitdiffstats
path: root/src/interface/efi/efi_path.c
Commit message (Collapse)AuthorAgeFilesLines
* [efi] Extract basic network settings from loaded image device pathMichael Brown2024-03-261-0/+241
| | | | | | | | | | | | | | | | | | | | | | | | | | The UEFI HTTP boot mechanism is extraordinarily badly designed, even by the standards of the UEFI specification in general. It has the symptoms of a feature that has been designed entirely in terms of user stories, without any consideration at all being given to the underlying technical architecture. It does work, provided that you are doing precisely and only what was envisioned by the product owner. If you want to try anything outside the bounds of the product owner's extremely limited imagination, then you are almost certainly about to enter a world of pain. As one very minor example of this: the cached DHCP packet is not available when using HTTP boot. The UEFI HTTP boot code does perform DHCP, but it pointlessly and unhelpfully throws away the DHCP packet and trashes the network interface configuration before handing over to the downloaded executable. Work around this imbecility by parsing and applying the few network configuration settings that are persisted into the loaded image's device path. This is limited to very basic information such as the IP address, gateway address, and DNS server address, but it does at least provide enough for a functional routing table. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add efi_path_mac() to parse a MAC address from an EFI device pathMichael Brown2024-03-261-0/+24
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add efi_path_uri() to parse a URI from an EFI device pathMichael Brown2024-03-191-0/+40
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add efi_path_guid() utility functionMichael Brown2024-03-061-0/+43
| | | | | | | | | | | EFI provides no API for determining the partition GUID (if any) for a specified device handle. The partition GUID appears to be exposed only as part of the device path. Add efi_path_guid() to extract the partition GUID (if any) from a device path. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [legal] Add missing FILE_LICENCE declaration to efi_path.cMichael Brown2023-01-281-0/+2
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add efi_path_prev() utility functionMichael Brown2023-01-231-7/+20
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add efi_path_terminate() utility functionMichael Brown2023-01-231-24/+8Star
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add efi_path_vlan() utility functionMichael Brown2022-12-221-0/+23
| | | | | | | | | | | | | | | | | | EFI provides no API for determining the VLAN tag (if any) for a specified device handle. There is the EFI_VLAN_CONFIG_PROTOCOL, but that exists only on the trunk device handle (not on the VLAN device handle), and provides no way to match VLAN tags against the trunk device's child device handles. The EDK2 codebase seems to rely solely on the device path to determine the VLAN tag for a specified device handle: both NetLibGetVlanId() and BmGetNetworkDescription() will parse the device path to search for a VLAN_DEVICE_PATH component. Add efi_path_vlan() which uses the same device path parsing logic to determine the VLAN tag. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Expose efi_path_next() utility functionMichael Brown2022-12-221-5/+29
| | | | | | | Provide a single central implementation of the logic for stepping through elements of an EFI device path. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Allow passing a NULL device path to path utility functionsMichael Brown2022-12-221-4/+4
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [infiniband] Allow SRP device to be described using an EFI device pathMichael Brown2020-10-231-0/+55
| | | | | | | | | The UEFI specification provides a partial definition of an Infiniband device path structure. Use this structure to construct what may be a plausible path containing at least some of the information required to identify an SRP target device. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [fcp] Allow Fibre Channel device to be described using an EFI device pathMichael Brown2020-10-221-0/+31
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [iscsi] Allow iSCSI device to be described using an EFI device pathMichael Brown2020-10-201-0/+70
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [aoe] Allow AoE device to be described using an EFI device pathMichael Brown2020-10-191-0/+47
| | | | | | | | | | | | | There is no standard defined for AoE device paths in the UEFI specification, and it seems unlikely that any standard will be adopted in future. Choose to construct an AoE device path using a concatenation of the network device path and a SATA device path, treating the AoE major and minor numbers as the HBA port number and port multiplier port number respectively. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Provide utility function to concatenate device pathsMichael Brown2020-10-191-0/+52
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Split efi_netdev_path() out to a separate functionMichael Brown2020-10-191-0/+65
| | | | | | | Provide efi_netdev_path() as a standalone function, to allow for reuse when constructing child device paths. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Provide efi_uri_path() to construct a URI device pathMichael Brown2020-10-191-0/+43
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Split efi_usb_path() out to a separate functionMichael Brown2020-10-161-0/+60
| | | | | | | Provide efi_usb_path() as a standalone function, to allow for reuse by the USB mass storage driver. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Define an interface operation to describe using an EFI device pathMichael Brown2020-10-161-0/+26
| | | | | | | Allow arbitrary objects to support describing themselves using an EFI device path. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Split device path functions out to efi_path.cMichael Brown2020-10-161-0/+57
Signed-off-by: Michael Brown <mcb30@ipxe.org>