summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
* [efi] Add definitions of GUIDs observed when chainloading from Intel driverMichael Brown2014-09-2512-2/+4246
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Centralise definitions of more protocol GUIDsMichael Brown2014-09-255-18/+23
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Use -malign-double to build 32-bit UEFI binariesMichael Brown2014-09-241-0/+4
| | | | | | | | | | | The EDK2 codebase uses -malign-double for 32-bit builds, which causes 64-bit integers to be naturally aligned. This affects the layout of some structures (including EFI_BLOCK_IO_MEDIA). This mirrors wimboot commit 7b8f39d ("[build] Fix building of 32-bit UEFI version"). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dhcp] Remove obsolete dhcp_chaddr() functionMichael Brown2014-09-221-75/+5Star
| | | | | | | | | | | | | | | As of commit 03f0c23 ("[ipoib] Expose Ethernet-compatible eIPoIB link-layer addresses and headers"), all link layers have used addresses which fit within the DHCP chaddr field. The dhcp_chaddr() function was therefore made obsolete by this commit, but was accidentally left present (though unused) in the source code. Remove the dhcp_chaddr() function and the only remaining use of it, unnecessarily introduced in commit 08bcc0f ("[dhcp] Check for matching chaddr in received DHCP packets"). Reported-by: Wissam Shoukair <wissams@mellanox.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dhcp] Check for matching chaddr in received DHCP packetsMichael Brown2014-09-221-0/+37
| | | | | | | | On large networks a DHCP XID collision is possible. Fix by explicitly checking the chaddr in received DHCP packets. Originally-fixed-by: Wissam Shoukair <wissams@mellanox.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Provide dummy device path in efi_image_probe()Michael Brown2014-09-191-1/+6
| | | | | | | | | | | | | | | | | Some UEFI platforms will fail the call to LoadImage() with EFI_INVALID_PARAMETER if we do not provide a device path (even though we are providing a non-NULL SourceBuffer). Fix by providing an empty device path for the call to LoadImage() in efi_image_probe(). The call to LoadImage() in efi_image_exec() already constructs and provides a device path (based on the most recently opened SNP device), and so does not require this fix. Reported-by: NICOLAS CATTIE <nicolas.cattie@mpsa.com> Tested-by: NICOLAS CATTIE <nicolas.cattie@mpsa.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Add I217-LM PCI IDJan Kiszka2014-09-161-1/+2
| | | | | | | Add the ID for the LM variant and differentiate it from the I217-V. Signed-off-by: Jan Kiszka <jan.kiszka@web.de> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add efifatbin utilityMichael Brown2014-09-104-0/+267
| | | | | | | | | | | | | | | | | Add utility for constructing EFI fat binaries (dual 32/64-bit binaries, usable only on Apple EFI systems). This utility is not part of the standard build process. To use it: make util/efifatbin bin-i386-efi/ipxe.efi bin-x86_64-efi/ipxe.efi and then ./util/efifatbin bin-*-efi/ipxe.efi fat-ipxe.efi Requested-by: Brandon Penglase <bpenglase-ipxe@spaceservices.net> Tested-by: Brandon Penglase <bpenglase-ipxe@spaceservices.net> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Clean up all binary directories on "make [very]clean"Michael Brown2014-09-041-1/+8
| | | | | | | | | | | | Allow a straightforward "make clean" or "make veryclean" to apply to all binary directories (using the shell pattern "bin{,-*}"). Individual binary directories can be cleaned using e.g. make bin clean make bin-x86_64-efi clean Reported-by: Robin Smidsrød <robin@smidsrod.no> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Allow for non-PCI snpnet devicesMichael Brown2014-09-041-7/+8
| | | | | | | | | | | | | We currently require information about the underlying PCI device to populate the snpnet device's name and description. If the underlying device is not a PCI device, this will fail and prevent the device from being registered. Fix by falling back to populating the device description with information based on the EFI handle, if no PCI device information is available. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Make EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL optionalMichael Brown2014-09-041-1/+7
| | | | | | | | | | Some UEFI systems (observed with a Hyper-V virtual machine) do not provide EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL. Make this an optional protocol (and fail any attempts to access PCI configuration space via the root bridge if the protocol is missing). Reported-by: Colin Blacker <Colin.Blacker@computerplanet.co.uk> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Avoid returning uninitialised data from PCI configuration space readsMichael Brown2014-09-041-0/+3
| | | | | | | | Under UEFI, reads from PCI configuration space may fail. If this happens, we should return all-ones (which will mimic the behaviour of an absent PCI device). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Use the SNP protocol instance to match the SNP chainloading deviceMichael Brown2014-09-041-8/+89
| | | | | | | | | | | | | | | | Some systems will install a child of the SNP device and use this as our loaded image's device handle, duplicating the installation of the underlying SNP protocol onto the child device handle. On such systems, we want to end up driving the parent device (and disconnecting any other drivers, such as MNP, which may be attached to the parent device). Fix by recording the SNP protocol instance at initialisation time, and using this to match against device handles (rather than simply comparing the handles themselves). Reported-by: Jarrod Johnson <jarrod.b.johnson@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Wrap any images loaded by our wrapped imageMichael Brown2014-08-294-24/+70
| | | | | | | | | | | | Propagate our modified EFI system table to any images loaded by the image that we wrap, thereby allowing us to observe boot services calls made by all subsequent EFI images. Also show details of intercepted ExitBootServices() calls. When wrapping is used, exiting boot services will almost certainly fail, but this at least allows us to see when it happens. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Make our virtual file system case insensitiveMichael Brown2014-08-271-4/+24
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Show details of intercepted LoadImage() callsMichael Brown2014-08-271-0/+30
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [mromprefix] Allow for .mrom images larger than 128kBMichael Brown2014-08-261-9/+1Star
| | | | | | | | | | The .mrom payload has a code type of 0xff and so the initialisation length field (single byte at offset 0x02) does not need to be present. Use only the PCI header's image length field, which allows the .mrom payload to be up to 32MB in size. Inspired-by: Swift Geek <swiftgeek@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [mromprefix] Use PCI length field to obtain length of individual imagesMichael Brown2014-08-261-7/+17
| | | | | | | | | | | | mromprefix.S currently uses the initialisation length field (single byte at offset 0x02) to determine the length of a ROM image within a multi-image ROM BAR. For PCI ROM images with a code type other than 0, the initialisation length field may not be present. Fix by using the PCI header's image length field instead. Inspired-by: Swift Geek <swiftgeek@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [util] Use PCI length field to obtain length of individual imagesMichael Brown2014-08-261-3/+2Star
| | | | | | | | | | | | | | Option::ROM currently uses the initialisation length field (single byte at offset 0x02) to determine the length of a ROM image within a multi-image ROM file. For PCI ROM images with a code type other than 0, the initialisation length field may not be present. Fix by using the PCI header's image length field instead. Note that this does not prevent us from correctly handling ISA ROMs, since ISA ROMs do not support multiple images within a single ROM BAR anyway. Inspired-by: Swift Geek <swiftgeek@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [prefix] Report both %esi and %ecx when opening payload failsMichael Brown2014-08-262-1/+6
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [prefix] Halt system without burning CPU if we cannot access the payloadMichael Brown2014-08-261-1/+4
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Avoid deleting config header files if build is interruptedMichael Brown2014-08-261-2/+15
| | | | | | | | | | | With extremely unlucky timing, it is possible to interrupt a build and cause make to delete config/named.h (and possibly any local configuration headers). Mark config/named.h and all local configuration headers as .PRECIOUS to prevent make from ever deleting them. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Avoid using embedded script in VirtualBox named configurationRobin Smidsrød2014-08-223-12/+8Star
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Allow ISA ROMs to be builtMichael Brown2014-08-228-30/+146
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The build process has for a long time assumed that every ROM is a PCI ROM, and will always include the PCI header and PCI-related functionality (such as checking the PCI BIOS version, including the PCI bus:dev.fn address within the ROM product name string, etc.). While real ISA cards are no longer in use, some virtualisation environments (notably VirtualBox) have support only for ISA ROMs. This can cause problems: in particular, VirtualBox will call our initialisation entry point with random garbage in %ax, which we then treat as the PCI bus:dev.fn address of the autoboot device: this generally prevents the default boot sequence from using any network devices. Create .isarom and .pcirom prefixes which can be used to explicitly specify the type of ROM to be created. (Note that the .mrom prefix always implies a PCI ROM, since the .mrom mechanism relies on reconfiguring PCI BARs.) Make .rom a magic prefix which will automatically select the appropriate PCI or ISA ROM prefix for ROMs defined via a PCI_ROM() or ISA_ROM() macro. To maintain backwards compatibility, we default to building a PCI ROM for anything which is not directly derived from a PCI_ROM() or ISA_ROM() macro (e.g. bin/intel.rom). Add a selection of targets to "make everything" to ensure that the (relatively obscure) ISA ROM build process is included within the per-commit QA checks. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Remove obsolete references to .zrom build targetsMichael Brown2014-08-221-8/+5Star
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [romprefix] Do not preserve unused register %diMichael Brown2014-08-221-8/+1Star
| | | | | | | | | | Since some PnP BIOSes fail to set %es:di to point to the PnP signature on entry, we identify a PnP BIOS by scanning through the top 64kB of base memory looking for the PnP structure. We therefore don't actually use the values of %es:di provided to the initialisation entry point, and so there is no need to preserve them. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Dump details of any calls to our dummy block and disk I/O protocolsMichael Brown2014-08-221-15/+33
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add definitions of GUIDs observed during Windows bootMichael Brown2014-08-218-1/+3795
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Add named configuration for VirtualBoxRobin Smidsrød2014-08-219-0/+49
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Apply PBS/PBA errata workaround only to ICH8 PCI device IDsMichael Brown2014-08-212-13/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ICH8 devices have an errata which requires us to reconfigure the packet buffer size (PBS) register, and correspondingly adjust the packet buffer allocation (PBA) register. The "Intel I/O Controller Hub ICH8/9/10 and 82566/82567/82562V Software Developer's Manual" notes for the PBS register that: 10.4.20 Packet Buffer Size - PBS (01008h; R/W) Note: The default setting of this register is 20 KB and is incorrect. This register must be programmed to 16 KB. Initial value: 0014h 0018h (ICH9/ICH10) It is unclear from this comment precisely which devices require the workaround to be applied. We currently attempt to err on the side of caution: if we detect an initial value of either 0x14 or 0x18 then the workaround will be applied. If the workaround is applied unnecessarily, then the effect should be just that we use less than the full amount of the available packet buffer memory. Unfortunately this approach does not play nicely with other device drivers. For example, the Linux e1000e driver will rewrite PBA while assuming that PBS still contains the default value, which can result in inconsistent values between the two registers, and a corresponding inability to transmit or receive packets. Even more unfortunately, the contents of PBS and PBA are not reset by anything less than a power cycle, meaning that this error condition will survive a hardware reset. The Linux driver (written and maintained by Intel) applies the PBS/PBA errata workaround only for devices in the ICH8 family, identified via the PCI device ID. Adopt a similar approach, using the PCI_ROM() driver data field to indicate when the workaround is required. Reported-by: Donald Bindner <dbindner@truman.edu> Debugged-by: Donald Bindner <dbindner@truman.edu> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Display before and after values for both PBS and PBAMichael Brown2014-08-211-2/+7
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Display PBS value when applying ICH errata workaroundMichael Brown2014-08-201-2/+2
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Allow for named configurations at build timeMichael Brown2014-08-209-2/+85
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Allow named configurations to be specified via the CONFIG=... build parameter. For headers in config/*.h which support named configurations, the following files will be included when building with CONFIG=<name>: - config/defaults/<platform>.h (e.g. config/defaults/pcbios.h) - config/<header>.h - config/<name>/<header>.h (only if the directory config/<name> exists) - config/local/<header>.h (autocreated if necessary) - config/local/<name>/<header>.h (autocreated if necessary) This mechanism allows for predefined named configurations to be checked in to the source tree, as a directory config/<name> containing all of the required header files. The mechanism also allows for users to define multiple local configurations, by creating header files in the directory config/local/<name>. Note that the config/*.h files which are used only to configure internal iPXE APIs (e.g. config/ioapi.h) cannot be modified via a named configuration. This avoids rebuilding the entire iPXE codebase whenever switching to a different named configuration. Inspired-by: Robin Smidsrød <robin@smidsrod.no> Tested-by: Robin Smidsrød <robin@smidsrod.no> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [smc9000] Avoid using CONFIG as a preprocessor macroMichael Brown2014-08-192-6/+6
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [readline] Add CTRL-W shortcut to remove a wordMarin Hannache2014-08-191-1/+35
| | | | | | Signed-off-by: Marin Hannache <git@mareo.fr> Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [xen] Cope with unexpected initial backend statesMichael Brown2014-08-143-11/+66
| | | | | | | | | | | | | | | | | | | | | | | | | Under some circumstances (e.g. if iPXE itself is booted via iSCSI, or after an unclean reboot), the backend may not be in the expected InitWait state when iPXE starts up. There is no generic reset mechanism for Xenbus devices. Recent versions of xen-netback will gracefully perform all of the required steps if the frontend sets its state to Initialising. Older versions (such as that found in XenServer 6.2.0) require the frontend to transition through Closed before reaching Initialising. Add a reset mechanism for netfront devices which does the following: - read current backend state - if backend state is anything other than InitWait, then set the frontend state to Closed and wait for the backend to also reach Closed - set the frontend state to Initialising and wait for the backend to reach InitWait. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [xen] Use version 1 grant tables by defaultMichael Brown2014-08-135-109/+349
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Using version 1 grant tables limits guests to using 16TB of grantable RAM, and prevents the use of subpage grants. Some versions of the Xen hypervisor refuse to allow the grant table version to be set after the first grant references have been created, so the loaded operating system may be stuck with whatever choice we make here. We therefore currently use version 2 grant tables, since they give the most flexibility to the loaded OS. Current versions (7.2.0) of the Windows PV drivers have no support for version 2 grant tables, and will merrily create version 1 entries in what the hypervisor believes to be a version 2 table. This causes some confusion. Avoid this problem by attempting to use version 1 tables, since otherwise we may render Windows unable to boot. Play nicely with other potential bootloaders by accepting either version 1 or version 2 grant tables (if we are unable to set our requested version). Note that the use of version 1 tables on a 64-bit system introduces a possible failure path in which a frame number cannot fit into the 32-bit field within the v1 structure. This in turn introduces additional failure paths into netfront_transmit() and netfront_refill_rx(). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [xen] Accept alternative Xen platform PCI device ID 5853:0002Michael Brown2014-08-131-0/+1
| | | | | | | | | | | | | | | | | At some point during XenServer development history, the Windows PV drivers changed to using a PCI device ID of 5853:0002 rather than 5853:0001. Current (7.2.0) drivers will bind to either 5853:0001 or 5853:0002, and the general approach taken by the world at large (including Amazon EC2) seems to be to use only 5853:0001. However, the current version of XenServer (6.2.0) will create the platform device as 5853:0002 (via the platform:device_id VM parameter) for any VMs created using the built-in templates for Windows Vista or later. Accept either PCI ID, since the underlying device is identical. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [readline] Ensure cursor is visible when prompting for inputMichael Brown2014-08-061-0/+3
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Support displaying and hiding cursorMichael Brown2014-08-061-0/+32
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [bios] Support displaying and hiding cursorMichael Brown2014-08-062-0/+44
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Generalise snpnet_pci_info() to efi_locate_device()Michael Brown2014-08-063-34/+63
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Move abstract device path and handle functions to efi_utils.cMichael Brown2014-08-068-85/+131
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Try various possible SNP receive filtersCurtis Larsen2014-08-061-11/+37
| | | | | | | | | | | | | | | | | | | | | | | | | The behavior observed in the Apple EFI (1.10) RecieveFilters() call is: - failure if any of the PROMISCUOUS or MULTICAST filters are included - success if only UNICAST is included, however the result is UNICAST|BROADCAST - success if only UNICAST and BROADCAST are included - if UNICAST, or UNICAST|BROADCAST are used, but the previous call tried (and failed) to set UNICAST|BROADCAST|MULTICAST, then the result is UNICAST|BROADCAST|MULTICAST Work around this apparently broken SNP implementation by trying RecieveFilterMask, then falling back to UNICAST|BROADCAST|MULTICAST, then UNICAST|BROADCAST, and finally UNICAST. Modified-by: Michael Brown <mcb30@ipxe.org> Tested-by: Curtis Larsen <larsen@dixie.edu> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Open device path protocol only at point of useMichael Brown2014-08-066-52/+73
| | | | | | | | | | | | Some EFI 1.10 systems (observed on an Apple iMac) do not allow us to open the device path protocol with an attribute of EFI_OPEN_PROTOCOL_BY_DRIVER and so we cannot maintain a safe, long-lived pointer to the device path. Work around this by instead opening the device path protocol with an attribute of EFI_OPEN_PROTOCOL_GET_PROTOCOL whenever we need to use it. Debugged-by: Curtis Larsen <larsen@dixie.edu> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Provide centralised definitions of commonly-used GUIDsMichael Brown2014-08-0612-141/+119Star
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Reset multicast filter list when setting SNP receive filtersMichael Brown2014-08-051-1/+1
| | | | | | | | According to the UEFI specification, the MCastFilter parameter (which we currently pass as NULL, along with a zero MCastFilterCnt) is optional only if ResetMCastFilter is true. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add ability to dump SNP device mode informationMichael Brown2014-08-051-0/+64
| | | | | Originally-implemented-by: Curtis Larsen <larsen@dixie.edu> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Report errors from attempting to disconnect existing driversCurtis Larsen2014-08-051-1/+8
| | | | | Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Print raw device path when we have no DevicePathToTextProtocolMichael Brown2014-08-011-4/+18
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2026-03-02 01:02:26 +0100