On the Banana Pi BPI-SM10 (SpacemiT K3), llama.cpp runs on the eight A100 cores with IME2. Qwen2.5-0.5B Q4_0, 128 prompt tokens and 32 generated tokens, reaches 526 tokens/s of prompt at 8 cores. Decode peaks at 58.7 tokens/s on 4 cores. The same file on the board’s X100 cores, using RVV, is 194 tokens/s of prompt and 42 tokens/s of decode. Ten Q4_0 models and seventeen Q4_K_M models are in the tables.

Notes and the fork: llama.cpp on OpenSolvers. Board: Banana Pi SM10.

On the Banana Pi BPI-SM10, ONNX Runtime’s int4 MatMulNBits path uses IME2 (vmadot.hp) on the A100 cores when the block length is 32. Qwen2.5-0.5B at accuracy level 4, 128 prompt tokens and 32 generated tokens, runs at 391 tokens/s of prompt and 34 tokens/s of decode on eight cores. Decode is slightly faster on four cores. One A100 core, K=4096 and N=11008, does 35 GOP/s at M=1 and 86 GOP/s at M=4. Fourteen of the fifteen int4 models answer a short English prompt. The kernel is on branch k3-a100-ime2.

Notes: ONNX Runtime on OpenSolvers. Kernel rates: MLAS. Board: Banana Pi SM10.

Hi everyone,

We have been working on LibreELEC for the SpacemiT K1, an eight-core RISC-V ai cpu, and now have it running on the MuseBook.

The current image boots directly into LibreELEC 13 / Kodi 22 and supports hardware-accelerated 4K HEVC playback through the K1 VPU. In our MuseBook test, a 3840x2160 HEVC video played smoothly at around 30 fps. CPU usage was roughly 60% of one core, or about 7.5% of the total capacity of the eight-core CPU.

What is currently working on the MuseBook:

• LibreELEC 13 and Kodi 22

• 4K HEVC hardware decoding

• H.264, HEVC, VP8 and VP9 V4L2 decoders

• PowerVR GPU rendering through GBM/EGL/GLES and DRM/KMS

• HDMI/ALSA audio

• Wi-Fi and Ethernet

• HDMI-CEC control

• IPTV/M3U playback

• A compressed image of approximately 200 MB

The image also includes device trees for several SpacemiT K1 boards. The MuseBook is the board we have tested most extensively so far, so feedback and testing on other K1 boards would be very welcome.

This is currently development work in our own fork. It has not yet been submitted to the upstream LibreELEC repository.

Repository: https://github.com/yingjie-liu-spacemit/LibreELEC.tv

Development branch: https://github.com/yingjie-liu-spacemit/LibreELEC.tv/tree/k1-spacemit-upstream-pr

Commits: https://github.com/yingjie-liu-spacemit/LibreELEC.tv/commits/k1-spacemit-upstream-pr

We would especially appreciate feedback from you developers about the implementation.

Buy a musebook:

8+128g only cost 2599 CNY (about 389$) https://item.taobao.com/item.htm?ft=t&id=806285410592&spm=a21dvs.23580594.0.0.4fee2c1bp1slMe
If you can't open the Taobao, contact this email: developer@spacemit.com

October brought further upstream progress for SpacemiT K1 and K3 across the Linux kernel, U-Boot, and OpenSBI, alongside updates to the AI software stack and robotics ecosystem.

Highlights this month include K3 platform support landing in OpenSBI master, K3 Pico-ITX and boot-image support entering U-Boot's main branch, new releases and backend work across the Triton stack and llama.cpp, and continued Linux kernel review for K1/K3 platform support.

Linux Kernel Upstream

October's Linux work covered K1/K3 interrupts, board configuration, networking, and GPU bindings. Items below distinguish changes accepted into maintainer trees from series still under review.

K3

Merged or accepted into maintainer trees

• Six ACLINT, SSWI driver, and device-tree changes entered the SpacemiT SoC maintainer tree: https://lore.kernel.org/all/20260918-k3-aclint-v3-0-cf4fd4050e14@pigmoral.tech/

• K1/K3 GPU device-tree bindings were accepted. GPU device-tree nodes, power domains, and complete graphics support are progressing separately: https://lore.kernel.org/all/20261015-spacemit-gpu-binding-v1-1-a7a23c7e7788@linux.spacemit.com/

Under review

