summaryrefslogtreecommitdiffstats
path: root/src/include/ipxe
Commit message (Collapse)AuthorAgeFilesLines
...
* [ipv6] Expose IPv6 settings acquired through NDPMichael Brown2016-07-191-0/+9
| | | | | | | | | Expose the IPv6 address (or prefix) as ${ip6}, the prefix length as ${len6}, and the router address as ${gateway6}. Originally-implemented-by: Hannes Reinecke <hare@suse.de> Originally-implemented-by: Marin Hannache <git@mareo.fr> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ipv6] Rename ipv6_scope to dhcpv6_scopeMichael Brown2016-07-161-1/+1
| | | | | | | | The settings scope ipv6_scope refers specifically to IPv6 settings that have a corresponding DHCPv6 option. Rename to dhcpv6_scope to more accurately reflect this purpose. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [settings] Create space for IPv6 in settings display orderMichael Brown2016-07-151-16/+20
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [acpi] Add support for ACPI power offMichael Brown2016-07-111-0/+75
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Install the HII config access protocol on a child of the SNP handleLaszlo Ersek2016-07-081-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In edk2, there are several drivers that associate HII forms (and corresponding config access protocol instances) with each individual network device. (In this context, "network device" means the EFI handle on which the SNP protocol is installed, and on which the device path ending with the MAC() node is installed also.) Such edk2 drivers are, for example: Ip4Dxe, HttpBootDxe, VlanConfigDxe. In UEFI, any given handle can carry at most one instance of a specific protocol (see e.g. the specification of the InstallProtocolInterface() boot service). This implies that the class of drivers mentioned above can't install their EFI_HII_CONFIG_ACCESS_PROTOCOL instances on the SNP handle directly -- they would conflict with each other. Accordingly, each of those edk2 drivers creates a "private" child handle under the SNP handle, and installs its config access protocol (and corresponding HII package list) on its child handle. The device path for the child handle is traditionally derived by appending a Hardware Vendor Device Path node after the MAC() node. The VenHw() nodes in question consist of a GUID (by definition), and no trailing data (by choice). The purpose of these VenHw() nodes is only that all the child nodes can be uniquely identified by device path. At the moment iPXE does not follow this pattern. It doesn't run into a conflict when it installs its EFI_HII_CONFIG_ACCESS_PROTOCOL directly on the SNP handle, but that's only because iPXE is the sole driver not following the pattern. This behavior seems risky (one might call it a "latent bug"); better align iPXE with the edk2 custom. Cc: Michael Brown <mcb30@ipxe.org> Cc: Gary Lin <glin@suse.com> Cc: Ladi Prosek <lprosek@redhat.com> Ref: http://thread.gmane.org/gmane.comp.bios.edk2.devel/13494/focus=13532 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ladi Prosek <lprosek@redhat.com> Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [profile] Allow profiling to be globally enabled or disabledMichael Brown2016-07-051-0/+2
| | | | | | | | | | As with assertions, profiling is enabled for objects built with any debug level (including an explicit debug level of zero). Allow profiling to be globally enabled or disabled by adding PROFILE=1 or PROFILE=0 respectively to the build command line. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dhcp] Automatically generate vendor class identifier stringMichael Brown2016-07-041-0/+23
| | | | | | | | | | | | The vendor class identifier strings in DHCP_ARCH_VENDOR_CLASS_ID are out of sync with the (correct) client architecture values in DHCP_ARCH_CLIENT_ARCHITECTURE. Fix by removing all definitions of DHCP_ARCH_VENDOR_CLASS_ID, and instead generating the vendor class identifier string automatically based on DHCP_ARCH_CLIENT_ARCHITECTURE and DHCP_ARCH_CLIENT_NDI. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dhcpv6] Include vendor class identifier option in DHCPv6 requestsMichael Brown2016-07-041-11/+32
| | | | | | | | | | | | | | | | | | | | | | | | RFC3315 defines DHCPv6 option 16 (vendor class identifier) but does not define any direct relationship with the roughly equivalent DHCPv4 option 60. The PXE specification predates IPv6, and the UEFI specification is expectedly vague on the subject. Examination of the reference EDK2 codebase suggests that the DHCPv6 vendor class identifier will be formatted in accordance with RFC3315, using a single vendor-class-data item in which the opaque-data field is the string as would appear in DHCPv4 option 60. RFC3315 requires the vendor class identifier to specify an IANA enterprise number, as a way of disambiguating the vendor-class-data namespace. The EDK2 code uses the value 343, described as: // TODO: IANA TBD: temporarily using Intel's Since this "TODO" has been present since at least 2010, it is probably safe to assume that it has now become a de facto standard. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dhcpv6] Include RFC5970 client architecture options in DHCPv6 requestsMichael Brown2016-07-041-0/+33
| | | | | | | | RFC5970 defines DHCPv6 options 61 (client system architecture type) and 62 (client network interface identifier), with contents equivalent to DHCPv4 options 93 and 94 respectively. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [virtio] Renumber virtio_pci_region flagsLadi Prosek2016-06-201-3/+3
| | | | | | | | | | | | | Some of the regions may end up being unmapped, either because they are optional or because the attempt to map them has failed. Region types starting at 0 didn't make it easy to test for this condition. This commit bumps all valid region types up by 1 with 0 having the implicit 'unmapped' meaning. Signed-off-by: Ladi Prosek <lprosek@redhat.com> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [thunderx] Add driver for Cavium ThunderX SoC NICsMichael Brown2016-06-131-0/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ntp] Add simple NTP clientMichael Brown2016-06-132-0/+110
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [time] Allow system clock to be adjusted at runtimeMichael Brown2016-06-131-1/+14
| | | | | | | | | | Provide a mechanism to allow an arbitrary adjustment to be applied to all subsequent calls to time(). Note that the underlying clock source (e.g. the RTC clock) will not be changed; only the time as reported within iPXE will be affected. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tcp] Send TCP keepalives on idle established connectionsMichael Brown2016-06-131-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | In some circumstances, intermediate devices may lose state in a way that temporarily prevents the successful delivery of packets from a TCP peer. For example, a firewall may drop a NAT forwarding table entry. Since iPXE spends most of its time downloading files (and hence purely receiving data, sending only TCP ACKs), this can easily happen in a situation in which there is no reason for iPXE's TCP stack to generate any retransmissions. The temporary loss of connectivity can therefore effectively become permanent. Work around this problem by sending TCP keepalives after a period of inactivity on an established connection. TCP keepalives usually send a single garbage byte in sequence number space that has already been ACKed by the peer. Since we do not need to elicit a response from the peer, we instead send pure ACKs (with no garbage data) in order to keep the transmit code path simple. Originally-implemented-by: Ladi Prosek <lprosek@redhat.com> Debugged-by: Ladi Prosek <lprosek@redhat.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Support systems with multiple PCI root bridgesMichael Brown2016-06-091-7/+9
| | | | | | | | | Extend the 16-bit PCI bus:dev.fn address to a 32-bit seg:bus:dev.fn address, assuming a segment value of zero in contexts where multiple segments are unsupported by the underlying data structures (e.g. in the iBFT or BOFM tables). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Expose DHCP packets via the Apple NetBoot protocolMichael Brown2016-05-292-0/+47
| | | | | | | | Mac OS X uses non-standard EFI protocols to obtain the DHCP packets from the UEFI firmware. Originally-implemented-by: Michael Kuron <m.kuron@gmx.de> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dhcp] Fix definitions for x86_64 and EFI BC client architecturesMichael Brown2016-05-261-4/+4
| | | | | | | | | | | | | | | There has been a longstanding disagreement between RFC4578 and the IANA "Processor Architecture Types" registry. RFC4578 section 2.1 defines type 7 as "EFI BC" and type 9 as "EFI x86-64"; the IANA registry quotes RFC4578 as its source but has these values erroneously swapped. The EDK2 codebase uses the IANA values. As of March 2016, RFC4578 has been modified by an errata to match the values as recorded in the IANA registry. Fix our definitions to match the consensus values. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [arm] Use correct DHCP client architecture valuesMichael Brown2016-05-261-0/+4
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [axge] Add driver for ASIX 10/100/1000 USB Ethernet NICsMichael Brown2016-05-261-0/+1
| | | | | | | Add driver for the AX88178A (USB2) and AX88179 (USB3) 10/100/1000 Ethernet NICs. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [settings] Extend numerical setting tags to "unsigned long"Michael Brown2016-05-201-1/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Add support for PCI Enhanced AllocationMichael Brown2016-05-203-0/+72
| | | | | | | Some embedded devices have immovable BARs, which are described via a PCI Enhanced Allocation capability. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Generalise EFI entropy generation to non-x86 CPUsMichael Brown2016-05-041-0/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Use a timer event to generate the currticks() timerMichael Brown2016-05-042-302/+18Star
| | | | | | | | | | | | | | We currently use the EFI_CPU_ARCH_PROTOCOL's GetTimerValue() method to generate the currticks() timer, calibrated against a 1ms delay from the boot services Stall() method. This does not work on ARM platforms, where GetTimerValue() is an empty stub which just returns EFI_UNSUPPORTED. Fix by instead creating a periodic timer event, and using this event to increment a current tick counter. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tcpip] Do not fall back to using unoptimised TCP/IP checksummingMichael Brown2016-05-041-9/+4Star
| | | | | | | | Require architecture-specific code to make a deliberate choice to use the unoptimised generic_tcpip_continue_chksum() function, if there is no optimised version available. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [virtio] Add virtio 1.0 PCI supportLadi Prosek2016-04-153-1/+153
| | | | | | | | | | | | This commit adds support for driving virtio 1.0 PCI devices. In addition to various helpers, a number of vpm_ functions are introduced to be used instead of their legacy vp_ counterparts when accessing virtio 1.0 (aka modern) devices. Signed-off-by: Ladi Prosek <lprosek@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [virtio] Add virtio 1.0 constants and data structuresLadi Prosek2016-04-152-0/+68
| | | | | | | | | | Virtio 1.0 introduces new constants and data structures, common to all devices as well as specific to virtio-net. This commit adds a subset of these to be able to drive the virtio-net 1.0 network device. Signed-off-by: Ladi Prosek <lprosek@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Add pci_find_next_capability()Ladi Prosek2016-04-151-0/+2
| | | | | | | | | | | | | | | | | PCI devices may support more capabilities of the same type (for example PCI_CAP_ID_VNDR) and there was no way to discover all of them. This commit adds a new API pci_find_next_capability which provides this functionality. It would typically be used like so: for (pos = pci_find_capability(pci, PCI_CAP_ID_VNDR); pos > 0; pos = pci_find_next_capability(pci, pos, PCI_CAP_ID_VNDR)) { ... } Signed-off-by: Ladi Prosek <lprosek@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pool] Fix check for reopenable pooled connectionsSuresh Sundriyal2016-04-121-1/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [iscsi] Include DHCP server address in iBFTMichael Brown2016-03-291-0/+2
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [golan] Add Connect-IB, ConnectX-4 and ConnectX-4 Lx (Infiniband) supportWissam Shoukair2016-03-221-0/+2
| | | | | Signed-off-by: Wissam Shoukair <wissams@mellanox.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [int13] Allow default drive to be specified via "san-drive" settingMichael Brown2016-03-221-3/+3
| | | | | | | | | | | The DHCP option 175.189 has been defined (by us) since 2006 as containing the drive number to be used for a SAN boot, but has never been automatically used as such by iPXE. Use this option (if specified) to override the default SAN drive number. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [int13] Allow drive to be hooked using the natural drive numberMichael Brown2016-03-221-1/+1
| | | | | | | Interpret the maximum drive number (0xff for hard disks, 0x7f for floppy disks) as meaning "use natural drive number". Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [infiniband] Allow drivers to override the eIPoIB LEMACMichael Brown2016-03-211-0/+4
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ipoib] Allow external code to identify IPoIB network devicesMichael Brown2016-03-201-0/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [xen] Use generic test_and_clear_bit() functionMichael Brown2016-03-161-0/+14
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [bitops] Add generic atomic bit test, set, and clear functionsMichael Brown2016-03-161-0/+19
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pseudobit] Rename bitops.h to pseudobit.hMichael Brown2016-03-161-6/+6
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Remove long-obsolete header fileMichael Brown2016-03-161-27/+0Star
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Provide access to files stored on EFI filesystemsMichael Brown2016-03-141-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Provide access to local files via the "file://" URI scheme. There are three syntaxes: - An opaque URI with a relative path (e.g. "file:script.ipxe"). This will be interpreted as a path relative to the iPXE binary. - A hierarchical URI with a non-network absolute path (e.g. "file:/boot/script.ipxe"). This will be interpreted as a path relative to the root of the filesystem from which the iPXE binary was loaded. - A hierarchical URI with a network path in which the authority is a volume label (e.g. "file://bootdisk/script.ipxe"). This will be interpreted as a path relative to the root of the filesystem with the specified volume label. Note that the potentially desirable shell mappings (e.g. "fs0:" and "blk0:") are concepts internal to the UEFI shell binary, and do not seem to be exposed in any way to external executables. The old EFI_SHELL_PROTOCOL (which did provide access to these mappings) is no longer installed by current versions of the UEFI shell. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add processor binding headers for ARM and AArch64Michael Brown2016-03-133-0/+329
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Update to current EDK2 headersMichael Brown2016-03-1313-42/+123
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [arp] Validate length of ARP packetMichael Brown2016-03-121-0/+10
| | | | | | | | | | | | There is no practical way to generate an underlength ARP packet since an ARP packet is always padded up to the minimum Ethernet frame length (or dropped by the receiving Ethernet hardware if incorrectly padded), but the absence of an explicit check causes warnings from some analysis tools. Fix by adding an explicit check on the I/O buffer length. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Allow for zero-length ASN.1 cursorsMichael Brown2016-03-111-2/+14
| | | | | | | | | | | | | The assumption in asn1_type() that an ASN.1 cursor will always contain a type byte is incorrect. A cursor that has been cleanly invalidated via asn1_invalidate_cursor() will contain a type byte, but there are other ways in which to arrive at a zero-length cursor. Fix by explicitly checking the cursor length in asn1_type(). This allows asn1_invalidate_cursor() to be reduced to simply zeroing the length field. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [xsigo] Add support for Xsigo virtual Ethernet (XVE) EoIB devicesMichael Brown2016-03-092-0/+407
| | | | | | | | | Add support for EoIB devices as implemented by Xsigo. Based on the public (but out-of-tree) Linux kernel drivers at https://oss.oracle.com/git/?p=linux-uek.git;a=log;h=v4.1.12-32.2.1 Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [eoib] Support non-FullMember gateway devicesMichael Brown2016-03-091-0/+22
| | | | | | | | | | | | | Some EoIB implementations utilise an EoIB-to-Ethernet gateway device that does not perform a FullMember join to the multicast group for the EoIB broadcast domain. This has various exciting side-effects, such as requiring every EoIB node to send every broadcast packet twice. As an added bonus, the gateway may also break the EoIB MAC address to GID mapping protocol by sending Ethernet-sourced packets from the wrong QPN. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [eoib] Allow the multicast group to be forcefully createdMichael Brown2016-03-091-0/+21
| | | | | | | | | | | | | Some EoIB implementations require each individual EoIB node to create the multicast group for the EoIB broadcast domain. It is left as an exercise for the interested reader to determine how such an implementation might ever allow the parameters of such a multicast group to be changed without requiring a simultaneous upgrade of every driver on every operating system on every machine currently attached to the fabric. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [eoib] Add Ethernet over Infiniband (EoIB) driverMichael Brown2016-03-092-0/+61
| | | | | | | | | | | | | | | | | | | | EoIB is a fairly simple protocol in which raw Ethernet frames (excluding the CRC) are encapsulated within Infiniband Unreliable Datagrams, with a four-byte fixed EoIB header (which conveys no actual information). The Ethernet broadcast domain is provided by a multicast group, similar to the IPoIB IPv4 multicast group. The mapping from Ethernet MAC addresses to Infiniband address vectors is achieved by snooping incoming traffic and building a peer cache which can then be used to map a MAC address into a port GID. The address vector is completed using a path record lookup, as for IPoIB. Note that this requires every packet to include a GRH. Add basic support for EoIB devices. This driver is substantially derived from the IPoIB driver. There is currently no mechanism for automatically creating EoIB devices. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ipoib] Resimplify test for received broadcast packetsMichael Brown2016-03-081-0/+3
| | | | | | | | | | | | Commit e62e52b ("[ipoib] Simplify test for received broadcast packets") relies upon the multicast LID being present in the destination address vector as passed to ipoib_complete_recv(). Unfortunately, this information is not present in many Infiniband devices' completion queue entries. Fix by testing instead for the presence of a multicast GID. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [infiniband] Assign names to queue pairsMichael Brown2016-03-081-1/+3
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [infiniband] Assign names to CMRC connectionsMichael Brown2016-03-081-4/+3Star
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2026-02-28 03:49:36 +0100