RISC-V Sstc Bring-Up: Enable the Supervisor Comparator Before Replacing SBI Timer Calls

An RV64 supervisor can read time but traps when it writes stimecmp. Another build accepts the write yet never enters its timer handler. Both failures can occur on a platform advertised as supporting Sstc, because extension presence, CSR access and interrupt delivery are separate parts of the integration.

This article follows Sstc version 1.0, the Machine-Level ISA 1.13 enable controls and the Supervisor-Level ISA 1.13 timer contract, all pinned at commit ff6bb3c. The scope is an RV64, nonvirtualized S-mode timer path. RV32 split-register updates and virtual-supervisor timers need additional handling and are deliberately excluded. No timer or firmware was executed.

Identify what Sstc changes

Without direct supervisor compare support, a supervisor execution environment can provide timer scheduling through SBI. Machine firmware arranges the timer source and delivers the lower-privilege timer indication. Sstc provides a supervisor-owned stimecmp CSR so S-mode can program its comparison directly when the platform enables access.

That change concerns how the deadline is programmed and how the timer-pending signal is generated. It does not remove the ordinary interrupt enables, delegation rules or the need for a correct supervisor trap entry. An application delay API also remains dependent on the operating system’s scheduler and time conversion.

Record the selected runtime path rather than guessing from the source tree. A kernel may retain an SBI fallback while another build selects direct CSR programming. Seeing an Sstc implementation in the processor documentation does not prove the boot firmware exposed it to the running supervisor.

Check the two machine-controlled access gates

The STCE field in menvcfg enables S-mode access to stimecmp. If Sstc is not implemented, that field is read-only zero. If Sstc is implemented but STCE=0, an attempt outside M-mode to access stimecmp raises an illegal-instruction exception.

The machine counter-enable register supplies another gate. If mcounteren.TM=0, access to stimecmp below M-mode also raises an illegal-instruction exception. A platform that sets only STCE has not necessarily completed the access contract.

Conversely, successful S-mode access to time supports a narrower conclusion: the applicable counter access is permitted. It does not prove that STCE is set or that the supervisor comparator exists. This explains why a diagnostic can print advancing timestamps immediately before faulting on its first comparator write.

These are machine-controlled settings. Diagnose them through the platform’s documented firmware handoff, supported diagnostics or an approved bring-up debugger. Do not insert M-mode CSR writes into an ordinary S-mode driver and expect privilege to appear. Keep extension discovery, firmware policy and the actual CSR-access result as distinct evidence.

Original Sstc integration diagram. Passing an earlier gate does not establish the later interrupt-handler outcome.

Know which operation clears the pending condition

For the enabled comparator path, a supervisor timer interrupt becomes pending when the unsigned time value reaches or exceeds stimecmp. It remains pending until the compare value is greater than current time, normally because software programs a future deadline.

Changing the supervisor interrupt-enable bit does not acknowledge the comparison. It merely changes delivery eligibility. Likewise, copying an old software-injected timer routine that attempts to clear a pending bit is not the correct completion mechanism for an active hardware comparator.

The menvcfg.STCE=0 case matters here too: the machine specification says timer-pending behavior reverts to the definition without Sstc. Do not combine one build’s software-injected pending-bit procedure with another build’s enabled direct-comparator procedure. Document who owns the timer source and which operation removes its pending condition.

The comparison’s change need only propagate to STIP eventually. A handler that writes a future deadline and returns can encounter an occasional still-pending timer interrupt. Preserve that allowed propagation behavior in the handler design instead of treating every immediate re-entry as proof that the CSR write failed.

Test delivery separately from comparator access

After proving the CSR write is supported, inspect the intended supervisor timer enable, delegation and current privilege/global-enable conditions. Confirm the actual trap entry reaches the timer dispatch path. A pending source that cannot presently trap is a delivery configuration problem, not evidence that the comparator is absent.

Use two bounded test cases in an isolated bring-up fixture. First, schedule a comfortably future deadline using the platform’s real timebase conversion. Record comparator programming, pending state where readable, and handler entry separately. Second, exercise a deadline that is already due and verify that the handler advances it according to the operating system’s policy rather than spinning on an unchanged expired value.

Do not derive timer units from the current CPU clock merely because both are frequencies. The platform defines the timebase used by time; Sstc does not redefine it as core cycles. Retain the actual frequency source and conversion arithmetic in the test record.

Preserve a compatible fallback deliberately

The supervisor timer specification explicitly preserves SBI-based timer scheduling: a supervisor execution environment can implement the existing service using stimecmp internally. Direct CSR support therefore does not require deleting the supported SBI path from every software image.

Choose the path through the platform’s established feature negotiation and firmware contract. If a required direct-access condition is missing, use an actually supported fallback or report an explicit unsupported configuration. Do not recover from arbitrary illegal instructions by assuming all of them mean “retry through SBI.”

No access-gate matrix, deadline or trap test was run here. A useful handoff contains the implemented extension, firmware enable policy, selected programming interface, timebase, pending-state behavior and verified interrupt route. That evidence distinguishes a missing CSR permission from an undeliverable interrupt without attributing every timer failure to the same feature flag.