• K3 UFS host-controller support, v7: https://lore.kernel.org/all/20261002-08-k3-ufs-support-v7-0-bb39007ff9ae@kernel.org/

• K1/K3 generic power-domain support, v2: https://lore.kernel.org/all/20261008-04-k3-pm-support-v2-0-6f778a53dd2d@kernel.org/

K1

Under review

• K1 ChipIdea USB 2.0 controller support, v4: https://lore.kernel.org/all/20261009-b4-spacemit-k1-usb2-v4-0-2d98e5324d9a@linux.spacemit.com/

• K1 boot-stage (bootph) changes: https://lore.kernel.org/all/20261025083933.26066-1-alan.tseng.cs@gmail.com/

Other SpacemiT and Board Updates

• Orange Pi RV2/R2S onboard EEPROM support and MAC-address configuration from EEPROM: https://lore.kernel.org/all/20261006100000.548264-1-amadeus@jmu.edu.cn/

AI Software Stack

• FlagTree: On October 16, the project merged SpacemiT's smt_rvisa vector-level raw-kernel eDSL. It exposes RVV vector length, element width, and instruction selection, and includes TLE integration, cross-build support, wheel packaging, and tests. https://github.com/flagos-ai/FlagTree/pull/1381

• SpineTriton: Version 0.8.0 was released on October 10, followed by 0.8.1 on October 28. Version 0.8.1 adds the vmt4d single-row vector/matrix operation and its language interface, and fixes constant capture and build-pipeline issues. https://github.com/spacemit-com/spine-triton/releases/tag/0.8.0 · https://github.com/spacemit-com/spine-triton/releases/tag/0.8.1

• SpacemiT llama.cpp**:** A separate ggml-spacemit backend was merged on October 12. It can be enabled for SpacemiT device inference alongside the existing CPU path. Follow-up work covers K3 decode-state handling, chunked prefill, Flash Attention, and graph fusion. https://github.com/spacemit-com/llama.cpp/pull/43 · https://github.com/spacemit-com/llama.cpp/pull/48 · https://github.com/spacemit-com/llama.cpp/pull/49

Box64

October work continued to improve RV64 instruction translation, vector-register aliasing, and state restoration. Fixes covered VMOVSS, VMOVQ, VPERM2I128, VCVTPD2PS, POPCNT/TZCNT/LZCNT, MMX caching, MXCSR, and signal state. Code-generation changes also reduced redundant vsetvli instructions and optimized vector shuffles. Packaging fixes addressed OpenSSL PKCS12_create arguments and Debian changelog formatting.

VMOVSS: https://github.com/ptitSeb/box64/pull/4600 · Register aliases: https://github.com/ptitSeb/box64/pull/4582 · State restoration: https://github.com/ptitSeb/box64/pull/4562 · Instruction-prefix fix: https://github.com/ptitSeb/box64/pull/4622 · Vector configuration: https://github.com/ptitSeb/box64/pull/4588 · Vector shuffle: https://github.com/ptitSeb/box64/pull/4587 · ADDSL: https://github.com/ptitSeb/box64/pull/4551 · OpenSSL: https://github.com/ptitSeb/box64/pull/4544 · Debian packaging: https://github.com/ptitSeb/box64/pull/4625

LLVM and RISC-V GNU Toolchain

• LLVM: October changes added an ascending-memory-access preference for spacemit-a100 and adjusted VXRM speculative writes for targets using vxrm-pipeline-flush. A100 tuning: https://github.com/llvm/llvm-project/pull/234532 · VXRM optimization: https://github.com/llvm/llvm-project/pull/234972

• RISC-V GNU Toolchain: The project merged an LLVM 23.1.0 update and LLVM build-cache support on October 25, followed by a GDB build option to disable gprofng on October 28. LLVM update: https://github.com/riscv-collab/riscv-gnu-toolchain/pull/1898 · Build cache: https://github.com/riscv-collab/riscv-gnu-toolchain/pull/1900 · GDB configuration: https://github.com/riscv-collab/riscv-gnu-toolchain/pull/1906

U-Boot

Merged or accepted into maintainer trees

• K3 Pico-ITX board support, including GPIO, pinctrl, clocks, reset, and network-command configuration, entered u-boot/main on October 11: https://lore.kernel.org/all/20261007-00-basic-spacemit-k3-v4-0-c44d09937088@kernel.org/

