openslx-ng/ipxe.git/src/util, branch openslx

[console] Mark generated keymaps as permitted for Secure Boot

2026-01-13T15:41:21+00:00

Signed-off-by: Michael Brown

[efi] Mark imported EDK2 headers as permitted for Secure Boot

2026-01-13T15:18:16+00:00

Signed-off-by: Michael Brown

[efi] Update to current EDK2 headers

2025-11-11T23:24:22+00:00

Signed-off-by: Michael Brown

[build] Handle isohybrid with xorrisofs

2025-07-08T10:49:16+00:00

Generating an isohybrid image with `xorrisofs` is supposed to happen with option `-isohybrid-gpt-basdat`, not command `isohybrid`. Signed-off-by: Michael Brown

[zbin] Allow for constructing compressed dynamic relocation records

2025-05-06T11:11:56+00:00

Define a new "ZREL" compressor information block, describing a block of Elf_Rel or Elf_Rela runtime relocations to be converted to an iPXE-specific compressed relocation format. The compressed relocation format is based loosely on the Elf_Relr bitmap+offset format, with some optimisations for use in iPXE. In particular: - a relative "skip" value is used instead of an absolute offset - the width of the skip value is reduced to 19 bits (when present) - an explicit skip value of zero is used to terminate the list - unaligned relocations are prohibited The layout of bits within the compressed relocation record is also adjusted to make assembly code implementations simpler: the skip flag bit is placed in the MSB so that it can be tested using "bltz" or similar instructions, and the skip value is placed above the relocation flag bits so that a typical shifting implementation will naturally end up with a zero value in its accumulator if and only if the record was a terminator. Signed-off-by: Michael Brown

[build] Allow for 32-bit and 64-bit versions of util/zbin

2025-05-06T11:11:02+00:00

Parsing ELF data is simpler if we don't have to build a single binary to handle both 32-bit and 64-bit ELF formats. Allow for separate 32-bit and 64-bit binaries built from util/zbin.c (as is already done for util/elf2efi.c). Signed-off-by: Michael Brown

[riscv] Add support for the RISC-V CPU architecture

2024-09-15T21:34:10+00:00

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

[efi] Ignore new LoongArch PC-relative relocations and relaxations

2024-02-22T14:40:53+00:00

Several new relocations types have been added in LoongArch ABI version 2.10. In particular: - R_LARCH_B16 (18-bit PC-relative jump) - R_LARCH_B21 (23-bit PC-relative jump) - R_LARCH_PCREL20_S2 (22-bit PC-relative offset) Also relocation relaxations have been introduced. Recent GCC (13.2) and binutils 2.41+ use these types of relocations, which confuses elf2efi tool. As a result, iPXE EFI images for LoongArch fail to build with the following error: Unrecognised relocation type 103 Fix by ignoring R_LARCH_B{16,21} and R_LARCH_PCREL20_S2 (as with other PC-relative relocations), and by ignoring relaxations (R_LARCH_RELAX). Relocation relaxations are basically optimizations: ignoring them results in a correct binary (although it might be suboptimal). Modified-by: Michael Brown Signed-off-by: Michael Brown

[efi] Add potentially missing relocation types

2023-12-21T12:29:03+00:00

Add definitions for relocation types that may be missing on older versions of the host system's elf.h. This mirrors wimboot commit 47f6298 ("[efi] Add potentially missing relocation types"). Signed-off-by: Michael Brown

[efi] Fix Coverity warning about unintended sign extension

2023-12-19T16:56:34+00:00

The result of multiplying a uint16_t by another uint16_t will be a signed int. Comparing this against a size_t will perform an unwanted sign extension. Fix by explicitly casting e_phnum to an unsigned int, thereby matching the data type used for the loop index variable (and avoiding the unwanted sign extension). This mirrors wimboot commit 15f6162 ("[efi] Fix Coverity warning about unintended sign extension"). Signed-off-by: Michael Brown