Fork of ipxe; additional commands and features https://git.openslx.org/openslx-ng/ipxe.git/atom/src/arch/arm32/core?h=openslx 2024-09-24T15:14:33+00:00 2024-09-24T15:14:33+00:00 Michael Brown 2024-09-24T10:52:16+00:00 urn:sha1:e0282688c1d9795a1400718b8c9e3f468530ae97 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> 2024-09-23T12:19:58+00:00 Michael Brown 2024-09-19T15:23:32+00:00 urn:sha1:3def13265d9475c861eed1a101584b761e97ae33 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> 2024-01-16T16:09:16+00:00 Michael Brown 2024-01-16T16:09:16+00:00 urn:sha1:26d3ef062b33e43e076b7ecef20c4ec3f9441860 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> 2023-01-23T12:55:44+00:00 Michael Brown 2023-01-23T12:30:41+00:00 urn:sha1:fcfb70bfb2a9aae78e86a2505669068e7e511f79 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> 2016-05-07T23:18:35+00:00 Michael Brown 2016-05-07T23:18:35+00:00 urn:sha1:edea3a434ccae8dc980c715949287c9ba63babf5 Signed-off-by: Michael Brown <mcb30@ipxe.org>