summaryrefslogtreecommitdiffstats
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
...
* [xhci] Ensure that zero-length packets are not part of a TRB chainMichael Brown2015-12-071-0/+6
| | | | | | | | | | | | Some xHCI controllers (such as qemu's emulated xHCI controller) do not correctly handle zero-length packets that are part of a TRB chain. The zero-length TRB ends up being squashed and does not result in a zero-length packet as seen by the device. Work around this problem by marking the zero-length packet as belonging to a separate transfer descriptor. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Add INTEL_NO_PHY_RST for I217-LMTorgeir Wulfsberg2015-12-071-1/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [acm] Add support for CDC-ACM (aka USB RNDIS) devicesMichael Brown2015-12-074-0/+648
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Allow additional settling time for out-of-spec hubsMichael Brown2015-12-072-0/+19
| | | | | | | | | | | | | Some hubs (e.g. the Avocent Corp. Virtual Hub on a Lenovo x3550 Integrated Management Module) have been observed to require more than the standard 200ms for ports to stabilise, with the result that devices appear to disconnect and immediately reconnect during the initial bus enumeration. Work around this problem by allowing specific hubs an extra 500ms of settling time. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Allow USB device IDs to include arbitrary driver-specific dataMichael Brown2015-12-072-3/+9
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Record USB device speed separately from current port speedMichael Brown2015-12-075-14/+15
| | | | | | | | | | | | | Record the speed of a USB device based on the port's speed at the time that the device was enabled. This allows us to remember the device's speed even after the device has been disconnected (and so the port's current speed has changed). In particular, this allows us to correctly identify the transaction translator for a low-speed or full-speed device after the device has been disconnected. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Use port->disconnected to check for disconnected devicesMichael Brown2015-12-072-10/+12
| | | | | | | | | | | | | The usb_message() and usb_stream() functions currently check for port->speed==USB_SPEED_NONE to determine whether or not a device has been unplugged. This test will give a false negative result if a new device has been plugged in before the hotplug mechanism has finished handling the removal of the old device. Fix by checking instead the port->disconnected flag, which is now cleared only after completing the removal of the old device. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add %.usb target for building EFI-bootable USB (or other) disk imagesMichael Brown2015-12-074-0/+72
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [bitops] Provide BIT_QWORD_PTR()Michael Brown2015-12-021-0/+7
| | | | | | | Provide BIT_QWORD_PTR() to allow for easy extraction of non-endian fields (e.g. Infiniband GUIDs) without unnecessary byte swapping. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [smsc95xx] Add driver for SMSC/Microchip LAN95xx USB Ethernet NICsMichael Brown2015-12-013-0/+1382
| | | | | | | | | | | | | | | | | | | | | | | | Tested using QEMU and usbredir to expose the LAN9512 chip present on a Raspberry Pi. There is a known issue with the LAN9512: an extra two bytes are appended to every transmitted packet. These two bytes comprise: { 0x00, 0x08 } if packet length == 0 (mod 8) { CRC[0], 0x00 } if packet length == 7 (mod 8) { CRC[0], CRC[1] } otherwise The extra bytes are appended whether the Ethernet CRC is generated manually or added automatically by the hardware. The issue occurs with the Linux kernel driver as well as the iPXE driver. It appears to be an undocumented hardware errata. TCP/IP traffic is not affected, since the IP header length field causes the extraneous bytes to be discarded by the receiver. However, protocols that rely on the length of the Ethernet frame (such as FCoE or iPXE's "lotest" protocol) will be unusable on this hardware. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [bitops] Fix definitions for big-endian devicesMichael Brown2015-11-301-6/+13
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Add definitions for PCI Express function level reset (FLR)Michael Brown2015-11-302-1/+7
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [infiniband] Add qword accessors for ib_guid and ib_gidMichael Brown2015-11-301-0/+2
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [infiniband] Add definitions for FDR and EDR link speedsMichael Brown2015-11-301-0/+3
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Correct definition of receive overrun bitMichael Brown2015-11-221-1/+1
| | | | | | Reported-by: Robin Smidsrød <robin@smidsrod.no> Tested-by: Robin Smidsrød <robin@smidsrod.no> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Forcibly skip PHY reset on some modelsMichael Brown2015-11-222-8/+19
| | | | | | | | | | | | | | | | | | On some models (notably ICH), the PHY reset mechanism appears to be broken. In particular, the PHY_CTRL register will be correctly loaded from NVM but the values will not be propagated to the "OEM bits" PHY register. This typically has the effect of dropping the link speed to 10Mbps. Since the original version of this driver in commit 945e428 ("[intel] Replace driver for Intel Gigabit NICs"), we have always worked around this problem by skipping the PHY reset if the link is already up. Enhance this workaround by explicitly checking for known-broken PCI IDs. Reported-by: Robin Smidsrød <robin@smidsrod.no> Tested-by: Robin Smidsrød <robin@smidsrod.no> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [comboot] Reset console before starting COMBOOT executableMichael Brown2015-11-172-0/+8
| | | | | | | | | | | | | | | | iPXE does not call shutdown() before invoking a COMBOOT executable, since the executable is allowed to make API calls back into iPXE. If a background picture is used, then the console will not be restored to text mode before invoking the COMBOOT executable. This can cause undefined behaviour. Fix by adding an explicit call to console_reset() immediately before invoking a COMBOOT or COM32 executable, analogous to the call made to console_reset() immediately before invokving a PXE NBP. Debugged-by: Andrew Widdersheim <awiddersheim@inetu.net> Tested-by: Andrew Widdersheim <awiddersheim@inetu.net> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dhcp] Limit maximum number of DHCP discovery deferralsMichael Brown2015-11-102-2/+12
| | | | | | | | | For switches which remain permanently in the non-forwarding state (or which erroneously report a non-forwarding state), ensure that iPXE will eventually give up waiting for the link to become unblocked. Originally-fixed-by: Wissam Shoukair <wissams@mellanox.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Add PCI IDs for i210/i211 flashless operationKyösti Mälkki2015-11-041-0/+2
| | | | | Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dhcp] Reset start time when deferring discoveryMichael Brown2015-10-301-0/+1
| | | | | | | | | | | | | | | | | | If we detect (via STP) that a switch port is in a non-forwarding state, then the link is marked as being temporarily blocked and DHCP discovery will be deferred until the link becomes unblocked. The timer used to decide when to give up waiting for ProxyDHCPOFFERs is currently based on the time that DHCP discovery was started, and makes no allowances for any time spent waiting for the link to become unblocked. Consequently, if STP is used then the timeout for ProxyDHCPOFFERs becomes essentially zero. Fix by resetting the recorded start time whenever DHCP discovery is deferred due to a blocked link. Debugged-by: Sebastian Roth <sebastian.roth@zoho.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add support for EFI_GRAPHICS_OUTPUT_PROTOCOL frame buffer consolesMichael Brown2015-10-165-0/+566
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Generalise CONSOLE_VESAFB to CONSOLE_FRAMEBUFFERMichael Brown2015-10-167-12/+141
| | | | | | | | | | | The name "vesafb" is intrinsically specific to a BIOS environment. Generalise the build configuration option CONSOLE_VESAFB to CONSOLE_FRAMEBUFFER, in preparation for adding EFI framebuffer support. Existing configurations using CONSOLE_VESAFB will continue to work. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [console] Tidy up config/console.hMichael Brown2015-10-161-7/+39
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [fbcon] Move margin calculations to fbcon.cMichael Brown2015-10-143-46/+40Star
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [fbcon] Allow character height to be selected at runtimeMichael Brown2015-10-143-23/+44
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Import EFI_HII_FONT_PROTOCOL definitionsMichael Brown2015-10-075-0/+838
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Update to current EDK2 headersMichael Brown2015-10-0728-373/+12442
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Reset root directory when installing EFI_SIMPLE_FILE_SYSTEM_PROTOCOLMichael Brown2015-10-071-0/+3
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [http] Verify server port when reusing a pooled connectionMichael Brown2015-10-021-7/+12
| | | | | | Reported-by: Allen <allen@gtf.org> Reported-by: Andreas Hammarskjöld <junior@2PintSoftware.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [peerdist] Avoid NULL pointer dereference for plaintext blocksMichael Brown2015-09-291-7/+10
| | | | | | | | Avoid accidentally dereferencing a NULL cipher context pointer for plaintext blocks (which are usually messages with a block length of zero, indicating a missing block). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [malloc] Avoid integer overflow for excessively large memory allocationsMichael Brown2015-09-291-48/+49
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Expose an UNDI interface alongside the existing SNP interfaceMichael Brown2015-09-281-23/+676
| | | | | | | | | | | | | | | | | | | | | | UEFI UNDI is a hideously ugly lump of poorly specified garbage bolted on as an appendix of the UEFI specification. My personal favourite line from the UNDI 'specification' is section E.2.2, which states "Basically, the rule is: Do it right, or don't do it at all". The author appears to believe that such exhortations are a viable substitute for documenting what it is that the wretched reader is supposed to, in fact, do. (Second favourite is the section listing the pros and cons of various driver types. This fails to identify a single con for the mythical "Hardware UNDI", a design so insanely intrinsically slow that it appears to have been the inspiration for the EFI_USB_IO_PROTOCOL.) UNDI is functionally isomorphic to the substantially less preposterous EFI_SIMPLE_NETWORK_PROTOCOL. Provide an UNDI interface (as a thin wrapper around the existing SNP interface) to allow for use by third-party software that has made poor life choices. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Avoid infinite loops when asked to stop non-existent devicesMichael Brown2015-09-281-1/+1
| | | | | | | | | | | | | | | Calling EDK2's OpenProtocol() with attributes BY_DRIVER|EXCLUSIVE will call DisconnectController() in a loop to attempt to dislodge any existing openers with attributes BY_DRIVER. The loop will continue indefinitely until either no such openers remain, or until DisconnectController() returns an error. If our driver binding protocol's Stop() method is ever called to disconnect a device that we are not in fact driving, then return EFI_DEVICE_ERROR rather than EFI_SUCCESS, in order to break this potentially infinite loop. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Work around broken 32-bit PE executable parsing in ImageHlp.dllMichael Brown2015-09-251-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | The Microsoft PE/COFF specification defines the MajorLinkerVersion and MinorLinkerVersion fields as "The linker major version number" and "The linker minor version number" respectively, and has nothing more to say on the matter. These fields have no significance: they do not affect the interpretation of the remainder of the file, but merely provide diagnostic information for interested humans to read. Apparently, versions 2.4 and earlier of the Microsoft linker produced binaries so incorrigibly cursed that even to attempt to parse such a binary would risk summoning a plague of enraged spiders. To protect users from unwanted arachnids, ImageHlp.dll's MapAndLoad() function will helpfully fail to map and/or load a 32-bit binary unless the linker version field indicates version 2.5 or later. (64-bit binaries are exempt from such helpfulness.) Work around the broken Microsoft ImageHlp.dll library by providing a linker version number that will satisfy the arbitrary whims of the MapAndLoad() function. This mirrors wimboot commit 670c7e2 ("[efi] Work around broken 32-bit PE executable parsing in ImageHlp.dll"). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [vmxnet3] Avoid completely filling the TX descriptor ringCarl Henrik Lunde2015-09-162-4/+12
| | | | | Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pxe] Notify BIOS via INT 1a,564e for each new network deviceMichael Brown2015-09-151-0/+26
| | | | | | | | | Use INT 1a,564e to notify the BIOS of each network device that we detect. This provides an opportunity for the BIOS to implement platform policy such as changing the MAC address by issuing a call to PXENV_UNDI_SET_STATION_ADDRESS. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pxe] Invoke INT 1a,564e when PXE stack is activatedMichael Brown2015-09-151-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Invoke INT 1a,564e whenever a PXE stack is activated, passing the address of the PXENV+ structure in %es:%bx. This is designed to allow a BIOS to be notified when a PXE stack has been installed, providing an opportunity for start-of-day commands such as setting the MAC address according to a policy chosen by the BIOS. PXE defines INT 1a,5650 as a means of locating the PXENV+ structure: this call returns %ax=0x564e and the address of the PXENV+ structure in %es:%bx. We choose INT 1a,564e as a fairly natural notification call, using the parameters as would be returned by INT 1a,5650. The full calling convention (documented as per section 3.1 of the PXE specification) is: INT 1a,564e - PXE installation notification Enter: %ax = 0x564e %es = 16-bit segment address of the PXENV+ structure %bx = 16-bit offset of the PXENV+ structure Exit: %edx may be trashed (as is the case for INT 1a,5650) All other register contents must be preserved CF is cleared IF is preserved All other flags are undefined Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Minimise use of iPXE header files when building host utilitiesMichael Brown2015-09-153-3/+6
| | | | | | | | | | Avoid dragging in unnecessary iPXE header files such as <ipxe/uuid.h> and <ipxe/tables.h> when building host utilities, and ensure that FILE_LICENCE() (present in the imported EDK2 headers) expands to a no-op. Reported-by: Michael Tautschnig <mt@debian.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Remove dependency on libibertyMichael Brown2015-09-141-1/+1
| | | | | | | | | | | | | | | | | Commit 7d36a1b ("[build] Explicitly link efilink against -liberty") introduced a dependency on libiberty to cope with old versions of libbfd. This commit dates from 2008 and seems to apply only to what are now extremely old versions of libbfd (prior to binutils 2.12). There are systems (such as current Debian) which do not include libiberty within the binutils packages. On such systems, our build dependency on libiberty represents a pointless hurdle. Remove the explicit dependency on libiberty, hoping that there are no modern systems where this will cause a problem. Suggested-by: Ben Hildred <42656e@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ncm] Support setting MAC addressMichael Brown2015-09-142-0/+14
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Expose unused USB devices via EFI_USB_IO_PROTOCOLMichael Brown2015-09-146-5/+1409
| | | | | | | Allow the UEFI platform firmware to provide drivers for unrecognised devices, by exposing our own implementation of EFI_USB_IO_PROTOCOL. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Allow for wildcard USB class IDsMichael Brown2015-09-149-49/+69
| | | | | | | | Make the class ID a property of the USB driver (rather than a property of the USB device ID), and allow USB drivers to specify a wildcard ID for any of the three component IDs (class, subclass, or protocol). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Select preferred USB device configuration based on driver scoreMichael Brown2015-09-1410-167/+309
| | | | | | | | | | | Generate a score for each possible USB device configuration based on the available driver support, and select the configuration with the highest score. This will allow us to prefer ECM over RNDIS (for devices which support both) and will allow us to meaningfully select a configuration even when we have drivers available for all functions (e.g. when exposing unused functions via EFI_USB_IO_PROTOCOL). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Include a copy of the device path within struct efi_deviceMichael Brown2015-09-133-23/+38
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Provide efi_devpath_len()Michael Brown2015-09-136-17/+19
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [xhci] Support arbitrarily large transfersMichael Brown2015-09-131-11/+45
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ehci] Support arbitrarily large transfersMichael Brown2015-09-131-14/+49
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ehci] Do not treat zero-length NULL pointers as unreachableMichael Brown2015-09-131-0/+2
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Generalise zero-length packet generation logicMichael Brown2015-09-136-19/+20
| | | | | | | | The decision on whether or not a zero-length packet needs to be transmitted is independent of the host controller and belongs in the USB core. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tcpip] Avoid generating positive zero for transmitted UDP checksumsMichael Brown2015-09-105-4/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | TCP/IP checksum fields are one's complement values and therefore have two possible representations of zero: positive zero (0x0000) and negative zero (0xffff). In RFC768, UDP over IPv4 exploits this redundancy to repurpose the positive representation of zero (0x0000) to mean "no checksum calculated"; checksums are optional for UDP over IPv4. In RFC2460, checksums are made mandatory for UDP over IPv4. The wording of the RFC is such that the UDP header is mandated to use only the negative representation of zero (0xffff), rather than simply requiring the checksum to be correct but allowing for either representation of zero to be used. In RFC1071, an example algorithm is given for calculating the TCP/IP checksum. This algorithm happens to produce only the positive representation of zero (0x0000); this is an artifact of the way that unsigned arithmetic is used to calculate a signed one's complement sum (and its final negation). A common misconception has developed (exemplified in RFC1624) that this artifact is part of the specification. Many people have assumed that the checksum field should never contain the negative representation of zero (0xffff). A sensible receiver will calculate the checksum over the whole packet and verify that the result is zero (in whichever representation of zero happens to be generated by the receiver's algorithm). Such a receiver will not care which representation of zero happens to be used in the checksum field. However, there are receivers in existence which will verify the received checksum the hard way: by calculating the checksum over the remainder of the packet and comparing the result against the checksum field. If the representation of zero used by the receiver's algorithm does not match the representation of zero used by the transmitter (and so placed in the checksum field), and if the receiver does not explicitly allow for both representations to compare as equal, then the receiver may reject packets with a valid checksum. For UDP, the combined RFCs effectively mandate that we should generate only the negative representation of zero in the checksum field. For IP, TCP and ICMP, the RFCs do not mandate which representation of zero should be used, but the misconceptions which have grown up around RFC1071 and RFC1624 suggest that it would be least surprising to generate only the positive representation of zero in the checksum field. Fix by ensuring that all of our checksum algorithms generate only the positive representation of zero, and explicitly inverting this in the case of transmitted UDP packets. Reported-by: Wissam Shoukair <wissams@mellanox.com> Tested-by: Wissam Shoukair <wissams@mellanox.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2026-03-01 09:33:59 +0100