[smbios] Mangle UUIDs for SMBIOS version 2.6 and newer
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>
[efi] Add our own EFI_LOAD_FILE_PROTOCOL implementation
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_PROTOCOL
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] Delegate to child device's EFI_COMPONENT_NAME2_PROTOCOL, if present
EFI's device naming model requires drivers to provide names for child
devices. Allow the driver's GetControllerName() method to delegate to
an instance of EFI_COMPONENT_NAME2_PROTOCOL installed on the child
device itself (if present); this allows the SNP device to expose its
own device name via the PCI driver's GetControllerName() method.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[efi] Provide guaranteed space in transmitted packets
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 headers
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>
[efi] Work around platforms which choke on EFI_PCI_DEVICE_ENABLE
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>
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] Allow usage to be defined independently for each console
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>
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()
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] Report {slot,port} to {bus:dev.fn,mport} mapping on newer BOFM builds
Newer BOFM builds provide support for mapping multiple physical ports
to a single PCI bus:dev.fn via PCI VPD descriptions. These builds
will also leave the {slot,port} field intact, and will populate the
mport field with a meaningful value.
Older BOFM builds will zero out the {slot,port} field. A zero value
in this field may indicate either a genuine zero value (i.e. slot 0
first port) or an older build.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
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>
[linux] Make malloc and linux_umalloc valgrindable
Make the allocators used by malloc and linux_umalloc valgrindable.
Include valgrind headers in the codebase to avoid a build dependency
on valgrind.
Signed-off-by: Piotr Jaroszyński <p.jaroszynski@gmail.com>
Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Improve the appearance of the "config" user interface by ensuring that
settings appear in some kind of logical order.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[settings] Formalise notion of setting applicability
Expose a function setting_applies() to allow a caller to determine
whether or not a particular setting is applicable to a particular
settings block.
Restrict DHCP-backed settings blocks to accepting only DHCP-based
settings.
Restrict network device settings blocks to accepting only DHCP-based
settings and network device-specific settings such as "mac".
Inspired-by: Glenn Brown <glenn@myri.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[efi] Mark SNP devices as children of EFI PCI device
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>
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] Use single "busdevfn" field in struct pci_device
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>
[settings] Apply settings block name in register_settings()
Pass the settings block name as a parameter to register_settings(),
rather than defining it with settings_init() (and then possibly
changing it by directly manipulating settings->name).
Signed-off-by: Michael Brown <mcb30@ipxe.org>
There exists an smbios userspace library so implementing this is
probably possible, but doesn't seem really important to have in
userspace. Hence provide a dummy implementation returning an error.
Signed-off-by: Piotr Jaroszyński <p.jaroszynski@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Michael Brown