Files

T

BFE EngineeringandClaude Fable 5 1d7dec167e clock diagnostics for issue #3 : probe, VM sanity scenario, fix plan

The qemu/ device sim answered the first question off-board: the same
kernel family under -M virt gives musl vDSO rate ratio 0.99963 — the
generic 6.18 armv7 vDSO is correct, so the board symptom is RV1106
register state (CNTFRQ/CNTVOFF, firmware-owned, secure-world boot chain).

- qemu/tests/clockprobe: interval-based musl probe separating RATE error
  (CNTFRQ) from boot OFFSET (CNTVOFF) — the original single absolute
  sample cannot distinguish them.
- qemu/tests/clock-sanity.sh: VM regression guard asserting the vDSO rate
  within 1% (PASSES: 1.00026); cross-builds the probe and stages it as
  payload itself.
- kernel/rv1106-enablement/timer/PLAN.md: the DT fix
  (arm,cpu-registers-not-fw-configured + measured clock-frequency on the
  board dts) gated on the two bench measurements; c8a3 is currently
  physically dark, needs hands at the bench.
- clockprobe joins the CI test loop.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018HUayid7W5w7jBdb9Rrj1K

2026-08-30 09:49:50 -06:00

2.2 KiB

Raw Blame History

arch-timer / vDSO clock fix — plan (issue #3)

Status: DIAGNOSED off-board, fix gated on two bench measurements.

Established (2026-08-30, qemu/ device sim)

The same kernel family under qemu-system-arm -M virt gives musl CLOCK_MONOTONIC/_RAW rate ratio 0.99963 vs /proc/uptime (interval measurement, qemu/tests/clockprobe). The generic 6.18 armv7 vDSO is therefore CORRECT; the board symptom (musl reads ~12% high, kernel time right) is RV1106-specific. The boot chain runs in the secure world and is closed rkbin — the NS view of the CPU timer registers (CNTFRQ, CNTVOFF) is whatever it left behind, and only the arch-counter path (vDSO, arch_sys_counter) trusts them.

What the bench must answer (single boot of the `_b` slot)

Run clockprobe (interval mode) on the 6.18 slot:

ratio_mono far from 1.0 -> RATE error: CNTFRQ wrong. The true rate = claimed rate (dmesg arch_timer: cp15 timer running at X MHz) times the measured ratio.
ratio_mono ~= 1.0 but abs_ratio far from 1.0 -> OFFSET error: CNTVOFF left nonzero; rate fine.

(The original issue measured only one absolute sample, which cannot distinguish these.)

The fix (both cases, one DT override)

Append to the BOARD dts (rv1106-warden.dts — never the vendor dtsi) an override on the armv7-timer node:

arm,cpu-registers-not-fw-configured;
clock-frequency = <MEASURED_HZ>;

The property makes the driver use the physical counter, ignore CNTVOFF, and take the frequency from DT — the documented remedy for firmware that does not configure the CPU timer registers. MEASURED_HZ comes from bench answer 1 (do NOT guess; a wrong value makes every clock wrong instead of one path). Ship as an update to the arch/dts patch in patches/.

Regression guards

Off-board: qemu/tests/clock-sanity.sh asserts the vDSO rate in the VM (guards the generic path; cannot see board registers).
On-board: re-run clockprobe on the patched _b slot; both ratios and the absolute ratio must be ~1.0. Record the numbers here and in issue #3.

Bench access note

2026-08-30: c8a3 is physically dark (CP2102 console silent through two remote power cycles; both network paths down) — needs hands at the bench before the measurements can run.

2.2 KiB Raw Blame History