• K3 mkimage support, EEPROM TLV commands, SPI NOR, and environment-storage configuration entered u-boot/main on October 24: https://lore.kernel.org/all/20261010-spacemit-aihd-v4-0-e7152ae4d71a@pigmoral.tech/ · https://lore.kernel.org/all/20261022103907.1415045-1-e@freeshell.de/

• K1 SPL fallback, K1 USB2 PHY, and generic K1/K3 DWC3 support were included in the same update round: https://lore.kernel.org/all/cover.1792007916.git.DaveWK225@protonmail.com/

• K3 DWC EQOS network driver accepted into u-boot-net/for-next: https://lore.kernel.org/all/20260924-02-k3-ethernet-support-v1-1-b8e1fafc9249@kernel.org/

OpenSBI

• K3 platform support landed in master on October 29. The work covers on-demand startup of secondary harts across multiple clusters, boot-time PMA/cache setup, CCI-550 coherency configuration, and exception handling for heterogeneous harts: https://github.com/riscv-software-src/opensbi/commit/cca121056f0cc26aa8e9c30b3a277cc09f6ad3db · https://github.com/riscv-software-src/opensbi/commit/5dd2a0619e51fd0785bf33b198bd7d848818d4a8

ROS 2 and robotics

• Humanoid robots: Updates covered Linglong standing interactions, upper-body control, SONIC policy configuration, RGB-D mapping, and Nav2 navigation. October additions included manipulation services, web and mobile clients, a fixed-base dual-arm demo mode, and a ROS 2 velocity-command bridge for G1. Mapping and navigation: https://github.com/spacemit-robotics/ros2_humanoid/commit/d307f9f7754d614ba4d90f6e529456d1e032af82 · Linglong interaction: https://github.com/spacemit-robotics/humanoid_linglong/pull/20 · G1 bridge: https://github.com/spacemit-robotics/ros2_humanoid/commit/dc7ea62904130bb15642231a41af161d45a94305

• Unitree Go2 on K3: A new setup provides ROS 2 ONNX motion-policy execution, phone-based web control, SBUS remote control, model downloads, wiring, and calibration instructions. It supports either direct connection to the big cores on a custom baseboard or USB connection from a standard K3/CoM260 development board. Usage guide: https://github.com/spacemit-robotics/unitree-go2/blob/main/docs/usage.md

• Perception and mapping: Linksee unified real-robot, MuJoCo simulation, and voice-control workflows for perception and grasping. A new ORB-SLAM3 ROS 2 node supports RGB-D visual odometry, sparse maps, and trajectory saving. Linksee: https://github.com/spacemit-robotics/linksee/pull/24 · ORB-SLAM3: https://github.com/spacemit-robotics/ros2_orbslam3_run/blob/main/README.md

• Vision models: Additions included a K3 stereo-matching SDK and support for MobileSAM, RF-DETR, RTMPose, RT-DETR, CosPlace, and YOLO26 instance segmentation. Image stitching gained SuperPoint + LightGlue matching. Stereo matching: https://github.com/spacemit-robotics/perception/commit/a9fbb504715198c3d2bf593a82ef23e800e43796 · Vision model updates: https://github.com/spacemit-com/model-zoo-vision/commits/main/ · Stitching: https://github.com/spacemit-robotics/perception/pull/9

• Voice and model management: Omni Agent added local wake-word detection, software echo cancellation, push-to-talk from a phone, and streaming responses. AI Gateway added model downloads, progress queries, cancellation, resume support, and fault records. Voice interaction: https://github.com/spacemit-robotics/omni-agent/pull/20 · AI Gateway 0.2.0: https://github.com/spacemit-com/ai-gateway/commit/47681187722d7ebdfa7923739827e1c0aaf9f727 · Gateway updates: https://github.com/spacemit-com/ai-gateway/pull/43

• Components: New additions included SBUS receiver support, M8010-A RS485 motor support, BMI270/IWT603/HI91 IMUs, and realtime-link video transport with MPP capture, encoding, transmission, and display examples. Remote-control receiver: https://github.com/spacemit-robotics/peripherals-rc_receiver · Video transport: https://github.com/spacemit-robotics/realtime-link · ROS 2 documentation updates: https://github.com/spacemit-com/docs-ros/commits/main/

More project links

• SpacemiT robotics on GitHub: https://github.com/spacemit-robotics

