openslx-ng/ipxe.git/src/arch/riscv/include, branch openslx

[riscv] Create coherent DMA mapping of 32-bit address space on demand

2025-07-11T11:23:51+00:00

Reuse the code that creates I/O device page mappings to create the coherent DMA mapping of the 32-bit address space on demand, instead of constructing this mapping as part of the initial page table. Signed-off-by: Michael Brown

[riscv] Invalidate data cache on completed RX DMA buffers

2025-07-10T13:39:07+00:00

The data cache must be invalidated twice for RX DMA buffers: once before passing ownership to the DMA device (in case the cache happens to contain dirty data that will be written back at an undefined future point), and once after receiving ownership from the DMA device (in case the CPU happens to have speculatively accessed data in the buffer while it was owned by the hardware). Only the used portion of the buffer needs to be invalidated after completion, since we do not care about data within the unused portion. Update the DMA API to include the used length as an additional parameter to dma_unmap(), and add the necessary second cache invalidation pass to the RISC-V DMA API implementation. Signed-off-by: Michael Brown

[riscv] Add optimised TCP/IP checksumming

2025-07-10T12:32:45+00:00

Add a RISC-V assembly language implementation of TCP/IP checksumming, which is around 50x faster than the generic algorithm. The main loop checksums aligned xlen-bit words, using almost entirely compressible instructions and accumulating carries in a separate register to allow folding to be deferred until after all loops have completed. Experimentation on a C910 CPU suggests that this achieves around four bytes per clock cycle, which is comparable to the x86 implementation. Signed-off-by: Michael Brown

[riscv] Provide a DMA API implementation for RISC-V bare-metal systems

2025-07-09T10:07:37+00:00

Provide an implementation of dma_map() that performs cache clean or invalidation as required, and an implementation of dma_alloc() that returns virtual addresses within the coherent mapping of the 32-bit physical address space. Signed-off-by: Michael Brown

[riscv] Support explicit cache management operations on I/O buffers

2025-07-07T15:38:23+00:00

On platforms where DMA devices are not in the same coherency domain as the CPU cache, it is necessary to be able to explicitly clean the cache (i.e. force data to be written back to main memory) and invalidate the cache (i.e. discard any cached data and force a subsequent read from main memory). Add support for cache management via the standard Zicbom extension or the T-Head cache management operations extension, with the supported extension detected on first use. Support cache management operations only on I/O buffers, since these are guaranteed to not share cachelines with other data. Signed-off-by: Michael Brown

[riscv] Add support for detecting T-Head vendor extensions

2025-07-07T15:38:23+00:00

Signed-off-by: Michael Brown

[riscv] Serialise MMIO accesses with respect to each other

2025-06-22T08:45:09+00:00

iPXE drivers have been written with the implicit assumption that MMIO writes are allowed to be posted but that an MMIO register read or write after another MMIO register write will always observe the effects of the first write. For example: after having written a byte to the transmit holding register (THR) of a 16550 UART, it is expected that any subsequent read of the line status register (LSR) will observe a value consistent with the occurrence of the write. RISC-V does not seem to provide any ordering guarantees between accesses to different registers within the same MMIO device. Add fences as part of the MMIO accessors to provide the assumed guarantees. Use "fence io, io" before each MMIO read or write to enforce full serialisation of MMIO accesses with respect to each other. This is almost certainly more conservative than is strictly necessary. Signed-off-by: Michael Brown

[riscv] Maximise barrier effects of memory fences

2025-06-12T11:33:46+00:00

The RISC-V "fence" instruction encoding includes bits for predecessor and successor input and output operations, separate from read and write operations. It is up to the CPU implementation to decide what counts as I/O space rather than memory space for the purposes of this instruction. Since we do not expect fencing to be performance-critical, keep everything as simple and reliable as possible by using the unadorned "fence" instruction (equivalent to "fence iorw, iorw"). Add a memory clobber to ensure that the compiler does not reorder the barrier. (The volatile qualifier seems to already prevent reordering in practice, but this is not guaranteed according to the compiler documentation.) Signed-off-by: Michael Brown

[riscv] Support mapping I/O devices outside of the identity map

2025-05-26T16:56:27+00:00

With the 64-bit paging schemes (Sv39, Sv48, and Sv57), we identity-map as much of the physical address space as is possible. Experimentation shows that this is not sufficient to provide access to all I/O devices. For example: the Sipeed Lichee Pi 4A includes a CPU that supports only Sv39, but places I/O devices at the top of a 40-bit address space. Add support for creating I/O page table entries on demand to map I/O devices, based on the existing design used for x86_64 BIOS. Signed-off-by: Michael Brown

[riscv] Support older SBI implementations

2025-05-25T09:43:39+00:00

Fall back to attempting the legacy SBI console and shutdown calls if the standard calls fail. Signed-off-by: Michael Brown