summaryrefslogtreecommitdiffstats
path: root/src/config/defaults/efi.h
Commit message (Collapse)AuthorAgeFilesLines
* [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-151-0/+1
| | | | | | | | | | | | | 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-171-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* [dma] Define a DMA API to allow for non-flat device address spacesMichael Brown2020-11-051-0/+1
| | | | | | | | | | | | | | | | | | | 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-131-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | 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-231-0/+1
| | | | 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>
* [efi] Add basic EFI SAN booting capabilityMichael Brown2016-11-171-1/+6
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [arm] Add support for 64-bit ARM (Aarch64)Michael Brown2016-05-081-1/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [arm] Add support for 32-bit ARMMichael Brown2016-05-061-2/+10
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Provide access to files stored on EFI filesystemsMichael Brown2016-03-141-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | Provide access to local files via the "file://" URI scheme. There are three syntaxes: - An opaque URI with a relative path (e.g. "file:script.ipxe"). This will be interpreted as a path relative to the iPXE binary. - A hierarchical URI with a non-network absolute path (e.g. "file:/boot/script.ipxe"). This will be interpreted as a path relative to the root of the filesystem from which the iPXE binary was loaded. - A hierarchical URI with a network path in which the authority is a volume label (e.g. "file://bootdisk/script.ipxe"). This will be interpreted as a path relative to the root of the filesystem with the specified volume label. Note that the potentially desirable shell mappings (e.g. "fs0:" and "blk0:") are concepts internal to the UEFI shell binary, and do not seem to be exposed in any way to external executables. The old EFI_SHELL_PROTOCOL (which did provide access to these mappings) is no longer installed by current versions of the UEFI shell. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ioapi] Split ioremap() out to a separate IOMAP APIMichael Brown2016-02-261-0/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Expose unused USB devices via EFI_USB_IO_PROTOCOLMichael Brown2015-09-141-0/+5
| | | | | | | Allow the UEFI platform firmware to provide drivers for unrecognised devices, by exposing our own implementation of EFI_USB_IO_PROTOCOL. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add EFI time sourceMichael Brown2015-04-141-1/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add EFI entropy sourceMichael Brown2015-04-141-2/+2
| | | | | Originally-implemented-by: Jarrod Johnson <jbjohnso@us.ibm.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [legal] Add missing FILE_LICENCE declarationsMarin Hannache2013-07-151-0/+2
| | | | | Signed-off-by: Marin Hannache <git@mareo.fr> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Enable "cpuid" command by default for EFIMichael Brown2013-03-221-0/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add "reboot" command for EFIMichael Brown2013-03-221-0/+3
| | | | | | | | | Abstract out the ability to reboot the system to a separate reboot() function (with platform-specific implementations), add an EFI implementation, and make the existing "reboot" command available under EFI. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Default to using raw x86 I/OMichael Brown2012-07-171-1/+1
| | | | | | | | | | The EFI_CPU_IO_PROTOCOL is not available on all EFI platforms. In particular, it is not available under OVMF, as used for qemu. Since the EFI_CPU_IO_PROTOCOL is an abomination of unnecessary complexity, banish it and use raw I/O instead. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [time] Define an API for getting the current timeMichael Brown2012-03-191-0/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [rng] Add ANS X9.82 Approved Source of Entropy InputMichael Brown2012-02-211-0/+1
| | | | | | | | | | | | | | | | ANS X9.82 specifies several Approved Sources of Entropy Input (SEI). One such SEI uses an entropy source as the Source of Entropy Input, condensing each entropy source output after each GetEntropy call. This can be implemented relatively cheaply in iPXE and avoids the need to allocate potentially very large buffers. (Note that the terms "entropy source" and "Source of Entropy Input" are not synonyms within the context of ANS X9.82.) Use the iPXE API mechanism to allow entropy sources to be selected at compilation time. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [bofm] Add support for BOFM under EFIMichael Brown2011-03-031-0/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [block] Replace gPXE block-device API with an iPXE asynchronous interfaceMichael Brown2010-09-141-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The block device interface used in gPXE predates the invention of even the old gPXE data-transfer interface, let alone the current iPXE generic asynchronous interface mechanism. Bring this old code up to date, with the following benefits: o Block device commands can be cancelled by the requestor. The INT 13 layer uses this to provide a global timeout on all INT 13 calls, with the result that an unexpected passive failure mode (such as an iSCSI target ACKing the request but never sending a response) will lead to a timeout that gets reported back to the INT 13 user, rather than simply freezing the system. o INT 13,00 (reset drive) is now able to reset the underlying block device. INT 13 users, such as DOS, that use INT 13,00 as a method for error recovery now have a chance of recovering. o All block device commands are tagged, with a numerical tag that will show up in debugging output and in packet captures; this will allow easier interpretation of bug reports that include both sources of information. o The extremely ugly hacks used to generate the boot firmware tables have been eradicated and replaced with a generic acpi_describe() method (exploiting the ability of iPXE interfaces to pass through methods to an underlying interface). The ACPI tables are now built in a shared data block within .bss16, rather than each requiring dedicated space in .data16. o The architecture-independent concept of a SAN device has been exposed to the iPXE core through the sanboot API, which provides calls to hook, unhook, boot, and describe SAN devices. This allows for much more flexible usage patterns (such as hooking an empty SAN device and then running an OS installer via TFTP). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Build iPXE script support into EFI binaries by defaultGeoff Lywood2010-06-231-0/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Use EFI-native mechanism for accessing SMBIOS tableMichael Brown2008-12-051-0/+1
| | | | | | 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] Add EFI image format and basic runtime environmentMichael Brown2008-10-131-0/+20
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.
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2024-06-06 19:46:56 +0200