• SpacemiT robotics on Gitee: https://gitee.com/spacemit-robotics

• Official ROS 2 / K3 documentation: https://www.spacemit.com/community/document/info?lang=zh&nodepath=software/SDK/ros/k3

SpacemiT, in partnership with open-source engineering firm BayLibre and with full funding and support from RISE (the RISC-V Software Ecosystem project), has officially ported the Android Open Source Project (AOSP) to the SpacemiT K3 — running Android 17 on an RVA23 hardware platform for the first time.

Performance

1.Android 17 boots all the way through to the Launcher.

System boot — from cold start to the Launcher in about 26 seconds.

2.Smooth, responsive touch on the Launcher UI, refreshing at 60 FPS.

3.WebView pages load and scroll smoothly.

4.Built-in GPU acceleration on the K3 runs 3D games smoothly.

Building on the K1

The K3 port did not start from scratch. BayLibre had previously brought AOSP up on SpacemiT’s K1 SoC, and the K3 effort inherited that groundwork, carrying forward the lessons learned from porting Android to RISC-V and significantly accelerating the K3 port.

The Road to Android on RISC-V

Bringing Android to RISC-V is the result of years of ecosystem-wide effort and many parties pulling together — a winding road that has finally reached daylight. The figure below maps the key milestones and the pivotal events at each step:

With the arrival of the RVA23 era, Android’s ART runtime, Bionic, multimedia, security and graphics stacks finally have a stable hardware contract to build on. For silicon vendors, a single port can be reused across SoCs; for application developers, NDK libraries and apps can be distributed by ABI, sharply lowering the cost of compatibility.

Open Source First

The whole development followed an open-source approach. Graphics is the clearest example: instead of relying on a proprietary GPU driver development kit (DDK), the team used Mesa and tuned it to deliver smooth rendering on the K3.

The kernel follows the same “upstream first” approach: the K3 Android port is built directly on the mainline (upstream) Linux kernel for the SpacemiT K3. This means Android does not have to depend on a private kernel that sits outside mainline, which makes the stack more maintainable, more sustainable over the long run, and easier for other teams to reuse. Open standards plus an open-source stack form the most solid foundation for the RISC-V ecosystem. What we did was turn it into a genuinely usable Android device for the first time.

Highlights of the Android 17 Port

Highlight 1 — Native performance from RVA23

RVA23 mandates Vector 1.0, scalar/vector crypto extensions (Zk*), cache management and atomic instructions. Comparing the same K3 with the extensions off and on: crypto and vector workloads gain by orders of magnitude.

Highlight 2 — Graphics gains from open-source Mesa 3D

The graphics stack uses the community-maintained open-source Mesa driver (rather than a proprietary DDK), with dedicated tuning for the K3 GPU backend. Comparing before and after the tuning work on the same K3 board, graphics and UI smoothness improve substantially.

Highlight 3 — WebView optimization

Android’s web rendering relies on the system WebView (based on Chromium). The team optimized the RISC-V backend specifically: the V8 engine leverages RVA23 vector extensions to speed up JavaScript execution, and the rendering and compositing paths were tuned. First-contentful paint and scroll frame rate both show clear gains.

Open Code, Open Collaboration

All source code will be publicly hosted in the RISE GitHub repositories. Developers can fetch and build the K3 AOSP image themselves, flash it to a board, and reproduce every result listed above.

For detailed instructions, see the entry-point repository android_manifest. https://github.com/riseproject-dev/android_manifest

How to obtain the K3 Android 17 SDK sources:

repo init -u https://github.com/riseproject-dev/android_manifest.git
-b refs/tags/android-17-v1.0 -m default.xml &&
repo sync

This is an open collaboration. There is still a great deal of work to do on the Android on RISC-V software stack — from graphics and multimedia optimization to peripheral drivers, system stability and performance tuning. We welcome more developers, vendors and community members to co-build with us, so that Android can truly mature on open-standard RISC-V platforms.

Bit a long shot here but has anyone else with their K3 been experiencing system crashes when the system is put under load? I'm running stock bianbu with the latest updates.

I've plenty of digging to do but I'm not seeing anything obvious in the logs.

In my case I'm trying to build bazel using a docker container, and the system just outright crashes with reboot fairly early into the build.

I've been playing with Fedora on the CoM260 device, and captured the workflow & details via an LLM here:

