sysadmin/ipxe
1
0
Fork 0
mirror of https://github.com/ipxe/ipxe synced 2026-02-14 02:31:26 +03:00
Code Issues Packages Projects Releases Wiki Activity
Files
595ff240304e98a725624c71a5735c2013562810
ipxe/src/config/defaults/efi.h

87 lines
2.0 KiB
C
Raw Normal View History

[efi] Add EFI image format and basic runtime environment 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.
2008-10-12 01:55:55 +01:00
#ifndef CONFIG_DEFAULTS_EFI_H
#define CONFIG_DEFAULTS_EFI_H
/** @file
*
* Configuration defaults for EFI
*
*/
[efi] Add EFI entropy source Originally-implemented-by: Jarrod Johnson <jbjohnso@us.ibm.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2015-04-14 10:56:20 +01:00
FILE_LICENCE ( GPL2_OR_LATER_OR_UBDL );
[legal] Add missing FILE_LICENCE declarations Signed-off-by: Marin Hannache <git@mareo.fr> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2013-07-15 12:30:57 +02:00
[uaccess] Rename UACCESS_EFI to UACCESS_FLAT 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>
2024-10-25 14:21:27 +01:00
#define UACCESS_FLAT
[ioapi] Split ioremap() out to a separate IOMAP API Signed-off-by: Michael Brown <mcb30@ipxe.org>
2016-02-26 15:33:40 +00:00
#define IOMAP_VIRT
[efi] Add EFI image format and basic runtime environment 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.
2008-10-12 01:55:55 +01:00
#define PCIAPI_EFI
[dma] Define a DMA API to allow for non-flat device address spaces 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>
2020-11-04 15:18:49 +00:00
#define DMAAPI_OP
[efi] Add EFI image format and basic runtime environment 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.
2008-10-12 01:55:55 +01:00
#define CONSOLE_EFI
#define TIMER_EFI
#define UMALLOC_EFI
[memmap] Define an API for managing the system memory map 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>
2025-05-14 22:19:54 +01:00
#define MEMMAP_NULL
[efi] Use EFI-native mechanism for accessing SMBIOS table 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.
2008-12-04 23:09:48 +00:00
#define SMBIOS_EFI
[efi] Add basic EFI SAN booting capability Signed-off-by: Michael Brown <mcb30@ipxe.org>
2016-11-16 22:22:22 +00:00
#define SANBOOT_EFI
[bofm] Add support for BOFM under EFI Signed-off-by: Michael Brown <mcb30@ipxe.org>
2011-02-17 00:31:38 +00:00
#define BOFM_EFI
[efi] Split out EFI_RNG_PROTOCOL as a separate entropy source 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>
2023-02-20 14:08:49 +00:00
#define ENTROPY_EFITICK
#define ENTROPY_EFIRNG
[efi] Add EFI time source Signed-off-by: Michael Brown <mcb30@ipxe.org>
2015-04-14 11:55:08 +01:00
#define TIME_EFI
[efi] Add "reboot" command for EFI 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>
2013-03-22 13:42:16 +00:00
#define REBOOT_EFI
[efi] Provide access to ACPI tables Signed-off-by: Michael Brown <mcb30@ipxe.org>
2017-05-23 18:32:31 +01:00
#define ACPI_EFI
[efi] Register a device tree if provided by the platform firmware Signed-off-by: Michael Brown <mcb30@ipxe.org>
2019-07-19 17:42:12 +01:00
#define FDT_EFI
[efi] Provide a multiprocessor API for EFI 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>
2024-03-13 15:16:47 +00:00
#define MPAPI_EFI
[efi] Centralise definition of efi_cpu_nap() 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>
2024-09-13 14:26:34 +01:00
#define NAP_EFI
[serial] Allow platform to specify mechanism for identifying console 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>
2025-06-23 16:19:07 +01:00
#define SERIAL_FIXED
[efi] Add EFI image format and basic runtime environment 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.
2008-10-12 01:55:55 +01:00
[efi] Enable NET_PROTO_IPV6 by default 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>
2018-11-18 20:13:46 +01:00
#define NET_PROTO_IPV6 /* IPv6 protocol */
[efi] Enable NET_PROTO_LLDP by default Requested-by: Christian I. Nilsson <nikize@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-02-05 18:53:03 +00:00
#define NET_PROTO_LLDP /* Link Layer Discovery protocol */
[efi] Enable NET_PROTO_IPV6 by default 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>
2018-11-18 20:13:46 +01:00
[efi] Provide access to files stored on EFI filesystems 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>
2016-03-14 15:23:42 +00:00
#define DOWNLOAD_PROTO_FILE /* Local filesystem access */
[efi] Add EFI image format and basic runtime environment 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.
2008-10-12 01:55:55 +01:00
#define IMAGE_EFI /* EFI image support */
[efi] Build iPXE script support into EFI binaries by default Signed-off-by: Michael Brown <mcb30@ipxe.org>
2010-06-16 14:35:24 -07:00
#define IMAGE_SCRIPT /* iPXE script image support */
[crypto] Support extracting certificates from EFI signature list images 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>
2025-03-11 11:58:28 +00:00
#define IMAGE_EFISIG /* EFI signature list support */
[efi] Add EFI image format and basic runtime environment 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.
2008-10-12 01:55:55 +01:00
[efi] Add basic EFI SAN booting capability Signed-off-by: Michael Brown <mcb30@ipxe.org>
2016-11-16 22:22:22 +00:00
#define SANBOOT_PROTO_ISCSI /* iSCSI protocol */
#define SANBOOT_PROTO_AOE /* AoE protocol */
#define SANBOOT_PROTO_IB_SRP /* Infiniband SCSI RDMA protocol */
#define SANBOOT_PROTO_FCP /* Fibre Channel protocol */
[efi] Add missing SANBOOT_PROTO_HTTP to EFI default configuration Signed-off-by: Michael Brown <mcb30@ipxe.org>
2017-03-06 15:01:39 +00:00
#define SANBOOT_PROTO_HTTP /* HTTP SAN protocol */
[efi] Add basic EFI SAN booting capability Signed-off-by: Michael Brown <mcb30@ipxe.org>
2016-11-16 22:22:22 +00:00
[efi] Expose unused USB devices via EFI_USB_IO_PROTOCOL 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>
2015-09-10 17:22:03 +01:00
#define USB_HCD_XHCI /* xHCI USB host controller */
#define USB_HCD_EHCI /* EHCI USB host controller */
#define USB_HCD_UHCI /* UHCI USB host controller */
#define USB_EFI /* Provide EFI_USB_IO_PROTOCOL interface */
[usbblk] Add support for USB mass storage devices 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>
2020-10-12 15:31:49 +01:00
#define USB_BLOCK /* USB block devices */
[efi] Expose unused USB devices via EFI_USB_IO_PROTOCOL 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>
2015-09-10 17:22:03 +01:00
[efi] Add "reboot" command for EFI 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>
2013-03-22 13:42:16 +00:00
#define REBOOT_CMD /* Reboot command */
[arm] Add support for 32-bit ARM Signed-off-by: Michael Brown <mcb30@ipxe.org>
2015-10-19 20:01:19 +01:00
[efi] Provide read-only access to EFI variables via settings mechanism 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>
2023-06-09 14:03:48 +01:00
#define EFI_SETTINGS /* EFI variable settings */
[efi] Accept and trust CA certificates in the TlsCaCertificates variable 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>
2025-03-13 14:04:26 +00:00
#define CERTS_EFI /* EFI certificate sources */
[arm] Add support for 32-bit ARM Signed-off-by: Michael Brown <mcb30@ipxe.org>
2015-10-19 20:01:19 +01:00
#if defined ( __i386__ ) || defined ( __x86_64__ )
#define IOAPI_X86
[rng] Allow entropy source to be selected at runtime 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>
2023-02-17 16:56:11 +00:00
#define ENTROPY_RDRAND
[efi] Enable "cpuid" command by default for EFI Signed-off-by: Michael Brown <mcb30@ipxe.org>
2013-03-22 13:58:54 +00:00
#define CPUID_CMD /* x86 CPU feature detection command */
[efi] Avoid setting direction flag on EFI platforms 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>
2020-07-07 13:49:17 +01:00
#define UNSAFE_STD /* Avoid setting direction flag */
[arm] Add support for 32-bit ARM Signed-off-by: Michael Brown <mcb30@ipxe.org>
2015-10-19 20:01:19 +01:00
#endif
[arm] Add support for 64-bit ARM (Aarch64) Signed-off-by: Michael Brown <mcb30@ipxe.org>
2016-05-08 00:20:20 +01:00
#if defined ( __arm__ ) || defined ( __aarch64__ )
[arm] Add support for 32-bit ARM Signed-off-by: Michael Brown <mcb30@ipxe.org>
2015-10-19 20:01:19 +01:00
#define IOAPI_ARM
[fdt] Add the "fdt" command 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>
2025-03-27 11:36:35 +00:00
#define FDT_CMD
[arm] Add support for 32-bit ARM Signed-off-by: Michael Brown <mcb30@ipxe.org>
2015-10-19 20:01:19 +01:00
#endif
[efi] Add "reboot" command for EFI 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>
2013-03-22 13:42:16 +00:00
[efi] Enable IMAGE_GZIP by default for AArch64 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>
2022-02-10 12:47:25 +00:00
#if defined ( __aarch64__ )
#define IMAGE_GZIP /* GZIP image support */
[fdt] Add the "fdt" command 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>
2025-03-27 11:36:35 +00:00
#define FDT_CMD
[efi] Enable IMAGE_GZIP by default for AArch64 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>
2022-02-10 12:47:25 +00:00
#endif
[loong64] Add support for building EFI binaries Signed-off-by: Xiaotian Wu <wuxiaotian@loongson.cn> Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-06-29 15:52:28 +01:00
#if defined ( __loongarch__ )
#define IOAPI_LOONG64
#endif
[riscv] Add support for the RISC-V CPU architecture 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>
2024-09-15 10:54:04 +01:00
#if defined ( __riscv )
#define IOAPI_RISCV
[fdt] Add the "fdt" command 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>
2025-03-27 11:36:35 +00:00
#define FDT_CMD
[riscv] Add support for the RISC-V CPU architecture 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>
2024-09-15 10:54:04 +01:00
#endif
[efi] Add EFI image format and basic runtime environment 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.
2008-10-12 01:55:55 +01:00
#endif /* CONFIG_DEFAULTS_EFI_H */
Reference in New Issue Copy Permalink