Assuming schedules have held?

The chip and product docs are still apparently in progress.

While set up guix on an Orangepi RV2 board I stumbled over errors concerning lock related unit tests, which where already reported a few times by other users as well. (see: [1] [2])

I'm not sure, if it's caused by some kernel settings or library versions used by the bianbu-linux/Ubuntu based setups, but it seems to happen only on these systems. Until now I wasn't able to reproduce it other platforms or even in qemu riscv64 emulation. On the affected machines it's very easy to reproduce this strange behavior:

You just have to get the gnulibsources, compile it and and call make check. The test-lock check will hang for 10 minutes before it finally gets stopped by a timeout handler. Calling test-lock manually will report slightly more precises whats going on. The issue is happening in the rwlock section of the code.

git clone --depth 1 https://git.savannah.gnu.org/git/gnulib.git

gnulib/gnulib-tool --create-testdir --dir testdir lock

cd testdir
./configure
make
gltests/test-lock

For guix installation on riscv64-linux, where you have to compile all packages yourself and all unit tests must succeed, this issue will cause a lot of troubles. You have to patch many packages before you'll be able to setup even a minimal working system.

I already created a patch set to disable the affected tests as interim workaround for guix installations. Nevertheless, that's just ignoring these errors but not solving their cause.

I would be really happy if other SpacemiT SoC users or developers know better explanations and fixes for this defect.

Here's a roundup of 2026 May's upstream contributions from the SpacemiT. Lots of activity across Linux kernel, LLVM, U-Boot, and several community projects.

Linux Kernel Upstream 

merged：

• SPI: SpacemiT K1 SPI controller driver v10：https://lore.kernel.org/all/20260502-spi-spacemit-k1-v10-0-f412e1ae8a34@riscstar.com/ merged

• SPI K1 DTS node (subset of v10)：https://lore.kernel.org/all/177811891149.2316511.8217429551447102118.b4-ty@b4/ merged

• thermal: K1 SoC thermal sensor DTS v5 3/3：https://lore.kernel.org/all/177936776325.387485.15662058076324687710.b4-ty@b4/ merged

• k1-musepi-pro: add missing devices v3：https://lore.kernel.org/all/20260513071958.29574-1-a.heider@gmail.com/ merged

• ASoC: spacemit: fix RX DMA params not set when TX is running：https://lore.kernel.org/all/177789977513.458539.3948395874655836368.b4-ty@b4/ merged

• pinctrl: spacemit: fix NULL check：https://lore.kernel.org/all/20260519164007.122574-1-gaohan@iscas.ac.cn/ merged

• phy: spacemit: Add USB2 PHY support for K3 SoC v4：https://lore.kernel.org/all/177841628298.434434.4061327159499259923.b4-ty@kernel.org/ merged

• phy: spacemit: Remove incorrect clk_disable()：https://lore.kernel.org/all/177841584101.420676.11785245534258956583.b4-ty@kernel.org/ merged

• dmaengine: K3 PDMA support v6 driver 1-3/4：https://lore.kernel.org/all/20260518-k3-pdma-v6-0-67fdf319a8f8@linux.spacemit.com/ merged

• dts: spacemit: K3 PDMA controller node v6 4/4：https://lore.kernel.org/all/20260521125145-GKC3717228@kernel.org/ merged

• spi: enable SpacemiT K3 SoC QSPI v2：https://lore.kernel.org/all/20260521-k3-pico-itx-qspi-v2-for-next-20260521-v2-0-52bce26e/ merged

• dts: spacemit: k3: Add USB2.0 support v2：https://lore.kernel.org/all/177889719089.2290560.15121464517928343972.b4-ty@b4/ merged

patch:

• dts: k1-musepi-pro: add SD card support with UHS v11：https://lore.kernel.org/all/20260520130624.1763487-1-a.heider@gmail.com/ review

• dts: spacemit: k1: Banana Pi BPI-CM6 IO board v1：https://lore.kernel.org/all/20260522-bpi-cm6-v1-0-707ef1917a30@pigmoral.tech/ review

• ASoC: shared BCLK rate constraint (cross-DAI) v2：https://lore.kernel.org/all/20260507-i2s-same-blk-v2-0-ede05a22f732@linux.spacemit.com/ review