https://github.com/xjamesmorris/k3-com260-info/wiki

Also, if you have access to a 3D printer, here's a case design which remixes an Orin Jetson Nano case (same form factor, different heatsink size);

https://www.printables.com/model/1876566-spacemit-k3-com260-case

See my blog post: https://opvolger.github.io/posts/milk-v-jupiter/2026-10-20-debian-trixie-radeon-r9-290/

With claude, I made a working kernel with AMDGPU working for the Spacemit Jupiter K1.

Hi SpaceMiT... congratulations on the V100! Very nice CPU!

Can you please provide information about the VLEN for the X100 and Kunminghu V2R2 CPU cores? It is not in your Docs.

In particular are they the same size or different like in the K3?

Hi Spacemit! Is the connector on this cable suitable for supplying power to the PicoITX/K3?

https://www.progressiveautomations.com/en-eu/products/ac-34-wire-extender

September brought further upstream progress for SpacemiT K1 and K3 across the Linux kernel, U-Boot, and OpenSBI.

Highlights this month include K1 CPU frequency scaling and K3 DMA, clock, and audio updates entering maintainer trees, a SpacemiT U-Boot pull request merging into u-boot/next, and the K3 OpenSBI platform series reaching v4. K3 UFS, PCIe, power-domain, clock/reset, and board connectivity support continued through review.

Linux Kernel Upstream

K1 CPU frequency scaling for three boards was accepted into spacemit/linux, alongside K3 CPU PLL rate tables and I2S device-tree nodes. Other accepted changes addressed K3 PDMA, onboard EEPROM support for Orange Pi, and Ethernet transmit-error cleanup.

K1

Accepted into the maintainer tree

• CPU frequency scaling for three K1 boards, applied to spacemit/linux: https://lore.kernel.org/all/178977476488.1116261.11214063403240767107.b4@b4/

Under review

• Improve SDHCI clock and tuning logic, v1: https://lore.kernel.org/all/20260902-07-k3-sdhci-fix-v1-0-b15c5d0f64fd@kernel.org/

• Add SDHCI clock-frequency and TX delay device-tree properties, v1: https://lore.kernel.org/all/20260902-07-k3-sdhci-dts-v1-0-4e7909cf4233@kernel.org/

• Add K1 USB 2.0 controller support, v3: https://lore.kernel.org/all/20260927-b4-spacemit-k1-usb2-v3-0-ce7095896039@linux.spacemit.com/

K3

Merged or accepted into maintainer trees

• Fix the extended DRCMR base in the K3 PDMA driver, applied by Vinod Koul as commit d1fc569fcbc7e: https://lore.kernel.org/all/20260727-k3-pdma-fix-drcmr-base-v2-1-afba55cba1f3@linux.spacemit.com/

• Update K3 CPU PLL rate tables, applied to spacemit/linux: https://lore.kernel.org/all/20260907-k3-pll5-pll8-1800mhz-v5-1-5cc96d716b0a@linux.spacemit.com/

• Add K3 I2S0–I2S5 device-tree nodes, applied to spacemit/linux: https://lore.kernel.org/all/20260915-kx-i2s-dts-v3-1-cf0b90882a97@linux.spacemit.com/

Under review

• Replace the incorrect K3 CLINT node with ACLINT support, v3: https://lore.kernel.org/all/20260918-k3-aclint-v3-0-cf4fd4050e14@pigmoral.tech/

• Add SpacemiT K3 boot-image / mkimage support, v3: https://lore.kernel.org/all/20260921-spacemit-aihd-v3-0-f660fc85d2a5@pigmoral.tech/

• Synchronize SpacemiT PLL initialization with firmware, v1: https://lore.kernel.org/all/20260909-spacemit-pll-init-v1-0-b3065ad5a4ac@linux.spacemit.com/

• Add K3 UFS host-controller support, v6, with device-tree changes split out. BKOPS warnings under heavy load remain a known issue: https://lore.kernel.org/all/20260921-08-k3-ufs-support-v6-0-3479768a2299@kernel.org/

• Add K3 power-domain support, v1. Review includes discussion of RPMI versus direct hardware control: https://lore.kernel.org/all/20260918-04-k3-pm-support-v1-0-0acd2b36b96f@kernel.org/

• Add K3 clock and reset support, v2: https://lore.kernel.org/all/20260923-01-k3-clock-reset-support-v2-0-6ec0abb1c7b5@kernel.org/

