summaryrefslogtreecommitdiffstats
path: root/src/core
Commit message (Collapse)AuthorAgeFilesLines
* [interface] Fix debug message values for temporary interfacesMichael Brown2023-07-042-1/+3
| | | | | | | | | | | | | | | The interface debug message values constructed by INTF_DBG() et al rely on the interface being embedded within a containing object. This assumption is not valid for the temporary outbound-only interfaces constructed on the stack by intf_shutdown() and xfer_vredirect(). Formalise the notion of a temporary outbound-only interface as having a NULL interface descriptor, and overload the "original interface descriptor" field to contain a pointer to the original interface that the temporary interface is shadowing. Originally-fixed-by: Vincent Fazio <vfazio@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [image] Generalise concept of selected imageMichael Brown2023-05-171-33/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Most image flags are independent values: any combination of flags may be set for any image, and the flags for one image are independent of the flags for any other image. The "selected" flag does not follow this pattern: at most one image may be marked as selected at any time. When invoking a kernel via the UEFI shim, there will be multiple "special" images: the selected kernel itself, the shim image, and potentially a shim-signed GRUB binary to be used as a crutch to assist shim in loading the kernel (since current versions of the UEFI shim are not capable of directly loading a Linux kernel). Remove the "selected" image flag and replace it with a general concept of an image tag with the same semantics: a given tag may be assigned to at most one image, an image may be found by its tag only while the image is currently registered, and a tag will survive unregistration and reregistration of an image (if it has not already been assigned to a new image). For visual consistency, also replace the current image pointer with a current image tag. The image pointer stored within the image tag holds only a weak reference to the image, since the selection of an image should not prevent that image from being freed. (The strong reference to the currently executing image is held locally within the execution scope of image_exec(), and is logically separate from the current image pointer.) Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [image] Always unregister currently executing imageMichael Brown2023-03-071-3/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | We unregister script images during their execution, to prevent a "boot" command from re-executing the containing script. This also has the side effect of preventing executing scripts from showing up within the Linux magic initrd image (or the Multiboot module list). Additional logic in bzimage.c and efi_file.c prevents a currently executing kernel from showing up within the magic initrd image. Similar logic in multiboot.c prevents the Multiboot kernel from showing up as a Multiboot module. This still leaves some corner cases that are not covered correctly. For example: when using a gzip-compressed kernel image, nothing will currently hide the original compressed image from the magic initrd. Fix by moving the logic that temporarily unregisters the current image from script_exec() to image_exec(), so that it applies to all image types, and simplify the magic initrd and Multiboot module list construction logic on the basis that no further filtering of the registered image list is necessary. This change has the side effect of hiding currently executing EFI images from the virtual filesystem exposed by iPXE. For example, when using iPXE to boot wimboot, the wimboot binary itself will no longer be visible within the virtual filesystem. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [image] Consistently use for_each_image() to iterate over imagesMichael Brown2023-03-061-1/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [params] Allow for arbitrary HTTP request headers to be specifiedMichael Brown2023-03-011-3/+8
| | | | | | | | | | | Extend the request parameter mechanism to allow for arbitrary HTTP headers to be specified via e.g.: params param --header Referer http://www.example.com imgfetch http://192.168.0.1/script.ipxe##params Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [params] Rename "form parameter" to "request parameter"Michael Brown2023-03-012-6/+6
| | | | | | | | Prepare for the parameter mechanism to be generalised to specifying request parameters that are passed via mechanisms other than an application/x-www-form-urlencoded form. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [image] Check delimiters when parsing command-line key-value argumentsMichael Brown2023-02-142-7/+33
| | | | | | | | | | | | | | | | The Linux kernel bzImage image format and the CPIO archive constructor will parse the image command line for certain arguments of the form "key=value". This parsing is currently implemented using strstr() in a way that can cause a false positive suffix match. For example, a command line containing "highmem=<n>" would erroneously be treated as containing a value for "mem=<n>". Fix by centralising the logic used for parsing such arguments, and including a check that the argument immediately follows a whitespace delimiter (or is at the start of the string). Reported-by: Filippo Giunchedi <filippo@esaurito.net> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [cachedhcp] Retain cached DHCPACK after startup if not already consumedMichael Brown2022-12-221-4/+22
| | | | | | | | | | | | | | We currently free an unclaimed cached DHCPACK immediately after startup, in order to free up memory. This prevents the cached DHCPACK from being applied to a device that is created after startup, such as a VLAN device created via the "vcreate" command. Retain any unclaimed DHCPACK after startup to allow it to be matched against (and applied to) any device that gets created at runtime. Free the DHCPACK during shutdown if it still remains unclaimed, in order to exit with memory cleanly freed. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [cachedhcp] Include VLAN tag in filter for applying cached DHCPACKMichael Brown2022-12-221-6/+22
| | | | | | | | | | | | | | | When chainloading iPXE from a VLAN device, the MAC address within the cached DHCPACK will match the MAC address of the trunk device created by iPXE, and the cached DHCPACK will then end up being erroneously applied to the trunk device. This tends to break outbound IPv4 routing, since both the trunk and VLAN devices will have the same assigned IPv4 address. Fix by recording the VLAN tag along with the cached DHCPACK, and treating the VLAN tag as part of the filter used to match the cached DHCPACK against candidate network devices. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [acpi] Expose system MAC address via ${sysmac} settingMichael Brown2022-06-101-0/+37
| | | | | | | | | | | | | | Expose the system MAC address (if any) via the ${sysmac} setting. This allows scripts to access the system MAC address even when iPXE has decided not to apply it to a network device (e.g. because the cached DHCPACK MAC address was selected in order to match the behaviour of a previous boot stage). The setting is named ${sysmac} rather than ${acpimac} in order to allow for forward compatibility with non-ACPI mechanisms that may exist in future for specifying a system MAC address. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [cachedhcp] Allow cached DHCPACK to override a temporary MAC addressMichael Brown2022-05-231-9/+42
| | | | | | | | | | | | | | | | | | When running on a system with an ACPI-provided system-specific MAC address, iPXE will apply this address to an ECM or NCM USB NIC. If iPXE has been chainloaded from a previous stage that does not understand the ACPI MAC mechanism then this can result in iPXE using a different MAC address than the previous stage, which is surprising to users. Attempt to minimise surprise by allowing the MAC address found in a cached DHCPACK packet to override a temporary MAC address, if the DHCPACK MAC address matches the network device's permanent MAC address. When a previous stage has chosen to use the network device's permanent MAC address (e.g. because it does not understand the ACPI MAC mechanism), this will cause iPXE to make the same choice. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [acpi] Support the "_RTXMAC_" format for ACPI-based MAC addressesMichael Brown2022-03-251-28/+125
| | | | | | | | | | | | | Some newer HP products expose the host-based MAC (HBMAC) address using an ACPI method named "RTMA" returning a part-binary string of the form "_RTXMAC_#<mac>#", where "<mac>" comprises the raw MAC address bytes. Extend the existing support to handle this format alongside the older "_AUXMAC_" format (which uses a base16-encoded MAC address). Reported-by: Andreas Hammarskjöld <junior@2PintSoftware.com> Tested-by: Andreas Hammarskjöld <junior@2PintSoftware.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [acpi] Allow for the possibility of overriding ACPI tables at link timeMichael Brown2022-03-242-3/+21
| | | | | | | Allow for linked-in code to override the mechanism used to locate an ACPI table, thereby opening up the possibility of ACPI self-tests. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [fbcon] Support Unicode character outputMichael Brown2022-03-151-0/+5
| | | | | | | Accumulate UTF-8 characters in fbcon_putchar(), and require the frame buffer console's .glyph() method to accept Unicode character values. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [utf8] Add ability to accumulate Unicode characters from UTF-8 bytesMichael Brown2022-03-011-0/+137
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [console] Support changing keyboard map at runtimeMichael Brown2022-02-162-2/+171
| | | | | | | | | | | | Provide the special keyboard map named "dynamic" which allows the active keyboard map to be selected at runtime via the ${keymap} setting, e.g.: #define KEYBOARD_MAP dynamic iPXE> set keymap uk Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [settings] Always process all settings applicatorsMichael Brown2022-02-161-7/+3Star
| | | | | | | | Settings applicators are entirely independent, and there is no reason why a failure in one applicator should prevent other applicators from being processed. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [image] Do not clear current working URI when executing embedded imageMichael Brown2022-02-161-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | Embedded images do not have an associated URI. This currently causes the current working URI (cwuri) to be cleared when starting an embedded image. If the current working URI has been set via a ${next-server} setting from a cached DHCP packet then this will result in unexpected behaviour. An attempt by the embedded script to use a relative URI to download files from the TFTP server will fail with the error: Could not start download: Operation not supported (ipxe.org/3c092083) Rerunning the "dhcp" command will not fix this error, since the TFTP settings applicator will not see any change to the ${next-server} setting and so will not reset the current working URI. Fix by setting the current working URI to the image's URI only if the image actually has an associated URI. Debugged-by: Ignat Korchagin <ignat@cloudflare.com> Originally-fixed-by: Ignat Korchagin <ignat@cloudflare.com> Tested-by: Ignat Korchagin <ignat@cloudflare.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [console] Support AltGr to access ASCII characters via remappingMichael Brown2022-02-151-1/+4
| | | | | | | | | | | | | Several keyboard layouts define ASCII characters as accessible only via the AltGr modifier. Add support for this modifier to ensure that all ASCII characters are accessible. Experiments suggest that the BIOS console is likely to fail to generate ASCII characters when the AltGr key is pressed. Work around this limitation by accepting LShift+RShift (which will definitely produce an ASCII character) as a synonym for AltGr. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [console] Centralise handling of key modifiersMichael Brown2022-02-151-6/+35
| | | | | | | Handle Ctrl and CapsLock key modifiers within key_remap(), to provide consistent behaviour across different console types. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [console] Allow for named keyboard mappingsMichael Brown2022-02-151-4/+10
| | | | | | | | Separate the concept of a keyboard mapping from a list of remapped keys, to allow for the possibility of supporting multiple keyboard mappings at runtime. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [console] Handle remapping of scancode 86Michael Brown2022-02-101-0/+3
| | | | | | | | | | | | | | | | | The key with scancode 86 appears in the position between left shift and Z on a US keyboard, where it typically fails to exist entirely. Most US keyboard maps define this nonexistent key as generating "\|", with the notable exception of "loadkeys" which instead reports it as generating "<>". Both of these mapping choices duplicate keys that exist elsewhere in the map, which causes problems for our ASCII-based remapping mechanism. Work around these quirks by treating the key as generating "\|" with the high bit set, and making it subject to remapping. Where the BIOS generates "\|" as expected, this allows us to remap to the correct ASCII value. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [console] Generalise bios_keymap() as key_remap()Michael Brown2022-02-101-0/+52
| | | | | | | Allow the keyboard remapping functionality to be exposed to consoles other than the BIOS console. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [uri] Allow for relative URIs that include colons within the pathMichael Brown2022-01-131-5/+10
| | | | | | | | | | | | | | | | RFC3986 allows for colons to appear within the path component of a relative URI, but iPXE will currently parse such URIs incorrectly by interpreting the text before the colon as the URI scheme. Fix by checking for valid characters when identifying the URI scheme. Deliberately deviate from the RFC3986 definition of valid characters by accepting "_" (which was incorrectly used in the iPXE-specific "ib_srp" URI scheme and so must be accepted for compatibility with existing deployments), and by omitting the code to check for characters that are not used in any URI scheme supported by iPXE. Reported-by: Ignat Korchagin <ignat@cloudflare.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Include Secure Boot Advanced Targeting (SBAT) metadataMichael Brown2022-01-131-0/+30
| | | | | | | | | | | | | | | | | SBAT defines an encoding for security generation numbers stored as a CSV file within a special ".sbat" section in the signed binary. If a Secure Boot exploit is discovered then the generation number will be incremented alongside the corresponding fix. Platforms may then record the minimum generation number required for any given product. This allows for an efficient revocation mechanism that consumes minimal flash storage space (in contrast to the DBX mechanism, which allows for only a single-digit number of revocation events to ever take place across all possible signed binaries). Add SBAT metadata to iPXE EFI binaries to support this mechanism. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [settings] Support formatting UUIDs as little-endian GUIDsMichael Brown2022-01-041-5/+18
| | | | | | | | | | | | | | | | | | The RFC4122 specification defines UUIDs as being in network byte order, but an unfortunately significant amount of (mostly Microsoft) software treats them as having the first three fields in little-endian byte order. In an ideal world, any server-side software that compares UUIDs for equality would perform an endian-insensitive comparison (analogous to comparing strings for equality using a case-insensitive comparison), and would therefore not care about byte order differences. Define a setting type name ":guid" to allow a UUID setting to be formatted in little-endian order, to simplify interoperability with server-side software that expects such a formatting. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [uri] Retain original encodings for path, query, and fragment fieldsMichael Brown2021-11-121-51/+80
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | iPXE decodes any percent-encoded characters during the URI parsing stage, thereby allowing protocol implementations to consume the raw field values directly without further decoding. When reconstructing a URI string for use in an HTTP request line, the percent-encoding is currently reapplied in a reversible way: we guarantee that our reconstructed URI string could be decoded to give the same raw field values. This technically violates RFC3986, which states that "URIs that differ in the replacement of a reserved character with its corresponding percent-encoded octet are not equivalent". Experiments show that several HTTP server applications will attach meaning to the choice of whether or not a particular character was percent-encoded, even when the percent-encoding is unnecessary from the perspective of parsing the URI into its component fields. Fix by storing the originally encoded substrings for the path, query, and fragment fields and using these original encoded versions when reconstructing a URI string. The path field is also stored as a decoded string, for use by protocols such as TFTP that communicate using raw strings rather than URI-encoded strings. All other fields (such as the username and password) continue to be stored only in their decoded versions since nothing ever needs to know the originally encoded versions of these fields. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [acpi] Allow for extraction of a MAC address from the DSDT/SSDTMichael Brown2021-09-091-0/+154
| | | | | | | | | | | | | | | | Some vendors provide a "system MAC address" within the DSDT/SSDT, to be used to override the MAC address for a USB docking station. A full implementation would require an ACPI bytecode interpreter, since at least one OEM allows the MAC address to be constructed by executable ACPI bytecode (rather than a fixed data structure). We instead attempt to extract a plausible-looking "_AUXMAC_#.....#" string that appears shortly after an "AMAC" or "MACA" signature. This should work for most implementations encountered in practice. Debugged-by: Andreas Hammarskjöld <junior@2PintSoftware.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [acpi] Generalise DSDT/SSDT data extraction logicMichael Brown2021-09-081-64/+30Star
| | | | | | | Allow for the DSDT/SSDT signature-scanning and value extraction code to be reused for extracting a pass-through MAC address. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Record cached ProxyDHCPOFFER and PXEBSACK, if presentMichael Brown2021-07-271-45/+130
| | | | | | | | | | | | | | | | | | | Commit cd3de55 ("[efi] Record cached DHCPACK from loaded image's device handle, if present") added the ability for a chainloaded UEFI iPXE to reuse an IPv4 address and DHCP options previously obtained by a built-in PXE stack, without needing to perform a second DHCP request. Extend this to also record the cached ProxyDHCPOFFER and PXEBSACK obtained from the EFI_PXE_BASE_CODE_PROTOCOL instance installed on the loaded image's device handle, if present. This allows a chainloaded UEFI iPXE to reuse a boot filename or other options that were provided via a ProxyDHCP or PXE boot server mechanism, rather than by standard DHCP. Tested-by: Andreas Hammarskjöld <junior@2PintSoftware.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [uri] Make URI schemes case-insensitiveMichael Brown2021-07-011-1/+2
| | | | | | | | | | | RFC 3986 section 3.1 defines URI schemes as case-insensitive (though the canonical form is always lowercase). Use strcasecmp() rather than strcmp() to allow for case insensitivity in URI schemes. Requested-by: Andreas Hammarskjöld <junior@2PintSoftware.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [libc] Match standard prototype for putchar()Michael Brown2021-06-071-1/+4
| | | | | Reported-by: Bernhard M. Wiedemann <bwiedemann@suse.de> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [base64] Include terminating NUL within base64 character arrayMichael Brown2021-06-071-1/+1
| | | | | Reported-by: Bernhard M. Wiedemann <bwiedemann@suse.de> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [cpio] Split out bzImage initrd CPIO header constructionMichael Brown2021-05-211-0/+85
| | | | | | | | | | | | iPXE will construct CPIO headers for images that have a non-empty command line, thereby allowing raw images (without CPIO headers) to be injected into a dynamically constructed initrd. This feature is currently implemented within the BIOS-only bzImage format support. Split out the CPIO header construction logic to allow for reuse in other contexts such as in a UEFI build. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [libc] Add strncasecmp()Michael Brown2021-05-181-1/+16
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [image] Propagate trust flag to extracted archive imagesMichael Brown2021-05-121-0/+4
| | | | | | | | An extracted image is wholly derived from the original archive image. If the original archive image has been verified and marked as trusted, then this trust logically extends to any image extracted from it. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [image] Allow single-member archive images to be executed transparentlyMichael Brown2021-05-121-0/+30
| | | | | | | | Provide image_extract_exec() as a helper method to allow single-member archive images (such as gzip compressed images) to be executed without an explicit "imgextract" step. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [image] Add "imgextract" command for extracting archive imagesMichael Brown2021-05-081-0/+104
| | | | | | | | Add the concept of extracting an image from an archive (which could be a single-file archive such as a gzip-compressed file), along with an "imgextract" command to expose this functionality to scripts. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [image] Provide image_set_len() utility functionMichael Brown2021-05-081-4/+21
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [acpi] Allow for platforms that provide ACPI tables individuallyMichael Brown2021-03-012-3/+3
| | | | | | | | | | | | | | | | The ACPI API currently expects platforms to provide access to a single contiguous ACPI table. Some platforms (e.g. Linux userspace) do not provide a convenient way to obtain the entire ACPI table, but do provide access to individual tables. All iPXE consumers of the ACPI API require access only to individual tables. Redefine the internal API to make acpi_find() an API method, with all existing implementations delegating to the current RSDT-based implementation. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [acpi] Eliminate redundant acpi_find_rsdt() in acpi_sx()Michael Brown2021-03-011-10/+2Star
| | | | | | | | The result from acpi_find_rsdt() is used only for the debug message. Simplify the debug message and remove the otherwise redundant call to acpi_find_rsdt(). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [acpi] Use a fixed colour for debug messagesMichael Brown2021-03-011-9/+12
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pxe] Split out platform-independent portions of cachedhcp.cMichael Brown2021-02-171-0/+158
| | | | | | | | | Split out the portions of cachedhcp.c that can be shared between BIOS and UEFI (both of which can provide a buffer containing a previously obtained DHCP packet, and neither of which provide a means to determine the length of this DHCP packet). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [image] Provide image_memory()Michael Brown2021-01-251-0/+44
| | | | | | | Consolidate the remaining logic common to initrd_init() and imgmem() into a shared image_memory() function. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [image] Provide image_set_data()Michael Brown2021-01-221-0/+24
| | | | | | | Extract part of the logic in initrd_init() to a standalone function image_set_data(). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [interface] Provide intf_insert() to insert a filter interfaceMichael Brown2020-12-072-3/+18
| | | | | | | | Generalise the filter interface insertion logic from block_translate() and expose as intf_insert(), allowing a filter interface to be inserted on any existing interface. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [interface] Ignore any attempts to plug in the null interfaceMichael Brown2020-12-071-0/+5
| | | | | | | Allow intf_plug() and intf_plug_plug() to be called safely on interfaces that may be the null interface. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dma] Provide dma_umalloc() for allocating large DMA-coherent buffersMichael Brown2020-11-291-0/+39
| | | | | | | | | | | | | | Some devices (e.g. xHCI USB host controllers) may require the use of large areas of host memory for private use by the device. These allocations cannot be satisfied from iPXE's limited heap space, and so are currently allocated using umalloc() which will allocate external system memory (and alter the system memory map as needed). Provide dma_umalloc() to provide such allocations as part of the DMA API, since there is otherwise no way to guarantee that the allocated regions are usable for coherent DMA. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dma] Move I/O buffer DMA operations to iobuf.hMichael Brown2020-11-282-41/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Include a potential DMA mapping within the definition of an I/O buffer, and move all I/O buffer DMA mapping functions from dma.h to iobuf.h. This avoids the need for drivers to maintain a separate list of DMA mappings for each I/O buffer that they may handle. Network device drivers typically do not keep track of transmit I/O buffers, since the network device core already maintains a transmit queue. Drivers will typically call netdev_tx_complete_next() to complete a transmission without first obtaining the relevant I/O buffer pointer (and will rely on the network device core automatically cancelling any pending transmissions when the device is closed). To allow this driver design approach to be retained, update the netdev_tx_complete() family of functions to automatically perform the DMA unmapping operation if required. For symmetry, also update the netdev_rx() family of functions to behave the same way. As a further convenience for drivers, allow the network device core to automatically perform DMA mapping on the transmit datapath before calling the driver's transmit() method. This avoids the need to introduce a mapping error handling code path into the typically error-free transmit methods. With these changes, the modifications required to update a typical network device driver to use the new DMA API are fairly minimal: - Allocate and free descriptor rings and similar coherent structures using dma_alloc()/dma_free() rather than malloc_phys()/free_phys() - Allocate and free receive buffers using alloc_rx_iob()/free_rx_iob() rather than alloc_iob()/free_iob() - Calculate DMA addresses using dma() or iob_dma() rather than virt_to_bus() - Set a 64-bit DMA mask if needed using dma_set_mask_64bit() and thereafter eliminate checks on DMA address ranges - Either record the DMA device in netdev->dma, or call iob_map_tx() as part of the transmit() method - Ensure that debug messages use virt_to_phys() when displaying "hardware" addresses Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dma] Record DMA device as part of DMA mapping if neededMichael Brown2020-11-281-26/+26
| | | | | | | Allow for dma_unmap() to be called by code other than the DMA device driver itself. Signed-off-by: Michael Brown <mcb30@ipxe.org>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2026-07-30 09:47:50 +0200