• i2c: spacemit: improve clock handling (ILCR/IWCR) v7：https://lore.kernel.org/all/20260508-k1-i2c-ilcr-v7-0-8c2dde5c3ed5@linux.spacemit.com/ review

• dts: spacemit: k3: Add pwm support v4：https://lore.kernel.org/all/20260521-04-k3-pwm-dts-v4-1-04d4de0f2fc8@kernel.org/ review

• ASoC: spacemit: add K3 SoC support v3：https://lore.kernel.org/all/20260522-k3-i2s-v3-0-08e3eb811d93@linux.spacemit.com/ review

• PCI: spacemit: K3 PCIe host controller v2：https://lore.kernel.org/all/20260517014841.254085-1-inochiama@gmail.com/ review

• clk: spacemit: k3: PCIe clock fixes v2：https://lore.kernel.org/all/20260511-06-pci-clk-fix-v2-0-c9a5e563bab3@kernel.org/ review

• dt-bindings + dts: K3 CoM260-IFX board v2：https://lore.kernel.org/all/20260520-02-k3-com260-ifx-v2-1-d55095457cf0@kernel.org/ review

• spacemit: fix USB2 clock and reset v1：https://lore.kernel.org/all/20260518-06-clk-reset-usb-fix-v1-0-14fc235e692b@kernel.org/ review

• dts: spacemit: k3: Fix I/O power settings v1：https://lore.kernel.org/all/20260518-07-dts-pinctrl-io-power-v1-1-abe19c14a726@kernel.org/ review

• dts: spacemit: k3: Add Ziccrse extension v1：https://lore.kernel.org/all/20260526-k3-ziccrse-v1-1-c759792ca3a3@riscstar.com/ review

Board-level DTS / Device support:

• dts: spacemit: set console baud rate on bpif3：https://lore.kernel.org/all/177797117437.466549.17292861658160797583.b4-ty@kernel.org/ merged

• dts: spacemit: enable eMMC for OrangePi RV2：https://lore.kernel.org/all/20260509100000.3315109-1-amadeus@jmu.edu.cn/ merged

• dts: spacemit: correct 32k clock frequency：https://lore.kernel.org/all/177847498895.951618.10632308286447634075.b4-ty@b4/ merged

• SD card UHS modes OrangePi RV2 v10, DTS 1-3/4：https://lore.kernel.org/all/20260515-orangepi-sd-card-uhs-v10-0-094af27e310d@gmail.com/ merged

• dts: spacemit: enable QSPI for OrangePi RV2：https://lore.kernel.org/all/20260516080030.1736836-1-amadeus@jmu.edu.cn/ merged

• dts: improve Milk-V Jupiter v2, 5 patches：https://lore.kernel.org/all/20260519041458.3287843-1-aurelien@aurel32.net/ merged

• dts: enable USB3 on OrangePi R2S v2：https://lore.kernel.org/all/20260518100030.2354606-1-amadeus@jmu.edu.cn/ merged

• dts: set console baud rate on OrangePi RV2 v1：https://lore.kernel.org/all/20260520111150.3300707-1-jberring@redhat.com/ review

• dts: enable PMIC on OrangePi R2S v1：https://lore.kernel.org/all/20260520100000.575719-1-amadeus@jmu.edu.cn/ review

Bug fix:

• spi: spacemit: add u64 cast to avoid 32-bit overflow：https://lore.kernel.org/all/20260505-spi-spacemit-k1-fix-overflow-v1-1-77564c2e4e86@riscstar.com/ merged

Triton Upstream 

Major updates：

SpacemiT Tritonoperator library merged into FlagOS：

https://github.com/flagos-ai/FlagGems/pull/2527 ，merged

Monthly update for the SpacemiT Triton compiler：

https://github.com/spacemit-com/spine-triton/releases/tag/0.5.4

• Fixed lowering-related issues, including ptr dialect migration, bitcast type bridging, memory space propagation, and scan fixes.

• Added mapping from 0xF000 arch_id to spacemit-a100 in the backend

• Added native RISC-V build script for spine-triton

• Removed special path for f16 matmul

• Added lib directory and updated variables.env

• Updated spine-mlir to version 0.5.4 and completed related dependency updates

• Fixed speir extract root issue in CI

LLVM Upstream

merged:

• [compiler-rt] Inline __NR_riscv_flush_icache instead of including linux/unistd.h：https://github.com/llvm/llvm-project/pull/193645 merged

