Skip to content

IP28: the Indigo2 IMPACT R10000 and the IMPACT board model - #145

Closed
atomchild411 wants to merge 4 commits into
techomancer:mainfrom
atomchild411:ip28-pr
Closed

atomchild411 wants to merge 4 commits into
techomancer:mainfrom
atomchild411:ip28-pr

Conversation

@atomchild411

Copy link
Copy Markdown
Contributor

The Indigo2 IMPACT R10000 (IP28) and the IMPACT board model, as four
commits, one per feature. Everything IP28 is behind --features ip28;
without it none of this code is built and the R4400/R5000 machines are
unchanged.

  1. mgras: an IMPACT board model in place of the ID stub. The display
    control bus devices, the raster engine, the command FIFO and GE port,
    host DMA and the interrupt lines. It implements GfxDisplay and presents
    a prebuilt frame the way GR2 does, so CI screenshots work headless.
    [impact] takes a board in the graphics slot only.
  2. ip28: the IP28 machine and its R10000 CPU. machine.profile = indigo2_ip28 with cpu = "r10000": the R10000 shadow cache and its
    CACHE ops, R10000 Config/TagHi/64-bit TagLo, a 64-entry JTLB, 44-bit VA;
    the IP28's MC sizing (256 MB banks, IP28-only), low-memory alias, HPC3
    board revision, Count/MC clock rates; ppmem always on, with a remap that
    no longer leaves the window faulting. ip28.toml.example to start from.
  3. jitv2: loads and stores straight to the ppmem window when the cache
    keeps no line data (today only the R10000's). 1.5-1.7x on IP28 on the
    workloads below; nothing else takes the path.
  4. monitor: ps2 mouse; status bar: 8254 clock ticks.

Testing

  • cargo test --workspace and --lib with jitv2, ip28 and
    ip28,jitv2: every commit builds and passes in all four.
  • Indy unchanged: cpu-tests at the baseline on R4400 and R5000 (interp and
    jitv2); IRIX 6.5.22 boots on both and a checksummed workload (gcc,
    bzip2/gzip, perl, awk, fork and syscall loops) matches a build without
    this branch; Debian's IP22 kernel reaches its installer.
  • IP28: the real PROM passes POST (including the secondary-cache
    diagnostic) and IRIX 6.5.22 (64-bit) boots to the 4Dwm desktop on IMPACT
    in about 27 s with jitv2. Output of a workload over ssh is identical with
    and without the direct path.

Host GL for IMPACT comes separately, later.

🤖 Generated with Claude Code

atomchild411 and others added 4 commits September 29, 2026 19:18
src/mgras.rs answered the board-ID probe and nothing else. This is a
model of the Indigo2 IMPACT (MGRAS) graphics board that the PROM and the
IRIX X server draw on, as a module in src/mgras/:

- dcb.rs: the display control bus devices -- the VC3 timing and cursor,
  the XMAP, the colour maps and the gamma DAC.
- raster.rs: the raster engine -- lines (stippled too), rectangles
  and block fills, pixel logic ops, RGB and colour-index pixels, the
  overlay planes, window IDs -- plus its tests.
- mod.rs: the GIO interface, the command FIFO and geometry engine port,
  host DMA for pixel transfers, the three interrupt lines (FIFO, general,
  vertical retrace), and scanout into a finished frame.

The board presents like GR2 does: it implements `GfxDisplay` and hands
the renderer a prebuilt frame (`Rex3Screen::prebuilt`), keeping `rgba`
current so CI screenshots work headless. Register names follow OpenBSD's
impact(4) driver, or say what the register does.

`[impact]` accepts a board in the graphics slot only; a second head is not
modelled, and exp0/exp1 are refused rather than silently ignored.

Tested by the model's own unit tests here; it boots to the IRIX desktop on
the IP28 that the next commit adds.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A machine profile, `indigo2_ip28`, with an R10000 CPU model, built only
with `--features ip28` (which implies ppmem). Without the feature the
profile and the model are refused at startup with a message naming it,
and none of their code is compiled: `MachineProfile::ip28()` is a
constant false, so the R4400/R5000 machines are unchanged.

The R10000 (`CpuModel::R10000`, `R10000ShadowCache`):
- A shadow cache, out of the data path: loads and stores go to memory,
  while tag and data arrays exist to answer CACHE ops and the PROM's
  diagnostics -- two ways per set, 64-bit tags with TagHi, the set's MRU
  bit, and the ECC bits Index_Store_Data carries.
- Cache ops 5/6/7 take their R10000 meanings (CacheBarrier,
  Index_Load_Data, Index_Store_Data), and TagLo is a 64-bit register.
- An R10000-format CP0 Config, a 64-entry JTLB (the arrays are sized to
  the largest model; R4400/R5000 still use 48), and 44 virtual address
  bits.
- cpu-tests identifies the R10000 (`CPU_R10000`, not in `CPU_ALL`).

The IP28 board:
- The memory controller sizes banks the IP28 way (MEMCFG's size field
  counts units of the base shift, 256 MB banks, which only the IP28
  accepts), and the low-memory alias follows where RAM actually is.
- The HPC3 reports board revision 13, so IRIX does not take the machine
  for an early IP26 baseboard.
- Count runs at 97.5 MHz and the MC clock at the CPU clock, the rates
  IRIX assumes from the PROM's `cpufreq`; the generic ones made UST run
  at a third of real time.
- ppmem is always on. A MEMCFG write that moves no bank leaves the window
  alone, a real move bumps every generation counter, and cleared ranges
  are scrubbed to zero-filled memory rather than unmapped: IRIX rewrites
  MEMCFG during boot while the JIT's compile workers and DMA are running,
  and a stale reader used to fault.

Tracing goes through devlog (`log mips mask cp0`, `log l2c`), with a few
IRIS_IP28_* switches for the bring-up paths. `ip28.toml.example` is a
starting config.

The real IP28 PROM passes POST, including its secondary-cache
diagnostic, and IRIX 6.5.22 (64-bit) boots to the 4Dwm desktop on the
IMPACT from the previous commit, in about 27 s with jitv2.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…eeps no data

A CPU model whose cache keeps no line data (`CpuModel::DATA_PASSTHROUGH`,
today the R10000's shadow cache) gives jitv2 nothing to model on a load
or store. With a ppmem window published (`set_ppmem_window`, from the
machine before the compile queue starts), compiled code now does what
the callout would have done, inline: after translation, test the region
bit in `ppmem_bitmap`, then load or store at `jit_pp_base + phys` with
ppmem's byte-lane rules (doublewords rotated by 32, halves `^2`, bytes
`^3`), and bump the page's generation on a store so self-modifying code
still retires compiled regions. An unmapped region falls back to the
callout.

The window base and generation window are read from the core at run
time, never baked into the code, and `direct` is part of the persistent
cache's fingerprint, so code compiled with and without the path never
mixes. Models that keep line data are unchanged: the path is only
emitted when `JitConsts::direct_mem` is set, which needs both the model
constant and a window.

On the IP28, forcing the path off in the same build and running the same
workload in IRIX 6.5.22: an awk loop over a 4096-entry array 3.9 s
instead of 5.9 s, the whole workload (awk, a floating-point loop, tar of
/usr/include) 15.5-16.7 s instead of 27.5 s, with identical output.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
`ps2 mouse <dx> <dy> [buttons]` pushes one mouse packet (buttons: 1 left,
2 right, 4 middle), so a desktop can be driven from the monitor or a
script without a window to click in.

The status bar's Hz now counts 8254 timer 0/1 interrupts as well. IRIX
keeps time with the 8254 unless the IOC's is known broken, in which case
it uses CP0 Compare, which was already counted; either way the number is
the kernel's tick rate, and the two never both run.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@atomchild411

Copy link
Copy Markdown
Contributor Author

Replaced by #150: the same IP28/IMPACT work, with the JIT's fast path built on tcache instead of a separate direct path, and the cpu-tests harness change (which broke the prebuilt stamp check here) left out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant