Part II begins: everything a hart needs beyond the unprivileged ISA to run an operating system and talk to devices. The design brief matters — this privileged architecture is deliberately replaceable (the unprivileged ISA doesn’t depend on it) and deliberately conventional (level-based protection), because its job is to run existing OSes.
1.1 The software stack, formalized
The layered-EEI idea from ch. I·1 gets names at each level:
Figure 1’s three stacks. One SBI sbi/see Supervisor Binary Interface / Supervisor Execution Environment: the OS-to-firmware contract (user+supervisor ISA plus SBI calls). One SBI lets one OS binary run on a bootloader SEE, a hypervisor VM, or a simulator. Linux's SEE is typically OpenSBI in M-mode. defined in ch. II·1 — open in glossary across all SEE implementations means one OS binary boots on firmware, under a hypervisor, or in a simulator.
1.2 Privilege levels
A hart always runs at some privilege mode privilege mode The mode a hart currently runs at: U=00, S=01, M=11 (10 reserved), encoded in CSR state but not directly readable. M is mandatory and fully trusted; legal combos are M, M+U, M+S+U (the Unix/Linux configuration). defined in ch. II·1 — open in glossary , encoded in CSR state (note: no CSR directly reads out the current mode — software knows it by construction):
| Encoding | Role | |
|---|---|---|
| M — Machine | 11 (level 3) | Mandatory. Inherently trusted, unfettered access |
| (reserved) | 10 (level 2) | Reserved encoding — decode your 2-bit mode register accordingly |
| S — Supervisor | 01 (level 1) | The OS home: adds virtual memory (ch. II·12) and its own trap machinery |
| U — User | 00 (level 0) | Applications; least privilege |
| Combos | M / M+U / M+S+U | Embedded / secure embedded / Unix-like |
The spec’s careful distinction: the level code is written for versus the mode it runs in. An S-level OS binary can run deprivileged in U-mode under a VMM, its privileged actions trapped and emulated by the SEE — same binary either way.
Normal life of a hart: U-mode application → trap (ECALL, timer, fault) → handler in a more-privileged mode → return. Traps that climb modes are vertical vertical vs horizontal trap Vertical = trap to a higher privilege mode (the hardware primitive); horizontal = handled at the same mode, implementable as a vertical trap that returns control to a less-privileged handler (what delegation automates). defined in ch. II·1 — open in glossary ; same-mode traps are horizontal — and hardware only needs vertical as the primitive (horizontal = vertical + return-to-lower-handler, which is what trap delegation automates in ch. II·3).
1.3 Debug mode
D-mode d-mode Debug mode: an optional above-M privilege level from the separate debug specification; reserves a few CSR addresses (only accessible in D-mode) and possibly physical address space. defined in ch. II·1 — open in glossary sits above even M-mode for off-chip debug and manufacturing test, specified separately. Two footprint reservations touch your design regardless: a few D-mode-only CSR addresses (0x7B0–0x7BF region) and possibly a slice of physical address space.
Hardware Designer Notes
This chapter fixes the mental frame for all of Part II: M-mode firmware (your SBI implementation — in practice OpenSBI) is part of the hardware deliverable for a Linux-bootable CPU. When Linux says “boot”, it means: reset → M-mode init (p03) → delegate traps → drop to S-mode kernel via the SBI contract — every following chapter builds one piece of that path.
Minimal Linux-boot hart MUST
- Implement M+S+U for the Linux target; keep the current mode as internal (non-CSR-readable) 2-bit state, encoding 10 rejected
- Land reset in M-mode with everything trusted from there (the p03 reset story)
- Leave the D-mode CSR addresses unclaimed even if you never build debug
MAY simplify / trap-and-emulate
- Ship M-only or M+U variants of the same core for embedded SKUs — the modes are designed to subset cleanly
- Treat horizontal traps purely as software convention over vertical hardware
Check yourself — privilege stack basics
1.Which privilege-mode combination does a Linux-bootable core implement, and which single mode is mandatory for ANY RISC-V hardware?
2.An S-level OS binary runs in U-mode under a classic virtual machine monitor. How do its privileged instructions work?
3.What makes the SBI worth standardizing separately from the hardware platform?
4.What's a horizontal trap, and must hardware support it directly?