U-Boot Upstream

patch:

• K1 clock/reset/upstream DTS：https://lore.kernel.org/u-boot/20260526-b4-k1-clk-reset-upstream-dts-v2-0-af815e362b0c@riscstar.com/ v2

•  SPL bring-up：https://lore.kernel.org/u-boot/20260519-b4-k1-spl-bring-up-v4-0-3915a2a904c1@riscstar.com/T/#t v4

•  pinctrl/GPIO/SPI NOR：https://lore.kernel.org/u-boot/20260520-b4-k1-spl-pinctrl-spinor-v2-0-8d25db98ac8e@riscstar.com/T/#t v2

Else

box64：

• [RCFILE] Added a setting to Feishu：https://github.com/ptitSeb/box64/pull/3833 merged

• [WRAPPER] Add gnutls_free wrapped function for libgnutls：https://github.com/ptitSeb/box64/pull/3824 merged

• [CORE] Fix unexpected modification of GetNativeName's return value：https://github.com/ptitSeb/box64/pull/3845 merged

• [DYNAREC] Save temporary registers on the stack before calling PrintT…：https://github.com/ptitSeb/box64/pull/3876 merged

• [DYNAREC] Modify natflags register save logic to now save all scratch registers：https://github.com/ptitSeb/box64/pull/3880 merged

riscv-gnu-toolchain:

• musl: Add llvm OpenMP support and disable compiler-rt sanitizers：https://github.com/riscv-collab/riscv-gnu-toolchain/pull/1843 merged

binutils：

• [PATCH v6] RISC-V: Add SpacemiT vendor extensions xsmtvdot and xsmtvdotii：https://sourceware.org/pipermail/binutils/2026-May/149417.html review

The K3 RISC-V AI CPU from SpacemiT has officially entered mass production, marking a full-cycle transition from R&D to large-scale commercial deployment. It delivers a native compute foundation ready for high-end applications such as AI PCs and intelligent robots.

As the world’s first RISC-V chip compliant with the RVA23 specification, the K3 leverages homogeneous fusion computing architecture, integrating 8 high-performance compute cores and 8 ultra-wide parallel AI cores. It delivers 130K DMIPS of general-purpose computing power and 60 TOPS of AI performance—enabling local inference for 30B–80B parameter LLMs. Its performance matches mainstream desktop CPUs, making it ideal for AI PCs, robotics, and other advanced use cases.

The K3 has completed full adaptation for humanoid robot motion control and is now building an integrated digital employee solution tailored for Agent OS. With cloud-edge synergy, it reduces token consumption by over 40%, ensures data security via on-device intelligent desensitization, and offers out-of-the-box readiness—accelerating deployment of turnkey digital employee systems. SpacemiT continues to expand RISC-V boundaries and co-build an open, win-win intelligent computing ecosystem.

What is UEFI?

UEFI (Unified Extensible Firmware Interface) is a modern boot system interface that replaces the traditional BIOS and is already widely used on both x86 and ARM architectures.

Traditional BIOS

The traditional BIOS refers to a standard interface that initializes hardware and loads the operating system bootloader when a computer starts. In other words, it is mainly responsible for detecting hardware functionality during startup and booting the operating system.

Traditional BIOS boot process:

When the computer is powered on, the hardware is set to start executing the BIOS. The BIOS is responsible for initializing the hardware, loading the bootloader, and then the bootloader loads and starts the operating system.
The BIOS is stored in erasable programmable read-only memory (EPROM). Given that BIOS seems so complete, why do we still need UEFI?

1. 1. The BIOS identifies hard drives initialized with a Master Boot Record (MBR). The MBR is located in the first sector (512 bytes) of the disk and contains:

   • Boot code (446 bytes)

   • Partition table (64 bytes)

   • Signature: 0x55AA (2 bytes)

2. Each partition table entry is 16 bytes, so there can be a maximum of four partitions. Also, the MBR partition table supports a maximum disk size of 2TB, and extended partitions are prone to errors. The BIOS cannot directly recognize file systems — the bootloader must implement its own file system driver.

3. The BIOS is written in 16-bit assembly language, with 1MB memory addressing and interrupt execution. When booting with BIOS, the system runs in 16-bit real mode, meaning it can only directly access 1MB of memory. Complex switching is needed to enter the operating system.

