summaryrefslogtreecommitdiffstats
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
* [xen] Add basic support for PV-HVM domainsMichael Brown2014-07-2918-0/+2272
| | | | | | | | | Add basic support for Xen PV-HVM domains (detected via the Xen platform PCI device with IDs 5853:0001), including support for accessing configuration via XenStore and enumerating devices via XenBus. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [xen] Import selected public headersMichael Brown2014-07-2919-0/+5650
| | | | | | | | | | | | Import selected headers from the xen/include/public directory of the Xen repository at git://xenbits.xen.org/xen.git The script ./include/xen/import.pl can be used to automatically import any required headers and their dependencies (in a similar fashion to ./include/ipxe/efi/import.pl). Trailing whitespace is stripped and an appropriate FILE_LICENCE declaration is added to each header file. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [lotest] Discard packets arriving on the incorrect network deviceMichael Brown2014-07-291-6/+6
| | | | | | | | | | | | | Commit 24bbaf6 ("[lotest] Allow loopback testing on shared networks") introduced a regression in which loopback testing packets would be accepted from any network device. This produces unexpected results, such as VLAN loopback testing succeeding even when incorrectly using the underlying trunk device as either transmitter or receiver. Fix by discarding any loopback testing packets which arrive on a network device other than the current loopback testing receiver. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ioapi] Centralise notion of PAGE_SIZEMichael Brown2014-07-283-3/+9
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Set GITVERSION only if there is a git repositoryFlorian Schmaus2014-07-281-1/+1
| | | | | | | | | | | | | | | The $(BIN)/version.%.o target will fail if iPXE is built within a non-git repository, e.g. when the user downloaded and extracted an archive containing iPXE sources, *and* if any parent directory of the iPXE sources is a git repository (or even contains a directory named ".git"). This is because git will by default ascend the directory tree and look for ".git". The problem typically manifests on source based distributions, see for example https://bugs.gentoo.org/show_bug.cgi?id=482804 Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Show more diagnostic information when building with DEBUG=efi_wrapMichael Brown2014-07-262-3/+6
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [lacp] Set "aggregatable" flag in response LACPDUSven Ulland2014-07-231-1/+2
| | | | | | | | | | | | | Some switches do not allow an individual link (as defined in IEEE Std 802.3ad-2000 section 43.3.5) to work alone in a link aggregation group as described in section 43.3.6. This is verified on Dell's PowerConnect M6220, based on the Broadcom Strata XGS-IV chipset. Set the LACP_STATE_AGGREGATABLE flag in the actor.state field to announce link aggregation in the response LACPDU, which will have the switch enable the link aggregation group and allow frames to pass. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [x86_64] Add functions to read and write model-specific registersMichael Brown2014-07-231-0/+43
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [i386] Add functions to read and write model-specific registersMichael Brown2014-07-231-0/+38
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [natsemi] Check for ioremap() failuresMichael Brown2014-07-161-0/+5
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [myson] Check for ioremap() failuresMichael Brown2014-07-161-0/+5
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [skel] Check for ioremap() failuresMichael Brown2014-07-161-0/+5
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [vmxnet3] Check for ioremap() failuresMichael Brown2014-07-161-0/+10
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [realtek] Check for ioremap() failuresMichael Brown2014-07-161-0/+5
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Check for ioremap() failuresMichael Brown2014-07-162-0/+10
| | | | | Debugged-by: Anton D. Kachalov <mouse@yandex-team.ru> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ioapi] Fail ioremap() when attempting to map a zero bus addressMichael Brown2014-07-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | When a 32-bit iPXE binary is running on a system which allocates PCI memory BARs above 4GB, our PCI subsystem will return the base address for any such BARs as zero (with a warning message if DEBUG=pci is enabled). Currently, ioremap() will happily map an address pointing to the start of physical memory, providing no sensible indication of failure. Fix by always returning NULL if we are asked to ioremap() a zero bus address. With a totally flat memory model (e.g. under EFI), this provides an accurate failure indication since no PCI peripheral will be mapped to the zero bus address. With the librm memory model, there is the possibility of a spurious NULL return from ioremap() if the bus address happens to be equal to virt_offset. Under the current virtual memory map, the NULL virtual address will always be the start of .textdata, and so this problem cannot occur; a NULL return from ioremap() will always be an accurate failure indication. Debugged-by: Anton D. Kachalov <mouse@yandex-team.ru> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Use EFI_CONSOLE_CONTROL_PROTOCOL to set text mode if availableCurtis Larsen2014-07-161-0/+34
| | | | | | | | | On some older EFI 1.10 implementations (observed with an old iMac), we must use the (now obsolete) EFI_CONSOLE_CONTROL_PROTOCOL to switch the console into text mode. Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Include EFI_CONSOLE_CONTROL_PROTOCOL headerMichael Brown2014-07-162-1/+125
| | | | | | | | | | | | The EFI_CONSOLE_CONTROL_PROTOCOL does not exist in the current UEFI specification, but is required to enable text output on some older EFI 1.10 implementations (observed on an old iMac). The header is not present in any of the standard include directories, but can still be found in the EDK2 codebase as part of EdkCompatibilityPkg. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Print well-known GUIDs by name in debug messagesMichael Brown2014-07-161-0/+32
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Allow for interception of boot services calls by loaded imageMichael Brown2014-07-163-0/+257
| | | | | | | When building with DEBUG=efi_wrap, print details of calls made by the loaded image to selected boot services functions. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Install our own disk I/O protocol and claim exclusive use of itMichael Brown2014-07-142-13/+223
| | | | | | | | | | | | | | | | | | | The EFI FAT filesystem driver has a bug: if a block device contains no FAT filesystem but does have an EFI_SIMPLE_FILE_SYSTEM_PROTOCOL instance, the FAT driver will assume that it must have previously installed the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL. This causes the FAT driver to claim control of our device, and to refuse to stop driving it, which prevents us from later uninstalling correctly. Work around this bug by opening the disk I/O protocol ourselves, thereby preventing the FAT driver from opening it. Note that the alternative approach of opening the block I/O protocol (and thereby in theory preventing DiskIo from attaching to the block I/O protocol) causes an endless loop of calls to our DRIVER_STOP method when starting the EFI shell. I have no idea why this is. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Update EDK2 headersMichael Brown2014-07-1420-96/+533
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [netdevice] Reset network device index when last device is unregisteredMichael Brown2014-07-141-2/+8
| | | | | | | | | | | | | | When functioning as an EFI driver, drivers can be disconnected and reconnected multiple times (e.g. via the EFI shell "connect" command, or by running an executable such as ipxe.efi which will temporarily disconnect existing drivers). Minimise surprise by resetting the network device index to zero whenever the last device is unregistered. This is not foolproof, but it does handle the common case of having all devices unregistered and then reregistered in the original order. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Fix debug messageMichael Brown2014-07-121-1/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Add support for iPAddress subject alternative namesMichael Brown2014-07-113-40/+105
| | | | | Originally-implemented-by: Jarrod Johnson <jarrod.b.johnson@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Include SNP NIC driver within the all-drivers targetMichael Brown2014-07-081-0/+4
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Rewrite SNP NIC driverMichael Brown2014-07-085-510/+418Star
| | | | | | | | | Rewrite the SNP NIC driver to use non-blocking and deferrable transmissions, to provide link status detection, to provide information about the underlying (PCI) hardware device, and to avoid unnecessary I/O buffer allocations during receive polling. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Attempt to start only drivers claiming support for a deviceMichael Brown2014-07-081-0/+7
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Identify autoboot device by MAC address when chainloadingMichael Brown2014-07-083-0/+89
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [autoboot] Allow autoboot device to be identified by link-layer addressMichael Brown2014-07-083-15/+65
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Allow network devices to be created on top of arbitrary SNP devicesMichael Brown2014-07-0311-397/+643
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Add yet another potential location for isolinux.binMichael Brown2014-06-261-1/+2
| | | | | Reported-by: Martin Sofaru <ipxe@fhloston.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Fix erroneous object name in version objectMichael Brown2014-06-261-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 8290a95 ("[build] Expose build timestamp, build name, and product names") introduced a regression in the build process which resulted in broken final binaries which had names based on object files (e.g. "undionly.kpxe" or "intel.rom") rather than on device IDs (e.g. "8086100e.mrom"). The underlying problem is the -DOBJECT=<name> macro which is used to generate the obj_<name> symbols used to select objects required for the final binary. The macro definition is derived from the initial portion (up to the first dot) of the object being built. In the case of e.g. undionly.kpxe.version.o, this gives -DOBJECT=undionly. This results in undionly.kpxe.version.o claiming to be the "undionly" object; the real "undionly" object will therefore never get dragged in to the build. Fix by renaming $(BIN)/%.version.o to $(BIN)/version.%.o, so that the object is always built with -DOBJECT=version (as might be expected, since it is built from core/version.c). Final binaries which have names based on device IDs (such as "8086100e.mrom") are not affected by this problem, since the object name "8086100e" will not conflict with that of the underlying "intel" object. This problem was not detected by the per-commit smoke testing procedure, which happens to use the binary bin/8086100e.mrom. Reported-by: Christian Hesse <list@eworm.de> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Restructure EFI driver modelMichael Brown2014-06-257-486/+582
| | | | | | | | | | | | | | | | | | | | | | | | | | | Provide a single instance of EFI_DRIVER_BINDING_PROTOCOL (attached to our image handle); this matches the expectations scattered throughout the EFI specification. Open the underlying hardware device using EFI_OPEN_PROTOCOL_BY_DRIVER and EFI_OPEN_PROTOCOL_EXCLUSIVE, to prevent other drivers from attaching to the same device. Do not automatically connect to devices when being loaded as a driver; leave this task to the platform firmware (or to the user, if loading directly from the EFI shell). When running as an application, forcibly disconnect any existing drivers from devices that we want to control, and reconnect them on exit. Provide a meaningful driver version number (based on the build timestamp), to allow platform firmware to automatically load newer versions of iPXE drivers if multiple drivers are present. Include device paths within debug messages where possible, to aid in debugging. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Provide a meaningful EFI SNP device nameMichael Brown2014-06-252-2/+3
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Allow device paths to be easily included in debug messagesMichael Brown2014-06-252-36/+52
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Expose build timestamp, build name, and product namesMichael Brown2014-06-2410-37/+101
| | | | | | | | Expose the build timestamp (measured in seconds since the Epoch) and the build name (e.g. "rtl8139.rom" or "ipxe.efi"), and provide the product name and product short name in a single centralised location. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [debug] Allow debug message colours to be customised via DBGCOL=...Michael Brown2014-06-162-3/+39
| | | | | | | | | | | | | | | | | | When multiple iPXE binaries are running concurrently (e.g. in the case of undionly.kpxe using an underlying iPXE driver via the UNDI interface) it would be helpful to be able to visually distinguish debug messages from each binary. Allow the range of debug colours used to be customised via the DBGCOL=... build parameter. For example: # Restrict to colours 31-33 (red, green, yellow) make DBGCOL=31-33 # Restrict to colours 34-36 (blue, magenta, cyan) make DBGCOL=34-36 Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Check if git index actually existsPeter Lemenkov2014-06-161-0/+2
| | | | | | | | | If iPXE is used as a git submodule then the ../.git/index file will not exist, and the build will fail. Fix by checking that the git index file exists before adding it as a build dependency. Signed-off-by: Peter Lemenkov <lemenkov@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [smbios] Expose board serial number as ${board-serial}Dale Hamel2014-06-122-0/+29
| | | | | | | | With blade servers, the chassis serial number (exposed via ${serial}) may not be unique. Expose ${board-serial} as a named setting to provide easy access to a more meaningful serial number. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [igbvf] Allow changing of MAC addressHannes Reinecke2014-06-121-0/+4
| | | | | | | | | The VF might not have assigned a MAC address upon startup, and will end up with a random MAC address during probe(). With this patch the MAC address can be changed later on. Signed-off-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [igbvf] Assign random MAC address if none is setHannes Reinecke2014-06-121-10/+4Star
| | | | | | | | | If the VF doesn't have a MAC address assigned we should create a random MAC address. Signed-off-by: Hannes Reinecke <hare@suse.de> Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [iscsi] Include IP address origin in iBFTMichael Brown2014-06-122-0/+15
| | | | | | | | | | | The iBFT includes an "origin" field to indicate the source of the IP address. We use the heuristic of assuming that the source should be "manual" if the IP address originates directly from the network device settings block, and "DHCP" otherwise. This is an imperfect guess, but is likely to be correct in most common situations. Originally-implemented-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [iscsi] Read IPv4 settings only from the relevant network deviceMichael Brown2014-06-121-9/+14
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [scsi] Improve sense code parsingMichael Brown2014-06-035-19/+93
| | | | | | | | Parse the sense data to extract the reponse code, the sense key, the additional sense code, and the additional sense code qualifier. Originally-implemented-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ethernet] Provide eth_random_addr() to generate random Ethernet addressesHannes Reinecke2014-06-022-0/+17
| | | | | Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ifmgmt] Do not sleep CPU while configuring network devicesMichael Brown2014-06-011-4/+0Star
| | | | | | | | | | | | | | | | | | | | | | | | | iPXE currently calls cpu_nap() while performing DHCP, in order to reduce CPU utilisation on virtual machines. Under mild broadcast load (~100 packets per second), this can cause received packets to be dropped because the receive descriptor ring is overrun before the next 18Hz timer interrupt wakes up the CPU. The result is that DHCP is likely to intermittently fail on networks with appreciable amounts of broadcast (or multicast) traffic. This behaviour was introduced in the series of commits which generalised the "dhcp" command to the "ifconf" command. The earlier code (which did not handle IPv6 configuration) had no call to cpu_nap() and so did not suffer from this problem. Fix by removing the call to cpu_nap() in ifpoller_progress(). This has the undesirable side effect that CPU utilisation will remain at 100% while waiting for DHCP to complete (which can take several seconds, if we have to wait around for potential ProxyDHCP offers to arrive). Reported-by: Alex Davies <adavies@jumptrading.com> Reported-by: Christoffer Stokbæk <christoffers@easyspeedy.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [librm] Allow for the PIC interrupt vector offset to be changedMichael Brown2014-05-271-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | Some external code (observed with FreeBSD's bootloader) will continue to make INT 13 calls after reconfiguring the 8259 PIC to change the vector offsets for IRQs. If an IRQ (e.g. the timer IRQ) subsequently occurs while iPXE is in protected mode, this will cause a general protection fault since the corresponding IDT entry is empty. A general protection fault is INT 0x0d, which happens to overlap with the original IRQ5. We therefore do have an ISR set up to handle a general protection fault, but this ISR simply reflects the interrupt down to the real-mode INT 0x0d and then attempts to return. Since our ISR is expecting a hardware interrupt rather than a general protection fault, it doesn't remove the error code from the stack before issuing the iret instruction; it therefore attempts to return to a garbage address. Since the segment part of this address is likely to be invalid, a second general protection fault occurs. This cycle continues until we run out of stack space and triple fault. Fix by reflecting all INTs down to real mode. This actually reduces the code size by four bytes (but increases the bss size by almost 2kB). Reported-by: Brian Rak <dn@devicenull.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ipv6] Avoid potentially copying from a NULL pointer in ipv6_tx()Michael Brown2014-05-231-1/+2
| | | | | | | | | | | | | If ipv6_tx() is called with a non-NULL network device, a NULL or unspecified source address, and a destination address which does not match any routing table entry, then it will attempt to copy the source address from a NULL pointer. I don't think that there is currently any code path which could trigger this behaviour, but we should probably ensure that it can never happen. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ipv6] Include network device when transcribing multicast addressesMichael Brown2014-05-231-1/+1
| | | | | | | Destination multicast addresses require a sin6_scope_id, which should therefore be transcribed to a network device name by ipv6_sock_ntoa(). Signed-off-by: Michael Brown <mcb30@ipxe.org>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2024-07-24 01:15:12 +0200