summaryrefslogtreecommitdiffstats
path: root/src/config/defaults
Commit message (Collapse)AuthorAgeFilesLines
* [build] Canonicalise console type configurationMichael Brown2026-01-164-5/+0Star
| | | | | | | | | Move all console configuration from config/defaults/<platform>.h to the top-level config/console.h, using indented conditional blocks to clarify which console types are supported and enabled on each platform. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Canonicalise USB configurationMichael Brown2026-01-162-12/+0Star
| | | | | | | | Move all USB configuration from config/defaults/<platform>.h to the top-level config/usb.h, using indented conditional blocks to clarify which options are supported and enabled on each platform. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Canonicalise settings sources configurationMichael Brown2026-01-161-2/+0Star
| | | | | | | | Move all settings source selection from config/defaults/<platform>.h to the top-level config/settings.h, using indented conditional blocks to clarify which sources are supported and enabled on each platform. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Canonicalise remaining portions of general configurationMichael Brown2026-01-162-5/+0Star
| | | | | | | | Move remaining general configuration from config/defaults/<platform>.h to the top-level config/general.h, using indented conditional blocks to clarify which features are supported and enabled on each platform. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Canonicalise SAN boot protocol configurationMichael Brown2026-01-163-18/+0Star
| | | | | | | | Move all SAN boot protocol selection from config/defaults/<platform>.h to the top-level config/general.h, using indented conditional blocks to clarify which protocols are supported and enabled on each platform. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Canonicalise download protocol configurationMichael Brown2026-01-161-2/+0Star
| | | | | | | | Move all download protocol selection from config/defaults/<platform>.h to the top-level config/general.h, using indented conditional blocks to clarify which protocols are supported and enabled on each platform. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Canonicalise network protocol configurationMichael Brown2026-01-161-3/+0Star
| | | | | | | | Move all network protocol selection from config/defaults/<platform>.h to the top-level config/general.h, using indented conditional blocks to clarify which protocols are supported and enabled on each platform. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Canonicalise command list configurationMichael Brown2026-01-164-17/+7Star
| | | | | | | | Move all command selection from config/defaults/<platform>.h to the top-level config/general.h, using indented conditional blocks to clarify which commands are supported and enabled on each platform. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Canonicalise image type configurationMichael Brown2026-01-154-17/+0Star
| | | | | | | | Move all image type selection from config/defaults/<platform>.h to the top-level config/general.h, using indented conditional blocks to clarify which image types are supported and enabled on each platform. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Mark core files as permitted for UEFI Secure BootMichael Brown2026-01-141-0/+1
| | | | | | | | | | | | 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>
* [spcr] Use the serial port defined by the ACPI SPCR by defaultMichael Brown2025-11-052-2/+2
| | | | | | | | On platforms where we expect ACPI tables to exist, use the serial port defined by the ACPI Serial Port Console Redirection (SPCR) table by default, falling back to the fixed serial port defined at build time. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [riscv] Provide a DMA API implementation for RISC-V bare-metal systemsMichael Brown2025-07-091-1/+2
| | | | | | | | | Provide an implementation of dma_map() that performs cache clean or invalidation as required, and an implementation of dma_alloc() that returns virtual addresses within the coherent mapping of the 32-bit physical address space. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [fdtcon] Add basic support for FDT-based system serial consoleMichael Brown2025-06-241-1/+2
| | | | | | | | Add support for probing a device based on the path or alias found in the "/chosen/stdout-path" node, and using a consequently instantiated UART as the default serial console. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [serial] Allow platform to specify mechanism for identifying consoleMichael Brown2025-06-234-0/+4
| | | | | | | | | Allow the platform configuration to provide a mechanism for identifying the serial console UART. Provide two globally available mechanisms: "null" (i.e. no serial console), and "fixed" (i.e. use whatever is specified by COMCONSOLE in config/serial.h). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [riscv] Support mapping I/O devices outside of the identity mapMichael Brown2025-05-261-1/+6
| | | | | | | | | | | | | | With the 64-bit paging schemes (Sv39, Sv48, and Sv57), we identity-map as much of the physical address space as is possible. Experimentation shows that this is not sufficient to provide access to all I/O devices. For example: the Sipeed Lichee Pi 4A includes a CPU that supports only Sv39, but places I/O devices at the top of a 40-bit address space. Add support for creating I/O page table entries on demand to map I/O devices, based on the existing design used for x86_64 BIOS. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [lkrn] Add basic support for the RISC-V Linux kernel image formatMichael Brown2025-05-201-0/+2
| | | | | | | | | | | | | | | | | | | | | | The RISC-V and AArch64 bare-metal kernel images share a common header format, and require essentially the same execution environment: loaded close to the start of RAM, entered with paging disabled, and passed a pointer to a flattened device tree that describes the hardware and any boot arguments. Implement basic support for executing bare-metal RISC-V and AArch64 kernel images. The (trivial) AArch64-specific code path is untested since we do not yet have the ability to build for any bare-metal AArch64 platforms. Constructing and passing an initramfs image is not yet supported. Rename the IMAGE_BZIMAGE build configuration option to IMAGE_LKRN, since "bzImage" is specific to x86. To retain backwards compatibility with existing local build configurations, we leave IMAGE_BZIMAGE as the enabled option in config/default/pcbios.h and treat IMAGE_LKRN as a synonym for IMAGE_BZIMAGE when building for x86 BIOS. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [bios] Use generic external heap based on the system memory mapMichael Brown2025-05-191-1/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [riscv] Use generic external heap based on the system memory mapMichael Brown2025-05-191-1/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [bios] Update to use the generic system memory map APIMichael Brown2025-05-161-1/+1
| | | | | | | | Provide an implementation of the system memory map API based on the assorted BIOS INT 15 calls, and a temporary implementation of the legacy get_memmap() function using the new API. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [fdtmem] Update to use the generic system memory map APIMichael Brown2025-05-161-1/+1
| | | | | | | | | Provide an implementation of the system memory map API based on the system device tree, excluding any memory outside the size of the accessible physical address space and defining an in-use region to cover the relocated copy of iPXE and the system device tree. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [memmap] Define an API for managing the system memory mapMichael Brown2025-05-164-0/+4
| | | | | | | | | Define a generic system memory map API, based on the abstraction created for parsing the FDT memory map and adding a concept of hidden in-use memory regions as required to support patching the BIOS INT 15 memory map. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [uaccess] Generalise librm's virt_offset mechanism for RISC-VMichael Brown2025-05-082-2/+2
| | | | | | | | | | | | | | The virtual offset memory model used for i386-pcbios and x86_64-pcbios can be generalised to also cover riscv32-sbi and riscv64-sbi. In both architectures, the 32-bit builds will use a circular map of the 32-bit address space, and the 64-bit builds will use an identity map for the relevant portion of the physical address space, with iPXE itself placed in the negative (kernel) address space. Generalise and document the virt_offset mechanism, and set it as the default for both PCBIOS and SBI platforms. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [fdt] Add the "fdt" commandMichael Brown2025-03-272-0/+4
| | | | | | | | | | | | | Allow a Flattened Device Tree blob (DTB) to be provided to a booted operating system using a script such as: #!ipxe kernel /images/vmlinuz console=ttyAMA0 initrd /images/initrd.img fdt /images/rk3566-radxa-zero-3e.dtb boot Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Accept and trust CA certificates in the TlsCaCertificates variableMichael Brown2025-03-131-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | UEFI's built-in HTTPS boot mechanism requires the trusted CA certificates to be provided via the TlsCaCertificates variable. (There is no equivalent of the iPXE cross-signing mechanism, so it is not possible for UEFI to automatically use public CA certificates.) Users who have configured UEFI HTTPS boot to use a custom root of trust (e.g. a private CA certificate) may find it useful to have iPXE automatically pick up and use this same root of trust, so that iPXE can seamlessly fetch files via HTTPS from the same servers that were trusted by UEFI HTTPS boot, in addition to servers that iPXE can validate through other means such as cross-signed certificates. Parse the TlsCaCertificates variable at startup, add any certificates to the certificate store, and mark these certificates as trusted. There are no access restrictions on modifying the TlsCaCertificates variable: anybody with access to write UEFI variables is permitted to change the root of trust. The UEFI security model assumes that anyone with access to run code prior to ExitBootServices() or with access to modify UEFI variables from within a loaded operating system is supposed to be able to change the system's root of trust for TLS. Any certificates parsed from TlsCaCertificates will show up in the output of "certstat", and may be discarded using "certfree" if unwanted. Support for parsing TlsCaCertificates is enabled by default in EFI builds, but may be disabled in config/general.h if needed. As with the ${trust} setting, the contents of the TlsCaCertificates variable will be ignored if iPXE has been compiled with an explicit root of trust by specifying TRUST=... on the build command line. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Support extracting certificates from EFI signature list imagesMichael Brown2025-03-111-0/+1
| | | | | | | | | | | Add support for the EFI signature list image format (as produced by tools such as efisecdb). The parsing code does not require any EFI boot services functions and so may be enabled even in non-EFI builds. We default to enabling it only for EFI builds. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [sbi] Add support for running as a RISC-V SBI payloadMichael Brown2024-10-281-0/+36
| | | | | | | | | | | | | | | | | Add basic support for running directly on top of SBI, with no UEFI firmware present. Build as e.g.: make CROSS=riscv64-linux-gnu- bin-riscv64/ipxe.sbi The resulting binary can be tested in QEMU using e.g.: qemu-system-riscv64 -M virt -cpu max -serial stdio \ -kernel bin-riscv64/ipxe.sbi No drivers or executable binary formats are supported yet, but the unit test suite may be run successfully. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [uaccess] Rename UACCESS_EFI to UACCESS_FLATMichael Brown2024-10-251-1/+1
| | | | | | | | | Running with flat physical addressing is a fairly common early boot environment. Rename UACCESS_EFI to UACCESS_FLAT so that this code may be reused in non-UEFI boot environments that also use flat physical addressing. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [riscv] Add support for the RISC-V CPU architectureMichael Brown2024-09-151-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | Add support for building iPXE as a 64-bit or 32-bit RISC-V binary, for either UEFI or Linux userspace platforms. For example: # RISC-V 64-bit UEFI make CROSS=riscv64-linux-gnu- bin-riscv64-efi/ipxe.efi # RISC-V 32-bit UEFI make CROSS=riscv64-linux-gnu- bin-riscv32-efi/ipxe.efi # RISC-V 64-bit Linux make CROSS=riscv64-linux-gnu- bin-riscv64-linux/tests.linux qemu-riscv64 -L /usr/riscv64-linux-gnu/sys-root \ ./bin-riscv64-linux/tests.linux # RISC-V 32-bit Linux make CROSS=riscv64-linux-gnu- SYSROOT=/usr/riscv32-linux-gnu/sys-root \ bin-riscv32-linux/tests.linux qemu-riscv32 -L /usr/riscv32-linux-gnu/sys-root \ ./bin-riscv32-linux/tests.linux Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Centralise definition of efi_cpu_nap()Michael Brown2024-09-131-3/+1Star
| | | | | | | | | Define a cpu_halt() function which is architecture-specific but platform-independent, and merge the multiple architecture-specific implementations of the EFI cpu_nap() function into a single central efi_cpu_nap() that uses cpu_halt() if applicable. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [bios] Provide a multiprocessor API for BIOSMichael Brown2024-03-151-1/+1
| | | | | | | | Provide an implementation of the iPXE multiprocessor API for BIOS, based on sending broadcast INIT and SIPI interprocessor interrupts to start up all application processors. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Provide a multiprocessor API for EFIMichael Brown2024-03-151-1/+1
| | | | | | | | | | | | | Provide an implementation of the iPXE multiprocessor API for EFI, based on using EFI_MP_SERVICES to start up a wrapper function on all application processors. Note that the processor numbers used by EFI_MP_SERVICES are opaque integers that bear no relation to the underlying CPU identity (e.g. the APIC ID), and so we must rely on our own (architecture- specific) implementation to determine the relevant CPU identifiers. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [mp] Define an API for multiprocessor functionsMichael Brown2024-03-153-0/+3
| | | | | | | | | | | | | Define an API for executing very limited functions on application processors in a multiprocessor system, along with an x86-only implementation. The normal iPXE runtime environment is effectively non-existent on application processors. There is no ability to make firmware calls (e.g. to write to a console), and there may be no stack space available. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [loong64] Add support for building EFI binariesXiaotian Wu2023-06-291-0/+5
| | | | | | Signed-off-by: Xiaotian Wu <wuxiaotian@loongson.cn> Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Provide read-only access to EFI variables via settings mechanismMichael Brown2023-06-091-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | EFI variables do not map neatly to the iPXE settings mechanism, since the EFI variable identifier includes a namespace GUID that cannot cleanly be supplied as part of a setting name. Creating a new EFI variable requires the variable's attributes to be specified, which does not fit within iPXE's settings concept. However, EFI variable names are generally unique even without the namespace GUID, and EFI does provide a mechanism to iterate over all existent variables. We can therefore provide read-only access to EFI variables by comparing only the names and ignoring the namespace GUIDs. Provide an "efi" settings block that implements this mechanism using a syntax such as: echo Platform language is ${efi/PlatformLang:string} show efi/SecureBoot:int8 Settings are returned as raw binary values by default since an EFI variable may contain boolean flags, integer values, ASCII strings, UCS-2 strings, EFI device paths, X.509 certificates, or any other arbitrary blob of data. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Implement "shim" as a dummy command on non-EFI platformsMichael Brown2023-05-241-1/+0Star
| | | | | | | | | | | | | | | | | | | | | | The "shim" command will skip downloading the shim binary (and is therefore a conditional no-op) if there is already a selected EFI image that can be executed directly via LoadImage()/StartImage(). This allows the same iPXE script to be used with Secure Boot either enabled or disabled. Generalise this further to provide a dummy "shim" command that is an unconditional no-op on non-EFI platforms. This then allows the same iPXE script to be used for BIOS, EFI with Secure Boot disabled, or EFI with Secure Boot enabled. The same effect could be achieved by using "iseq ${platform} efi" within the script, but this would complicate end-user documentation. To minimise the code size impact, the dummy "shim" command is a pure no-op that does not call parse_options() and so will ignore even standardised arguments such as "--help". Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add "shim" commandMichael Brown2023-05-221-0/+1
| | | | | | | | | | | | Allow a shim to be used to facilitate booting a kernel using a script such as: kernel /images/vmlinuz console=ttyS0,115200n8 initrd /images/initrd.img shim /images/shimx64.efi boot Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Split out EFI_RNG_PROTOCOL as a separate entropy sourceMichael Brown2023-02-201-1/+2
| | | | | | | | | | | | | | | | | | Commit 7ca801d ("[efi] Use the EFI_RNG_PROTOCOL as an entropy source if available") added EFI_RNG_PROTOCOL as an alternative entropy source via an ad-hoc mechanism specific to efi_entropy.c. Split out EFI_RNG_PROTOCOL to a separate entropy source, and allow the entropy core to handle the selection of RDRAND, EFI_RNG_PROTOCOL, or timer ticks as the active source. The fault detection logic added in commit a87537d ("[efi] Detect and disable seriously broken EFI_RNG_PROTOCOL implementations") may be removed completely, since the failure will already be detected by the generic ANS X9.82-mandated repetition count test and will now be handled gracefully by the entropy core. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [rng] Allow entropy source to be selected at runtimeMichael Brown2023-02-173-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | As noted in commit 3c83843 ("[rng] Check for several functioning RTC interrupts"), experimentation shows that Hyper-V cannot be trusted to reliably generate RTC interrupts. (As noted in commit f3ba0fb ("[hyperv] Provide timer based on the 10MHz time reference count MSR"), Hyper-V appears to suffer from a general problem in reliably generating any legacy interrupts.) An alternative entropy source is therefore required for an image that may be used in a Hyper-V Gen1 virtual machine. The x86 RDRAND instruction provides a suitable alternative entropy source, but may not be supported by all CPUs. We must therefore allow for multiple entropy sources to be compiled in, with the single active entropy source selected only at runtime. Restructure the internal entropy API to allow a working entropy source to be detected and chosen at runtime. Enable the RDRAND entropy source for all x86 builds, since it is likely to be substantially faster than any other source. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Enable NET_PROTO_LLDP by defaultMichael Brown2023-02-051-0/+1
| | | | | Requested-by: Christian I. Nilsson <nikize@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Enable IMAGE_GZIP by default for AArch64Michael Brown2022-02-101-0/+4
| | | | | | | | | AArch64 kernels tend to be distributed as gzip compressed images. Enable IMAGE_GZIP by default for AArch64 to avoid the need for uncompressed images to be provided. Originally-implemented-by: Alessandro Di Stefano <aleskandro@redhat.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [linux] Provide ACPI settings via /sys/firmware/acpi/tablesMichael Brown2021-03-011-0/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dma] Define a DMA API to allow for non-flat device address spacesMichael Brown2020-11-053-0/+3
| | | | | | | | | | | | | | | | | | | iPXE currently assumes that DMA-capable devices can directly address physical memory using host addresses. This assumption fails when using an IOMMU. Define an internal DMA API with two implementations: a "flat" implementation for use in legacy BIOS or other environments in which flat physical addressing is guaranteed to be used and all allocated physical addresses are guaranteed to be within a 32-bit address space, and an "operations-based" implementation for use in UEFI or other environments in which DMA mapping may require bus-specific handling. The purpose of the fully inlined "flat" implementation is to allow the trivial identity DMA mappings to be optimised out at build time, thereby avoiding an increase in code size for legacy BIOS builds. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Enable NET_PROTO_IPV6 by defaultTore Anderson2020-10-141-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | IPv6 PXE was included in the UEFI specification over eight years ago, specifically in version 2.3 (Errata D). http://www.uefi.org/sites/default/files/resources/UEFI_Spec_2_3_D.pdf When iPXE is being chainloaded from a UEFI firmware performing a PXE boot in an IPv6 network, it is essential that iPXE supports IPv6 as well. I understand that the reason for NET_PROTO_IPV6 being disabled by default (in src/config/general.h) is that it would cause certain space-constrained build targets to become too large. However, this should not be an issue for EFI builds. It is also worth noting that RFC 6540 makes a clear recommendation that IPv6 support should not be considered optional. https://tools.ietf.org/html/rfc6540 Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Tore Anderson <tore@fud.no> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usbblk] Add support for USB mass storage devicesMichael Brown2020-10-132-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | Some UEFI BIOSes (observed with at least the Insyde UEFI BIOS on a Microsoft Surface Go) provide a very broken version of the UsbMassStorageDxe driver that is incapable of binding to the standard EFI_USB_IO_PROTOCOL instances and instead relies on an undocumented proprietary protocol (with GUID c965c76a-d71e-4e66-ab06-c6230d528425) installed by the platform's custom version of UsbCoreDxe. The upshot is that USB mass storage devices become inaccessible once iPXE's native USB host controller drivers are loaded. One possible workaround is to load a known working version of UsbMassStorageDxe (e.g. from the EDK2 tree): this driver will correctly bind to the standard EFI_USB_IO_PROTOCOL instances exposed by iPXE. This workaround is ugly in practice, since it involves embedding UsbMassStorageDxe.efi into the iPXE binary and including an embedded script to perform the required "chain UsbMassStorageDxe.efi". Provide a native USB mass storage driver for iPXE, allowing USB mass storage devices to be exposed as iPXE SAN devices. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Avoid setting direction flag on EFI platformsMichael Brown2020-07-071-0/+1
| | | | | | | | | | | | | | | | | | | The only remaining use case in iPXE for the CPU direction flag is in __memcpy_reverse() where it is set to allow the use of "rep movsb" to perform the memory copy. This matches the equivalent functionality in the EDK2 codebase, which has functions such as InternalMemCopyMem that also temporarily set the direction flag in order to use "rep movsb". As noted in commit d2fb317 ("[crypto] Avoid temporarily setting direction flag in bigint_is_geq()"), some UEFI implementations are known to have buggy interrupt handlers that may reboot the machine if a timer interrupt happens to occur while the direction flag is set. Work around these buggy UEFI implementations by using the (unoptimised) generic_memcpy_reverse() on i386 or x86_64 UEFI platforms. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Register a device tree if provided by the platform firmwareMichael Brown2019-07-191-0/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Provide access to ACPI tablesMichael Brown2017-05-231-1/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [acpi] Make acpi_find_rsdt() a per-platform methodMichael Brown2017-05-232-0/+2
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [linux] Use dummy SAN deviceMichael Brown2017-03-281-1/+7
| | | | | | | Allow for easier testing of SAN code by using the dummy SAN device by default. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add missing SANBOOT_PROTO_HTTP to EFI default configurationMichael Brown2017-03-071-0/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2026-03-04 22:46:30 +0100