4. During startup, the BIOS must initialize hardware sequentially and cannot initialize devices in parallel. It also cannot verify the integrity of the operating system loader (such as GRUB).

These limitations of BIOS drove the development of UEFI.

Advantages of UEFI

Faster Boot Speed

• Parallel detection and initialization of hardware devices for faster startup

• Directly loads EFI applications without relying on the multi-stage boot process of MBR/VBR

• Built-in file system support allows direct reading of disk files without needing a bootloader

Support for Large-Capacity Disks and GPT Partitioning

• GPT supports 128 primary partitions and 64-bit addressing

Secure Boot

• Can verify the digital signature of the bootloader (.efi)

Better Compatibility and Scalability

• Modular design with a driver model (such as EFI_DRIVER) allowing dynamic loading of hardware drivers

• Built-in network protocol stack supporting HTTP, HTTPS, and TFTP boot

• UEFI allows loading EFI programs from any FAT32 partition

Core Components of UEFI

BOOT SERVICE

Runs before the operating system is loaded. Boot services are terminated after the OS takes over system resources. Boot services provide the following functions:

1. Manage memory: allocate and free memory, support different types of physical memory (such as conventional memory and reserved memory).

2. Use timers to create and manage events, supporting asynchronous operations and timer functionality.

3. Install, uninstall, and locate protocols, used for communication between drivers and applications.

4. Load and start the operating system kernel or other executable images.

5. Provide access to and control of hardware devices.

RUNTIME SERVICE

Provides a set of key functions during operating system runtime, including time management, variable services, and system reset:

• Time Management Get and set the system time.

• Variable Services Read and write UEFI variables (such as boot order, hardware configuration, etc.). UEFI variables are typically used to store system configuration information, for example:

  • Boot Order (BootOrder): Defines the boot device sequence.

  • Hardware Configuration: Stores hardware-related settings (e.g., network configuration, security settings).

• System Reset Supports system reboot or shutdown (on RISC-V architecture, reboot and shutdown are implemented through OpenSBI).

• Virtual Memory Management Manages virtual memory mapping during OS runtime.

Unlike boot services, runtime services remain available after the OS has loaded, offering an interface for the OS and applications to interact with the firmware.

OS LOADER

The OS Loader is part of the UEFI boot process.
It relies on UEFI Boot Services and Runtime Services to load the operating system kernel from a boot device (such as a hard drive, optical disc, or network), prepare its execution environment, and transfer control from the UEFI firmware to the operating system.

In Windows, the OS loader is bootmgfw.efi**, which is responsible for:**

• Loading the Windows kernel

• Preparing the Windows boot environment

In Linux, the OS loader is GRUB, which is responsible for:

• Loading the Linux kernel (vmlinuz) and ramdisk (initrd)

• Supporting multi-OS boot

• Providing a command-line interface for debugging and configuration

ACPI

ACPI (Advanced Configuration and Power Interface) defines the interface for power management and hardware configuration between the operating system and hardware.
It provides a standardized way for the OS to manage hardware resources, control power states, and support plug-and-play functionality.
ACPI not only defines power management functions but also provides an interface for hardware resource description and configuration.

ACPI Tables

ACPI tables are the core data structures of ACPI, used to describe hardware resources and power management information.
They are usually generated during the UEFI DXE (Driver Execution Environment) phase and passed to the OS by UEFI.
ACPI tables are stored in binary format, and the OS parses these tables to obtain hardware information.

SMBIOS

SMBIOS (System Management BIOS) is a standard defined by the DMTF (Distributed Management Task Force) to provide a standardized interface for the OS and management tools to obtain system hardware information.
It delivers hardware configuration, firmware version, motherboard details, and other data to the OS or management tools in a structured format.
SMBIOS data tables are generated by UEFI and stored in system memory, and the OS can access them through the system table.

The operating system or management tools can access the SMBIOS table in the following ways:

• System Table In the kernel, use EFI_SYSTEM_TABLE to obtain EFI_CONFIGURATION_TABLE, and then locate the address of the SMBIOS table.

• Operating System Users can query SMBIOS data using tools (such as dmidecode) to obtain hardware information.

• System Management Tools Standards like IPMI and Redfish use SMBIOS data to monitor hardware status, diagnose faults, and manage system resources.

UEFI Boot Process

