A six-month survey of upstream Linux kernel, QEMU, and OpenSBI development by Tenstorrent contributors, intended as source material for a NotebookLM "deep dive" audio podcast about the team. Drew Fustini's own patch series (CBQRI, Ssqosid, RQSC, kernel-side IOMMU bindings, and his maintainer-hat pull requests) are deliberately excluded: those are the listener's own work and would dilute the focus on coworkers.
The period covered is roughly 2025-11-09 through 2026-05-09, the six months ending the day before the corpus was assembled.
Tenstorrent is upstreaming a complete RISC-V software stack for two SoCs. The work touches three different upstream communities and three different mailing lists:
- lkml / linux-riscv / dt / clk / arm-kernel / acpi / iommu: kernel enablement. Device-tree bindings, clock and reset drivers, perf support, IOMMU bindings, SWIOTLB fixes.
- qemu-devel / qemu-riscv: the virtual model. Machine model for
Atlantis, the
tt-ascalonCPU model, RVV correctness, debug-trigger emulation. - opensbi mailing list (lists.riscv.org/g/opensbi): the M-mode firmware that boots before the kernel. Atlantis platform glue, the Smrnmi resumable-NMI extension, dbtr (debug-trigger) extensions, PMP encoding refactor for the Tenstorrent IOMMU.
These three layers move in lockstep. The QEMU model boots OpenSBI and the Linux kernel built for Atlantis. Bring-up of new RISC-V extensions in hardware (Smrnmi, Sdtrig) needs all three to land coherently. This report tracks each contributor's work and the cross-layer dependencies between them.
| Person | Layer | Major focus | |
|---|---|---|---|
| Anirudh Srinivasan | asrinivasan@oss.tenstorrent.com |
kernel, opensbi | Atlantis PRCM (clk/reset), Blackhole DT, payload alignment |
| Joel Stanley | joel@jms.id.au, jms@oss.tenstorrent.com |
qemu | Atlantis machine model v1-v4, tt-ascalon mvendorid |
| Nicholas Piggin | npiggin@gmail.com, npiggin@oss.tenstorrent.com |
qemu, opensbi | Atlantis machine v5, dbtr, Sdtrig, OpenSBI Atlantis platform, PMP refactor, IOMMU |
| Anton Blanchard | antonb@tenstorrent.com |
qemu | RVV emulation accuracy: LMUL, mask reg, reductions |
| Michael Ellerman | mpe@oss.tenstorrent.com |
qemu | tt-ascalon mvendorid commit reference + reviews |
| Michael Neuling | (via Anirudh) | kernel | Blackhole PMU device-tree node (original author) |
| Evgeny Voevodin | evvoevod@tenstorrent.com, evvoevod@oss.tenstorrent.com |
opensbi | RISC-V Smrnmi extension, three revisions |
Only Anirudh, Joel, Nicholas, and Anton initiated full series during the period. Michael Ellerman and Michael Neuling appear as named authors on single artifacts but their public list activity is limited. Evgeny appears only on the OpenSBI list, not on lkml or qemu-devel, but his Smrnmi work is the second-most active OpenSBI series after Anup Patel's maintenance flow.
The longest-running and most-iterated arc. Anirudh shipped the Atlantis PRCM (clock and reset controller) driver across eight revisions between 2026-01-15 and 2026-03-06, then the Blackhole PMU device-tree node and a Blackhole-tested SWIOTLB above-4GB fix in April.
The PRCM is the clock and reset controller for the Atlantis SoC's RISC-V
cluster. It exposes resets and a small set of configurable clocks to
the kernel via the standard clk and reset frameworks. The driver
itself is small (a few hundred lines of C); the long iteration count is
about getting the device-tree bindings, KConfig naming, and the driver
shape right.
v1, 2026-01-15: 8 patches, custom syscon approach. The first
posting wired the PRCM as a syscon with separate child nodes for
clocks and resets. Reviewers (Krzysztof Kozlowski, Conor Dooley, Rob
Herring) pushed back: the syscon path is for legacy IP that has no
kernel framework presence; PRCM should use the standard clk and reset
DT framework.
v2, 2026-01-22: 3 patches, restructured. Anirudh dropped the
syscon scaffolding and made it a single platform driver registering
through clk and reset_controller. Cuts ~60% of the diff size.
v3, 2026-01-26: minor binding tweaks. Adjusted the description of
the clock cells, added the standard reg with width specification.
v4, 2026-01-30: review-driven changelog. Krzysztof asked for kernel-doc on the clk/reset id macros; Conor asked for an exact description of the reset latching behavior.
v5, 2026-02-02: this version drew the most review activity (18
messages). Real architectural feedback this round: Krzysztof noted that
naming the compatible string tenstorrent,atlantis-prcm was a
ratification problem because future Atlantis variants might add a
"system PRCM" distinct from the RISC-V cluster PRCM, and the
filename-must-match-compatible rule would lock in confusion. The
rename atlantis-prcm -> atlantis-prcm-rcpu ("RISC-V CPU PRCM")
landed in v6.
v6, 2026-02-16: the big rename. All compatible strings, file
names, and KConfig symbols carry the -rcpu suffix. Stephen Boyd (clk
maintainer) starts paying close attention.
v7, 2026-03-03: KConfig polish, default to n, fixed a build
failure on !OF. Phlipp Zabel reviewed the reset side and gave
Reviewed-by.
v8, 2026-03-06: final. All three patches collected a full
Reviewed-by: set from the DT, clk, and reset maintainers. Anirudh's
work is the last-author commit in the series. Drew's role here is to
pick up the patches into the Tenstorrent SoC tree and act as the
intermediary between Anirudh and the maintainer-stable trees.
Resolution.
On 2026-03-10 Mark Brown noted a small linux-next conflict between the
Tenstorrent clk branch and another tree; that thread is in
add-tenstorrent-clk-to-linux-next. On 2026-03-16 Stephen Boyd issued
the formal pull request [GIT PULL] clk: tenstorrent: Add Atlantis PRCM for v7.1. Merged.
riscv-dts-tenstorrent-add-pmu-node-to-bl, 2026-04-09. A single-patch
DT addition: defines the riscv,pmu node for the Tenstorrent Blackhole
SoC so Linux's perf subsystem can see the hardware performance counters.
Originally written by Michael Neuling, posted by Anirudh, reviewed by
Drew. Two messages. Queued for tenstorrent-dt-for-next.
riscv-mm-fix-swiotlb-initialization-for, 2026-04-03. Authored by
Troy Mitchell (SpacemiT), not Tenstorrent. Anirudh added a Tested-by:
indicating he booted Linux on Tenstorrent's Blackhole accelerator card
with this patch and verified the fix. Blackhole has all DRAM above 4GB
so this fix is functionally required for them.
srinivasan-payload-alignment (opensbi list), 2026-05-08. A single
patch: platform: Fix payload alignment when FW_TEXT_START isn't 2M/4M aligned. Switches FW_PAYLOAD_OFFSET to FW_PAYLOAD_ALIGN in the
generic and template makefiles. Root cause: FW_PAYLOAD requires the
payload at a 2M (RV64) or 4M (RV32) aligned address, but
FW_PAYLOAD_OFFSET only worked when FW_TEXT_START was already
aligned. For FW_TEXT_START=0x80000, the payload ended at 0x280000,
not 2M aligned. No review captured in the window; this is a clean
correctness fix.
A platform-driver person. Eight iterations of a clock driver to land it cleanly is the kind of patient, review-driven work that mature upstream contributors do. His name appears on three different lists (lkml-DT, opensbi, riscv) and on both Atlantis and Blackhole. He is also the Tenstorrent contact who validates other people's RISC-V mm fixes against actual hardware.
The virtual machine model of Atlantis used for software bring-up before hardware availability. Five revisions over five months, with a leadership handoff at v5.
v1, 2026-01-06 (hw-riscv-add-the-tenstorrent-atlantis-mach). Joel
Stanley posts a 14-patch series introducing the tt-atlantis QEMU
machine, including a custom boot-helper, AIA setup, machine-specific
device tree generation, and rudimentary PCIe and i2c skeletons. Anton
Blanchard, Daniel Henrique Barboza (Ventana), and Alistair Francis (WD,
QEMU RISC-V maintainer) review. Major themes: rework the boot helper
into something more general, drop or rework the bus controllers,
clarify the Svadu/Svade setup.
v2, 2026-01-14: 11 patches. Boot helper made more general, AIA moved to a helper file, some review cleanup. But several big questions remain: the PCIe model uses a custom RC instead of pcie-host-mmio, the i2c controller is under-specified.
v3, 2026-04-21: 21 patches, three-month gap from v2. Joel comes
back with a substantial respin. pcie-host-mmio is still custom; new
patches address discontiguous memory in boot_info. Andrew Jones gives
detailed feedback on the boot-info patches. This version sees Nicholas
Piggin appear on the patch list as a co-author for the first time.
v4, 2026-04-25: 24 patches. Last version with Joel as primary author. At this point both Joel and Nick are visible on the cover; the implicit handoff is in progress.
v5, 2026-05-07: Nicholas Piggin sole author. Cover letter: "I will taking over this series while Joel is away. Many thanks to the reviewers on v4." Nick's strategy is decisive narrowing: drop the PCIe controller patch entirely (will be reposted with the standard DesignWare controller in a follow-up), drop all I2C work (significant changes should be made independently), move the OpenSBI dummy payload hack from a generic boot helper into tt-atlantis-specific code, remove a redundant AIA MAINTAINERS entry, and update Microchip pfsoc to use the new discontiguous boot_info API. Nine-patch series, ~975 LOC, down from v4's ~2300 LOC. Reviewed by Daniel Henrique Barboza, Philippe Mathieu-Daude, and Andrew Jones.
The one remaining open thread at end-of-window is Andrew's observation
on the Svadu/Svade extension patch (patch 6). Nick's commit message
said "QEMU makes Svadu and Svade mutually exclusive, remove Svade so
Ascalon comes up with Svadu working." Andrew's correction: Svadu and
Svade aren't mutually exclusive, see commit 70d22fd92c3b
("target/riscv: Gate hardware A/D PTE bit updating"). The cleanest
model is to enable both extensions and let Linux negotiate Svadu through
the SBI FWFT extension SBI_FWFT_PTE_AD_HW_UPDATING. Practical caveat:
Linux doesn't yet support checking for and enabling this FWFT, so kernel
patches are still needed. The right answer is debatable until Linux
catches up.
Joel Stanley owned the series for v1-v4 (January through April 2026) and then handed it to Nicholas Piggin while away. This is a clean example of how an open-source SoC bring-up team can rotate without losing momentum: Joel had the institutional context from authoring the machine, Nicholas had the systems-level context to make the right narrowing decisions when the series threatened to grow. v5 is half the size of v4 because Nick was willing to defer two whole sub-systems to follow-up series rather than continue chasing perfection on PCIe and i2c.
Without the QEMU machine, software for Atlantis can't be developed or
tested in CI before hardware exists. This series is the bottom of the
software stack, everything else (OpenSBI Atlantis platform, kernel
device-tree, perf, Smrnmi support) is gated by a working tt-atlantis
QEMU machine. Nick himself notes in the OpenSBI Atlantis platform v1
cover: "Atlantis hardware is not yet released, and QEMU models are in
the process of being upstreaming, but at the moment not complete." The
v5 narrowing accepts that status: get the core working first, layer on
PCIe and i2c later.
Ascalon is Tenstorrent's in-house RVA23-compliant RISC-V CPU. QEMU's
tt-ascalon CPU model is a long-running effort to give it accurate
emulation. Three sub-threads in this window:
Two posts a few days apart in January. v1 on 2026-01-10, v2 on
2026-01-14, both authored by Joel Stanley. Michael Ellerman appears as a
co-author on v1 (his name is in the From-author list per the corpus
metadata). The single patch sets the proper Tenstorrent JEDEC mvendorid
on the tt-ascalon CPU. Reviewed by Daniel Henrique Barboza, Andrew
Jones, and Alistair Francis.
Resolution.
On 2026-04-29 Alistair Francis sent [PULL 37/51] target/riscv: tt-ascalon: Add Tenstorrent mvendorid as part of his pull request
that became QEMU 11.1. Merged. This is the first official Tenstorrent
identifier in upstream QEMU.
target-riscv-debug-sdtrig-fixes-and-tt-asc-rfc, 2026-01-14. A
25-patch RFC by Nicholas Piggin introducing Sdtrig (RISC-V hardware
debug-trigger) emulation in QEMU, including a per-CPU debug_cfg
framework for Ascalon's heterogeneous 9-trigger layout (4 breakpoint, 4
watchpoint, 1 instruction-count). Sdtrig is the hardware-breakpoint
extension; emulating it accurately means the QEMU debug stub can drive
trigger registers identically to real Ascalon hardware.
No on-list replies were captured during the window. This is a Nick research-prototype: the patches build internally, but the upstream review activity hadn't started by 2026-05-09. There's a parallel OpenSBI Sdtrig story (the dbtr 18-patch series in storyline 7) which is very active; the QEMU side will follow when there's hardware to test against.
Anton's tour of QEMU's RVV (RISC-V Vector) implementation, with all
five fixes posted in two short bursts in January and April. The
through-line is that Tenstorrent runs real workloads on QEMU
tt-ascalon and was hitting QEMU/hardware divergence on vector
operations. Each patch is targeted, small, and identifies a specific
spec-vs-implementation gap.
1. Fractional LMUL on SHA crypto (target-riscv-rvv-allow-fractional-lmul-o,
2026-01-04). QEMU was rejecting fractional LMUL values on the SHA
extension's vector instructions. The spec allows them. Reviewed-by
Daniel Henrique Barboza. Awaiting application as of EOD 2026-05-09.
2. mask_reg_full_update option (target-riscv-rvv-add-mask-reg-full-updat,
2026-01-05). Adds an optional behavior flag to QEMU to match Ascalon
hardware's mask register update behavior. When set, the entire mask
register is overwritten by mask-producing instructions (vmsop, etc.),
instead of leaving the upper unused bits as the spec recommends but
doesn't mandate. No review captured. This is the kind of "vendor
behavior" knob Tenstorrent needs to flip in QEMU to make tt-ascalon
match real silicon for software bring-up.
3. vext_check_input_eew on reductions (target-riscv-rvv-apply-vext-check-input-v3,
2026-04-17). v3 of a series adding EEW (Effective Element Width) checks
to reduction instructions. Carried forward by Max Chou (SiFive) into
his QEMU tree; patches 1/3 and 3/3 applied, 2/3 withdrawn for a scalar
vd/vs1 issue.
4. Reduction mask/source overlap (target-riscv-rvv-handle-mask-source-over,
2026-04-17). Mask and source register overlap rules on reduction
instructions. Reviewed-by Daniel Henrique Barboza. Applied to
riscv-to-apply.next by Alistair Francis.
5. Widening reduction source overlap (target-riscv-rvv-handle-source-overlap-o,
2026-04-17). Same day as #4; covers source register overlap on
widening reduction instructions. No captured reply at end-of-window.
Distinct from the other contributors: focused, narrow, fast. Five patches, each independently mergeable, each a real correctness fix identified by hardware-vs-emulator divergence. This is the kind of work that makes a vendor presence on QEMU look healthy; it isn't about landing a feature, it's about closing the gap between the vendor's CPU and the canonical model. Three of the five are now in maintainer trees.
The M-mode firmware glue for Atlantis. Three sub-pieces:
Cover-letter Message-Id 20260310005000.3837512-1-npiggin@gmail.com.
Four patches:
- Add Atlantis as a generic-platform. Enables
single_fw_regionoption, verifies and prints HART PMA CSR configuration. Createsplatform/generic/tenstorrent/{ascalon.c,atlantis.c,pma.c,Kconfig, objects.mk}anddocs/platform/tt-atlantis.md. ~330 LOC. - Move PMP encoding into a new file (precursor to the standalone PMP refactor in storyline 9).
- Add
hart_prefix to PMP functions. platform: generic: tenstorrent: Add RISC-V IOMMU support.
The IOMMU patch (4/4) depends on a Linux device-tree binding RFC for
tenstorrent,riscv-iommu posted to linux-riscv (Drew's RFC,
Message-Id 20260310003850.3837030-1-npiggin@gmail.com). Atlantis's
RISC-V IOMMU implements PMP MMRs in the same encoding as the hart PMP
CSRs, motivating the shared-encoding refactor.
After early review, Nick split out the PMP refactor and IOMMU patches into separate series. v2 is a single-patch repost of just the platform skeleton + PMA/Ascalon scaffolding. v3 (a few hours later same day) is "Fix silly 32-bit build issue".
The v1 → v2/v3 split is a typical OpenSBI development pattern: get the platform scaffolding in, then layer feature work on top. By splitting the IOMMU and PMP refactor out, Nick made each piece independently reviewable.
OpenSBI is the M-mode supervisor binary interface implementation that
sits between the kernel and the hardware on RISC-V. It boots, sets up
PMPs, programs interrupt controllers, and provides ecall services to
S-mode (Linux). Atlantis can't boot a useful kernel without OpenSBI
support. Nick's v1 cover spells out the public-facing description:
"The Tenstorrent Atlantis is an SoC and development board from
Tenstorrent in partnership with CoreLab Technology. It contains 8
RISC-V RVA23 compliant Tenstorrent Ascalon cores with RISC-V AIA,
RISC-V IOMMU, and a range of devices and IO connectivity." Recent (6.18)
Linux/riscv 64-bit defconfig kernels run the QEMU tt-atlantis
machine.
End-of-window: under active review. Anup Patel (OpenSBI maintainer) hasn't yet applied the platform skeleton, but the structure is clean and follows the existing pattern set by the eswin and starfive generic platforms. Once it lands, the PMP refactor (storyline 9) and the IOMMU (deferred) will follow.
The most fascinating cross-vendor handoff in the corpus. RISC-V Smrnmi (Resumable Non-Maskable Interrupts) adds three CSRs (MNEPC, MNCAUSE, MNSTATUS), an NMIE bit so NMIs can be delivered without permanently destroying machine context, and routing of traps to NMEVEC when NMIE=0. It's the canonical RISC-V way to implement watchdog or hardware-fault NMIs.
Two parallel efforts ran in this window: SiFive started, Tenstorrent finished.
Nylon Chen (nylon.chen@sifive.com), v3 of [PATCH 0/3] [PATCH v3] lib: sbi: Add RISC-V Smrnmi extension support. Co-developed-by Zong
Li (SiFive), Suggested-by Nick Hu / Samuel Holland (SiFive),
Signed-off-by Yong-Xuan Wang (SiFive). v3 split a single patch into
three per Anup's earlier feedback: detection, enable handler, common
NMI trap handler in fw_base.S. Adds sbi_rnmi_vector_init() to
allocate per-HART RNMI context, platform op set_rnmi_trap_vector()
for vector programming, suspend/resume support for RNMI CSRs.
This SiFive series did not land. Anup gave detailed review and asked for another revision. None came.
Tenstorrent's Evgeny Voevodin posts [PATCH 0/7] Add RISC-V Smrnmi extension support, Message-Id
20260310183155.2186463-1-evvoevod@oss.tenstorrent.com. Based on top
of Nick Piggin's Atlantis platform v1, a deliberate choice to land
the dependency-aware sequence.
Provides infrastructure for Resumable NMI (RNMI) and Resumable NMI
Exception (RNME) handling: dedicated MNEPC/MNSTATUS/MNCAUSE CSRs,
implementation-defined NMI vector locations via NMIVEC/NMEVEC. Patches
1-5 are shared infrastructure, tmp1 scratch slot (RNMI handlers use
MNSCRATCH instead of MSCRATCH and need separate scratch space), Smrnmi
extension macros and enum bit, RNMI/RNME handlers in firmware/fw_base.S,
platform callback smrnmi_handlers_init(), detect-and-enable Smrnmi
early before trap-based feature detection. Patches 6-7 are Tenstorrent
platform glue: Ascalon callback hookup and Atlantis stub handler.
Testing: "Verified on virtual Whisper platform." (Whisper is a Tenstorrent simulator.)
Major rework based on Anup's review. Five patches.
Dropped patches 6/7 and 7/7 (Tenstorrent platform support). Per cover: "They will go through the Atlantis platform series instead." So Smrnmi-on-Atlantis explicitly depends on the Atlantis platform series landing first. This is the cleanest illustration of cross-series sequencing in the corpus: Nick's Atlantis platform must merge before Voevodin's Smrnmi-on-Atlantis can.
Dropped the dedicated _rnme_handler assembly entry, ops->rnme_handler
callback, and sbi_rnme_handler() C function. RNME is now reused
through the existing _trap_handler since RNME is taken as a regular
M-mode trap with NMIE=0; ops->smrnmi_handlers_init() passes
_trap_handler in place of _rnme_handler. Renamed _rnmi_handler
-> _trap_rnmi_handler and the C handler to
sbi_trap_rnmi_handler(). Kept ops->rnmi_handler as the temporary
RNMI dispatch mechanism.
The Zkr collision. Between v1 and v2, upstream introduced commit
ecdb6c90 ("firmware: Initialize stack guard via Zkr"). The Zkr
seed-CSR access can trap if Zkr is unimplemented. On Smrnmi platforms
NMIE=0 by default after reset, which routes that trap to NMEVEC
instead of MTVEC. With no NMEVEC handler installed yet, the early-boot
Zkr probe in _start would crash. New patch 4/5 refactors the inline
seed loop in fw_base.S into a callable __stack_chk_guard_init and
invokes it from init_coldboot() after sbi_hart_init() has installed
Smrnmi handlers and set NMIE=1. This is one of those "two well-meaning
improvements collide" situations that only show up when you actually
boot the firmware.
Six patches. Title changed to "Add RNMI handler infrastructure for
Smrnmi extension" (more accurate for the scope). Rebased on
2257e9957103 ("lib: sbi_bitmap_test: add tests for bitmap_empty()").
Per Anup's v2 review, splits former patch 4 into two:
- Patch 4: only moves
sbi_platform_extensions_init()to the beginning ofhart_detect_features(). - Patch 5: moves Zkr stack-guard initialization out of
fw_base.Sintoinit_coldboot()in C, and drops the asm__stack_chk_guard_init()helper,__stack_chk_guardis initialized directly frominit_coldboot().
Testing now also on a HW emulator in addition to Whisper. Patch 2
("Add Smrnmi extension macros for registers and bits") picked up
Reviewed-by: Anup Patel. This patch defines MNSTATUS_NMIE/MNPV/MNPP
and CSRs CSR_MNSCRATCH=0x740, CSR_MNEPC=0x741, CSR_MNCAUSE=0x742,
CSR_MNSTATUS=0x744, plus enum bit SBI_HART_EXT_SMRNMI.
The series is in advanced review at end-of-window; only the Zkr split is left to settle.
Same hardware extension, two different teams. SiFive proposed it, Anup reviewed it carefully, SiFive went silent. Tenstorrent picked the work up three months later and pushed it to ratification with v3 showing real traction. The RISC-V upstream community is small enough that this kind of cross-vendor relay is observable on a single mailing list. The CSR encodings and MNSTATUS bit definitions are common between both efforts; the implementation details differ in sophistication (Voevodin's v3 handles the Zkr-stack-guard race that SiFive's never tested for, because Smrnmi-on-Atlantis requires it).
piggin-dbtr-18patch.mbox, 2026-03-13. An eighteen-patch series:
dbtr: Fixes and heterogeneous trigger types, Message-Id
20260313051948.4017134-1-npiggin@gmail.com.
Motivated explicitly by "implementing and testing heterogeneous trigger types as found in the Tenstorrent Ascalon CPU."
The series breakdown:
- Patches 1-11: bug fixes. Range checks on every dbtr ecall
handler, sbiret.value on update failure, endian conversion in the
install handler, "do not support chain bit" (per spec), error-handling
for enable/disable/uninstall, avoiding crash in
sbi_debug_read_triggers, succeeding ops with no triggers in mask, fixing read-trigger to not read HW trigger when not mapped. - Patch 12: refactor. Move HW trigger probing into a function.
- Patches 13-15: Rework install/update error handling, decouple dbtr trigger index from hardware trigger number, move trigger feature support test into a function.
- Patches 16-17: the heterogeneous part. Different HW triggers
support different functions, so the existing 1:1 dbtr-trig → HW-trigger
mapping is relaxed. HW triggers are allocated independently from
what can satisfy the requested type. Heterogeneous access type
matching for
mcontroltriggers. - Patch 18: "Work around specification bug in range checks", held last because it depends on a pending SBI spec update; Nick offered to move it forward if the issue is confirmed.
Companion kvm-unit-tests series (piggin-dbtr-kvm-unit-tests.mbox)
posted same week: riscv: sbi: dbtr: fix enable trigger return code check and riscv: dbtr: Add initial API corner case / error handling tests. Nick is also building the test harness for dbtr.
The dbtr (SBI Debug Trigger) extension was introduced earlier with a 1:1 model: each dbtr-numbered trigger corresponds 1:1 to one underlying HW trigger of the same number. That's fine on uniform-trigger CPUs. Ascalon has 9 heterogeneous triggers (4 breakpoint, 4 watchpoint, 1 instruction-count). The dbtr API needs to allocate the right kind of HW trigger for the requested function, not just give a fixed index. Half the series is correctness fixes Nick had to make to even probe dbtr behavior properly; the other half is the architectural change. That's why it's 18 patches as a single drop, splitting them apart would lose the motivation thread.
Linux's kernel debugger (KGDB) and userspace gdb-stub both want to set hardware breakpoints/watchpoints. On RISC-V, that flows through Sdtrig in the hardware to dbtr in OpenSBI to the kernel/gdb. If the dbtr layer is wrong (or assumes uniform triggers), Ascalon's mixed trigger types are unreachable. Nick's series unblocks Linux debugging on Atlantis silicon.
piggin-pmp-refactor.mbox, 2026-04-30. [PATCH 0/7] Make PMP encoding usable for non-hart PMPs, Message-Id
20260430045528.420437-1-npiggin@gmail.com.
Rationale (from the cover): "The Tenstorrent RISC-V IOMMU implements PMPs with MMRs in the same format as specified in the RISC-V ISA for the hart CSRs. This series splits out the PMP encoding functions so it can be shared by both users."
The seven patches:
- Introduce
pmp_ttype. - Split PMP encoding from CSR access.
- Move RISC-V PMP encoding functions to
lib/sbi/sbi_pmp.c. - Move non-HART PMP functions to
sbi_pmp.c. - Add PMP CSR read/write accessors.
- Add
pmp_is_enabled()helper. - Move hart PMP functions to
lib/sbi/sbi_hart_pmp.c.
Touches platform/generic/eswin/eic770x.c along the way
(some -/+ lines). Notes that the IOMMU patch from the original
Atlantis series will be reposted "after the base Atlantis platform and
this series is merged."
This is a textbook architectural refactor: the same data structures (PMP encoding) are needed by two clients (HART CSRs, IOMMU MMRs); pull the shared part out, keep the client-specific access paths. No new functionality, all motivated by enabling new functionality in a clean way. Anup's review style favors this kind of incremental restructuring; expect it to land.
The kernel-side device-tree bindings RFC was Drew's
(dt-bindings-iommu-riscv-add-bindings-for-t-rfc, 2026-04-02, excluded
from this corpus by request). The OpenSBI side of this storyline is
visible in two places:
- In the original Atlantis platform v1 (storyline 5), patch 4/4
was
platform: generic: tenstorrent: Add RISC-V IOMMU support. This patch was dropped from v2/v3 because Nick split it out. - As a follow-up after the PMP refactor (storyline 8), Nick says the IOMMU patch will be reposted once both the Atlantis platform skeleton and the PMP refactor have landed.
So the IOMMU is sequenced behind two other series. At end-of-window
the kernel-side bindings have Acked-by: Joerg Roedel (IOMMU
subsystem maintainer) and Reviewed-by: Joel Stanley, but the OpenSBI
side hasn't reposted yet. This is a cross-layer choreography problem:
kernel bindings need to match OpenSBI implementation, and OpenSBI
implementation needs the PMP refactor as a prerequisite.
Worth noting: the Tenstorrent IOMMU is a RISC-V IOMMU (a la Tomasz Jeznach's framework, the upstream IOMMU author at Rivos), but with PMP-style MMRs. That detail is what motivates the entire PMP refactor series in storyline 8.
hw-riscv-aia-provide-number-of-irq-sourc, 2026-01-29. A single-patch
QEMU helper that lets a tt-atlantis machine query the number of IRQ
sources from the AIA (Advanced Interrupt Architecture) APLIC controller
without hardcoding it. Reviewed-by Daniel Henrique Barboza and Nutty
Liu. Awaiting Alistair's pickup at end-of-window.
This is the kind of one-line helper that exists because the Atlantis machine model needs it. Joel's atlantis-mach v3-v5 use this.
Two threads in the corpus capture Anup Patel's [PATCH 0/3] (later 0/4) Timer events for OpenSBI series, posted 2026-04-15 and respun 2026-04-23.
The series extends sbi_timer so platform drivers can use timer events
for timeouts and periodic checks; adds sbi_scratch_hartindex() macro,
per-HART timer state, support for timer events in lib/sbi/sbi_timer.c
(~221 LOC delta).
Nick's role here is reviewer. His review comments shape one of the
sub-patches (sbi_timer_compute_delta) and he marks several others
with Reviewed-by: Nicholas Piggin <npiggin@gmail.com>. Anup applied
patches he's collected reviewed-by tags on.
Why include this in a Tenstorrent-coworker corpus? Because Nick's upstream presence is more than just patches he authors. His review work on adjacent series (Anup's timer rework, Anup's irqchip overhauls) keeps OpenSBI moving, and tells us something about how seriously the Tenstorrent OpenSBI presence is taken.
The work is best understood as a dependency graph rather than a list:
+--- Atlantis hardware (target) ---+
| |
(silicon) | |
v v
OpenSBI Atlantis Linux Atlantis DT
platform skeleton + clk/reset (PRCM)
(Piggin storyline 5) (Srinivasan storyline 1)
|
|---> PMP refactor (Piggin sl 8)
| |
| v
| Tenstorrent IOMMU (deferred)
| ^
| |
| Kernel IOMMU bindings (Drew, excluded)
|
|---> Smrnmi infrastructure (Voevodin sl 6)
| ^
| |
| SiFive Smrnmi v3 (origin, did not land)
|
|---> dbtr heterogeneous triggers (Piggin sl 7)
^
|
Sdtrig QEMU emulation (Piggin sl 3, RFC)
QEMU tt-atlantis machine (Stanley → Piggin sl 2)
|
|---> tt-ascalon mvendorid (Stanley + Ellerman sl 3, merged)
|---> RVV correctness (Blanchard sl 4)
|---> AIA irq-source helper (Piggin sl 10)
|---> Sdtrig RFC (Piggin sl 3, no review yet)
Specific dependencies that came up explicitly in cover letters or review comments:
-
Voevodin Smrnmi v2 explicitly waits for Atlantis platform: "They will go through the Atlantis platform series instead." The Tenstorrent platform-glue patches that were 6/7 and 7/7 of v1 are now sequenced behind Nick's OpenSBI Atlantis platform.
-
Tenstorrent IOMMU waits for both Atlantis platform AND PMP refactor: Nick's PMP refactor cover says the IOMMU repost happens after both prerequisites land. Three series in series.
-
Atlantis OpenSBI platform v1 referenced kernel IOMMU bindings: Nick's v1 cover pointed at Drew's
linux-riscvbindings RFC as the companion piece for IOMMU support. Both sides moved in the same week. -
Smrnmi v2 vs Zkr stack guard: Mid-stream upstream commit
ecdb6c90introduced theInitialize stack guard via Zkrchange, which interacts with Smrnmi's NMIE=0 default. Voevodin's v2 absorbed the workaround; v3 cleaned it up to Anup's preference. -
Atlantis QEMU machine v5 needs AIA irq-source helper: Joel's v3 onwards use Nick's
hw-riscv-aia-provide-number-of-irq-sourcpatch. The helper exists because the machine needs it. -
Andrew Jones's Svadu/Svade observation on QEMU v5 hinges on Linux SBI FWFT support: cleanest emulation requires Linux to negotiate Svadu through
SBI_FWFT_PTE_AD_HW_UPDATING, which the Linux RISC-V tree doesn't yet support. The "right answer in QEMU" is genuinely blocked on a kernel feature that hasn't been written. -
Anirudh's SWIOTLB Tested-by on Troy Mitchell's patch: Tenstorrent doesn't author the patch but is the production validator. This is what coworker test-coverage looks like across vendors.
For listener orientation only, since the listener IS Drew: Drew's role across this corpus is the RISC-V kernel maintainer side. He:
- Pulls Tenstorrent device-tree branches into linux-next via the RISC-V SoC tree (e.g., the v6.19 pull that Arnd Bergmann processed on the soc tree).
- Picks up Tenstorrent maintainer-stable trees (clk-tenstorrent, tenstorrent-dt-for-next).
- Reviews coworker patches with Reviewed-by tags (Anirudh's PMU node, Anirudh's PRCM v8, Joel's tt-ascalon mvendorid).
- Authored the kernel-side IOMMU bindings RFC that cross-references Nick's OpenSBI IOMMU work (excluded from this corpus by request).
- Authored the kernel CBQRI/Ssqosid/RQSC series that's the listener's flagship work (also excluded by request).
The point: the listener's coworkers' work and Drew's own work co-evolve. Anirudh's PRCM lands through clk-next, but lands in a kernel where the Tenstorrent SoC tree is co-maintained by Drew and Conor Dooley. Drew's RFC and Nick's OpenSBI IOMMU together gate the kernel-side IOMMU support. So the threads listed below all touch Drew's review queue or maintainer tree at some point.
- Atlantis QEMU machine v5: under review. Andrew Jones's Svadu observation needs a response.
- Atlantis QEMU machine: PCIe and i2c rework: deferred to follow-up series, no posting yet.
- Atlantis OpenSBI platform v3: in review queue.
- OpenSBI PMP refactor: in review queue.
- OpenSBI Atlantis IOMMU repost: blocked behind the above two.
- Smrnmi v3: advanced review, only Zkr split left to settle.
- Smrnmi-on-Atlantis (former v1 patches 6/7 and 7/7): deferred to Atlantis platform series.
- dbtr 18-patch: posted, Mamay (
vmamay@?, co-reviewer) replied, no Anup verdict in the window. - Sdtrig QEMU RFC (25 patches): no on-list reply captured.
- Anton's RVV LMUL fix: Reviewed-by, awaiting application.
- Anton's RVV mask_reg_full_update: posted, no review captured.
- Anton's RVV widening reduction overlap: no captured reply.
- Joel's AIA irq-source helper: Reviewed-by, awaiting Alistair's pickup.
- Troy Mitchell's SWIOTLB above-4GB fix (Tenstorrent-tested): awaiting RISC-V maintainer pickup.
In short: Anirudh's PRCM is fully landed. tt-ascalon mvendorid is in
QEMU 11.1. Two of Anton's RVV fixes are in riscv-to-apply.next.
Everything else is in flight.
NotebookLM responds well to multiple medium-length sources rather than one giant source. Suggested approach:
The Atlantis PRCM saga from v1 to v8 plus the linux-next merge. Six months of patient review-driven iteration. Strong character study.
- Sources:
lore-summaries/add-tenstorrent-atlantis-clock-reset-con*.md(8 files, v1 through v8) - Plus:
lore-summaries/add-tenstorrent-clk-to-linux-next.md - Themes: how upstream review shapes a small driver, the rename that prevented a future ABI mistake, the difference between v1 (over-engineered) and v8 (idiomatic).
Joel's Atlantis machine v1-v4, then Nick takes over for v5. Why it shrank. What Andrew Jones is asking about.
- Sources:
lore-summaries/hw-riscv-add-the-tenstorrent-atlantis-mach*.md(5 files, v1 through v5) - Plus:
lore-summaries/hw-riscv-aia-provide-number-of-irq-sourc.md(the helper Nick added that the machine model needs). - Themes: feature triage under time pressure, the discipline of deferring known-but-unfinished work, the Svadu/Svade subtlety.
Two years of cross-vendor history compressed into one mailing list arc.
- Sources:
opensbi-mbox/sifive-smrnmi-v3-origin.mbox,opensbi-mbox/voevodin-smrnmi-v1.mbox,opensbi-mbox/voevodin-smrnmi-v2.mbox,opensbi-mbox/voevodin-smrnmi-v3.mbox. - Themes: how upstream priorities get reassigned, the Zkr-stack-guard collision, what "advanced review" looks like.
Five RVV correctness patches as five short stories.
- Sources: all five
lore-summaries/target-riscv-rvv-*.mdfiles. - Themes: what hardware-versus-emulator divergence looks like in practice, the "vendor knob" pattern, why narrow patches succeed.
Atlantis platform → PMP refactor → IOMMU. Sequencing as architecture.
- Sources:
opensbi-mbox/piggin-atlantis-platform.mbox,opensbi-mbox/piggin-atlantis-platform-v2.mbox,opensbi-mbox/piggin-atlantis-platform-v3-32bit-fix.mbox,opensbi-mbox/piggin-pmp-refactor.mbox. - Plus:
opensbi-list-broader-digest.mdfor context. - Themes: how a single hardware feature (IOMMU) drives a refactor of unrelated firmware infrastructure (PMP encoding) two layers down.
Nick's 18-patch flood through dbtr. The architectural change buried in a fix sequence.
- Sources:
opensbi-mbox/piggin-dbtr-18patch.mbox,opensbi-mbox/piggin-dbtr-kvm-unit-tests.mbox. - Plus:
lore-summaries/target-riscv-debug-sdtrig-fixes-and-tt-asc-rfc.md(the QEMU side of the same architectural arc). - Themes: when a fix series is also a feature series, what Ascalon's 9-trigger heterogeneous layout reveals about the limits of the current dbtr API.
The pieces are visible across all three lists, but the actual IOMMU patches are deferred until prerequisites land. Cross-layer choreography.
- Sources:
lore-summaries/dt-bindings-iommu-riscv-add-bindings-for-t-rfc.md(excluded from corpus by request, but referenced). Use the OpenSBI v1 atlantis platform mbox where IOMMU patch 4/4 first appeared:opensbi-mbox/piggin-atlantis-platform.mbox. - Plus:
opensbi-mbox/piggin-pmp-refactor.mbox. - Themes: how a single hardware design (IOMMU with PMP-format MMRs) shapes work across kernel bindings, OpenSBI implementation, and the PMP encoding infrastructure.
The single-patch fixes and helpers that make the bigger work possible.
- Sources:
lore-summaries/riscv-mm-fix-swiotlb-initialization-for.md,lore-summaries/riscv-dts-tenstorrent-add-pmu-node-to-bl.md,lore-summaries/hw-riscv-aia-provide-number-of-irq-sourc.md,opensbi-mbox/srinivasan-payload-alignment.mbox,opensbi-mbox/patel-timer-events-v1.mbox(Nick reviewing Anup),lore-summaries/pull-37-51-target-riscv-tt-ascalon-add-ten.md. - Themes: vendor co-validation across teams, why one-patch contributions matter, the merge plumbing that makes the whole thing add up.
tenstorrent-coworkers-podcast/
├── REPORT.md this file (~6,000 words)
├── INDEX.md short index pointing into corpus
├── lore-threads.json metadata for 26 lore threads
├── opensbi-threads.json metadata for 13 opensbi threads
├── opensbi-list-broader-digest.md the broader OpenSBI list digest
│ (Anup, MIPS, RISCstar, etc.) for
│ ecosystem context
├── lore-mbox/ 26 raw mbox files from lkml/qemu
├── lore-summaries/ 26 detailed per-thread summaries
└── opensbi-mbox/ 13 grouped opensbi-list mboxes
Drop the entire directory into NotebookLM as a folder source, or attach
individual .md/.mbox files for episode-specific deep dives.
- Lore corpus: previously assembled from local lore archive
(
semcode-index --lore) covering acpica-devel, linux-acpi, linux-arm-kernel, linux-devicetree, linux-doc, linux-riscv, lkml, and qemu-devel. 37 unique threads were identified; 11 Drew-as-primary threads excluded for this corpus, leaving 26. - The 2 threads where Drew co-authored with Anirudh (PRCM v8 with Reviewed-by add, Blackhole PMU DT) are kept because Anirudh is the substantive author and Drew's contribution is review-side.
- The single thread where Mark Brown initiated and Drew responded
(
add-tenstorrent-clk-to-linux-next) is kept because the substance is about Anirudh's PRCM clk landing in linux-next. - OpenSBI corpus: extracted from
~/opensbi-mail-archive/2026-{Jan..May}.txtby matching author pattern (@tenstorrent.com,npiggin@gmail.com, etc.) and subject keyword (Tenstorrent/Atlantis/Ascalon/Blackhole), then expanded to full thread roots and descendants via In-Reply-To traversal. 522 total messages indexed, 119 messages in 13 thread groups identified as Tenstorrent-relevant. - Drew is not an active author or reviewer on the OpenSBI list during
this window (zero matches for
fustiniacross all five months); no exclusion needed there. - Date sorting is approximate; some pipermail entries lack proper parseable Date headers and sort to the empty string.
The companion file opensbi-list-broader-digest.md (~33 KB,
~7,000 words) is the broader OpenSBI digest covering the wider
ecosystem. Section 1 of that digest is a focused dive on the three
Tenstorrent OpenSBI contributors and overlaps with storylines 5, 6, and
the Anirudh OpenSBI sub-section here; sections 2-7 of that digest
cover the broader OpenSBI ecosystem (Anup's irqchip overhaul, RISCstar's
HWISO/WorldGuard, MIPS p8700 platforms, Andes HSM, Bytedance SSE
fixes, Dave Patel's eager FP/V context switch, Nylon Chen's earlier
Smrnmi origin, etc.) and is provided as supplementary listening for
ecosystem episodes.
Tenstorrent coworkers, 6-month upstream corpus, short index
Start with
REPORT.mdfor the narrative. This file is a flat indexinto the per-thread material so you can attach specific items to a
NotebookLM source.
Period: 2025-11-09 through 2026-05-09. Drew Fustini's own series and
maintainer-hat pulls excluded; see
REPORT.md"What Drew is doing inthe periphery" for context.
Sizes
Lore mbox / summary index (26 threads)
Sorted by first message date. See
lore-threads.jsonfor fullmetadata.
Each thread is in
lore-mbox/<thread>.mboxandlore-summaries/<thread>.md.OpenSBI mbox index (13 thread groups)
Sorted approximately by first message date. See
opensbi-threads.jsonfor full metadata.
sifive-smrnmi-v3-origin.mboxAdd RISC-V Smrnmi extension supportv3, January 2026, the series that did not landvoevodin-smrnmi-v1.mboxpiggin-atlantis-platform.mboxpiggin-atlantis-platform-v2.mboxpiggin-atlantis-platform-v3-32bit-fix.mboxpiggin-dbtr-18patch.mboxdbtr: Fixes and heterogeneous trigger types, 18 patches, 2026-03-13piggin-dbtr-kvm-unit-tests.mboxpatel-timer-events-v1.mboxpatel-timer-events-v2.mboxpiggin-pmp-refactor.mboxMake PMP encoding usable for non-hart PMPs, 7 patches, 2026-04-30voevodin-smrnmi-v2.mboxvoevodin-smrnmi-v3.mboxsrinivasan-payload-alignment.mboxFix payload alignment when FW_TEXT_START isn't 2M/4M aligned, 2026-05-08Per-contributor pointer
add-tenstorrent-atlantis-clock-reset-con*(v1-v8),add-tenstorrent-clk-to-linux-next,riscv-mm-fix-swiotlb-initialization-for,riscv-dts-tenstorrent-add-pmu-node-to-bl,srinivasan-payload-alignment.mboxhw-riscv-add-the-tenstorrent-atlantis-mach*(v1-v4),target-riscv-tt-ascalon-add-tenstorrent*(v1, v2),pull-37-51-target-riscv-tt-ascalon-add-tenhw-riscv-add-the-tenstorrent-atlantis-mach-v3/v4/v5,hw-riscv-aia-provide-number-of-irq-sourc,target-riscv-debug-sdtrig-fixes-and-tt-asc-rfc,piggin-atlantis-platform*.mbox,piggin-dbtr-18patch.mbox,piggin-dbtr-kvm-unit-tests.mbox,piggin-pmp-refactor.mbox,patel-timer-events-v1.mbox,patel-timer-events-v2.mboxtarget-riscv-rvv-*threadstarget-riscv-tt-ascalon-add-tenstorrent(v1)riscv-dts-tenstorrent-add-pmu-node-to-bl(original author of the PMU node, posted by Anirudh)voevodin-smrnmi-v1.mbox,voevodin-smrnmi-v2.mbox,voevodin-smrnmi-v3.mboxPer-storyline pointer (see REPORT.md for narrative)
hw-riscv-add-the-tenstorrent-atlantis-mach*+ AIA irq-source helpertarget-riscv-rvv-*piggin-atlantis-platform*.mbox(3 files)sifive-smrnmi-v3-origin.mbox+ Voevodin v1/v2/v3piggin-dbtr-18patch.mbox+piggin-dbtr-kvm-unit-tests.mbox+target-riscv-debug-sdtrig-fixes-and-tt-asc-rfcpiggin-pmp-refactor.mboxpiggin-atlantis-platform.mbox(patch 4/4) andpiggin-pmp-refactor.mboxcoverhw-riscv-aia-provide-number-of-irq-sourcpatel-timer-events-v1.mbox+patel-timer-events-v2.mbox