summaryrefslogtreecommitdiffstats
path: root/src/interface
Commit message (Collapse)AuthorAgeFilesLines
* [efi] Fix incorrect debug message level when device has no device pathMichael Brown2014-07-301-2/+2
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Default to releasing network devices for use via SNPMichael Brown2014-07-302-30/+31
| | | | | | | | | | | | | | | | | | | | | | | | We currently treat network devices as available for use via the SNP API only if RX queue processing has been frozen. (This is similar in spirit to the way that RX queue processing is frozen for the network device currently exposed via the PXE API.) The default state of a freshly created network device is for the RX queue to not be frozen, and thus to be unavailable for use via SNP. This causes problems when devices are added through code paths other than _efidrv_start() (which explicitly releases devices for use via SNP). We don't actually need to freeze RX queue processing, since calls via the SNP API will always use netdev_poll() rather than net_poll(), and so will never trigger the RX queue processing code path anyway. We can therefore simplify the code to use a single global flag to indicate whether network devices are claimed for use by iPXE or available for use via SNP. Using a global flag allows the default state for dynamically created network devices to behave sensibly. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [xen] Add basic support for PV-HVM domainsMichael Brown2014-07-293-0/+1065
| | | | | | | | | 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>
* [efi] Show more diagnostic information when building with DEBUG=efi_wrapMichael Brown2014-07-262-3/+6
| | | | 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] 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-161-0/+237
| | | | | | | 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-141-13/+104
| | | | | | | | | | | | | | | | | | | 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] 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-081-0/+71
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Allow network devices to be created on top of arbitrary SNP devicesMichael Brown2014-07-034-355/+361
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Restructure EFI driver modelMichael Brown2014-06-254-453/+509
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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-251-1/+2
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Allow device paths to be easily included in debug messagesMichael Brown2014-06-251-20/+50
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Expose build timestamp, build name, and product namesMichael Brown2014-06-243-13/+12Star
| | | | | | | | 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>
* [smbios] Expose board serial number as ${board-serial}Dale Hamel2014-06-121-0/+12
| | | | | | | | 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>
* [efi] Do not try to fetch loaded image device path protocolMichael Brown2014-05-201-23/+0Star
| | | | | | | | | | | Some UEFI systems (observed with a Mac Pro) do not provide a loaded image device path protocol. We don't currently use the loaded image device path protocol for anything beyond printing a debug message, so simply remove the code which attempts to fetch it. Reported-by: Matt Woodward <pxematt@woodwardcc.com> Tested-by: Matt Woodward <pxematt@woodwardcc.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Make EFI_HII_DATABASE_PROTOCOL optionalMichael Brown2014-05-201-1/+10
| | | | | | | | | | | | Some UEFI systems (observed with a Mac Pro) do not provide EFI_HII_DATABASE_PROTOCOL. We can continue to function without providing access to network device settings via HII, so make this protocol optional and fall back to simply not providing any HII protocols. Reported-by: Matt Woodward <pxematt@woodwardcc.com> Tested-by: Matt Woodward <pxematt@woodwardcc.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Make EFI_DEVICE_PATH_TO_TEXT_PROTOCOL optionalMichael Brown2014-05-201-9/+15
| | | | | | | | | | | Some UEFI systems (observed with a Mac Pro) do not provide EFI_DEVICE_PATH_TO_TEXT_PROTOCOL. Since we use this protocol only for debug messages, make it optional and fall back to printing the raw device path bytes. Reported-by: Matt Woodward <pxematt@woodwardcc.com> Tested-by: Matt Woodward <pxematt@woodwardcc.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Allow for optional protocolsMichael Brown2014-05-191-2/+3
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Disable SNP devices when running iPXE as the applicationMichael Brown2014-03-141-7/+126
| | | | | | | | | | | | | Some UEFI builds will set up a timer to continuously poll any SNP devices. This can drain packets from the network device's receive queue before iPXE gets a chance to process them. Use netdev_rx_[un]freeze() to explicitly indicate when we expect our network devices to be driven via the external SNP API (as we do with the UNDI API on the standard BIOS build), and disable the SNP API except when receive queue processing is frozen. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Connect driver to devices as part of installationMichael Brown2014-03-121-20/+69
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Allow driver to be unloadedMichael Brown2014-03-104-4/+158
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [linux] Avoid starting currticks() from zero every timeMichael Brown2014-03-071-1/+7
| | | | | | | | | | | | | | | | | | | iPXE uses currticks() (along with the MAC address(es) of any network devices) to seed the (non-cryptographic) random number generator. The current implementation of linux_currticks() ensures that the first call to currticks() will always return zero; this results in identical random number sequences on each run of iPXE on a given machine. This can cause odd-looking behaviour due to e.g. the reuse of local TCP port numbers. Fix by effectively rounding down the start time recorded by linux_currticks() to the nearest whole second; this makes it unlikely that consecutive runs of iPXE will use the exact same RNG sequence. (Note that none of this affects the cryptographic RNG, which uses /dev/random as a source of entropy.) Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [settings] Allow for multiple definitions of each predefined settingMichael Brown2013-12-051-0/+4
| | | | | | | | | | Allow for multiple setting definitions with the same name but different scopes and tags. For example, allow for a "filename" setting with default scope and tag value 67 (for DHCPv4) and a corresponding "filename" setting with IPv6 scope and tag value 59 (for DHCPv6). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [settings] Force settings into alphabetical order within sectionsMichael Brown2013-12-051-39/+44
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [linux] Provide access to SMBIOS via /dev/memMichael Brown2013-12-052-9/+135
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [settings] Explicitly separate the concept of a completed fetched settingMichael Brown2013-12-052-6/+10
| | | | | | | | | | The fetch_setting() family of functions may currently modify the definition of the specified setting (e.g. to add missing type information). Clean up this interface by requiring callers to provide an explicit buffer to contain the completed definition of the fetched setting, if required. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [console] Pass escape sequence context to ANSI escape sequence handlersMichael Brown2013-11-271-4/+10
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [settings] Clarify usage of the term "named setting"Michael Brown2013-07-181-2/+2
| | | | | | | | | | | | There are currently two conflicting usages of the term "named setting" within iPXE: one refers to predefined settings (such as show up in the "config" UI), the other refers to settings identified by a name (such as "net0.dhcp/ip"). Split these usages into the term "predefined setting" and "named setting" to avoid ambiguity. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [cmdline] Add "poweroff" commandMarin Hannache2013-07-151-0/+17
| | | | | | Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Marin Hannache <git@mareo.fr> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [linux] Add missing #include <stddef.h>Marin Hannache2013-07-142-0/+2
| | | | | Signed-off-by: Marin Hannache <git@mareo.fr> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [linux] Add support for accessing PCI configuration space via /proc/bus/pciMichael Brown2013-07-131-0/+185
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [smbios] Allow access to multiple instances of SMBIOS structuresMichael Brown2013-05-012-4/+9
| | | | | | | | | | | | | | | | | | | | | | | Extend the syntax for numerical SMBIOS settings from smbios/<type>.<offset>.<length> to smbios/[<instance>.]<type>.<offset>.<length> Where SMBIOS provides multiple structures with the same <type>, this extended syntax allows for access to structures other than the first. If <instance> is omitted then it will default to zero, giving access to the first instance (and so matching existing behaviour). The 16-bit SMBIOS handle (which is an alternative way to disambiguate multiple instances of the same type of structure) can be accessed, if required, using smbios/<instance>.<type>.2.2:uint16 Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [smbios] Allow access to unreferenced SMBIOS stringsMichael Brown2013-05-011-4/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | iPXE allows access to general SMBIOS settings using the syntax: smbios/<type>.<offset>.<length> This provides access to any fixed-offset field within an SMBIOS structure. This syntax is currently overloaded to interpret a zero <length> as meaning that the byte at <offset> contains a string index; this provides access to SMBIOS strings (which are not located at fixed offsets). The "OEM Strings" SMBIOS structure contains strings which are not referenced by any fixed string index field within the structure. iPXE currently provides no way to access these strings. Fix by overloading the syntax for numerical SMBIOS settings to interpret an <offset> of zero as implying that <length> contains a literal string index. The OEM Strings can then be accessed using: smbios/11.0.1 smbios/11.0.2 smbios/11.0.3 ... The actual byte at offset zero will always contain the structure type, which is already known since it must be specified in order to access the structure. There is thus no plausible existing use case for an offset of zero; overloading the syntax in this way should therefore not break compatibility with any existing scripts. The corner case where both <offset> and <length> are zero is undefined (and, for now, will simply return a "not found" error). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [settings] Eliminate settings "tag magic"Michael Brown2013-05-011-21/+11Star
| | | | | | | Create an explicit concept of "settings scope" and eliminate the magic values used for numerical setting tags. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Perform meaningful error code conversionsMichael Brown2013-04-1913-137/+131Star
| | | | | | | | Exploit the redefinition of iPXE error codes to include a "platform error code" to allow for meaningful conversion of EFI_STATUS values to iPXE errors and vice versa. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Remove obsolete EFI I/O implementation using EFI_CPU_IO_PROTOCOLMichael Brown2013-04-191-218/+0Star
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Fetch device path for loaded image during initialisationMichael Brown2013-03-271-13/+37
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [cmdline] Add ability to perform a warm rebootMichael Brown2013-03-221-2/+3
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add "reboot" command for EFIMichael Brown2013-03-221-0/+43
| | | | | | | | | Abstract out the ability to reboot the system to a separate reboot() function (with platform-specific implementations), add an EFI implementation, and make the existing "reboot" command available under EFI. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Provide efi_guid_ntoa() for printing EFI GUIDsMichael Brown2013-03-203-12/+31
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [uuid] Abstract UUID mangling code out to a separate uuid_mangle() functionMichael Brown2013-03-201-4/+1Star
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [smbios] Mangle UUIDs for SMBIOS version 2.6 and newerMichael Brown2013-03-201-9/+33
| | | | | | | | | | | | | | | | iPXE treats UUIDs as being in network byte order (big-endian). The SMBIOS specification version 2.6 states that UUIDs are stored with little-endian values in the first three fields; earlier versions did not specify an endianness. This results in some inconsistency between the BIOS, vendor PXE, iPXE, and operating system interpretations of the SMBIOS UUID. dmidecode assumes that the byte order is little-endian if and only if the SMBIOS version is 2.6 or higher. Choose to match this behaviour. Reported-by: Matthew Helton <mwhelton@gmail.com> Reported-by: Alexandru Bordei <alexandru.bordei@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [smbios] Provide SMBIOS version number via smbios_version()Michael Brown2013-03-202-0/+19
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add EFI-specific debugging macrosMichael Brown2013-03-201-0/+95
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add our own EFI_LOAD_FILE_PROTOCOL implementationMichael Brown2013-03-141-1/+56
| | | | | | | | | | | | | When iPXE is used as a UEFI driver, the UEFI PXE base code currently provides the TCP/IP stack, network protocols, and user interface. This represents a substantial downgrade from the standard BIOS iPXE user experience. Fix by installing our own EFI_LOAD_FILE_PROTOCOL implementation which initiates the standard iPXE boot procedure. This upgrades the UEFI iPXE user experience to match the standard BIOS iPXE user experience. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Expose downloaded images via EFI_SIMPLE_FILE_SYSTEM_PROTOCOLMichael Brown2013-03-132-21/+607
| | | | | | | | | | | | | | | | | Expose iPXE's images as a UEFI file system, allowing the booted image to access all images downloaded by iPXE. This functionality is complementary to the custom iPXE download protocol. The iPXE download protocol allows a booted image to utilise iPXE to download arbitrary URIs, but requires the booted image to specifically support the custom iPXE download protocol. The new functionality limits the booted image to accessing only files that were already downloaded by iPXE (e.g. as part of a script), but can work with any generic UEFI image (e.g. the UEFI shell). Both protocols are provided simultaneously, and are attached to the SNP device handle. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add last_opened_snpdev()Michael Brown2013-03-131-0/+15
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Include product short name in EFI SNP device namesMichael Brown2012-11-211-3/+5
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>