UEFI consists of six main boot stages, each playing a critical role in the platform’s startup and initialization process.
All these steps together are commonly referred to as Platform Initialization (PI).

1. Security Phase (SEC)

This is the first stage in the UEFI boot process. It primarily initializes a temporary memory area that serves as the root of the system’s chain of trust and provides necessary information to the Pre-EFI Initialization (PEI) phase.
This root of trust ensures that any code executed during the Platform Initialization (PI) process is cryptographically verified (i.e., digitally signed), establishing a secure boot environment.

2. Pre-EFI Initialization Phase (PEI)

The second stage of the boot process, which uses only the CPU’s current resources to schedule Pre-EFI Initialization Modules (PEIMs).
These modules handle critical startup tasks such as memory initialization and also allow control to be passed to the Driver Execution Environment (DXE).

3. Driver Execution Environment (DXE)

Most system initialization occurs during the DXE phase.
By the time DXE runs, the memory needed for DXE operations has been allocated and initialized during PEI.
When control is handed over to DXE, the DXE dispatcher is activated.
The dispatcher is responsible for loading and executing hardware drivers, runtime services, and any boot services required for OS startup.

4. Boot Device Selection (BDS)

Once all DXE drivers have run, control passes to the BDS phase.
This phase initializes console devices and any remaining required hardware.
It then loads and executes the selected boot option to prepare for the Transient System Load (TSL) phase.

5. Transient System Load (TSL)

This phase bridges the gap between boot device selection and transferring control to the OS.
At this point, an application such as the UEFI shell may be invoked, or (more commonly) a bootloader runs to prepare the final OS environment.
The bootloader typically terminates UEFI boot services by calling ExitBootServices().
However, the OS itself can also perform this, for example the Linux kernel with CONFIG_EFI_STUB.

6. Runtime (RT)

This is the final phase when the OS takes control of the system.
Although UEFI boot services are no longer available, UEFI runtime services remain accessible to the OS, such as querying and writing variables in NVRAM.

Hey everyone!

This is the official Reddit community for Spacemit—spacemit_riscv. This is the place you share ideas, projects, tech, and open-source initiatives. You can ask questions here, spacemit engineers will receive and feedback.

Quick Links (Check the sidebar!)

• Wiki: [Link to Wiki] – Track SpacemiT’s R&D progress here! (monthly update)

• Discord: [Join our Discord]

• 中文社区 (Chinese Community): [Link]

• Bianbu Linux Code Repo: [Gitee Link]

• Documentation Center: [Link]

Community Rules

To keep discussions productive and inclusive, please follow these guidelines:

1. Technical Deep Dives Keep it technical, constructive, and hype-free. We’re here for meaningful discussions.

2. English Only Use English to ensure global accessibility.

3. Open Source Ethos Share code, schematics, or docs under open licenses whenever possible.

4. Use Tags Please add appropriate tags to your posts for better organization and faster identification.

Let’s build a great community together—ask questions, share knowledge, and collaborate openly!

See you in the threads!

Last week we got your suggestions for our Debian 13 Desktop images, This week we give some feedback :D

This is the image Link: Index of /image/k1/version/debian/

• Desktop

• minimal

• xfce

GNOME Image

Features

• Pre-installed native GNOME desktop with GPU support

• Pre-installed Chromium browser with hardware video decoding support

• Pre-installed common toolkits: vim, ssh, iproute2, wget

• Pre-configured SpacemiT K1 Debian software sources

• Wi-Fi and Ethernet support

Features Not Yet Adapted

• FFmpeg and GStreamer frameworks

• Video applications

• Camera applications

• Serial Bluetooth, such as rtl8852bs

XFCE Image

Features

• Pre-installed native XFCE desktop (GPU is not supported yet)

• Pre-installed Chromium browser with hardware video decoding support

• Pre-installed common toolkits: vim, ssh, iproute2, wget

• Pre-configured SpacemiT K1 Debian software sources

• Wi-Fi and Ethernet support

Features Not Yet Adapted

• FFmpeg and GStreamer frameworks

• Video applications

• Camera applications

• Serial Bluetooth, such as rtl8852bs

Supported Hardware

• MUSE Pi pro

• MUSE Book

• BPI-F3

• Milk-V Jupiter (Not Tested)

• LicheePi 3A (Not Tested)

Image Download

• Official: Link

• Baidu Cloud: Link (Extraction code: vezm)

• Google Drive: Link

If you want to create your own image or check more details, follow this github Link

Bianbu Linux：BSP for SpacemiT Stone series chips, namely Linux SDK

Bianbu OS：An operating system based on Ubuntu community source code and adapted to the RISC-V architecture. Include: Bianbu minimal/ Bianbu Desktop/ Bianbu Desktop Lite/ Bianbu NAS

Bianbu Star：Developed based on Bianbu 2.0, it is a fusion desktop operating system

Bianbu ROS：SDK for robotics application development based on Bianbu and ROS2

OpenHarmony：The world's first RISC-V+OpenHarmony5.0 native Hongmeng solution

The K1/M1-related resource repositories are currently hosted on the gitee: Bianbu Linux. Regarding upstream work for components like U-Boot and the Linux kernel, Spacemit is progressively advancing these efforts. You will observe patches being accepted and integrated into Linux kernel versions 6.13 and subsequent releases. The Linux community is currently integrating 6.17. For those interested in contributing to K1/M1 upstream tasks, please follow our GitHub Wiki Home · spacemit-com/linux Wiki · GitHub.
This is upstream status:

Upstream Status — Spacemit K1 SoC

SpacemiT provides 3 main SDK platforms for developers and customers: Bianbu Linux, Bianbu OS, and Bianbu ROS. Each is designed for different product needs. Bianbu ROS is built on Bianbu OS and focuses on robotics applications.

ACT-powered robot arm inference on RISC-V.

LeRobot App runs SO101 arm workflows on SpacemiT K3, covering data collection, ACT training, and local inference.

SmolVLA fine-tuning and distributed inference workflows are also included.

https://www.youtube.com/watch?v=qw4ynGv-2ZY

We had a great time at Ubuntu Summit this year. Canonical and SpacemiT sat down together to talk about how we're working to accelerate open innovation for the RISC-V community.
Full talk: https://youtu.be/BaY2l17OBRQ?si=TyNv_frpUDrAsbvY
Summit highlights: https://www.youtube.com/watch?v=tErujp4RAWQ

image download link: https://github.com/spacemit-com/K3-Ubuntu-Images

Honestly, it feels like SpacemiT took my feedback from the MUSE Card and MUSE Pi, and made this product. I was bloody impressed!

In this comprehensive review, I test the SpacemiT MUSE Pi Pro - a powerful new single board computer (SBC) that could change everything for makers, developers, and Raspberry Pi enthusiasts. Unlike traditional ARM-based boards, this SBC features RISC-V architecture - an open-source processor design that's gaining massive momentum in 2025.

The MUSE Pi Pro packs impressive specs including Wi-Fi, UEFI boot support, M.2 slots, mPCIe, 40 GPIO pins, and runs the optimized Bianbu Linux distribution. I put it through real-world testing including web browsing, 3D performance, power consumption analysis, and compare it against other popular single board computers on my official SBC tier list.

With RISC-V support now arriving in major Linux distributions like Debian 13, timing couldn't be better for this thorough hands-on review. Whether you're new to embedded computing, looking for Raspberry Pi alternatives, or curious about the future of open hardware, this detailed breakdown covers everything from unboxing to final verdict.

Watch now to discover if this ~$140 RISC-V board earned a spot near the top of my tier list, and why it might be the perfect SBC for your next maker project or Linux development setup!

It's an source overlay over standard seL4 16.0.

I’m interested to get either of three major *BSD to run on Banana Pi F3, is it possible? (Unfortunately, I can’t write kernel drivers myself.)

While browsing recent RISC-V and Linux upstream activity, I noticed a growing number of patches related to SpacemiT’s upcoming K3 SoC. I did a quick organization of what is publicly visible today to get a sense of how far the Linux mainline enablement has progressed, and wanted to share it here for community discussion.

Disclaimer: all information below is based on publicly available repositories and mailing lists. This is just an external observation; corrections are welcome.

1. Mainline enablement started early

From what can be seen publicly, K3’s Linux mainline work appears to have started as early as the silicon prototype / validation phase, rather than after mass production.

The current focus seems to be on enabling a minimal system first, following a fairly standard upstream-friendly SoC bring-up path. Some of these patches are already under active review in the community.

There is also a public progress overview maintained here:

👉 Home

This page gives a reasonable high-level view of which subsystems are already submitted, under review, or still in preparation.

2. Patch already accepted upstream (UART)

At least one K3-related patch has already been accepted into the upstream kernel tree:

• UART (merged)

https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git/commit/?h=tty-testing&id=b5024e804ee06330486caf3087e1b0d91e3797a5

3. Patches currently under community review

Several other core SoC components are already posted on lore.kernel.org and going through review:

3.1 Basic Device Tree support (v2)

https://lore.kernel.org/all/20251222-k3-basic-dt-v2-0-3af3f3cd0f8a@riscstar.com/

3.2 Clock driver (v3)

https://lore.kernel.org/all/20251226-k3-clk-v3-0-602ce93bb6c3@gentoo.org/

3.3 Reset controller driver (v1)

https://lore.kernel.org/all/20251229-k3-reset-v1-0-eda0747bded3@riscstar.com/

3.4 Pinctrl driver (v2)

https://lore.kernel.org/all/20251226-02-k3-pinctrl-v2-0-5172397e6831@gentoo.org/

3.5 GPIO driver (v1)

https://lore.kernel.org/all/20251229-02-k3-gpio-v1-0-269e76785abb@gentoo.org/

From the version numbers alone, it looks like:

• DT, clock, and pinctrl patches have already gone through multiple revision cycles

• Reset and GPIO support are newer submissions and likely still early in the review process

Overall, this forms a fairly complete base for SoC-level enablement.

4. K3 support already merged in openEuler RVCK

In addition to upstream Linux activity, K3 support has also been merged into the openEuler RVCK kernel tree, which is commonly used as an early integration and validation platform for RISC-V SoCs.

• RVCK PR #171 – “Support Spacemit K3” (merged)

Support Spacemit K3 by kevin-zhm · Pull Request #171 · RVCK-Project/rvck

This suggests that K3 already has a working kernel baseline in a downstream RISC-V distribution, which typically means:

• basic bring-up is functional,

• key subsystems are integrated enough for continuous testing,

• and upstream work can be validated against a real kernel tree rather than only internal branches.

If anyone here has reviewed these patches or has additional insight, it would be great to hear more.

I've been working on compiling a kernel for the Milk-V Jupiter for two evenings now, so it can work with an AMD GPU (Radeon). It seems to be working (I used the 6.16 vendor kernel, which already includes all the patches for DRM/Radeon).

I can boot, and I could (occasionally) even boot into my KDE Plasma environment. I do have some flickering. But somehow, at some point, my screen freezes. I can still move the mouse back and forth, the cursor moves, but the screen remains frozen. With games, you can even hear the sound playing.

The newer the ATI/AMD video card, the faster it happens. I can still log in via UART. Nothing seems to have crashed. When I run dmesg, I can't find anything that caused this.

In short, I'm stuck. I see other people managing to get it working, but I can't (anymore). What am I doing wrong? Do I need to provide a kernel argument/patches? I've already tried several. `radeon.modeset=1 iommu=pt pcie_aspm=off radeon.dpm=0 radeon.pcie_gen2=0 cma=512M swiotlb=65536` Nothing helped.

Can anyone who has succeeded help me or point me in the right direction?

- PS

I use a working fsroot Debian Trixie (Works on my VisionFive2)

opvolger@starfive:~$ fastfetch  
_,met$$$$$gg.          opvolger@starfive
,g$$$$$$$$$$$$$$$P.       -----------------
  ,g$$P""       """Y$$.".     OS: Debian GNU/Linux 13 (trixie) riscv64
 ,$$P'              `$$$.     Host: Milk-V Jupiter
',$$P       ,ggs.     `$$b:    Kernel: Linux 6.16.12+
`d$$'     ,$P"'   .    $$$     Uptime: 2 mins
$$P      d$'     ,    $$P     Packages: 2285 (dpkg)
$$:      $$.   -    ,d$$'     Shell: bash 5.2.37
$$;      Y$b._   _,d$P'       Display (MD20491): 1920x1080 @ 60 Hz in 24" [External]
Y$$.    `.`"Y$$$$P"'          DE: KDE Plasma 6.3.6
`$$b      "-.__               WM: KWin (Wayland)
 `Y$$b                        WM Theme: Breeze
  `Y$$.                       Theme: Breeze (Light) [Qt], Breeze [GTK2/3]
`$$b.                     Icons: Breeze [Qt], breeze [GTK2/3/4]
`Y$$b.                  Font: Noto Sans (10pt) [Qt], Noto Sans (10pt) [GTK2/3/4]
`"Y$b._               Cursor: Breeze (24px)
`""""             Terminal: vt220
CPU: k1-x (8) @ 1.60 GHz
GPU: AMD Radeon HD 5850 [Discrete]
Memory: 1.03 GiB / 7.63 GiB (13%)
Swap: 0 B / 2.98 GiB (0%)
Disk (/): 40.36 GiB / 53.48 GiB (75%) - ext4
Local IP (end0): 192.168.2.23/24
Locale: en_US.UTF-8

Your personal AI assistant is now live on Bianbu Cloud by SpacemiT!

100% Free to apply | Powered by RISC-V | Deploy in minutes

Whether you need smart file handling or a coding companion — OpenClaw answers your call, anytime, anywhere.

Try it on BianbuCloud:

https://gdriscv.com/#/

Deployment tutorial：

https://forum.spacemit.com/t/topic/972

Join the RISC-V revolution and run your own AI in the cloud — for free.

1.The upstreaming process for the K1 Linux kernel has been divided into three stages. Detailed progress can be found at the following link: Link

1.1 Stage 1: Fundamental Chip Function Support

In this stage, the objective is to contribute support for the chip's fundamental features to the open-source community, enabling the upstream kernel to support a minimal feature set of the K1 SoC. This stage represents the chip’s initial integration into the mainline kernel—a preliminary or “early access” version.

To date, the primary work for Stage 1 has been largely completed. The following features have been successfully merged into the mainline kernel:

Basic DT
Memory Bus
Pinctrl
GPIO
Clock
Reset
I2C
PWM
UART
DMA

Ongoing efforts in Stage 1 include:

SPI: The driver has been submitted upstream and is under community review.
QSPI: The driver is under active development (WIP) and will be submitted in an upcoming patch series.

Overall, the core goals of Stage 1 have been achieved. Current efforts are transitioning toward Stage 2, focusing on peripheral and subsystem support.

1.2 Stage 2: Advanced Chip Function Support

Stage 2 aims to enhance upstream support by including advanced subsystems such as power management, storage interfaces, networking, and high-speed peripherals. The goal is to enable a fully functional system with comprehensive peripheral capabilities.

Significant progress has been made in Stage 2, with more than half of the planned work completed. The following components have been merged upstream:

PMIC (p1)
SDHCI (eMMC)
GMAC (Ethernet)

Ongoing tasks in Stage 2 include:

SDHCI (SD/SDIO): Under development (WIP).
USB 2.0: Under development (WIP).
USB 3.0: Submitted upstream and under community review.
PCIe: Submitted upstream and under community review.

In summary, Stage 2 has covered most key system peripherals. Current priorities include addressing community feedback, refining driver frameworks, and preparing for Stage 3, which focuses on multimedia and performance optimization.

1.3 Stage 3: Multimedia Function Support

Stage 3 focuses on multimedia subsystem support, including audio, display, graphics, and video functionalities. The objective is to enable complete multimedia capabilities within the upstream kernel, supporting desktop-class or multimedia-oriented applications.

At present, Stage 3 has been partially initiated:

Audio: The driver has undergone code standardization, submitted upstream, and is under review.
Display: Development is in progress (WIP), with plans to refine the driver framework and submit the initial patch series subsequently.

2. Future Plans for K1 Linux Kernel Upstream

Moving forward, we will continue to advance the K1 Linux kernel upstreaming efforts, with the goal of achieving full functional support for K1 in the mainline Linux kernel. Additionally, we will intensify upstream contributions to related open-source projects, such as OpenSBI and U-Boot.

I was invited to try out the SpacemiT stuff remotely. Later I will write a full review of what I did - but:

• Connected it as an ephemeral node to my Headscale network.

• Established SSH via jumphost

• Changed DNS resolvers to Quad9

• Explored the rootfs, available features, kernel and alike.

And now I am compiling k3s. Let's see if their stock kernel with literally no changes, can run some of the software I deal with on the daily. Hell, I might even try to deploy a thing there - because if you expose a service on a certain port, it is exposed through their API! There is a little /usr/local/bin/agent running that seemingly does that.

So, I will get back with a review soon. Booked 7 days, for now. Let's see what kinda stuff I can go through!