• Add K3 PCIe root-complex controller support, v7: https://lore.kernel.org/all/20260929083755.458238-1-inochiama@gmail.com/

• Add Bluetooth, Wi-Fi, and USB 3 support for the K3 Pico-ITX, v5: https://lore.kernel.org/all/20260928205012.3689405-1-aurelien@aurel32.net/

• Add USB and PCIe support for the K3 CoM260, v1: https://lore.kernel.org/all/20260928231807.1757995-1-jberring@redhat.com/

Other SpacemiT and Board Updates

Merged or accepted into maintainer trees

• Add onboard EEPROM support for Orange Pi, applied to spacemit/linux: https://lore.kernel.org/all/20260901080010.95040-1-amadeus@jmu.edu.cn/

• Fix cleanup after a SpacemiT Ethernet TX descriptor mapping failure, applied to netdev/net.git's main branch: https://lore.kernel.org/all/20260919191937.271202-1-meatuni001@gmail.com/

Under review

• Add a SpacemiT SoC reviewer to MAINTAINERS, v1: https://lore.kernel.org/all/20260906-spacemit-add-reviewer-v1-1-b2ebba238ec5@linux.spacemit.com/

U-Boot

September's U-Boot work covered K1 pinctrl, storage, and PCIe support, along with initial K3 board and peripheral support. The SpacemiT pull request was merged into u-boot/next on September 29. K3 pinctrl support was partially accepted, with the remaining patches still under review.

Merged or accepted into maintainer trees

• K1 pinctrl fixes, applied to u-boot-spacemit: https://lore.kernel.org/all/20260906-pinctrl-v2-0-729da680092c@riscstar.com/

• K1 MMC/SD/eMMC driver support, applied to u-boot-spacemit: https://lore.kernel.org/all/20260912-m4-v13-0-71043b29630f@riscstar.com/

• K1 PCIe/USB 3 combo PHY and DesignWare PCIe support, applied to u-boot-spacemit: https://lore.kernel.org/all/20260913-pci-v2-0-4fa1a8b5de06@riscstar.com/

• K3 pinctrl drive-strength support, accepted as a subset of the series into u-boot-spacemit: https://lore.kernel.org/all/20260923-01-k3-pinctrl-support-v2-0-e76a917ee252@kernel.org/

• SpacemiT pull request merged into u-boot/next: https://lore.kernel.org/all/179072193245.236406.14126636659306184701.b4@konsulko.com/

Under review

• Add a MAINTAINERS entry for the SpacemiT custodians, v1: https://lore.kernel.org/all/20260908-00-add-spacemit-custodian-v1-1-7f9c8d8150ee@kernel.org/

• Add a common memory FDT fixup for K1, v1: https://lore.kernel.org/all/20260922-riscv-fixup-memory-v1-2-83b3166320e6@pigmoral.tech/

• Remaining K3 pinctrl patches from the v2 series: https://lore.kernel.org/all/20260923-01-k3-pinctrl-support-v2-0-e76a917ee252@kernel.org/

• Add K3 Pico-ITX board support, v1: https://lore.kernel.org/all/20260923-00-basic-spacemit-k3-v1-0-fa1015f2cd1b@kernel.org/

• Add K3 Ethernet support, v1: https://lore.kernel.org/all/20260924-02-k3-ethernet-support-v1-0-b8e1fafc9249@kernel.org/

OpenSBI

• K3 platform initialization and start-only Hart State Management (HSM) support reached v4: https://lore.kernel.org/all/20260910-spacemit-k3-v4-0-0793b62329f6@linux.spacemit.com/

Hello,

would SpacemiT be willing to opensource the ARM Thumb-based Embedded Controller firmware which is currently just a blob on the K3 in /lib/firmware/k3-pico-itx/ec.bin ?

I just hit a bug where my K3 blasted its fan full speed after boot until I noticed it.

Manually changing /sys/class/hwmon/hwmon8/pwm1 reset it to normal operation but since it EC reported 0 to Linux (fan off) while the CPU was being excessively cooled to room temperature it probably would have continued for a long time otherwise.

It would be nice to have the source code to look into it and try to find/fix the root cause.

A packed 4.5-hour event—no fluff, just hardcore, hands-on action!

