summaryrefslogtreecommitdiffstats
path: root/src/drivers/bus
Commit message (Collapse)AuthorAgeFilesLines
* [build] Mark known reviewed files as permitted for UEFI Secure BootMichael Brown2026-01-146-0/+6
| | | | | | | | | Some past security reviews carried out for UEFI Secure Boot signing submissions have covered specific drivers or functional areas of iPXE. Mark all of the files comprising these areas as permitted for UEFI Secure Boot. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Mark core files as permitted for UEFI Secure BootMichael Brown2026-01-142-0/+2
| | | | | | | | | | | | Mark all files used in a standard build of bin-x86_64-efi/snponly.efi as permitted for UEFI Secure Boot. These files represent the core functionality of iPXE that is guaranteed to have been included in every binary that was previously subject to a security review and signed by Microsoft. It is therefore legitimate to assume that at least these files have already been reviewed to the required standard multiple times. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Allow probing permission to vary by rangeMichael Brown2025-11-252-5/+17
| | | | | | | Make pci_can_probe() part of the runtime selectable PCI I/O API, and defer this check to the per-range API. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Use linker tables for runtime selectable PCI APIsMichael Brown2025-11-242-2/+258
| | | | | | | Use the linker table mechanism to enumerate the underlying PCI I/O APIs, to allow PCIAPI_CLOUD to become architecture-independent code. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Disable decoding while setting a BAR valueMichael Brown2025-10-301-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Setting the base address for a 64-bit BAR requires two separate 32-bit writes to configuration space, and so will necessarily result in the BAR temporarily holding an invalid partially written address. Some hypervisors (observed on an AWS EC2 c7a.medium instance in eu-west-2) will assume that guests will write BAR values only while decoding is disabled, and may not rebuild MMIO mappings for the guest if the BAR registers are written while decoding is enabled. The effect of this is that MMIO accesses are not routed through to the device even though inspection from within the guest shows that every single PCI configuration register has the correct value. Writes to the device will be ignored, and reads will return the all-ones pattern that typically indicates a nonexistent device. With the ENA network driver now using low latency transmit queues, this results in the transmit descriptors being lost (since the MMIO writes to BAR2 never reach the device), which in turn causes the device to lock up as soon as the transmit doorbell is rung for the first time. Fix by disabling decoding of memory and I/O cycles while setting a BAR address (as we already do while sizing a BAR), so that the invalid partial address can never be decoded and so that hypervisors will rebuild MMIO mappings as expected. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Record prefetchable memory window for PCI bridgesMichael Brown2025-10-141-5/+23
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Handle sizing of 64-bit BARsMichael Brown2025-10-142-36/+76
| | | | | | | | Provide pci_bar_set() to handle setting the base address for a potentially 64-bit BAR, and rewrite pci_bar_size() to correctly handle sizing of 64-bit BARs. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Map all MSI-X interrupts to a dummy target address by defaultMichael Brown2025-10-091-0/+52
| | | | | | | | | | | | | | | | | | | | | | | Interrupts as such are not used in iPXE, which operates in polling mode. However, some network cards (such as the Intel 40GbE and 100GbE NICs) will defer writing out completions until the point of asserting an MSI-X interrupt. From the point of view of the PCI device, asserting an MSI-X interrupt is just a 32-bit DMA write of an opaque value to an opaque target address. The PCI device has no know to know whether or not the target address corresponds to a real APIC. We can therefore trick the PCI device into believing that it is asserting an MSI-X interrupt, by configuring it to write an opaque 32-bit value to a dummy target address in host memory. This is sufficient to trigger the associated write of the completions to host memory. Allocate a dummy target address when enabling MSI-X on a PCI device, and map all interrupts to this target address by default. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [fdt] Provide fdt_reg() for unsized single-entry regionsMichael Brown2025-08-071-7/+3Star
| | | | | | | | Many region types (e.g. I2C bus addresses) can only ever contain a single region with no size cells specified. Provide fdt_reg() to reduce boilerplate in this common use case. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dwgpio] Add driver for the DesignWare GPIO controllerMichael Brown2025-08-051-5/+2Star
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [fdt] Use phandle as device locationMichael Brown2025-08-041-0/+1
| | | | | | | | | | | | | Consumption of phandles will be in the form of locating a functional device (e.g. a GPIO device, or an I2C device, or a reset controller) by phandle, rather than locating the device tree node to which the phandle refers. Repurpose fdt_phandle() to obtain the phandle value (instead of searching by phandle), and record this value as the bus location within the generic device structure. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [init] Show initialisation function names in debug messagesMichael Brown2025-07-152-0/+2
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dt] Allow for creation of standalone devicesMichael Brown2025-06-111-59/+52Star
| | | | | | | | | | | | | | | | | We will want to be able to create the console device as early as possible. Refactor devicetree probing to remove the assumption that a devicetree device must have a devicetree parent, and expose functions to allow a standalone device to be created given only the offset of a node within the tree. The full device path is no longer trivial to construct with this assumption removed. The full path is currently used only for debug messages. Remove the stored full path, use just the node name for debug messages, and ensure that the topology information previously visible in the full path is reconstructible from the combined debug output if needed. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dt] Locate parent node at point of use in dt_ioremap()Michael Brown2025-05-301-9/+15
| | | | | | | | | | | | We currently rely on the recursive nature of devicetree bus probing to obtain the region cell size specification from the parent device. This blocks the possibility of creating a standalone console device based on /chosen/stdout-path before probing the whole bus. Fix by using fdt_parent() to locate the parent device at the point of use within dt_ioremap(). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [fdt] Generalise access to "reg" propertyMichael Brown2025-05-091-16/+7Star
| | | | | | | | | | The "reg" property is also used by non-device nodes, such as the nodes describing the system memory map. Provide generalised functionality for parsing the "#address-cells", "#size-cells", and "reg" properties. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [uaccess] Reduce scope of included uaccess.h headerMichael Brown2025-04-301-1/+0Star
| | | | | | | | | The uaccess.h header is no longer required for any code that touches external ("user") memory, since such memory accesses are now performed through pointer dereferences. Reduce the number of files including this header. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [uaccess] Remove redundant copy_from_user() and copy_to_user()Michael Brown2025-04-304-0/+4
| | | | | | | Remove the now-redundant copy_from_user() and copy_to_user() wrapper functions. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [acpi] Remove userptr_t from ACPI table parsingMichael Brown2025-04-221-20/+14Star
| | | | | | | Simplify the ACPI table parsing code by assuming that all table content is fully accessible via pointer dereferences. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dt] Provide dt_ioremap() to map device registersMichael Brown2025-04-151-0/+75
| | | | | | | | | | | | | Devicetree devices encode register address ranges within the "reg" property, with the number of cells used for addresses and for sizes determined by the #address-cells and #size-cells properties of the immediate parent device. Record the number of address and size cells for each device, and provide a dt_ioremap() function to allow drivers to map a specified range without having to directly handle the "reg" property. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dt] Add basic concept of a devicetree busMichael Brown2025-04-141-0/+297
| | | | | | | | Add a basic model for devices instantiated by parsing the system flattened device tree, with drivers matched via the "compatible" property for any non-root node. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Drag in PCI settings mechanism only when PCI support is presentMichael Brown2024-10-251-0/+6
| | | | | | | Allow for the existence of platforms with no PCI bus by including the PCI settings mechanism only if PCI bus support is included. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Expose USB device descriptor and strings via settingsMichael Brown2024-10-182-5/+179
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Allow scripts to read basic information from USB device descriptors via the settings mechanism. For example: echo USB vendor ID: ${usb/${busloc}.8.2} echo USB device ID: ${usb/${busloc}.10.2} echo USB manufacturer name: ${usb/${busloc}.14.0} The general syntax is usb/<bus:dev>.<offset>.<length> where bus:dev is the USB bus:device address (as obtained via the "usbscan" command, or from e.g. ${net0/busloc} for a USB network device), and <offset> and <length> select the required portion of the USB device descriptor. Following the usage of SMBIOS settings tags, a <length> of zero may be used to indicate that the byte at <offset> contains a USB string descriptor index, and an <offset> of zero may be used to indicate that the <length> contains a literal USB string descriptor index. Since the byte at offset zero can never contain a string index, and a literal string index can never be zero, the combination of both <length> and <offset> being zero may be used to indicate that the entire device descriptor is to be read as a raw hex dump. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Add "usbscan" command for iterating over USB devicesMichael Brown2024-10-171-2/+73
| | | | | | | | Implement a "usbscan" command as a direct analogy of the existing "pciscan" command, allowing scripts to iterate over all detected USB devices. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Separate permission to probe buses from bus:dev.fn range discoveryMichael Brown2024-08-152-0/+5
| | | | | | | | | | | | | | | | | The UEFI device model requires us to not probe the PCI bus directly, but instead to wait to be offered the opportunity to drive devices via our driver service binding handle. We currently inhibit PCI bus probing by having pci_discover() return an empty range when using the EFI PCI I/O API. This has the unwanted side effect that scanning the bus manually using the "pciscan" command will also fail to discover any devices. Separate out the concept of being allowed to probe PCI buses from the mechanism for discovering PCI bus:dev.fn address ranges, so that this limitation may be removed. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Check that ECAM configuration space is within reachable memoryMichael Brown2023-11-021-0/+9
| | | | | | | | | | | | | | | | | Some machines (observed with an AWS EC2 m7a.large instance) will place the ECAM configuration space window above 4GB, thereby making it unreachable from non-paged 32-bit code. This problem is currently ignored by iPXE, since the address is silently truncated in the call to ioremap(). (Note that other uses of ioremap() are not affected since the PCI core will already have checked for unreachable 64-bit BARs when retrieving the physical address to be mapped.) Fix by adding an explicit check that the region to be mapped starts within the reachable memory address space. (Assume that no machines will be sufficiently peverse to provide a region that straddles the 4GB boundary.) Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Cache ECAM mapping errorsMichael Brown2023-11-021-2/+4
| | | | | | | | | When an error occurs during ECAM configuration space mapping, preserve the error within the existing cached mapping (instead of invalidating the cached mapping) in order to avoid flooding the debug log with repeated identical mapping errors. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Handle non-zero starting bus in ECAM allocationsMichael Brown2023-11-021-0/+1
| | | | | | | | | | | | | The base address provided in the PCI ECAM allocation within the ACPI MCFG table is the base address for the segment as a whole, not for the starting bus within that allocation. On machines that provide ECAM allocations with a non-zero starting bus number (observed with an AWS EC2 m7a.large instance), this will result in iPXE accessing the wrong memory addresses within the ECAM region. Fix by adding the appropriate starting bus offset to the base address. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Force completion of ECAM configuration space writesMichael Brown2023-11-011-1/+10
| | | | | | | | | | | | | | | | | | | | | The PCIe specification requires that "processor and host bridge implementations must ensure that a method exists for the software to determine when the write using the ECAM is completed by the completer" but does not specify any particular method to be used. Some platforms might treat writes to the ECAM region as non-posted, others might require reading back from a dedicated (and implementation-specific) completion register to determine when the configuration space write has completed. Since PCI configuration space writes will never be used for any performance-critical datapath operations (on any sane hardware), a simple and platform-independent solution is to always read back from the written register in order to guarantee that the write must have completed. This is safe to do, since the PCIe specification defines a limited set of configuration register types, none of which have read side effects. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [virtio] Fix implementation of vpm_ioread32()Alexander Eichner2023-08-221-2/+2
| | | | | | | | | | | The current implementation of vpm_ioread32() erroneously reads only 16 bits of data, which fails when used with the (stricter) virtio device emulation in VirtualBox. Fix by using the correct readl()/inl() I/O wrappers. Reworded-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [eisa] Check for system board presence before probing for slotsMichael Brown2023-02-111-0/+8
| | | | | | | | | | | | | | | EISA expansion slot I/O port addresses overlap space that may be assigned to PCI devices, which can lead to register reads and writes with unwanted side effects during EISA probing. Reduce the chances of performing EISA probing on PCI devices by probing EISA slot vendor and product ID registers only if the EISA system board vendor ID register indicates that the motherboard supports EISA. Debugged-by: Václav Ovsík <vaclav.ovsik@gmail.com> Tested-by: Václav Ovsík <vaclav.ovsik@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Do not attempt to drive PCI bridge devicesMichael Brown2023-02-031-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | The "bridge" driver introduced in 3aa6b79 ("[pci] Add minimal PCI bridge driver") is required only for BIOS builds using the ENA driver, where experimentation shows that we cannot rely on the BIOS to fully assign MMIO addresses. Since the driver is a valid PCI driver, it will end up binding to all PCI bridge devices even on a UEFI platform, where the firmware is likely to have completed MMIO address assignment correctly. This has no impact on most systems since there is generally no UEFI driver for PCI bridges: the enumeration of the whole PCI bus is handled by the PciBusDxe driver bound to the root bridge. Experimentation shows that at least one laptop will freeze at the point that iPXE attempts to bind to the bridge device. No deeper investigation has been carried out to find the root cause. Fix by causing efipci_supported() to return an error unless the configuration space header type indicates a non-bridge device. Reported-by: Marcel Petersen <mp@sbe.de> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Backup and restore standard config space across PCIe FLRMichael Brown2022-11-131-2/+7
| | | | | | | | | | | | | | The behaviour of PCI devices across a function-level reset seems to be inconsistent in practice: some devices will preserve PCI BARs, some will not. Fix the behaviour of FLR on devices that do not preserve PCI BARs by backing up and restoring PCI configuration space across the reset. Preserve only the standard portion of the configuration space, since there may be registers with unexpected side effects in the remaining non-standardised space. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Allow PCI config space backup to be limited by maximum offsetMichael Brown2022-11-131-4/+6
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Add minimal PCI bridge driverMichael Brown2022-09-191-0/+132
| | | | | | | Add a minimal driver for PCI bridges that can be used to locate the bridge to which a PCI device is attached. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Select PCI I/O API at runtime for cloud imagesMichael Brown2022-09-181-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pretty much all physical machines and off-the-shelf virtual machines will provide a functional PCI BIOS. We therefore default to using only the PCI BIOS, with no fallback to an alternative mechanism if the PCI BIOS fails. AWS EC2 provides the opportunity to experience some exceptions to this rule. For example, the t3a.nano instances in eu-west-1 have no functional PCI BIOS at all. As of commit 83516ba ("[cloud] Use PCIAPI_DIRECT for cloud images") we therefore use direct Type 1 configuration space accesses in the images built and published for use in the cloud. Recent experience has discovered yet more variation in AWS EC2 instances. For example, some of the metal instance types have multiple PCI host bridges and the direct Type 1 accesses therefore see only a subset of the PCI devices. Attempt to accommodate future such variations by making the PCI I/O API selectable at runtime and choosing ECAM (if available), falling back to the PCI BIOS (if available), then finally falling back to direct Type 1 accesses. This is implemented as a dedicated PCIAPI_CLOUD API, rather than by having the PCI core select a suitable API at runtime (as was done for timers in commit 302f1ee ("[time] Allow timer to be selected at runtime"). The common case will remain that only the PCI BIOS API is required, and we would prefer to retain the optimisations that come from inlining the configuration space accesses in this common case. Cloud images are (at present) disk images rather than ROM images, and so the increased code size required for this design approach in the PCIAPI_CLOUD case is acceptable. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Add support for the Enhanced Configuration Access Mechanism (ECAM)Michael Brown2022-09-161-0/+265
| | | | | | | | | | | | | The ACPI MCFG table describes a direct mapping of PCI configuration space into MMIO space. This mapping allows access to extended configuration space (up to 4096 bytes) and also provides for the existence of multiple host bridges. Add support for the ECAM mechanism described by the ACPI MCFG table, as a selectable PCI I/O API alongside the existing PCI BIOS and Type 1 mechanisms. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Generalise pci_num_bus() to pci_discover()Michael Brown2022-09-151-13/+21
| | | | | | | | | | Allow pci_find_next() to discover devices beyond the first PCI segment, by generalising pci_num_bus() (which implicitly assumes that there is only a single PCI segment) with pci_discover() (which has the ability to return an arbitrary contiguous chunk of PCI bus:dev.fn address space). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Check for wraparound in callers of pci_find_next()Michael Brown2022-09-151-3/+3
| | | | | | | | | | | | | | | | The semantics of the bus:dev.fn parameter passed to pci_find_next() are "find the first existent PCI device at this address or higher", with the caller expected to increment the address between finding devices. This does not allow the parameter to distinguish between the two cases "start from address zero" and "wrapped after incrementing maximal possible address", which could therefore lead to an infinite loop in the degenerate case that a device with address ffff:ff:1f.7 really exists. Fix by checking for wraparound in the caller (which is already responsible for performing the increment). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Allow pci_find_next() to return non-zero PCI segmentsMichael Brown2022-09-151-8/+8
| | | | | | | | Separate the return status code from the returned PCI bus:dev.fn address, in order to allow pci_find_next() to be used to find devices with a non-zero PCI segment number. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Generalise function-level reset mechanismMichael Brown2022-08-081-0/+22
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Ensure that pci_read_config() initialises all fieldsMichael Brown2022-02-161-0/+5
| | | | | | | | | | | | | | | | | | As per the general pattern for initialisation functions in iPXE, pci_init() saves code size by assuming that the caller has already zeroed the underlying storage (e.g. as part of zeroing a larger containing structure). There are several places within the code where pci_init() is deliberately used to initialise a transient struct pci_device without zeroing the entire structure, because the calling code knows that only the PCI bus:dev.fn address is required to be initialised (e.g. when reading from PCI configuration space). Ensure that using pci_init() followed by pci_read_config() will fully initialise the struct pci_device even if the caller did not previously zero the underlying storage, since Coverity reports that there are several places in the code that rely upon this. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [virtio] Update driver to use DMA APIAaron Young2021-10-282-17/+32
| | | | Signed-off-by: Aaron Young <aaron.young@oracle.com>
* [pci] Avoid scanning nonexistent buses when using PCIAPI_DIRECTMichael Brown2021-04-101-2/+25
| | | | | | | | | | | | | | There is no method for obtaining the number of PCI buses when using PCIAPI_DIRECT, and we therefore currently scan all possible bus numbers. This can cause a several-second startup delay in some virtualised environments, since PCI configuration space access will necessarily require the involvement of the hypervisor. Ameliorate this situation by defaulting to scanning only a single bus, and expanding the number of PCI buses to accommodate any subordinate buses that are detected during enumeration. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Inhibit spurious array bounds warning on some versions of gccMichael Brown2021-01-151-1/+1
| | | | | | | | | | | | Some versions of gcc (observed with gcc 9.3.0 on NixOS Linux) produce a spurious warning about an out-of-bounds array access for the isa_extra_probe_addrs[] array. Work around this compiler bug by redefining the array index as a signed long, which seems to somehow avoid this spurious warning. Debugged-by: Manuel Mendez <mmendez534@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [isa] Add missing #include <config/isa.h>Manuel Mendez2021-01-141-0/+1
| | | | | | Signed-off-by: Manuel Mendez <mmendez534@gmail.com> Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Avoid dragging in USB subsystem via efi_usb_path()Michael Brown2020-10-301-17/+0Star
| | | | | | | | | | | | Commit 87e39a9c9 ("[efi] Split efi_usb_path() out to a separate function") unintentionally introduced an undefined symbol reference from efi_path.o to usb_depth(), causing the USB subsystem to become a dependency of all EFI builds. Fix by converting usb_depth() to a static inline function. Reported-by: Pico Mitchell <pico@randomapplications.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Allow endpoints to be refilled to a specified upper limitMichael Brown2020-10-121-3/+16
| | | | | | | | | | | | For USB mass storage devices, we do not want to submit more bulk IN packets than are required for the inbound data, since this will waste memory. Allow an upper limit to be specified on each refill attempt. The endpoint will be refilled to the lower of this limit or the limit specified by usb_refill_init(). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Allow device halt to be cleared independently of host controllerMichael Brown2020-10-121-14/+31
| | | | | | | | | | | | | | | | | | Closing and reopening a USB endpoint will clear any halt status recorded by the host controller, but may leave the endpoint halted at the device. This will cause the first packet submitted to the reopened endpoint to be lost, before the automatic stall recovery mechanism detects the halt and resets the endpoint. This is relatively harmless for USB network or HID devices, since the wire protocols will recover gracefully from dropped packets. Some protocols (e.g. for USB mass storage devices) assume zero packet loss and so would be adversely affected. Fix by allowing any device endpoint halt status to be cleared on a freshly opened endpoint. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Avoid integer underflow on malformed string descriptorsMichael Brown2020-10-021-1/+8
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Show debug message on device removalMichael Brown2020-09-291-0/+5
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2026-03-05 00:53:34 +0100