summaryrefslogtreecommitdiffstats
path: root/src/arch/riscv/include/ipxe
Commit message (Collapse)AuthorAgeFilesLines
* [riscv] Create coherent DMA mapping of 32-bit address space on demandMichael Brown2025-07-111-6/+1Star
| | | | | | | | 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 <mcb30@ipxe.org>
* [riscv] Invalidate data cache on completed RX DMA buffersMichael Brown2025-07-101-11/+0Star
| | | | | | | | | | | | | | | | | | 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 <mcb30@ipxe.org>
* [riscv] Provide a DMA API implementation for RISC-V bare-metal systemsMichael Brown2025-07-093-3/+66
| | | | | | | | | 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 <mcb30@ipxe.org>
* [riscv] Support explicit cache management operations on I/O buffersMichael Brown2025-07-071-0/+17
| | | | | | | | | | | | | | | | | 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 <mcb30@ipxe.org>
* [riscv] Add support for detecting T-Head vendor extensionsMichael Brown2025-07-072-0/+25
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [riscv] Serialise MMIO accesses with respect to each otherMichael Brown2025-06-221-4/+8
| | | | | | | | | | | | | | | | | | | | | | | 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 <mcb30@ipxe.org>
* [riscv] Maximise barrier effects of memory fencesMichael Brown2025-06-121-1/+1
| | | | | | | | | | | | | | | | | | | 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 <mcb30@ipxe.org>
* [riscv] Support mapping I/O devices outside of the identity mapMichael Brown2025-05-261-0/+26
| | | | | | | | | | | | | | 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 <mcb30@ipxe.org>
* [riscv] Support older SBI implementationsMichael Brown2025-05-251-6/+48
| | | | | | | Fall back to attempting the legacy SBI console and shutdown calls if the standard calls fail. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [riscv] Use generic external heap based on the system memory mapMichael Brown2025-05-191-18/+0Star
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [riscv] Check if seed CSR is accessible from S-modeMichael Brown2024-10-291-0/+75
| | | | | | | | | | | | | The seed CSR defined by the Zkr extension is accessible only in M-mode by default. Older versions of OpenSBI (prior to version 1.4) do not set mseccfg.sseed, with the result that attempts to access the seed CSR from S-mode will raise an illegal instruction exception. Add a facility for testing the accessibility of arbitrary CSRs, and use it to check that the seed CSR is accessible before reporting the seed CSR entropy source as being functional. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [sbi] Add support for running as a RISC-V SBI payloadMichael Brown2024-10-282-0/+37
| | | | | | | | | | | | | | | | | Add basic support for running directly on top of SBI, with no UEFI firmware present. Build as e.g.: make CROSS=riscv64-linux-gnu- bin-riscv64/ipxe.sbi The resulting binary can be tested in QEMU using e.g.: qemu-system-riscv64 -M virt -cpu max -serial stdio \ -kernel bin-riscv64/ipxe.sbi No drivers or executable binary formats are supported yet, but the unit test suite may be run successfully. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [riscv] Add support for checking CPU extensions reported via device treeMichael Brown2024-10-281-0/+16
| | | | | | | | | | | | | RISC-V seems to allow for direct discovery of CPU features only from M-mode (e.g. by setting up a trap handler and then attempting to access a CSR), with S-mode code expected to read the resulting constructed ISA description from the device tree. Add the ability to check for the presence of named extensions listed in the "riscv,isa" property of the device tree node corresponding to the boot hart. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [riscv] Add support for reboot and power off via SBIMichael Brown2024-10-222-0/+28
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [riscv] Add support for the SBI debug consoleMichael Brown2024-10-221-0/+157
| | | | | | | | Add the ability to issue Supervisor Binary Interface (SBI) calls via the ECALL instruction, and use the SBI DBCN extension to implement a debug console. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [riscv] Add support for the RISC-V CPU architectureMichael Brown2024-09-151-0/+137
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>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2026-03-09 15:43:04 +0100