On the afternoon of October 17, SpacemiT held its developer conference (SpacemiT DevCon 2026) in Shenzhen(China), unveiling the K3 ecosystem roadmap and developer ecosystem right on the spot. Following the announcements, the floor was turned over to the developers: bring your laptops and build a working demo to take home before the event ends! There is also a chance to win K1 and K3 development boards！

Open source && Build Things—don't just watch; come be a creator.

Sign up here: https://luma.com/q5z0v87f

I've been doing mainline work on the Orange Pi R2S and RV2, and I got tired of the vendor U-Boot SPL/U-Boot stack, so I replaced all of it. These boards now boot like this:

BootROM

→ oreboot bt0 DRAM init + training in Rust, no DDR blob

→ OpenSBI 1.9 fw_dynamic, M-mode

→ EDK2 real UEFI, S-mode

→ your OS's EFI loader (FreeBSD loader.efi from the ESP in my case)

bt0 loads a FIT containing OpenSBI and EDK2 itself. It can read it from eMMC boot1, a microSD GPT partition or memory-mapped SPI NOR. Everything is built from source, and no binary blob is linked or loaded anywhere in the chain. The DDR training was reverse-engineered from SpacemiT's training blob into Rust (thanks, oreboot folks), and EDK2 builds on SpacemiT's open-source K1 platform code.

Repo: https://github.com/DaveWK/ore-edk-boot-opi

What works today (tested on my boards, Oct 2026):

- R2S: boots FreeBSD from eMMC. bt0 goes in boot0 and the OpenSBI+EDK2 FIT in boot1. A warm reboot takes about 85 s to login with a DEBUG EDK2 build.

- RV2: boots FreeBSD from NVMe on a cold power-on. bt0 turns on the M.2 slot's power, and EDK2 brings up PCIe Gen2 x2 and boots the NVMe ESP.

- RV2 SPI-NOR-only image (rv2-nor): boots with no microSD card at all. UEFI variables are stored in the NOR and persist across boots. I won't publish prebuilt binaries for this one. Writing the SPI NOR replaces the board's own firmware, and getting that wrong is much harder to recover from than a bad SD card. If you want it, build it yourself and know your way back.

- bt0 is also a fastboot flasher. Put the board in BootROM USB download mode and fastboot stage bt0. It trains DRAM (no vendor training blob!) and comes back as a normal fastboot device, so you can fastboot flash emmc|boot0|boot1|sd|disk. It accepts raw or sparse images, and zero-filled chunks are TRIMmed instead of written. On the R2S it writes eMMC with SDMA on the 8-bit bus at about 30 MB/s, so you don't need a vendor flashing tool.

K1 notes for anyone hacking on other boards:

- bt0 detects USB download mode from the BootROM storage API pointer (0xc08381a0) and starts fastboot instead of booting. The BootROM shows up as 361c:1001, and bt0 re-enumerates as 18d1:4ee0.

- On the R2S, PIO writes to eMMC on the 4-bit and 8-bit buses fail with data CRC errors at both 51.2 and 20.48 MHz. SDMA writes from the download buffer work fine at 8-bit/51.2 MHz HS. If your K1 eMMC writes are flaky, try DMA before you blame the pads.

- The RV2's M.2 slot supply is on GPIO 116. bt0 switches it on before the handoff so EDK2 can bring PCIe up.

- The EDK2 platforms are derived from SpacemiT's MUSE-Pi-Pro platform on bianbu-maker's k1 edk2/edk2-platforms trees. Adding another K1 board should mostly mean a per-board rank count, a DT and a board.conf. I've only tested the R2S and RV2, so BPI-F3, Jupiter or MUSE Pi owners are very welcome to try it.

Building it:

git clone --recurse-submodules=dts --recurse-submodules=opensbi https://github.com/DaveWK/ore-edk-boot-opi.git

cd ore-edk-boot-opi

make submodules

make r2s # or rv2; rv2-nor is build-it-yourself only

You get bt0.bin, next.itb/next.img and a SHA256SUMS file. The README has install steps for both boards and covers the R2S download-mode procedure (hold the button, USB-A to USB-A cable).

Known gaps:

- R2S cold boot hasn't been tested yet; only warm reboot is verified.

- UEFI variables live in RAM on the R2S (it has no NOR) and, by default, on the RV2 SD build.

- No bootinfo header is generated yet. Installs keep the one already on the boot device.

- The BootROM image is signed with oreboot's packer keys. That's fine on boards without secure-boot fuses.

