让 Linux 在一块 RISC-V 板卡上启动并不等于完成适配。真正可用的系统还要处理指令集基线、内核驱动、图形桌面、软件仓库和 AI 推理工具链之间的衔接。deepin 25 RVA23 版本面向进迭时空 SpacemiT K3 的适配，值得关注的正是这种从“点亮硬件”走向“承载实际工作负载”的过程。
从已有信息看，deepin-ports SIG 持续推进 RISC-V 支持，覆盖单板计算机、开发板、桌面环境、内核和图形驱动。K3 适配可以放在这条主线中理解：它不只是增加一个启动镜像，还要让发行版的软件生态与新一代 RISC-V 硬件能力对齐。
RVA23 改变的不只是编译参数
RVA23 是面向 64 位 RISC-V 应用处理器的一组架构能力约定。对发行版而言，采用更明确的指令集基线，可以减少“同为 RISC-V，但二进制能力差异很大”的问题，也有利于编译器、基础库和上层应用围绕统一目标优化。
不过，架构基线提高后也会带来边界：
- 软件包必须使用匹配的编译器和 ABI 构建；
- 较老的 RISC-V 处理器未必能够执行面向新基线生成的二进制；
- 虚拟机或模拟器如果没有暴露对应扩展，也可能触发非法指令；
- 高性能计算库不能只判断
riscv64，还应识别具体扩展与运行环境。
因此，验证一个 RVA23 系统时，不能只看 uname -m。内核报告的 ISA、用户态 ABI、动态链接器以及实际程序执行结果都需要检查。
一次适配要穿过四层栈
1. 启动链与硬件描述
固件、引导程序、内核和设备树必须对内存布局、中断控制器、串口、存储与 PCIe 等硬件形成一致认识。任何一层描述不匹配，都可能表现为无法启动、设备丢失或负载升高后不稳定。
2. 内核和外设驱动
开发板能够进入 Shell，只说明串口、CPU、内存和根文件系统基本可用。桌面系统还需要显示、GPU、网络、音频、USB、电源管理等驱动协同工作。对于计划长期运行模型的设备，散热、调频和内存压力同样是适配质量的一部分。
3. RVA23 用户空间
发行版的软件仓库需要提供一致的 RISC-V 二进制，包括编译器运行库、glibc、Python、图形组件以及模型推理依赖。若某个底层库退回通用实现，程序通常仍能运行，但性能可能与硬件能力不匹配。
4. AI 推理工具链
“小板子运行大模型”最终取决于模型大小、量化格式、内存带宽、线程调度和推理后端。操作系统适配为这些能力提供基础，但并不自动意味着所有模型或加速后端都已可用。尤其是厂商 NPU、GPU 或专用矩阵计算单元，需要对应的驱动、运行时和框架集成；不能仅凭系统能够启动便假设硬件加速已经生效。
上板后先做一轮可复现检查
下面是一份可以直接复制的基础检查脚本。它不依赖 K3 私有接口，适合在 deepin 25 RVA23 系统启动后收集架构、内核、内存、温度和图形设备信息。不同镜像暴露的节点可能不同，因此脚本对可选项做了容错。
cat > check-riscv-board.sh <<'EOF'
#!/usr/bin/env bash
set -u
echo '== System =='
uname -a
printf 'Architecture: '; uname -m
printf 'Word size: '; getconf LONG_BIT
[ -f /etc/os-release ] && cat /etc/os-release
echo
echo '== CPU and ISA =='
command -v lscpu >/dev/null 2>&1 && lscpu || true
grep -Ei '^(processor|hart|isa|uarch|mmu)' /proc/cpuinfo || true
echo
echo '== Memory =='
free -h
echo
echo '== Kernel command line =='
cat /proc/cmdline
echo
echo '== Display and accelerator devices =='
find /dev/dri -maxdepth 1 -type c -o -type l 2>/dev/null || true
find /dev -maxdepth 2 \( -iname '*npu*' -o -iname '*accel*' \) 2>/dev/null || true
echo
echo '== Thermal zones =='
for zone in /sys/class/thermal/thermal_zone*; do
[ -r "$zone/temp" ] || continue
type=$(cat "$zone/type" 2>/dev/null || echo unknown)
temp=$(cat "$zone/temp")
awk -v type="$type" -v temp="$temp" 'BEGIN {printf "%s: %.1f C\n", type, temp/1000}'
done
echo
echo '== Recent kernel warnings =='
dmesg --level=warn,err 2>/dev/null | tail -n 80 || true
EOF
chmod +x check-riscv-board.sh
./check-riscv-board.sh | tee board-report.txt
重点关注以下结果：
uname -m是否为riscv64；/proc/cpuinfo是否报告了预期 ISA 扩展；dmesg中是否存在固件加载失败、IOMMU、GPU、存储或网络错误；/dev/dri或加速设备节点是否出现；- 持续负载下温度是否快速升高，以及是否发生明显降频。
需要注意，/proc/cpuinfo 的输出格式取决于内核版本。没有显示某个字段不一定表示硬件缺失，必要时还应结合内核配置、设备树和厂商文档判断。
可以这样验证一个量化模型
如果目标是验证 CPU 侧推理，可以采用支持 RISC-V 的开源推理项目自行构建。下面以 llama.cpp 的通用 CMake 流程为例；这是一种可实践的验证方案，并不表示系统镜像预装了该项目，也不代表 K3 的专用加速后端已经接入。
运行前需要安装 Git、CMake、C/C++ 编译器，并准备一个你有权使用的 GGUF 量化模型。模型路径和提示词需要自行替换。
sudo apt update
sudo apt install -y git cmake build-essential
git clone --depth 1 https://github.com/ggml-org/llama.cpp.git
cd llama.cpp
cmake -S . -B build -DCMAKE_BUILD_TYPE=Release
cmake --build build -j"$(nproc)"
./build/bin/llama-cli \
-m /path/to/model.gguf \
-p '用三句话解释 RISC-V 指令集架构。' \
-n 128 \
-t "$(nproc)"
建议先从小参数量、低比特量化模型开始，并同时观察资源占用：
/usr/bin/time -v ./build/bin/llama-cli \
-m /path/to/model.gguf \
-p 'Hello, RISC-V' \
-n 64 \
-t "$(nproc)"
记录峰值常驻内存、加载时间、首个 token 延迟和持续生成速度，比只记录“能不能运行”更有意义。若要比较不同构建选项，应固定模型、提示词、线程数和散热条件，避免把缓存或温度差异误认为编译优化。
部署前的判断清单
对开发者来说，deepin 25 RVA23 与 K3 的组合提供了一个观察新 RISC-V 平台成熟度的窗口。评估时可以按以下顺序推进：
- 验证启动、关机、重启和存储稳定性；
- 检查网络、USB、显示、音频及电源管理；
- 确认目标软件包能够从仓库安装，或可以在板端稳定编译；
- 用固定模型建立 CPU 推理基线；
- 如果使用专用加速器，再单独核对驱动、运行时、算子覆盖和模型格式；
- 进行长时间压力测试，记录温度、频率、内存占用和内核日志。
RISC-V 桌面与边缘 AI 的价值，不只在于把系统移植到另一种架构，而在于形成可以持续升级、调试和分发的软件栈。对 K3 这类新平台而言，“能启动”是里程碑，“驱动完整、软件可装、模型可测、问题可复现”才是走向实际开发与部署的关键。