Two months of SpacemiT upstream work in one place: a standalone ggml-spacemit llama.cpp backend, K3 platform support merged into OpenSBI master, dozens of K1/K3 kernel patches moving from review into maintrees, and steady box64/LLVM/U-Boot gains.
SpacemiT Upstream Progress, September-October 2026
SpacemiT publishes a bi-monthly upstream report on its own forum. The September-October edition is the most substantive one so far, because for the first time a large batch of K1/K3 work moved from "under review" into actual maintainer trees - and K3 landed in OpenSBI master. If you build on K1 or K3, this is the list to read instead of guessing what your kernel can actually do.
We summarized the August edition earlier. This is the September-October continuation, reorganized by subsystem so you can jump straight to what affects your board.
AI software stack
FlagTree merged the SpacemiT smt_rvisa extension (October 16). The merge adds a vector-level raw-kernel eDSL: explicit control over RVV vector length, element bit width, and instruction selection, wired into the generic TLE infrastructure, plus cross-build support, wheel packaging, and test configuration. Practically, this means kernel authors can express RVV explicitly instead of hoping the compiler picks the right vectorization - the same idea as writing CUDA intrinsics rather than relying on auto-vectorization.
SpacemiT llama.cpp gained a standalone inference backend (October 12). The new ggml-spacemit backend coexists with the original CPU path, so you enable device inference on demand rather than replacing the whole pipeline. Follow-up work targets K3 decode state handling, chunked prefill, Flash Attention, and graph fusion. Anyone who has been running llama.cpp on K3 through the CPU path only should watch this - it is the beginning of a proper device path rather than a patch on top of CPU kernels.
Linux kernel - what actually got accepted
The interesting signal in this report is not the list of pending patches but the list of accepted ones. Several multi-round series finally cleared review:
- K3 interrupt, DMA, clock, and audio plumbing. The PDMA DRCMR base address fix was accepted; I2S0 through I2S5 nodes entered the SpacemiT maintenance tree; the CPU PLL frequency table fix went into clk-fixes. In October, the ACLINT bindings, SSWI driver, and its DTS series entered the SpacemiT SoC tree.
- K1 board-level DVFS and network config. CPU DVFS patches for MusePi Pro and OrangePi RV2/R2S were accepted; OrangePi RV2/R2S gained an on-board EEPROM plus MAC address read from that EEPROM; the K1 EMAC fix that cleans up TX descriptors after a DMA mapping failure went into the network tree. That last one matters: a leaked TX descriptor path on a gateway that runs for months is exactly the kind of bug that surfaces as "the board died after three weeks".
- Temperature sensor and USB. Four CTF2301 driver and binding patches were accepted; the K1 USB2 PHY dependency and default-enable configuration were accepted; CoM260 USB, rfkill, and power DTS entered the SpacemiT tree.
- K3 board peripherals into the DT pull. I2C6, CoM260 CTF2301, and Pico ITX USB3 B/C, Bluetooth, and WLAN rfkill DTS were folded into spacemit-dt-for-7.4-1 and a pull request was opened upstream. Note the caveat in the report itself: this pull request carries no SoC-maintainer acknowledgement yet, so treat it as submitted, not merged.
- GPU bindings and reviewer entries. K1/K3 GPU device-tree bindings were accepted and SpacemiT reviewer entries were added to MAINTAINERS. The GPU device tree, power domains, and full graphics support continue on separate tracks.
Still in review - plan around these
- K3 PCIe RC controller at v7 and UFS host driver at v7. Both are in their seventh revision, still working through review comments and known issues.
- K3 display v2, K1/K3 genpd v2, CCU auxiliary device, GPU DTS. Review continues.
- K1 USB2: ChipIdea USB2 controller v4, board-level USB2 DTS, bootph boot-stage markers. Still being revised or waiting for acceptance.
For a K3 desktop or AI inference box, PCIe, UFS, and display are the three that decide whether mainline is usable. Seven revisions on PCIe RC means it is being taken seriously, and also that you should not plan a product around mainline PCIe yet.
box64 - still grinding through x86_64 compatibility
Two months of fixes, in the order they were reported:
September - instruction compatibility and runtime fixes. Added VZEROUPPER and VZEROALL support; fixed floating-point rounding, vector register aliasing, and several classes of AVX instruction handling. Improved ELF relocation, varargs handling for GLib/GIO/GStreamer, and libc function wrappers. Optimized REP STOSB, MASKMOVDQU, and PMULUDQ implementations.
October - RV64 instruction translation and state restore. Fixed VMOVSS, VMOVQ, VPERM2I128, VCVTPD2PS, and POPCNT/TZCNT/LZCNT handling; completed vector register aliasing, MMX cache, MXCSR state, and signal state restore.
October - codegen and packaging. Reduced redundant vsetvli emissions, optimized VSHUFPS and VPERMILPS, used ADDSL and BSETI to simplify some instruction sequences; fixed OpenSSL PKCS12_create argument handling and Debian changelog formatting.
The signal-state restore work is the one that matters for real applications: without correct MXCSR and signal state, floating-point code under emulation silently diverges instead of crashing, which is far worse to debug.
LLVM, GNU toolchain, V8, lzbench
- October 23: spacemit-a100 ascending memory access preference merged into LLVM.
- October 26: VXRM write optimization scope narrowed - speculative writes for targets with vxrm-pipeline-flush enabled are now restricted to loops.
- October 25: LLVM 23.1.0 upgrade and LLVM build cache support merged into the RISC-V GNU toolchain.
- October 28: GDB build configuration disables gprofng.
- V8: fixed RISC-V atomic compare-exchange expected-value and temporary register clobbering issues, with regression tests added in a follow-up.
- lzbench: fixed an aceapex double-free on empty compressed streams (PR #325).
The A100 memory-access tuning detail is small but telling: the toolchain is now being tuned for the K3 AI cores specifically, not just for "RISC-V" in general.
U-Boot
- September, into u-boot/next: SpacemiT custodians and maintenance tree information added; K1 pinctrl fix, MMC/SDHCI, SPL, and SD/eMMC boot merged; PCIe controller, PCIe/USB3 combo PHY, and NVMe configuration merged.
- October 11, into u-boot/main: K3 Pico ITX board-level base support, GPIO, pinctrl, clock and reset, mix-clock mux fix, and network command configuration.
- October 24, into u-boot/main: K3 mkimage boot image support, EEPROM TLV commands, SPI NOR and environment storage configuration; K1 SPL boot fallback, K1 USB2 PHY, and K1/K3 generic DWC3 support.
- In flight: the K3 DWC EQOS driver was accepted into u-boot-net/for-next. K1 PCIe/USB3 PHY, SDHCI, DDR firmware relocation, and EMAC fixes remain under review.
OpenSBI - K3 landed in master
On October 29, K3 platform support and its accompanying changes entered OpenSBI master. The submission implements multi-cluster secondary hart on-demand startup, boot-stage PMA and cache configuration, CCI-550 coherency setup, and exception handling selection for heterogeneous harts.
This is the milestone of the two months. K3 support went from patch review in August to code in the upstream tree in October. If you are booting K3 boards with a vendor OpenSBI fork, that fork now has an upstream reference to converge on - which is how downstream maintenance cost eventually drops.
What this means if you build on these chips
For K1 gateways (OpenWrt or Bianbu): the accepted DVFS, EEPROM MAC, and EMAC TX descriptor fixes are the ones that affect field reliability. If you are shipping K1-based routers, the EMAC fix is worth backporting even if you stay on a vendor kernel - a DMA mapping failure under memory pressure should not leave stale descriptors behind.
For K3 AI boxes: the llama.cpp backend and FlagTree raw-kernel eDSL are the two pieces that make K3 programmable at the kernel level rather than only through vendor libraries. But PCIe RC, UFS, and display are still in review, so treat mainline as a development target rather than a shipping baseline for now.
For toolchain work: LLVM now has A100-specific tuning, which means benchmarking K3 AI cores with an older LLVM underestimates the hardware. Rebuild before you publish numbers.
Our own K1/K3 board bring-up notes assume exactly this split - vendor kernel for production, mainline for anything you want to survive the next two years. If you are sourcing K1 or K3 hardware for a gateway or edge inference product, this report is the best available proxy for which subsystems you can expect to maintain yourself.
Sources
Compiled by Open RISC-V AI Assistant. Patch status is as reported by SpacemiT; verify current state in the respective tree before relying on it.
For product inquiries, contact contact@open-riscv.com or visit /forum/inquiry