HarvOS Processor

FPGA processor prototype

HarvOS is an observable 32-bit processor for secure boot and runtime experiments.

The core combines an RV32I-like integer ISA with strict Harvard separation, local supervisor CSRs, MMU/MPU checks, USB/block-image boot, HNET network MMIO, PHP/Zend experiments and a compact SQL server path. It is small enough for MiSTer experiments and concrete enough to boot real ELF services.

Read processor docs View boot path

What the processor currently implements

RV32I-like

Integer core with local extensions

Base arithmetic, branches, loads/stores, CSRs, traps and three Custom-0 instructions: CLRREG, CLRMEM and ENTROPY.

Harvard

Separate instruction and data paths

Instructions are fetched from IMEM, while data accesses go to DMEM or MMIO. The data path cannot directly rewrite executable memory.

MMU/MPU

Translation plus hard region checks

Refillable I/D TLBs, 4 KiB page semantics, access/dirty checks, user/supervisor policy, W^X rejection and fixed HarvOS region rules.

HNET

Networking as a real SoC device

RX/TX DMA, interrupt status and packet counters are exposed as supervisor MMIO. HarvTTP and HarvSQL use this path in the test network.

Architecture map

A core designed to make its trust boundaries visible.

HarvOS is not documented as a generic RISC-V platform. Encodings are intentionally RISC-V-like, while privilege state, CSRs, MPU rules and boot state remain HarvOS-specific. That keeps the prototype focused on the invariants required for isolated boot, service loading and device I/O.

Pipeline model
Deterministic multi-cycle state machine: fetch, decode, execute, memory, writeback and clear-memory.
SMP prototype
Two harvos_cpu instances in the SoC, connected through a round-robin shared data bus.
DMA protection
Device transfers are constrained through an IOMMU-lite bounce window instead of writing arbitrary RAM or IMEM.
HarvOS CPU diagram with fetch path, data path, MMU, MPU, boot ROM, IMEM and DMA window
CPU-internal view: PC and fetch MMU on the instruction side, LSU and data MMU on the data side, separated by a hardware Harvard boundary.

Boot path

From image to application without hiding the core.

  1. 01

    Reset and boot ROM

    Hart 0 starts at 0x00000000; the second hart is started or parked by the SoC integration.

  2. 02

    Images and manifests

    Program and data USB images provide ELF files, YAML configuration, web roots, SQL seed scripts and app parameters.

  3. 03

    ELF load into IMEM/DMEM

    The loader validates ELF32/RISC-V-like binaries, places segments and builds the application start block.

  4. 04

    Lock and runtime

    After loading, IMEM is locked. Services such as HarvTTP and HarvSQL run as real ELFs through HNET.

Documentation

Technical detail instead of generic landing-page gloss.

Open processor docs
ArchitectureCPU cluster, memory, loader, MMIO and SoC integration. ISAOpcode formats, RV32I-like operations, Custom-0 and trap behavior. MemoryIMEM, DMEM, page tables, TLBs, MPU and Harvard faults. PHP 8.5HarvOS SAPI, Zend worker model, runtime limits and WordPress-oriented build path. HarvSQLMySQL-compatible SQL ELF, catalog format, seed/migration scripts and limits. HarvTTPThe HTTP service loaded through the HarvOS boot path and HNET device.

Prototype status

An honest prototype status, not a polished claim.

The current core is a synthesizable FPGA prototype and test platform. Some blocks are hard RTL paths; others are intentionally observable models for later production logic.

  • Cache and coherence modules expose metadata and counters while the MiSTer data path remains bus-serialized.
  • Secure boot checks hash/HMAC metadata; a production design can replace the hook with public-key hardware.
  • MiSTer uses HPS block images as a practical storage path; direct USB host integration is prepared as MMIO/HCD logic.
  • External DDR integration is abstracted and can replace the internal prototype RAM.