summaryrefslogtreecommitdiffstats
path: root/src/interface/efi
Commit message (Collapse)AuthorAgeFilesLines
...
* [efi] Provide guaranteed space in transmitted packetsMichael Brown2012-09-141-6/+7
| | | | | | | | | | | | | eIPoIB requires space to expand a transmitted ARP packet. This guarantee is met by ensuring that a transmitted packet consists of at least MAX_LL_HEADER_LEN bytes from the start of the I/O buffer up to the end of the link-layer header, and at least IOB_ZLEN bytes thereafter. Adjust the I/O buffer allocation for SNP transmitted packets to ensure that this guarantee is met. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ipoib] Expose Ethernet-compatible eIPoIB link-layer addresses and headersMichael Brown2012-08-311-1/+2
| | | | | | | | | | | | | Almost all clients of the raw-packet interfaces (UNDI and SNP) can handle only Ethernet link layers. Expose an Ethernet-compatible link layer to local clients, while remaining compatible with IPoIB on the wire. This requires manipulation of ARP (but not DHCP) packets within the IPoIB driver. This is ugly, but it's the only viable way to allow IPoIB devices to be driven via the raw-packet interfaces. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [legal] Update FSF mailing address in GPL licence textsMichael Brown2012-07-2013-13/+26
| | | | | Suggested-by: Daniel P. Berrange <berrange@redhat.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Work around platforms which choke on EFI_PCI_DEVICE_ENABLEMichael Brown2012-05-161-10/+12
| | | | | | | | | | | | | | | | | | | | | | | | | EFI_PCI_DEVICE_ENABLE is a list of the standard attributes that must be enabled for a PCI device to function: I/O cycles, memory cycles, and bus-mastering. We currently call EFI_PCI_IO_PROTOCOL::Attribute() with the parameter EFI_PCI_DEVICE_ENABLE to enable a PCI device. This should translate to a single write to PCI configuration space. Simplicity is not a virtue within the UEFI world. Some platforms will 'helpfully' report an error if EFI_PCI_DEVICE_ENABLE is used on a device that doesn't actually support all three of the relevant attributes. For example, if a PCI device provides only memory-mapped accesses (and so hardwires the I/O enable bit to zero), then using EFI_PCI_DEVICE_ENABLE on such a platform will result in an EFI_UNSUPPORTED error. There is no plausible use case in which it is useful for the platform to return an error in this way, and doing so makes it impossible to distinguish genuine errors from noise. Work around this broken behaviour by attempting to enable the three attributes individually, and ignoring any errors. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Update link state in SNP device mode dataMichael Brown2012-04-191-2/+15
| | | | | | | | | | | There is no explicit SNP API call to determine link state; the SNP interface user may check the MediaPresent field within the mode data at any time. Update the MediaPresent field whenever the link state changes. Reported-by: Michael R Turner <mikeyt@us.ibm.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [console] Remove "log message" usage from interactive console defaultsMichael Brown2012-03-271-1/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [console] Allow usage to be defined independently for each consoleMichael Brown2012-03-261-0/+8
| | | | | | | | | | | | | | | | | | | | | Add the concept of a "console usage", such as "standard output" or "debug messages". Allow usages to be associated with each console independently. For example, to send debugging output via the serial port, while preventing it from appearing on the local console: #define CONSOLE_SERIAL CONSOLE_USAGE_ALL #define CONSOLE_PCBIOS ( CONSOLE_USAGE_ALL & ~CONSOLE_USAGE_DEBUG ) If no usages are explicitly specified, then a default set of usages will be applied. For example: #define CONSOLE_SERIAL will have the same affect as #define CONSOLE_SERIAL CONSOLE_USAGE_ALL Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add iPXE download protocolJarrod Johnson2012-02-151-0/+233
| | | | | | | | | | | | | iPXE exposes some extended capabilities via the PXE FILE API to allow NBPs such as pxelinux to use protocols other than TFTP. Provide an equivalent interface as a UEFI protocol so that EFI binaries may also take advantage of iPXE's extended capabilities. This can be used with a patched version of elilo, for example: http://comments.gmane.org/gmane.comp.boot-loaders.elilo.general/147 Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [netdevice] Allow link layer to report broadcast/multicast packets via pull()Michael Brown2011-07-151-1/+3
| | | | | | | | Allow the link layer to directly report whether or not a packet is multicast or broadcast at the time of calling pull(), rather than relying on heuristics to determine this at a later stage. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [bofm] Pass BOFM version 2 table to SetStatus() if applicableMichael Brown2011-05-051-10/+29
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [bofm] Increase amount of debugging availableMichael Brown2011-05-051-32/+48
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Ensure that each HII package list and formset has a unique GUIDMichael Brown2011-05-031-3/+6
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add support for HIIMichael Brown2011-04-081-0/+374
| | | | | | | Some EFI platforms expect us to provide an HII interface to display information about the driver. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add EFI string formatting functionsMichael Brown2011-04-083-15/+156
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [bofm] Use BOFM protocol version 2 if availableMichael Brown2011-03-301-17/+62
| | | | | | | | | The original EFI BOFM protocol has a design flaw that limits the size of the table to 1kB, since the table is embedded within the IBM_BOFM_DRIVER_CONFIGURATION_PROTOCOL structure. Version 2 of the protocol works around this problem. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Ensure that all drivers are shut down before the OS bootsMichael Brown2011-03-292-2/+51
| | | | | | Reported-by: Itay Gazit <itayg@mellanox.co.il> Suggested-by: Michael R Turner <mikeyt@us.ibm.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Mark SNP devices as children of EFI PCI deviceMichael Brown2011-03-152-0/+64
| | | | | | | | | | | | | Re-open the EFI_PCI_IO_PROTOCOL specifying an Attributes value of EFI_OPEN_PROTOCOL_BY_CHILD_CONTROLLER. This causes the SNP devices to be marked as children of the EFI PCI device (as shown in the "devtree" command). On at least one IBM blade system, this is required in order to have the relevant drivers automatically attach to the SNP controller at device creation time. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [console] Move include/console.h to include/ipxe/console.hMichael Brown2011-03-091-1/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [bofm] Add support for BOFM under EFIMichael Brown2011-03-031-0/+322
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Allow EFI to control PCI bus enumerationMichael Brown2011-02-173-285/+593
| | | | | | | | | | | | | | EFI performs its own PCI bus enumeration. Respect this, and start controlling devices only when instructed to do so by EFI. As a side benefit, we should now correctly create multiple SNP instances for multi-port devices. This should also fix the problem of failing to enumerate devices because the PCI bridges have not yet been enabled at the time the iPXE driver is loaded. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Replace pci_max_bus() with pci_num_bus()Michael Brown2011-02-171-1/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Use single "busdevfn" field in struct pci_deviceMichael Brown2011-02-172-11/+10Star
| | | | | | | Merge the "bus" and "devfn" fields into a single "busdevfn" field, to match the format used by the majority of external code. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Always allow MAX_LL_HEADER_LEN for the link-layer headerMichael Brown2010-11-191-1/+4
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ioapi] Move get_memmap() to the I/O API groupPiotr Jaroszyński2010-08-161-0/+12
| | | | | | | | | pcbios specific get_memmap() is used by the b44 driver making all-drivers builds fail on other platforms. Move it to the I/O API group and provide a dummy implementation on EFI. Signed-off-by: Piotr Jaroszyński <p.jaroszynski@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add the "snpnet" driverGeoff Lywood2010-06-021-1/+22
| | | | | | | | | Add a new network driver that consumes the EFI Simple Network Protocol. Also add a bus driver that can find the Simple Network Protocol that iPXE was loaded from; the resulting behavior is similar to the "undionly" driver for BIOS systems. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Update UEFI header files with latest version from TianoCoreGeoff Lywood2010-05-301-1/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Rename gPXE to iPXEMichael Brown2010-04-2010-44/+44
| | | | | | | | | | | Access to the gpxe.org and etherboot.org domains and associated resources has been revoked by the registrant of the domain. Work around this problem by renaming project from gPXE to iPXE, and updating URLs to match. Also update README, LOG and COPYRIGHTS to remove obsolete information. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [netdevice] Add netdev_is_open() wrapper functionMichael Brown2010-03-231-2/+2
| | | | Signed-off-by: Michael Brown <mcb30@etherboot.org>
* [netdevice] Allow the hardware and link-layer addresses to differ in sizeMichael Brown2009-08-121-4/+5
| | | | | | | | | | IPoIB has a 20-byte link-layer address, of which only eight bytes represent anything relating to a "hardware address". The PXE and EFI SNP APIs expect the permanent address to be the same size as the link-layer address, so fill in the "permanent address" field with the initial link layer address (as generated by register_netdev() based upon the real hardware address).
* [netdevice] Separate out the concept of hardware and link-layer addressesMichael Brown2009-08-121-1/+1
| | | | | | | | | | | The hardware address is an intrinsic property of the hardware, while the link-layer address can be changed at runtime. This separation is exposed via APIs such as PXE and EFI, but is currently elided by gPXE. Expose the hardware and link-layer addresses as separate properties within a net device. Drivers should now fill in hw_addr, which will be used to initialise ll_addr at the time of calling register_netdev().
* [netdevice] Make ll_broadcast per-netdevice rather than per-ll_protocolMichael Brown2009-07-181-2/+1Star
| | | | | | | | | IPoIB has a link-layer broadcast address that varies according to the partition key. We currently go through several contortions to pretend that the link-layer address is a fixed constant; by making the broadcast address a property of the network device rather than the link-layer protocol it will be possible to simplify IPoIB's broadcast handling.
* [netdevice] Add netdev argument to link-layer push and pull handlersJoshua Oreman2009-06-231-3/+4
| | | | | | | | | | | | | | | In order to construct outgoing link-layer frames or parse incoming ones properly, some protocols (such as 802.11) need more state than is available in the existing variables passed to the link-layer protocol handlers. To remedy this, add struct net_device *netdev as the first argument to each of these functions, so that more information can be fetched from the link layer-private part of the network device. Updated all three call sites (netdevice.c, efi_snp.c, pxe_undi.c) and both implementations (ethernet.c, ipoib.c) of ll_protocol to use the new argument. Signed-off-by: Michael Brown <mcb30@etherboot.org>
* [legal] Add a selection of FILE_LICENCE declarationsMichael Brown2009-05-1810-0/+20
| | | | | Add FILE_LICENCE declarations to almost all files that make up the various standard builds of gPXE.
* [tables] Redefine methods for accessing linker tablesMichael Brown2009-03-131-14/+2Star
| | | | | | | | | | | | | | | Intel's C compiler (icc) chokes on the zero-length arrays that we currently use as part of the mechanism for accessing linker table entries. Abstract away the zero-length arrays, to make a port to icc easier. Introduce macros such as for_each_table_entry() to simplify the common case of iterating over all entries in a linker table. Represent table names as #defined string constants rather than unquoted literals; this avoids visual confusion between table names and C variable or type names, and also allows us to force a compilation error in the event of incorrect table names.
* [iobuf] Add iob_disown() and use it where it simplifies codeMichael Brown2009-02-011-2/+1Star
| | | | | | | | | | | | | | | | | | | | | | | | | There are many functions that take ownership of the I/O buffer they are passed as a parameter. The caller should not retain a pointer to the I/O buffer. Use iob_disown() to automatically nullify the caller's pointer, e.g.: xfer_deliver_iob ( xfer, iob_disown ( iobuf ) ); This will ensure that iobuf is set to NULL for any code after the call to xfer_deliver_iob(). iob_disown() is currently used only in places where it simplifies the code, by avoiding an extra line explicitly setting the I/O buffer pointer to NULL. It should ideally be used with each call to any function that takes ownership of an I/O buffer. (The SSA optimisations will ensure that use of iob_disown() gets optimised away in cases where the caller makes no further use of the I/O buffer pointer anyway.) If gcc ever introduces an __attribute__((free)), indicating that use of a function argument after a function call should generate a warning, then we should use this to identify all applicable function call sites, and add iob_disown() as necessary.
* [efi] Expose both GUIDs for the EFI_NETWORK_INTERFACE_IDENTIFIER_PROTOCOLMichael Brown2009-01-121-7/+12
| | | | | | | At some point, it seems that someone decided to change the GUID for the EFI_NETWORK_INTERFACE_IDENTIFIER_PROTOCOL. Current EFI builds ignore the older GUID, older EFI builds ignore the newer GUID, so we have to expose both.
* [efi] Add an EFI_NETWORK_INTERFACE_IDENTIFIER_PROTOCOL interfaceMichael Brown2009-01-121-0/+24
| | | | | This allegedly optional interface seems to be compulsory if you want EFI's PXE code to bother trying to use your network interface.
* [efi] Provide component name protocol and device path protocol interfacesMichael Brown2009-01-121-22/+151
| | | | | | | | | | | | | | Include a minimal component name protocol so that the driver name shows up as something other than "<UNKNOWN>" in the driver list, and a device path protocol so that the network interface shows up as a separate device in the device list, rather than being attached directly to the PCI device. Incidentally, the EFI component name protocol reaches new depths for signal-to-noise ratio in program code. A typical instance within the EFI development kit will use an additional 300 lines of code to provide slightly less functionality than GNU gettext achieves with three additional characters.
* [efi] Use elf2efi utility in place of efilinkMichael Brown2009-01-071-6/+4Star
| | | | | | | | | | | elf2efi converts a suitable ELF executable (containing relocation information, and with appropriate virtual addresses) into an EFI executable. It is less tightly coupled with the gPXE build process and, in particular, does not require the use of a hand-crafted PE image header in efiprefix.S. elf2efi correctly handles .bss sections, which significantly reduces the size of the gPXE EFI executable.
* [efi] Use EFI-native mechanism for accessing SMBIOS tableMichael Brown2008-12-051-0/+62
| | | | | | EFI provides a copy of the SMBIOS table accessible via the EFI system table, which we should use instead of manually scanning through the F000:0000 segment.
* [efi] Allow use of EFI configuration tablesMichael Brown2008-12-051-4/+45
| | | | | | | EFI passes in copies of SMBIOS and other system configuration tables via the EFI system table. Allow configuration tables to be requested using a mechanism similar to the current method for requesting EFI protocols.
* [x86_64] Fix assorted 64-bit compilation errors and warningsMichael Brown2008-11-191-18/+25
| | | | | | Remove various 32-bit assumptions scattered throughout the codebase. The code is still not necessarily 64-bit clean, but will at least compile.
* [efi] Add efi_strerror()Michael Brown2008-11-197-25/+73
| | | | | | | | | EFI_STATUS is defined as an INTN, which maps to UINT32 (i.e. unsigned int) on i386 and UINT64 (i.e. unsigned long) on x86_64. This would require a cast each time the error status is printed. Add efi_strerror() to avoid this ickiness and simultaneously enable prettier reporting of EFI status codes.
* [i386] Change [u]int32_t to [unsigned] int, rather than [unsigned] longMichael Brown2008-11-196-27/+27
| | | | | | This brings us in to line with Linux definitions, and also simplifies adding x86_64 support since both platforms have 2-byte shorts, 4-byte ints and 8-byte long longs.
* [netdevice] Retain and report detailed error breakdownsMichael Brown2008-11-081-10/+12
| | | | | | | | | | netdev_rx_err() and netdev_tx_complete_err() get passed the error code, but currently use it only in debug messages. Retain error numbers and frequencey counts for up to NETDEV_MAX_UNIQUE_ERRORS (4) different errors for each of TX and RX. This allows the "ifstat" command to report the reasons for TX/RX errors in most cases, even in non-debug builds.
* [efi] Add basic implementation of EFI SIMPLE_NETWORK_PROTOCOLMichael Brown2008-10-161-0/+978
| | | | | This implementation is tested and working, but not currently tied in to the EFI build.
* [efi] Add EFI image format and basic runtime environmentMichael Brown2008-10-137-0/+886
We have EFI APIs for CPU I/O, PCI I/O, timers, console I/O, user access and user memory allocation. EFI executables are created using the vanilla GNU toolchain, with the EXE header handcrafted in assembly and relocations generated by a custom efilink utility.