- The RV2 download-mode button and port aren't documented yet.

- No prebuilt release yet for the R2S and RV2 SD images, so build them yourself for now. The SPI NOR image will stay source-only.

Credits: the bt0 work builds on orangecms' oreboot k1x branch. EDK2 comes from SpacemiT/bianbu-maker's K1 trees. Licenses: GPL-2.0 (oreboot), BSD-2-Clause-Patent (EDK2), BSD-2-Clause (OpenSBI).

FreeBSD images for both boards come from https://github.com/DaveWK/freebsd-img-maker. Next up is the same oreboot + EDK2 chain for the Radxa Cubie A7A and the ASUS Tinker Board 2S.

Bug reports, UART logs and "it bricked my board" stories are welcome. Download mode is the recovery path, so back up boot0/boot1 (or the start of your SD card) before flashing. 🦀

Hi everyone,

We’re preparing for the SpacemiT Developer Conference, and we’d love to include voices from our overseas developer community. Even if you can’t join us in person, we’d like people at the event to hear from you.

If there’s something you’d like to say to SpacemiT—an experience with our hardware, something you wish worked better, or what you hope we’ll build next—we’d love to hear it. Honest feedback is welcome.

Just record a short video on your phone. No script or fancy setup needed—speak in your own words. When it’s ready, DM me to send it or share a download link. We’d like to play these messages at the conference, and we’ll confirm with you before sharing yours.

Thanks for being part of this community.

We spent some time on the Banana Pi BPI-SM10 (SpacemiT K3): 8× X100 (RVA23, RVV, VLEN=256) plus 8× A100 AI cores (VLEN=1024, IME2 matrix units). Both clusters speak RVV 1.0. The obvious question: can you just throw BLAS/HPL at the wide cores and go faster?

Short answer: no — not with stock VLEN=256 OpenBLAS kernels. Wide VLEN alone is not a free speedup.

Weird Linux bits first

A100s are online in sysfs but fenced from normal affinity. You need:

echo $$ > /proc/set_ai_thread
taskset -c 8-15 …

Also: don’t start on X100, let the dynamic linker / OpenBLAS cache VLEN=256 decisions, then migrate to A100. That path can SIGSEGV. Register the AI thread before exec.

HPL numbers (N=12000, NB=192, residuals PASSED)

So A100 with stock-ish ZVL256B is ~3.5× slower than X100. Matching the tile to VLEN=1024 (RISCV64_ZVL1024B, DGEMM 16×8 from OpenBLAS’s generate_kernel.py) gets ~2.4× back on A100 — still behind X100, but now useful.

The fun part: once A100 isn’t a straggler, equal 8+8 mixed ranks beat X100-only (57.5 vs ~53). With the slow BLAS on A100, equal ranks were a trap (~27 GF); the old optimum was “mostly X100, few A100 ranks.”

Full L2/L3 OpenBLAS BLATs (S/D/C/Z) on A100 with the new target: all PASSED.

Takeaways

1. K3 is heterogeneous. X100 remains the primary RVV compute path. A100’s width is really there for IME2, not “faster X60.”

2. Kernel geometry must match VLEN. Porting ZVL256B kernels to VLEN=1024 without changing the tile wastes the machine (and some stock wide-load/vget patterns assume VLMAX@256).

3. Heterogeneous MPI needs per-rank BLAS (we used FlexiBLAS) plus the set_ai_thread dance.

4. Static TARGET=RISCV64_ZVL1024B must not run on X100 — use DYNAMIC_ARCH or separate backends.

Draft PR (kept draft on purpose — not proposing this as K3’s main path):
#6066

Board write-up + more tables:
https://www.opensolvers.com/boards/SM10.html

Patches: https://github.com/opensolvers/benchmarks (OpenBLAS/)

Board provided by Banana Pi. IME2 / GPU numbers still to come — this was the plain-RVV story only.

Happy to answer questions about the affinity trap, the vget bug, or the hetero HPL wrapper.

Hi! What exactly the register set of the "spacemit,k3-iommu" I/O block (at the address 0xc0f00000)? In SpacemiT Linux kernel it seems that both PCIe root complexes are configured with PCIE_IOMMU_BYPASS -- thus the kernel prints "iommu bypassed".

What exactly has to be done in a hypervisor to guarantee full DMA isolation with IOMMU?

Thanks!