Repository navigation
Tags: lowRISC/qemu
Tags
[ot] .github/workflows: create_release: target triggering branch Use the triggering branch ref (`github.ref_name` / `github.ref`) instead of forcing the repository default branch, allowing releases to be generated from any branch selected when dispatching the workflow. Signed-off-by: Yi-Hsuan Deng <yhdeng@google.com> Change-Id: I1ef845b342d60b0d68bbd592e348c62d6a6a6964
[ot] subprojects: dtc: update to latest commit Includes commit 9a1c801a1a3c102bf95c5339c9e985b26b823a21 [0] which is needed for more recent compilers which reject the `const` qualifier being dropped by default. [0]: https://gitlab.com/qemu-project/dtc/-/commit/9a1c801a1a3c102bf95c5339c9e985b26b823a21 Signed-off-by: James Wainwright <james.wainwright@lowrisc.org>
[ot] hw/opentitan: ot_uart: model watermark/empty as status interrupts tx_watermark, rx_watermark and tx_empty are declared as status-type interrupts in the UART HWIP (uart.hjson / prim_intr_hw IntrT="Status"): their INTR_STATE bits are read-only and track the live FIFO condition every cycle rather than latching, so INTR_STATE writes do not affect them and they de-assert automatically once the condition clears. The model treated them as event-type, latching the bit on a receive batch and clearing it only via RW1C. As a result, once software drained the RX FIFO the latched rx_watermark bit stayed asserted, so the next received byte produced no fresh interrupt edge and interrupt-driven RX (e.g. a software-loopback test on ot-earlgrey) would hang. Compute the status-type bits live from the FIFO levels and OR them with the latched event-type bits when reading INTR_STATE and when driving the IRQ lines, so they assert and de-assert with the hardware condition: - rx_watermark: rx_fifo_depth >= threshold - tx_watermark: tx_fifo_depth < threshold - tx_empty: tx_fifo_depth == 0 Re-evaluate the lines after an RDATA pop and on FIFO_CTRL writes, and drop the now-unused tx_watermark edge-tracking state. The status-type bits are ro and never stored in regs[R_INTR_STATE], so the INTR_STATE RW1C write masks them out and only clears event-type bits. Also align the FIFO depths (TxFifoDepth=32, RxFifoDepth=64) and the watermark threshold mappings (TX saturates at TxFifoDepth/2; RX saturates at RxFifoDepth-2, with rxilvl=7 disabling the interrupt) with uart_core.sv, and only push as many received bytes as the RX FIFO can hold. Signed-off-by: Miguel Osorio <miguelosorio@google.com>
[ot] hw/opentitan: ot_darjeeling, ot_earlgrey: connect LC DEBUG to SRAM Connect the lifecycle controller's broadcast `LC_HW_DEBUG_EN` signal to each SRAM controller in both tops, to match the ifetch/execution enablement conditions that are specified in the RTL. Signed-off-by: Alex Jones <alex.jones@lowrisc.org>
[ot] hw/opentitan: ot_spi_device: Maintain CSb across transactions Rework handling of the emulated CSb (Chip Select) value to be performed manually rather than using the current bus state. The current behaviour assumes that CS is only active when the bus is not idle or in an error state, but in the case where we get an incoming transaction with a header with the `release` bit not set, this will lead to the host thinking that the CS is held asserted between transactions whereas the device thinks that it is released between them. Move to manually handling this CSb state on bus transition to mimic the previous behaviour with fixes for holding the CS across transactions. Signed-off-by: Alex Jones <alex.jones@lowrisc.org>
[ot] hw/riscv: dm: Handle haltreqs for unresponsive harts This patch works around the Debug Module's current non-conformance with the RISC-V debug specification in how it handles halt requests (haltreqs) to unresponsive harts (e.g. harts currently in reset). Several parts of the RISC-V Debug Specification refer to this behaviour (see sections 3.2, 3.4, 3.5) but section C.1.3 is specifically a bug fix defined just for this behaviour. The current DM implementation just ignores incoming halt requests if the hart is unresponsive. This commit instead latches these requests in a bitmask, so that when the hart comes out of reset (i.e. starts executing instructions) it can be checked and used to immediately halt the hart. Unfortunately, a fully correct implementation of this behaviour would likely require a direct link between the RISC-V CPU and the DM to allow the hart to be halted at this point. Such links are not currently supported by QEMU. This commit introduces a reasonable workaround where we poll the availability of cores on a `dmstatus` read and halt newly responsive harts with latched haltreqs there, relying on the fact that most debuggers interacting with the DM will write the haltreq and then repeatedly poll `dmstatus` to watch the harts halt (see e.g. section B.3 of the RISC-V Debug specification). This is not 100% conformant (if dmstatus is not polled for a while then the hart will execute some instructions whereas in real HW it would halt immediately before executing guest code) but is a small workaround / hack that can support the majority of practical use cases reasonably enough. Signed-off-by: Alex Jones <alex.jones@lowrisc.org>
[ot] hw/opentitan: ot_spi_device: Reduce arbitrary flipbuf pacing See the relevant comment - this arbitrary timeout is much longer than expected and can cause unexpected timeouts when using the SPI device for large reads with software that does not expect to handle this event and fill these buffers. When using an icount shift of 6, we can often end up waiting just over a second for the read to resume, greatly slowing down SPI operation. Signed-off-by: Alex Jones <alex.jones@lowrisc.org>
PreviousNext