summaryrefslogtreecommitdiffstats
path: root/src/arch/arm32
Commit message (Collapse)AuthorAgeFilesLines
* [build] Allow for 32-bit and 64-bit versions of util/zbinMichael Brown2025-05-061-0/+4
| | | | | | | | | | 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 <mcb30@ipxe.org>
* [crypto] Expose shifted out bit from big integer shiftsMichael Brown2025-02-131-8/+14
| | | | | | | Expose the bit shifted out as a result of shifting a big integer left or right. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Expose carry flag from big integer addition and subtractionMichael Brown2024-11-261-8/+15
| | | | | | | | Expose the effective carry (or borrow) out flag from big integer addition and subtraction, and use this to elide an explicit bit test when performing x25519 reduction. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Use architecture-independent bigint_is_set()Michael Brown2024-10-101-19/+0Star
| | | | | | | | | | | Every architecture uses the same implementation for bigint_is_set(), and there is no reason to suspect that a future CPU architecture will provide a more efficient way to implement this operation. Simplify the code by providing a single architecture-independent implementation of bigint_is_set(). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Rename bigint_rol()/bigint_ror() to bigint_shl()/bigint_shr()Michael Brown2024-10-071-4/+4
| | | | | | | | | | | The big integer shift operations are misleadingly described as rotations since the original x86 implementations are essentially trivial loops around the relevant rotate-through-carry instruction. The overall operation performed is a shift rather than a rotation. Update the function names and descriptions to reflect this. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Eliminate temporary carry space for big integer multiplicationMichael Brown2024-09-271-7/+8
| | | | | | | | | | | | An n-bit multiplication product may be added to up to two n-bit integers without exceeding the range of a (2n)-bit integer: (2^n - 1)*(2^n - 1) + (2^n - 1) + (2^n - 1) = 2^(2n) - 1 Exploit this to perform big integer multiplication in constant time without requiring the caller to provide temporary carry space. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [arm] Support building as a Linux userspace binary for AArch32Michael Brown2024-09-241-0/+25
| | | | | | | | | | | | | Add support for building as a Linux userspace binary for AArch32. This allows the self-test suite to be more easily run for the 32-bit ARM code. For example: make CROSS=arm-linux-gnu- bin-arm32-linux/tests.linux qemu-arm -L /usr/arm-linux-gnu/sys-root/ \ ./bin-arm32-linux/tests.linux Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [arm] Check PMCCNTR availability before use for profilingMichael Brown2024-09-242-3/+99
| | | | | | | | | | | | Reading from PMCCNTR causes an undefined instruction exception when running in PL0 (e.g. as a Linux userspace binary), unless the PMUSERENR.EN bit is set. Restructure profile_timestamp() for 32-bit ARM to perform an availability check on the first invocation, with subsequent invocations returning zero if PMCCNTR could not be enabled. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [profile] Standardise return type of profile_timestamp()Michael Brown2024-09-241-1/+1
| | | | | | | | | | | | | | | | All consumers of profile_timestamp() currently treat the value as an unsigned long. Only the elapsed number of ticks is ever relevant: the absolute value of the timestamp is not used. Profiling is used to measure short durations that are generally fewer than a million CPU cycles, for which an unsigned long is easily large enough. Standardise the return type of profile_timestamp() as unsigned long across all CPU architectures. This allows 32-bit architectures such as i386 and riscv32 to omit all logic associated with retrieving the upper 32 bits of the 64-bit hardware counter, which simplifies the code and allows riscv32 and riscv64 to share the same implementation. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Use constant-time big integer multiplicationMichael Brown2024-09-232-111/+29Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Big integer multiplication currently performs immediate carry propagation from each step of the long multiplication, relying on the fact that the overall result has a known maximum value to minimise the number of carries performed without ever needing to explicitly check against the result buffer size. This is not a constant-time algorithm, since the number of carries performed will be a function of the input values. We could make it constant-time by always continuing to propagate the carry until reaching the end of the result buffer, but this would introduce a large number of redundant zero carries. Require callers of bigint_multiply() to provide a temporary carry storage buffer, of the same size as the result buffer. This allows the carry-out from the accumulation of each double-element product to be accumulated in the temporary carry space, and then added in via a single call to bigint_add() after the multiplication is complete. Since the structure of big integer multiplication is identical across all current CPU architectures, provide a single shared implementation of bigint_multiply(). The architecture-specific operation then becomes the multiplication of two big integer elements and the accumulation of the double-element product. Note that any intermediate carry arising from accumulating the lower half of the double-element product may be added to the upper half of the double-element product without risk of overflow, since the result of multiplying two n-bit integers can never have all n bits set in its upper half. This simplifies the carry calculations for architectures such as RISC-V and LoongArch64 that do not have a carry flag. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Remove redundant EFI_BOOT_FILE definitionsMichael Brown2024-09-161-4/+0Star
| | | | | | | | | | | | As of commit 79c0173 ("[build] Create util/genfsimg for building filesystem-based images"), the EFI boot file name for each CPU architecture is defined within the genfsimg script itself, rather than being passed in as a Makefile parameter. Remove the now-redundant Makefile definitions for EFI_BOOT_FILE. Reported-by: Christian I. Nilsson <nikize@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [libc] Centralise architecture-independent portions of setjmp.hMichael Brown2024-09-121-9/+3Star
| | | | | | | | | | | The definitions of the setjmp() and longjmp() functions are common to all architectures, with only the definition of the jump buffer structure being architecture-specific. Move the architecture-specific portions to bits/setjmp.h and provide a common setjmp.h for the function definitions. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [gdb] Allow CPU architectures to omit support for GDBMichael Brown2024-09-051-45/+0Star
| | | | | | | | Move the <gdbmach.h> file to <bits/gdbmach.h>, and provide a common dummy implementation for all architectures that have not yet implemented support for GDB. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Centralise dummy architecture-specific headersMichael Brown2024-09-031-19/+0Star
| | | | | | | | Simplify the process of adding a new CPU architecture by providing common implementations of typically empty architecture-specific header files. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Allow multiplicand and multiplier to differ in sizeMichael Brown2024-01-162-12/+18
| | | | | | | | | | | Big integer multiplication is currently used only as part of modular exponentiation, where both multiplicand and multiplier will be the same size. Relax this requirement to allow for the use of big integer multiplication in other contexts. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Remove unnecessary ".text" directivesMichael Brown2024-01-142-2/+0Star
| | | | | | | | | The .text directive is entirely redundant when followed by a .section directive giving an explicit section name and attributes. Remove these unnecessary directives to simplify the code. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Allow for per-architecture unprefixed constant operand modifierMichael Brown2023-02-061-0/+3
| | | | | | | | | | | | | | | | | | Over the years, the undocumented operand modifier used to produce the unprefixed constant values in __einfo_error() has varied from "%c0" to "%a0" in commit 1a77466 ("[build] Fix use of inline assembly on GCC 4.8 ARM64 builds") and back to "%c0" in commit 3fb3ffc ("[build] Fix use of inline assembly on GCC 8 ARM64 builds"), according to the evolving demands of the toolchain. LoongArch64 suffers from a similar issue: GCC 13 will allow either, but the currently released GCC 12 allows only the "%a0" form. Introduce a macro ASM_NO_PREFIX, defined in bits/compiler.h, to abstract away this difference and allow different architectures to use different operand modifiers. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [arm] Inhibit linker warnings about an implied executable stackMichael Brown2023-01-233-0/+3
| | | | | | | | | | | Some versions of the 32-bit ARM linker seem to treat the absence of a .note.GNU-stack section as implying an executable stack, and will print a warning that this is deprecated behaviour. Silence the warning by adding a .note.GNU-stack section to each assembly file and retaining the sections in the Linux linker script. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [arm] Use -mfloat-abi=soft only for EFI buildsMichael Brown2023-01-232-1/+5
| | | | | | | | | The EFI ABI requires the use of -mfloat-abi=soft, but other platforms may require -mfloat-abi=hard. Allow for this by using -mfloat-abi=soft only for EFI builds. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [arm] Use -fno-short-enums for all 32-bit ARM buildsMichael Brown2023-01-232-4/+5
| | | | | | | | | | | The EFI ABI requires the use of -fno-short-enums, and the EDK2 headers will perform a compile-time check that enums are 32 bits. The EDK2 headers may be included even in builds for non-EFI platforms, and so the -fno-short-enums flag must be used in all 32-bit ARM builds. Fortunately, nothing else currently cares about enum sizes. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dhcp] Simplify platform-specific client architecture definitionsMichael Brown2023-01-222-40/+20Star
| | | | | | | | | | | | | | | | Move the platform-specific DHCP client architecture definitions to header files of the form <ipxe/$(PLATFORM)/dhcparch.h>. This simplifies the directory structure and allows the otherwise unused arch/$(ARCH)/include/$(PLATFORM) to be removed from the include directory search path, which avoids the confusing situation in which a header file may potentially be accessed through more than one path. For Linux userspace binaries on any architecture, use the EFI values for that architecture by delegating to the EFI header file. This avoids the need to explicitly select values for Linux userspace binaries for each architecture. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Fix ARM32 EFI builds with current EDK2 headersMichael Brown2017-07-281-0/+4
| | | | | | | | | | | | EDK2 commit 6440385 ("MdePkg/Include: Add enumeration size checks to Base.h") enforced the UEFI specification mandate that enums should always be 32 bits. This revealed a latent bug in iPXE, which does not build with -fno-short-enums. Fix by adding -fno-short-enums to CFLAGS for ARM32 EFI builds. Reported-by: Benjamin S. Allen <bsallen@alcf.anl.gov> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dhcp] Automatically generate vendor class identifier stringMichael Brown2016-07-041-5/+0Star
| | | | | | | | | | | | The vendor class identifier strings in DHCP_ARCH_VENDOR_CLASS_ID are out of sync with the (correct) client architecture values in DHCP_ARCH_CLIENT_ARCHITECTURE. Fix by removing all definitions of DHCP_ARCH_VENDOR_CLASS_ID, and instead generating the vendor class identifier string automatically based on DHCP_ARCH_CLIENT_ARCHITECTURE and DHCP_ARCH_CLIENT_NDI. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dhcp] Allow for variable encapsulation of architecture-specific optionsMichael Brown2016-07-041-7/+6Star
| | | | | | | | | | | | | DHCPv4 and DHCPv6 share some values in common for the architecture- specific options (such as the client system architecture type), but use different encapsulations: DHCPv4 has a single byte for the option length while DHCPv6 has a 16-bit field for the option length. Move the containing DHCP_OPTION() and related wrappers from the individual dhcp_arch.h files to dhcp.c, thus allowing for the architecture-specific values to be reused in dhcpv6.c. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [arm] Use correct DHCP client architecture valuesMichael Brown2016-05-261-1/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [arm] Add optimised TCP/IP checksumming for 64-bit ARMMichael Brown2016-05-111-0/+19
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [arm] Add optimised string functions for 64-bit ARMMichael Brown2016-05-111-0/+60
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [arm] Split out 32-bit-specific code to arch/arm32Michael Brown2016-05-0817-0/+1121
Signed-off-by: Michael Brown <mcb30@ipxe.org>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2026-03-06 18:28:29 +0100