diff --git a/i18n/zh-Hans/docusaurus-plugin-content-blog/development/2026-05/openRuyi-ai-progress.mdx b/i18n/zh-Hans/docusaurus-plugin-content-blog/development/2026-05/openRuyi-ai-progress.mdx
new file mode 100644
index 0000000..8400934
--- /dev/null
+++ b/i18n/zh-Hans/docusaurus-plugin-content-blog/development/2026-05/openRuyi-ai-progress.mdx
@@ -0,0 +1,95 @@
+---
+title: openRuyi AI 新进展：让 RISC-V 异构 AI 开箱即用
+tags: [development]
+date: 2026-05-08
+slug: 2026-05/openruyi-ai-progress
+---
+> openRuyi 是一个基于 RISC-V 架构的原生发行版，专注于性能、安全、AI 以及云原生工作负载的优化。openRuyi 滚动版本对齐最新上游基线，并致力于为 RISC-V 构建前沿标准和软件应用的最佳实践。
+<!-- truncate -->
+在 AI 基础设施快速迭代的今天，RISC-V 平台的 AI 生态长期面临软件栈碎片化、配置门槛高、上游社区支持薄弱等挑战。围绕这些问题，中国科学院软件研究所 openRuyi 团队持续推进相关工作，逐步完善从底层 GPU 计算栈到上层应用工具的适配与集成。此次更新，openRuyi 带来了三项 AI 相关进展：ROCm 7.1.1 的性能提升、Ollama 的开箱即用本地推理，以及 PicoClaw AI 助手的集成。
+
+## 一、ROCm：大模型推理性能显著提升，支持更多显卡
+
+ROCm (Radeon Open Compute platform) 是 AMD 旗下全栈开源的 GPU 通用计算平台，涵盖驱动、运行时、算子库等完整组件，是当前开源生态中较为成熟的非 NVIDIA GPU 计算方案之一。openRuyi 已在 RISC-V 平台上完成 ROCm 的全栈移植适配，并在本次更新中将集成版本升级至较新的 ROCm 7.1.1。
+
+从测试结果来看，在 RX 7900 XTX 平台、llama.cpp b6029 环境下，llama 8B Q4_K - Medium 模型在不同测试项性能均有提升：
+
+| 测试项 | ROCm 6.2.4              | ROCm 7.1.1               |
+| ------ | ----------------------- | ------------------------ |
+| pp512  | 1116.23 ± 2.69 tokens/s | 2815.99 ± 16.68 tokens/s |
+| tg128  | 52.18 ± 0.06 tokens/s   | 77.56 ± 0.04 tokens/s    |
+
+这表明，openRuyi 在 RISC-V 平台上的 ROCm 适配已具备较好的实际可用性，并在推理性能上取得了进一步提升。与此同时，openRuyi 在本次更新中还新增了对主流 RDNA4 系列显卡 (RX90xx) 的支持，进一步拓宽了 RISC-V 平台对相关异构 AI 硬件的支持范围。
+
+### ROCm 上游化：让 RISC-V 成为 AI 开源生态的一等公民
+
+除了性能提升之外，openRuyi 团队也在积极推动 ROCm 的 RISC-V 上游化。目前，尚未上游化的相关补丁可在 openRuyi 的 SPECS 仓库<sup>[1]</sup> 中查看。接下来，团队将继续推进这些补丁的上游化工作，重点维护基础工具链与 ROCm 运行时相关的补丁，进一步完善 RISC-V 对 ROCm 生态的支持。
+
+## 二、Ollama：一条命令，本地大模型即刻可用
+
+Ollama 是当前较为流行的本地大模型管理与运行工具，支持 Llama、Qwen、Mistral、DeepSeek 等主流开源模型的一键下载与本地推理，无需复杂配置，是个人开发者和研究人员部署本地 LLM 的常用工具。
+
+此前，较新版本的 Ollama 尚不支持 riscv64 架构。针对这一问题，openRuyi 团队修复了 Ollama 在 riscv64 平台上的编译问题，并在此基础上为其启用了对 ROCm 7.1.1 的 GPU 加速支持，使 RISC-V 用户能够利用 AMD GPU 的算力进行本地模型推理<sup>[2]</sup>。
+
+在 openRuyi 上使用 Ollama，仅需执行以下命令：
+
+```
+sudo dnf install ollama
+# 或者使用 qwen3 等其他本地模型
+ollama run deepseek-r1
+```
+
+无需手动编译，也无需额外配置环境变量，安装完成后即可直接使用。这意味着，RISC-V 平台上本地大模型的部署门槛进一步降低，在本地开展推理也更加方便。
+
+![Ollama 本地运行 deepseek-r1:8b 模型时的性能表现](/article-images/2026-05/deepseek-r1.webp)
+<p align="center">Ollama 本地运行 deepseek-r1:8b 模型时的性能表现</p>
+
+## 三、PicoClaw：完全本地的 AI 智能体
+
+除了模型运行能力，openRuyi 也在进一步完善面向实际开发场景的 AI 应用工具支持。
+
+PicoClaw 是轻量的开源自主 AI 智能体软件，目前已经集成到 openRuyi 中，安装同样只需一条命令：
+
+```
+sudo dnf install picoclaw
+```
+
+安装后，用户可按照 PicoClaw 官方入门文档完成初始配置并开始使用<sup>[3]</sup>。
+
+基于 openRuyi 预集成的 Ollama + ROCm 7.1.1 后端，用户可以将 PicoClaw 的推理后端切换到本地 Ollama 服务，从而实现以下能力：
+
+- **推理完全本地化**：模型运行在本机 AMD GPU 上，数据无需经过任何外部服务器
+- **无需网络连接**：即使在离线环境下，也能够获得 AI 辅助能力
+- **GPU 加速**：借助 ROCm 7.1.1，在 RISC-V + AMD GPU 平台上获得更高的推理速度
+
+这表明，openRuyi 在 RISC-V 平台上的 AI 能力建设，已经从单纯的模型推理进一步延伸到 Agent 场景。
+
+![PicoClaw 通过本地 Ollama 后端运行，实现高性能的本地化 AI 辅助](/article-images/2026-05/picoclaw.png)
+<p align="center">PicoClaw 通过本地 Ollama 后端运行，实现高性能的本地化 AI 辅助</p>
+
+## 四、openRuyi AI 栈 Roadmap：我们的下一步
+
+当前版本中对 Ollama 和 PicoClaw 的集成，只是 openRuyi AI 能力建设的起点。根据项目规划，openRuyi AI 栈将沿以下方向持续演进：
+
+- **近期方向**：扩展支持更多 GPU 型号。在目前已验证 RX 7900 XTX 的基础上，后续将进一步测试并支持更多 AMD Radeon 显卡型号；继续推进 ROCm 上游化，向 ROCm、llama.cpp 等项目贡献 RISC-V 支持补丁，推动相关支持逐步合入主线。
+- **中期方向**：打通 vLLM 推理全链路，在 RISC-V + AMD GPU 平台上实现基于 PyTorch 和 vLLM 的大模型分布式推理服务，并探索多 GPU 分布式大模型训练能力；完善端侧推理支持，集成经 RISC-V 向量扩展 (RVV) 优化的 llama.cpp，覆盖算能 SG2044、SpacemiT K3、玄铁 C950 等主流 RISC-V 处理器，使无 GPU 的纯 CPU 环境也能够运行轻量模型；扩大模型验证覆盖范围，除语言模型外，逐步推进视觉模型 (YOLO)、多模态模型等在 RISC-V 平台上的验证；围绕主流 Agent 框架（如 LangChain 等）在 RISC-V 平台上的适配与运行，结合本地模型推理能力，探索端侧 Agent 应用的部署方案。
+- **长期方向**：探索国产加速硬件在 RISC-V 主机上的适配，推进“RISC-V + 国产加速器”全链路国产化方案，为后续 AI 生态适配与应用拓展奠定基础；基于 openRuyi 的软硬件协同能力，进一步探索面向具体行业场景的智能体应用落地，打造 RISC-V 平台上完整的 Agent 运行与开发体验。
+
+## 结语
+
+此次 openRuyi 在 ROCm、Ollama 和 PicoClaw 方面的相关工作，进一步完善了面向 RISC-V 平台的本地 AI 软件栈，也降低了本地大模型的部署和使用门槛。后续，openRuyi 还将继续围绕性能优化、工具完善、生态适配和上游协同等工作，持续完善 RISC-V 平台上的 AI 支持。
+
+## 相关链接
+
+[1] openRuyi SPECS 仓库：
+https://github.com/openRuyi-Project/openRuyi/tree/main/SPECS
+
+[2] openRuyi 中的 Ollama 适配与打包文件：
+https://github.com/openRuyi-Project/openRuyi/tree/main/SPECS/ollama
+
+[3] PicoClaw 官方入门文档：
+https://docs.picoclaw.io/zh-Hans/docs/getting-started/
+
+## 联系我们
+
+对 openRuyi 工作感兴趣的伙伴们可以关注 GitHub 开源项目，访问 openRuyi 文档中心获取更多信息，也欢迎加入 Discord 社区参与交流。团队长期招收全职/兼职/实习生，欢迎投递简历至邮箱 [wangjingwei@iscas.ac.cn](mailto:wangjingwei@iscas.ac.cn)（王经纬）。
\ No newline at end of file
diff --git a/i18n/zh-Hans/docusaurus-plugin-content-blog/development/2026-05/openruyi-secure-boot-guide.mdx b/i18n/zh-Hans/docusaurus-plugin-content-blog/development/2026-05/openruyi-secure-boot-guide.mdx
new file mode 100644
index 0000000..96354a0
--- /dev/null
+++ b/i18n/zh-Hans/docusaurus-plugin-content-blog/development/2026-05/openruyi-secure-boot-guide.mdx
@@ -0,0 +1,319 @@
+---
+title: 在 openRuyi 上开启 RISC-V 安全启动：从固件到内核的实践指南
+tags: [development]
+date: 2026-05-21
+slug: 2026-05/openruyi-secure-boot-guide
+---
+Secure Boot 是系统启动阶段建立可信校验链的重要机制。对于 RISC-V 平台上的系统适配、固件调试和启动流程验证来说，完成一套可复现的配置流程，有助于开发者理解启动组件之间的信任关系。
+
+本文基于 openRuyi 文档中心《在 openRuyi 上开启安全启动》指南<sup>[1]</sup>，以 openRuyi UEFI 固件和 openRuyi Server edition QCOW2 镜像为例，梳理在 QEMU 环境中配置 Secure Boot 的主要步骤。整个实践从固件和系统镜像准备开始。
+<!-- truncate -->
+## 一、准备 UEFI 固件和系统镜像
+
+开启 Secure Boot 前，需要先准备 openRuyi UEFI 固件和 openRuyi Server edition QCOW2 系统镜像。其中，UEFI 固件可从 openRuyi 软件源<sup>[2]</sup> 中的 `ovmf` 包获取，解压后得到 `.fd` 文件。
+
+```bash
+wget https://boat.openruyi.cn/stable/rva23/riscv64/ovmf-202602-11.3.or.riscv64.rpm
+rpm2cpio ovmf-202602-11.3.or.riscv64.rpm | cpio -idmv
+cp ./usr/share/ovmf/*.fd ./
+```
+
+本文使用的 openRuyi Server edition QCOW2 系统镜像，可从 openRuyi 发布件页面<sup>[3]</sup>获取。
+
+> 注意：如果实际使用时 `ovmf` 软件包或系统镜像版本已经更新，请以 openRuyi 软件源和发布件页面中的最新文件为准，并同步修改后续脚本中的文件名。
+
+## 二、创建 QEMU 快速启动脚本
+
+固件和系统镜像准备完成后，创建 QEMU 启动脚本 `start_or.sh`，并赋予可执行权限：
+
+```bash
+touch start_or.sh
+chmod +x start_or.sh
+```
+
+将以下脚本内容写入 `start_or.sh`：
+
+```bash
+#!/usr/bin/env bash
+
+# Start a riscv64 QEMU virtual machine with specific parameters.
+
+RESTORE=$(echo -en '\001\033[0m\002')
+YELLOW=$(echo -en '\001\033[00;33m\002')
+
+## Configuration
+vcpu=2
+memory=8
+drive="openRuyi-2026.04-Server-cloud.qcow2"
+fw1="virt_code.fd"
+fw2="virt_vars.fd"
+ssh_port=12055
+
+cmd="qemu-system-riscv64 \
+  -nographic -machine virt,pflash0=pflash0,pflash1=pflash1,acpi=off \
+  -cpu rva23s64,sv39=on \
+  -smp "$vcpu" -m "$memory"G \
+  -blockdev node-name=pflash0,driver=file,read-only=on,filename="$fw1" \
+  -blockdev node-name=pflash1,driver=file,filename="$fw2" \
+  -drive file="$drive",format=qcow2,id=hd0,if=none \
+  -object rng-random,filename=/dev/urandom,id=rng0 \
+  -device virtio-vga \
+  -device virtio-rng-device,rng=rng0 \
+  -device virtio-blk-device,drive=hd0 \
+  -device virtio-net-device,netdev=usernet \
+  -netdev user,id=usernet,hostfwd=tcp::"$ssh_port"-:22 \
+  -device qemu-xhci -usb -device usb-kbd -device usb-tablet"
+
+echo ${YELLOW}:: Starting VM...${RESTORE}
+echo ${YELLOW}:: Using following configuration${RESTORE}
+echo ""
+echo ${YELLOW}vCPU Cores: "$vcpu"${RESTORE}
+echo ${YELLOW}Memory: "$memory"G${RESTORE}
+echo ${YELLOW}Disk: "$drive"${RESTORE}
+echo ${YELLOW}SSH Port: "$ssh_port"${RESTORE}
+echo ""
+echo ${YELLOW}:: NOTE: Make sure ONLY ONE .qcow2 file is${RESTORE}
+echo ${YELLOW}in the current directory${RESTORE}
+echo ""
+echo ${YELLOW}:: Tip: Try setting DNS manually if QEMU user network doesn\'t work well. ${RESTORE}
+echo ${YELLOW}:: HOWTO -\> https://serverfault.com/a/810639 ${RESTORE}
+echo ""
+echo ${YELLOW}:: Tip: If \'ping\' reports permission error, try reinstalling \'iputils\'. ${RESTORE}
+echo ${YELLOW}:: HOWTO -\> \'sudo dnf reinstall iputils\' ${RESTORE}
+echo ""
+
+sleep 2
+
+eval $cmd
+```
+
+该脚本通过 `qemu-system-riscv64` 启动 openRuyi 虚拟机，并指定 RISC-V virt 机器、UEFI pflash、QCOW2 磁盘、virtio 设备和 SSH 端口转发等参数。其中，`drive` 对应 openRuyi Server QCOW2 镜像，`fw1` 和 `fw2` 分别对应 `virt_code.fd` 与 `virt_vars.fd`，`ssh_port` 则用于配置 SSH 端口转发。
+
+执行启动脚本，进入 openRuyi 环境：
+
+```bash
+./start_or.sh
+```
+
+系统启动后，可使用以下用户登录：
+
+```text
+root / openruyi
+openruyi / openruyi
+```
+
+## 三、安装 Secure Boot 所需工具
+
+进入系统后，安装 Secure Boot 配置所需工具：
+
+```bash
+dnf install -y efibootmgr efitools grub-unsigned mokutil sbsigntools shim wget
+```
+
+安装完成后，将 `grub.cfg` 和 `grubriscv64.efi` 复制到 `/boot/efi/EFI/openruyi` 目录：
+
+```bash
+cp /boot/efi/EFI/BOOT/grub.cfg /boot/efi/EFI/openruyi/
+cp /lib/grub/riscv64-efi/monolithic/grubriscv64.efi /boot/efi/EFI/openruyi/
+```
+
+## 四、下载 Secure Boot 辅助脚本
+
+进入 Secure Boot 配置阶段后，本节中的命令均需以 root 用户执行；如果使用 openruyi 用户登录，请在命令前添加 `sudo`。
+
+```bash
+wget https://github.com/wxjstz/secureboot-setup/archive/refs/heads/main.tar.gz
+tar xvf main.tar.gz
+cd secureboot-setup-main
+```
+
+该仓库主要包含三个脚本：
+
+```text
+1.gen_keys          # 创建 PK、KEK、db 和 MOK 密钥
+2.import_mok        # 通过 mokutil 发起 MOK enrollment
+3.import_uefi_cert  # 将 PK、KEK 和 db 导入 UEFI 变量存储区
+```
+
+> 注意：完成 Secure Boot 密钥 enrollment 后，请继续使用同一个 `virt_vars.fd` 文件。QEMU 会将 UEFI 变量保存在该文件中；如果替换为新的 `virt_vars.fd`，系统会丢失已导入的密钥。
+
+## 五、确认固件处于 Setup Mode
+
+创建或导入密钥前，确认固件处于 Setup Mode：
+
+```bash
+mokutil --sb-state
+```
+
+预期输出如下：
+
+```text
+SecureBoot disabled
+Platform is in Setup Mode
+```
+
+如果未进入 Setup Mode，请使用干净的 `virt_vars.fd` 重新启动 QEMU，或者进入 BIOS / UEFI 清除 Secure Boot 密钥。
+
+## 六、生成 Secure Boot 签名密钥
+
+确认处于 Setup Mode 后，生成 Secure Boot 所需密钥和证书：
+
+```bash
+./1.gen_keys
+```
+
+脚本执行时会提示输入证书所有者名称。该名称会写入生成证书的 Common Name 字段，如果直接按 Enter，则会使用默认值。
+
+执行完成后，会生成如下目录结构：
+
+```text
+secureboot/
+├── cert/       # Private keys, certificates, and MOK.der
+├── esl/        # EFI Signature Lists
+└── keystore/   # Signed .auth files for UEFI enrollment
+```
+
+### 备份提醒
+
+需要备份整个 `secureboot/` 目录，尤其是 `secureboot/cert` 下的私钥文件。
+
+## 七、签名启动链中的关键文件
+
+Secure Boot 不只是打开启动选项，更关键的是为启动链中的关键文件提供有效签名。
+
+```text
+UEFI 固件 → db 信任 → shim → MOK 信任 → MokManager / GRUB / Linux kernel
+```
+
+本流程采用的签名策略为：
+
+- 使用 db 密钥签名 shim；
+- 使用 MOK 密钥签名 MokManager、GRUB 和 Linux kernel。
+
+签名前，备份原始文件：
+
+```bash
+mkdir -p orig
+
+cp /boot/linux orig/
+cp /boot/efi/EFI/openruyi/shimriscv64.efi orig/
+cp /boot/efi/EFI/openruyi/mmriscv64.efi orig/
+cp /boot/efi/EFI/openruyi/grubriscv64.efi orig/
+```
+
+使用 db 密钥签名 shim：
+
+```bash
+sbsign \
+    --key secureboot/cert/db.key \
+    --cert secureboot/cert/db.crt \
+    --output /boot/efi/EFI/openruyi/shimriscv64.efi \
+    orig/shimriscv64.efi
+```
+
+使用 MOK 密钥分别签名 MokManager、GRUB 和 Linux kernel：
+
+```bash
+sbsign \
+    --key secureboot/cert/MOK.key \
+    --cert secureboot/cert/MOK.crt \
+    --output /boot/efi/EFI/openruyi/mmriscv64.efi \
+    orig/mmriscv64.efi
+
+sbsign \
+    --key secureboot/cert/MOK.key \
+    --cert secureboot/cert/MOK.crt \
+    --output /boot/efi/EFI/openruyi/grubriscv64.efi \
+    orig/grubriscv64.efi
+
+sbsign \
+    --key secureboot/cert/MOK.key \
+    --cert secureboot/cert/MOK.crt \
+    --output /boot/linux \
+    orig/linux
+```
+
+## 八、导入 MOK 证书
+
+导入 UEFI 证书前，先导入 MOK 证书。shim 将通过 MOK 信任已签名的 MokManager、GRUB 和 kernel。
+
+执行以下命令，发起 MOK enrollment 请求：
+
+```bash
+./2.import_mok
+```
+
+执行过程中需要设置 enrollment password。重启后进入 MokManager 时，需要使用该密码完成确认。
+
+```bash
+reboot
+```
+
+系统重启后，MokManager 会进入蓝色的 Mok Management 界面。按以下步骤完成 enrollment：
+
+1. 选择 `Enroll MOK` → `Continue`；
+2. 输入刚刚设置的密码；
+3. 选择 `Yes` 确认 enrollment；
+4. 选择 `Reboot`。
+
+第二次重启完成后，使用以下命令确认 MOK 证书是否已经导入：
+
+```bash
+mokutil --list-enrolled
+```
+
+## 九、导入 UEFI 证书
+
+完成 MOK 导入后，再将 PK、KEK 和 db 导入 UEFI 变量存储区：
+
+```bash
+./3.import_uefi_cert
+```
+
+导入完成后，分别检查各个 UEFI key database：
+
+```bash
+mokutil --pk
+mokutil --kek
+mokutil --db
+```
+
+确认命令输出中已包含前面生成的证书后，再次重启系统：
+
+```bash
+reboot
+```
+
+## 十、验证 Secure Boot 是否开启成功
+
+系统重新启动后，执行以下命令：
+
+```bash
+mokutil --sb-state
+```
+
+如果输出结果为：
+
+```text
+SecureBoot enabled
+```
+
+表示 openRuyi 已成功开启 Secure Boot。
+
+## 小结
+
+通过这份指南，开发者可以在 openRuyi 的 QEMU 环境中完整体验 Secure Boot 的配置流程。从固件准备、QEMU 启动，到密钥生成、启动文件签名、MOK 与 UEFI 证书导入，整个过程展示了 Secure Boot 在 openRuyi 上的基本工作方式。
+
+对于关注 RISC-V 系统安全、UEFI 固件适配和启动链验证的开发者来说，这不仅是一次 Secure Boot 配置实践，也是一条理解 RISC-V 系统可信启动机制的入门路径。
+
+## 相关链接
+
+[1] openRuyi 安全启动指南：https://openruyi.cn/zh-Hans/docs/guide/enable-secure-boot/
+
+[2] openRuyi 软件源：https://boat.openruyi.cn/stable/rva23/
+
+[3] openRuyi 发布件：https://releases.openruyi.cn/
+
+## 联系我们
+
+对 openRuyi 工作感兴趣的伙伴们，可以关注 GitHub 开源项目，访问 openRuyi 文档中心获取更多信息，也欢迎加入 Discord 社区参与交流。团队长期招收全职、兼职和实习生，欢迎投递简历至邮箱 wangjingwei@iscas.ac.cn（王经纬）。
\ No newline at end of file
diff --git a/i18n/zh-Hans/docusaurus-plugin-content-blog/ecosystem/2026-05/dpdk-riscv-maintainer.mdx b/i18n/zh-Hans/docusaurus-plugin-content-blog/ecosystem/2026-05/dpdk-riscv-maintainer.mdx
new file mode 100644
index 0000000..450c3fc
--- /dev/null
+++ b/i18n/zh-Hans/docusaurus-plugin-content-blog/ecosystem/2026-05/dpdk-riscv-maintainer.mdx
@@ -0,0 +1,59 @@
+---
+title: 软件所孙越池成为 DPDK RISC-V 架构维护者，推动 openRuyi 高性能网络与存储栈生态建设
+tags: [ecosystem]
+date: 2026-05-15
+slug: 2026-05/dpdk-riscv-maintainer
+---
+近日，中国科学院软件研究所工程师孙越池成为 DPDK（Data Plane Development Kit）RISC-V 架构维护者，维护范围从此前的 RVV（RISC-V 向量扩展）子系统进一步扩展至整个 RISC-V 架构。
+<!-- truncate -->
+![DPDK MAINTAINERS 相关变更](/article-images/2026-05/DPDK-1.png)
+<p align="center">DPDK MAINTAINERS 相关变更</p>
+
+> DPDK 是全球广泛部署的用户态高速数据平面框架，覆盖电信网络、云数据中心、虚拟交换、负载均衡等关键场景，也是 SPDK、OVS-DPDK、VPP 等高性能网络与存储项目的核心依赖。RISC-V 架构维护职责由长期投入相关优化的开发者承担，意味着该架构的补丁评审、CI 维护与版本发布将进入更稳定的节奏，并进一步推动 RISC-V 在数据中心与网络基础设施场景中的规模化落地。
+
+## 长期投入 RISC-V，逐步深入维护体系
+
+自 2023 年下半年起，DPDK 社区中的 RISC-V 相关提交一度长期停留在评审阶段，整体合入节奏放缓。2025 年以来，孙越池围绕 V 扩展检测、运行时调度，以及 lpm/fib 等核心查表数据结构的 RVV 向量化推动了一批补丁，相关工作成为近三年来首批进入 DPDK 主线的 RISC-V 优化成果。
+
+同期，他以 RVV 子系统维护者身份进入 DPDK MAINTAINERS。随着持续投入和社区协作不断深入，他进一步承担起整个 RISC-V 架构的维护职责。
+
+## openRuyi 的 DPDK 推动计划
+
+DPDK 的 RISC-V 适配，是 openRuyi 系统化推进高性能软件栈的关键一环。除推动 DPDK 上游合入 RVV 优化外，如意存储（RuyiSDS）方向也在 openRuyi 操作系统中同步建设 DPDK 的发行版构建、运行验证与持续集成能力。
+
+这些能力将让每一个 RISC-V 相关上游变更都能在真实 RISC-V 服务器硬件上获得快速反馈，降低因硬件资源不足导致补丁搁置、维护停滞的风险。
+
+围绕 DPDK 的 RISC-V 优化，openRuyi 已开展并将持续推进以下工作：
+
+- **指令扩展检测框架**：在编译期与运行期统一识别 V 等扩展能力，为后续优化分发奠定基础。
+- **核心数据结构 RVV 优化**：针对 fib、lpm 等查表/路由热路径完成 RVV 向量化，性能取得明显提升。
+- **构建与测试基础设施**：完善 RISC-V 平台上 V 扩展相关的构建与单元测试，保障 DPDK 在 RISC-V 上的稳定性。
+- **持续拓展**：mem、node、acl 等模块的 RVV 优化探索正在进行中，后续将逐步推向上游。
+
+与此同时，DPDK 社区中已有越来越多国内外开发者（例如中兴、字节等）参与 RISC-V 适配，目前在评审与讨论中的相关工作覆盖 Z 系列扩展（Zbc、Zicbop 等）支持与 hwprobe 检测、hash 等核心库的 RVV 向量化、rte_memcpy 优化、I/O 设备内存与预取操作等多个方向。孙越池将与社区贡献者协同推进这些工作的评审与合入，让 RISC-V 在 DPDK 上的优化版图持续扩展。
+
+## 围绕 Ceph 的 RISC-V 存储栈：openRuyi 的下一站
+
+在 RISC-V 平台上，存储栈优化离不开一条自下而上的组件链：上层 Ceph 分布式存储依赖 SPDK 用户态块存储栈、ISA-L 数据加速库、OpenSSL、zstd 等基础组件；SPDK 又依赖 DPDK 提供高性能内存池、轮询与无锁队列等运行时设施。
+
+RuyiSDS 方向的工作主线，正是沿着这条依赖链系统推进：
+
+- **底层加速库**：联合上游社区，在 ISA-L、zstd、OpenSSL 等 Ceph 依赖的基础组件上推进 RVV 向量化与 riscv64 适配。例如，今年早些时候发布的 ISA-L v2.32 已正式支持 riscv64，覆盖纠删码、CRC、压缩校验等核心算子的 RVV 实现。
+- **运行时与块存储**：以 DPDK 维护工作为支点，向上推动 SPDK 在 RISC-V 上的适配与完善，并逐步打通 Ceph 在 RISC-V 平台上的 DPDK/SPDK 路径。
+- **集成验证**：相关工作完成后，将在 openRuyi 中先行运行完整的 Ceph CI，争取使 openRuyi 成为业界首个完整支持 Ceph 的 RISC-V 发行版。
+- **性能调优**：在功能完整的基础上，逐步接入并验证 Ceph 中依赖 DPDK/SPDK 的高性能与下一代 OSD 路径；部分能力在上游仍处于实验阶段，后续将持续跟进。
+
+![openRuyi RISC-V 软件栈](/article-images/2026-05/DPDK-2.png)
+<p align="center">openRuyi RISC-V 软件栈</p>
+
+随着 RVA23 标准正式落地、服务器级 RISC-V 平台逐步成熟，网络与存储栈的系统级优化正从“逐点适配”进入“端到端协同”的新阶段。openRuyi 将以 DPDK 维护工作为支点，协同 SPDK、ISA-L、Ceph、OVS 等上下游组件，构建贯通基础设施与分布式应用的 RISC-V 软件栈。
+
+## 共建生态
+
+未来，RuyiSDS 方向将持续投入 RISC-V 在高性能网络与分布式存储领域的上游协作，推动更多优化合入 DPDK、SPDK、Ceph 等核心项目，并依托 openRuyi 提供稳定的开发、构建与验证环境，助力 RISC-V 服务器生态中的关键基础软件早日具备产线可用能力。
+
+我们诚挚邀请更多开发者、芯片厂商与系统厂商加入，与 openRuyi 共同推进 RISC-V 网络与存储软件栈的演进。
+
+## 联系我们
+
+对 openRuyi 工作感兴趣的伙伴们，可以关注 GitHub 开源项目，访问 openRuyi 文档中心获取更多信息，也欢迎加入 Discord 社区参与交流。团队长期招收全职、兼职和实习生，欢迎投递简历至邮箱 [wangjingwei@iscas.ac.cn](mailto:wangjingwei@iscas.ac.cn)（王经纬）。
\ No newline at end of file
diff --git a/news/development/2026-05/openRuyi-ai-progress.mdx b/news/development/2026-05/openRuyi-ai-progress.mdx
new file mode 100644
index 0000000..b78132a
--- /dev/null
+++ b/news/development/2026-05/openRuyi-ai-progress.mdx
@@ -0,0 +1,96 @@
+---
+title: "openRuyi AI Progress: Ready-to-Use Heterogeneous AI on RISC-V"
+tags: [development]
+date: 2026-05-08
+slug: 2026-05/openruyi-ai-progress
+---
+
+> openRuyi is a native Linux distribution for the RISC-V architecture, with a focus on performance, security, AI, and cloud-native workloads. The rolling-release version of openRuyi tracks the latest upstream baseline and is committed to building best practices for cutting-edge standards and software applications on RISC-V.
+<!-- truncate -->
+As AI infrastructure continues to evolve rapidly, the AI ecosystem on RISC-V has long faced challenges such as fragmented software stacks, high configuration barriers, and limited support from upstream communities. To address these issues, the openRuyi team at the Institute of Software, Chinese Academy of Sciences has been continuously advancing related work, gradually improving adaptation and integration from the low-level GPU computing stack to upper-layer application tools. In this update, openRuyi brings three AI-related improvements: performance gains with ROCm 7.1.1, ready-to-use local inference with Ollama, and integration of the PicoClaw AI assistant.
+
+## 1. ROCm: Significantly Improved LLM Inference Performance and Support for More GPUs
+
+ROCm (Radeon Open Compute platform) is AMD’s fully open-source GPU computing platform. It covers a complete set of components including drivers, runtime, and operator libraries, and is one of the more mature non-NVIDIA GPU computing solutions in the open-source ecosystem. openRuyi has completed full-stack ROCm porting and adaptation on the RISC-V platform, and in this update, the integrated version has been upgraded to the newer ROCm 7.1.1.
+
+According to test results, on the RX 7900 XTX platform with llama.cpp b6029, the llama 8B Q4_K - Medium model shows performance improvements across multiple test items:
+
+| Test item | ROCm 6.2.4              | ROCm 7.1.1               |
+| --------- | ----------------------- | ------------------------ |
+| pp512     | 1116.23 ± 2.69 tokens/s | 2815.99 ± 16.68 tokens/s |
+| tg128     | 52.18 ± 0.06 tokens/s   | 77.56 ± 0.04 tokens/s    |
+
+These results indicate that openRuyi’s ROCm adaptation on RISC-V has reached a good level of practical usability and has achieved further improvement in inference performance. At the same time, this update also adds support for mainstream RDNA4 series GPUs (RX90xx), further expanding RISC-V platform support for heterogeneous AI hardware.
+
+### Upstreaming ROCm: Making RISC-V a First-Class Citizen in the Open-Source AI Ecosystem
+
+In addition to performance improvements, the openRuyi team is also actively promoting the upstreaming of RISC-V support for ROCm. The relevant patches that have not yet been upstreamed can currently be found in the openRuyi SPECS repository<sup>[1]</sup>. Going forward, the team will continue to push these patches upstream, with a focus on maintaining patches related to the base toolchain and ROCm runtime, further improving RISC-V support in the ROCm ecosystem.
+
+## 2. Ollama: Run Local LLMs with a Single Command
+
+Ollama is a popular tool for managing and running local large language models. It supports one-command download and local inference for mainstream open-source models such as Llama, Qwen, Mistral, and DeepSeek. With no complex configuration required, it is widely used by individual developers and researchers for deploying local LLMs.
+
+Previously, newer versions of Ollama did not support the riscv64 architecture. To address this issue, the openRuyi team fixed the compilation problems of Ollama on riscv64 and enabled GPU acceleration with ROCm 7.1.1, allowing RISC-V users to leverage AMD GPU computing power for local model inference<sup>[2]</sup>.
+
+On openRuyi, using Ollama only requires the following commands:
+
+```
+sudo dnf install ollama
+# Or use other local models, such as qwen3
+ollama run deepseek-r1
+```
+
+No manual compilation or additional environment variable configuration is required. After installation, it can be used directly. This further lowers the barrier to deploying local LLMs on RISC-V and makes local inference more convenient.
+
+![Performance of running the deepseek-r1:8b model locally with Ollama](/article-images/2026-05/deepseek-r1.webp)
+<p align="center">Performance of running the deepseek-r1:8b model locally with Ollama</p>
+
+## 3. PicoClaw: A Fully Local AI Agent
+
+Beyond model runtime capability, openRuyi is also improving support for AI application tools aimed at real-world development scenarios.
+
+PicoClaw is a lightweight open-source autonomous AI agent. It has now been integrated into openRuyi, and installation also requires only a single command:
+
+```
+sudo dnf install picoclaw
+```
+
+After installation, users can follow the official PicoClaw getting-started documentation to complete the initial configuration and begin using it<sup>[3]</sup>.
+
+Based on openRuyi’s pre-integrated Ollama + ROCm 7.1.1 backend, users can switch PicoClaw’s inference backend to the local Ollama service, enabling the following capabilities:
+
+- **Fully local inference**: models run on the local AMD GPU, and data does not need to pass through any external server.
+- **No network connection required**: AI assistance remains available even in offline environments.
+- **GPU acceleration**: ROCm 7.1.1 enables higher inference speed on RISC-V + AMD GPU platforms.
+
+This shows that openRuyi’s AI capability development on RISC-V has moved beyond basic model inference and is now extending into agent scenarios.
+
+![PicoClaw runs through a local Ollama backend, enabling high-performance localized AI assistance](/article-images/2026-05/picoclaw.png)
+<p align="center">PicoClaw runs through a local Ollama backend, enabling high-performance localized AI assistance</p>
+
+## 4. openRuyi AI Stack Roadmap: What Comes Next
+
+The current integration of Ollama and PicoClaw is only the starting point for openRuyi’s AI capability development. According to the project roadmap, the openRuyi AI stack will continue to evolve in the following roadmap:
+
+- **Near-term priorities**: expand support for more GPU models. Based on the currently verified RX 7900 XTX, more AMD Radeon GPU models will be tested and supported in the future; continue promoting ROCm upstreaming by contributing RISC-V support patches to projects such as ROCm and llama.cpp, and gradually push related support into the mainline.
+- **Mid-term priorities**: complete the full vLLM inference pipeline, enabling distributed LLM inference services based on PyTorch and vLLM on RISC-V + AMD GPU platforms, while exploring multi-GPU distributed LLM training capabilities; improve edge-side inference support by integrating llama.cpp optimized with RISC-V Vector Extension (RVV), covering mainstream RISC-V processors such as SOPHGO SG2044, SpacemiT K3, and Xuantie C950, so that lightweight models can also run in CPU-only environments without a GPU; expand model validation coverage beyond language models, gradually advancing validation for vision models (YOLO), multimodal models, and more on the RISC-V platform; explore deployment solutions for edge-side agent applications by adapting and running mainstream agent frameworks such as LangChain on RISC-V, combined with local model inference capabilities.
+- **Long-term priorities**: explore adaptation of domestic acceleration hardware on RISC-V hosts, promote a fully domestic “RISC-V + domestic accelerator” end-to-end solution, and lay the foundation for future AI ecosystem adaptation and application expansion; based on openRuyi’s software-hardware co-design capabilities, further explore agent applications for specific industry scenarios and build a complete agent runtime and development experience on RISC-V.
+
+## Conclusion
+
+The work on ROCm, Ollama, and PicoClaw further improves openRuyi’s local AI software stack for the RISC-V platform and lowers the barrier to deploying and using local LLMs. Going forward, openRuyi will continue to improve AI support on RISC-V through performance optimization, tool enhancement, ecosystem adaptation, and upstream collaboration.
+
+## Related Links
+
+[1] openRuyi SPECS repository:  
+https://github.com/openRuyi-Project/openRuyi/tree/main/SPECS
+
+[2] Ollama adaptation and packaging files in openRuyi:  
+https://github.com/openRuyi-Project/openRuyi/tree/main/SPECS/ollama
+
+[3] Official PicoClaw getting-started documentation:  
+https://docs.picoclaw.io/zh-Hans/docs/getting-started/
+
+## Contact Us
+
+If you are interested in openRuyi, you can follow our GitHub project, visit the openRuyi documentation center for more information, and join our Discord community for discussion and collaboration. The team is also continuously recruiting full-time employees, part-time contributors, and interns. Please send your resume to [wangjingwei@iscas.ac.cn](mailto:wangjingwei@iscas.ac.cn) (Jingwei Wang).
\ No newline at end of file
diff --git a/news/development/2026-05/openruyi-secure-boot-guide.mdx b/news/development/2026-05/openruyi-secure-boot-guide.mdx
new file mode 100644
index 0000000..1b107dc
--- /dev/null
+++ b/news/development/2026-05/openruyi-secure-boot-guide.mdx
@@ -0,0 +1,321 @@
+---
+title: "Enabling RISC-V Secure Boot on openRuyi: A Practical Guide from Firmware to Kernel"
+tags: [development]
+date: 2026-05-21
+slug: 2026-05/openruyi-secure-boot-guide
+
+---
+
+Secure Boot is an important mechanism for establishing a trusted verification chain during system startup. For system adaptation, firmware debugging, and boot process validation on RISC-V platforms, a reproducible configuration workflow helps developers understand the trust relationships among boot components.
+
+Based on the openRuyi Documentation Center guide, "Enable Secure Boot on openRuyi"<sup>[1]</sup>, this article uses the openRuyi UEFI firmware and the openRuyi Server edition QCOW2 image as examples to outline the main steps for configuring Secure Boot in a QEMU environment. The process begins with preparing the firmware and system image.
+<!-- truncate -->
+## 1. Prepare the UEFI Firmware and System Image
+
+Before enabling Secure Boot, prepare the openRuyi UEFI firmware and the openRuyi Server edition QCOW2 system image. The UEFI firmware can be obtained from the `ovmf` package in the openRuyi package repository<sup>[2]</sup>. Extracting the package produces the `.fd` files.
+
+```bash
+wget https://boat.openruyi.cn/stable/rva23/riscv64/ovmf-202602-11.3.or.riscv64.rpm
+rpm2cpio ovmf-202602-11.3.or.riscv64.rpm | cpio -idmv
+cp ./usr/share/ovmf/*.fd ./
+```
+
+The openRuyi Server edition QCOW2 system image used in this article can be obtained from the openRuyi releases page<sup>[3]</sup>.
+
+> Note: If the `ovmf` package or system image has been updated by the time you follow this guide, use the latest files available in the openRuyi package repository and releases page, and update the filenames in the scripts below accordingly.
+
+## 2. Create a QEMU Quick-Start Script
+
+After preparing the firmware and system image, create a QEMU startup script named `start_or.sh` and make it executable:
+
+```bash
+touch start_or.sh
+chmod +x start_or.sh
+```
+
+Write the following content to `start_or.sh`:
+
+```bash
+#!/usr/bin/env bash
+
+# The script is created for starting a riscv64 qemu virtual machine with specific parameters.
+
+RESTORE=$(echo -en '\001\033[0m\002')
+YELLOW=$(echo -en '\001\033[00;33m\002')
+
+## Configuration
+vcpu=2
+memory=8
+drive="openRuyi-2026.04-Server-cloud.qcow2"
+fw1="virt_code.fd"
+fw2="virt_vars.fd"
+ssh_port=12055
+
+cmd="qemu-system-riscv64 \
+  -nographic -machine virt,pflash0=pflash0,pflash1=pflash1,acpi=off \
+  -cpu rva23s64,sv39=on \
+  -smp "$vcpu" -m "$memory"G \
+  -blockdev node-name=pflash0,driver=file,read-only=on,filename="$fw1" \
+  -blockdev node-name=pflash1,driver=file,filename="$fw2" \
+  -drive file="$drive",format=qcow2,id=hd0,if=none \
+  -object rng-random,filename=/dev/urandom,id=rng0 \
+  -device virtio-vga \
+  -device virtio-rng-device,rng=rng0 \
+  -device virtio-blk-device,drive=hd0 \
+  -device virtio-net-device,netdev=usernet \
+  -netdev user,id=usernet,hostfwd=tcp::"$ssh_port"-:22 \
+  -device qemu-xhci -usb -device usb-kbd -device usb-tablet"
+
+echo ${YELLOW}:: Starting VM...${RESTORE}
+echo ${YELLOW}:: Using following configuration${RESTORE}
+echo ""
+echo ${YELLOW}vCPU Cores: "$vcpu"${RESTORE}
+echo ${YELLOW}Memory: "$memory"G${RESTORE}
+echo ${YELLOW}Disk: "$drive"${RESTORE}
+echo ${YELLOW}SSH Port: "$ssh_port"${RESTORE}
+echo ""
+echo ${YELLOW}:: NOTE: Make sure ONLY ONE .qcow2 file is${RESTORE}
+echo ${YELLOW}in the current directory${RESTORE}
+echo ""
+echo ${YELLOW}:: Tip: Try setting DNS manually if QEMU user network doesn\'t work well. ${RESTORE}
+echo ${YELLOW}:: HOWTO -\> https://serverfault.com/a/810639 ${RESTORE}
+echo ""
+echo ${YELLOW}:: Tip: If \'ping\' reports permission error, try reinstalling \'iputils\'. ${RESTORE}
+echo ${YELLOW}:: HOWTO -\> \'sudo dnf reinstall iputils\' ${RESTORE}
+echo ""
+
+sleep 2
+
+eval $cmd
+```
+
+This script starts an openRuyi virtual machine using `qemu-system-riscv64` and specifies parameters including the RISC-V virt machine, UEFI pflash devices, QCOW2 disk, virtio devices, and SSH port forwarding. Here, `drive` points to the openRuyi Server QCOW2 image, `fw1` and `fw2` correspond to `virt_code.fd` and `virt_vars.fd`, and `ssh_port` configures SSH port forwarding.
+
+Run the startup script to enter the openRuyi environment:
+
+```bash
+./start_or.sh
+```
+
+After the system starts, log in using either of the following accounts:
+
+```text
+root / openruyi
+openruyi / openruyi
+```
+
+## 3. Install the Tools Required for Secure Boot
+
+After entering the system, install the tools required to configure Secure Boot:
+
+```bash
+dnf install -y efibootmgr efitools grub-unsigned mokutil sbsigntools shim wget
+```
+
+After installation, copy `grub.cfg` and `grubriscv64.efi` to the `/boot/efi/EFI/openruyi` directory:
+
+```bash
+cp /boot/efi/EFI/BOOT/grub.cfg /boot/efi/EFI/openruyi/
+cp /lib/grub/riscv64-efi/monolithic/grubriscv64.efi /boot/efi/EFI/openruyi/
+```
+
+## 4. Download the Secure Boot Helper Scripts
+
+From this point onward, all commands in this section must be run as the root user. If you are logged in as the `openruyi` user, add `sudo` before each command.
+
+```bash
+wget https://github.com/wxjstz/secureboot-setup/archive/refs/heads/main.tar.gz
+tar xvf main.tar.gz
+cd secureboot-setup-main
+```
+
+The repository mainly contains three scripts:
+
+```text
+1.gen_keys          # Generate PK, KEK, db, and MOK keys
+2.import_mok        # Initiate MOK enrollment through mokutil
+3.import_uefi_cert  # Import PK, KEK, and db into the UEFI variable store
+```
+
+> Note: After completing Secure Boot key enrollment, continue using the same `virt_vars.fd` file. QEMU stores UEFI variables in this file. Replacing it with a new `virt_vars.fd` will cause the system to lose the enrolled keys.
+
+## 5. Confirm That the Firmware Is in Setup Mode
+
+Before creating or importing keys, confirm that the firmware is in Setup Mode:
+
+```bash
+mokutil --sb-state
+```
+
+The expected output is:
+
+```text
+SecureBoot disabled
+Platform is in Setup Mode
+```
+
+If the firmware is not in Setup Mode, restart QEMU with a clean `virt_vars.fd`, or enter the BIOS/UEFI interface and clear the Secure Boot keys.
+
+## 6. Generate Secure Boot Signing Keys
+
+After confirming that the firmware is in Setup Mode, generate the keys and certificates required for Secure Boot:
+
+```bash
+./1.gen_keys
+```
+
+When the script runs, it prompts you to enter the certificate owner name. This name is written to the Common Name field of the generated certificate. Press Enter to use the default value.
+
+After the script finishes, it generates the following directory structure:
+
+```text
+secureboot/
+├── cert/       # Private keys, certificates, and MOK.der
+├── esl/        # EFI Signature Lists
+└── keystore/   # Signed .auth files for UEFI enrollment
+```
+
+### Backup Reminder
+
+Back up the entire `secureboot/` directory, especially the private key files under `secureboot/cert`.
+
+## 7. Sign the Key Files in the Boot Chain
+
+Secure Boot is not simply a matter of enabling a boot option. More importantly, the key files in the boot chain must carry valid signatures.
+
+```text
+UEFI firmware → trust through db → shim → trust through MOK → MokManager / GRUB / Linux kernel
+```
+
+This workflow uses the following signing strategy:
+
+- Use the db key to sign shim.
+- Use the MOK key to sign MokManager, GRUB, and the Linux kernel.
+
+Before signing, back up the original files:
+
+```bash
+mkdir -p orig
+
+cp /boot/linux orig/
+cp /boot/efi/EFI/openruyi/shimriscv64.efi orig/
+cp /boot/efi/EFI/openruyi/mmriscv64.efi orig/
+cp /boot/efi/EFI/openruyi/grubriscv64.efi orig/
+```
+
+Use the db key to sign shim:
+
+```bash
+sbsign \
+    --key secureboot/cert/db.key \
+    --cert secureboot/cert/db.crt \
+    --output /boot/efi/EFI/openruyi/shimriscv64.efi \
+    orig/shimriscv64.efi
+```
+
+Use the MOK key to sign MokManager, GRUB, and the Linux kernel:
+
+```bash
+sbsign \
+    --key secureboot/cert/MOK.key \
+    --cert secureboot/cert/MOK.crt \
+    --output /boot/efi/EFI/openruyi/mmriscv64.efi \
+    orig/mmriscv64.efi
+
+sbsign \
+    --key secureboot/cert/MOK.key \
+    --cert secureboot/cert/MOK.crt \
+    --output /boot/efi/EFI/openruyi/grubriscv64.efi \
+    orig/grubriscv64.efi
+
+sbsign \
+    --key secureboot/cert/MOK.key \
+    --cert secureboot/cert/MOK.crt \
+    --output /boot/linux \
+    orig/linux
+```
+
+## 8. Enroll the MOK Certificate
+
+Before importing the UEFI certificates, enroll the MOK certificate. shim will use MOK to trust the signed MokManager, GRUB, and kernel.
+
+Run the following command to initiate the MOK enrollment request:
+
+```bash
+./2.import_mok
+```
+
+During this process, you need to set an enrollment password. After rebooting into MokManager, use this password to confirm the enrollment.
+
+```bash
+reboot
+```
+
+After the system restarts, MokManager opens the blue Mok Management interface. Complete the enrollment as follows:
+
+1. Select `Enroll MOK` → `Continue`.
+2. Enter the password you just set.
+3. Select `Yes` to confirm the enrollment.
+4. Select `Reboot`.
+
+After the second reboot, use the following command to confirm that the MOK certificate has been enrolled:
+
+```bash
+mokutil --list-enrolled
+```
+
+## 9. Import the UEFI Certificates
+
+After enrolling the MOK certificate, import PK, KEK, and db into the UEFI variable store:
+
+```bash
+./3.import_uefi_cert
+```
+
+After the import completes, check each UEFI key database:
+
+```bash
+mokutil --pk
+mokutil --kek
+mokutil --db
+```
+
+After confirming that the command output includes the certificates generated earlier, reboot the system again:
+
+```bash
+reboot
+```
+
+## 10. Verify That Secure Boot Is Enabled
+
+After the system restarts, run:
+
+```bash
+mokutil --sb-state
+```
+
+If the output is:
+
+```text
+SecureBoot enabled
+```
+
+Secure Boot has been successfully enabled on openRuyi.
+
+## Summary
+
+This guide enables developers to walk through the complete Secure Boot configuration process in an openRuyi QEMU environment. From firmware preparation and QEMU startup to key generation, boot-file signing, and MOK and UEFI certificate enrollment, the workflow demonstrates how Secure Boot works on openRuyi.
+
+For developers interested in RISC-V system security, UEFI firmware adaptation, and boot-chain verification, this is not only a hands-on Secure Boot configuration exercise, but also an introduction to the trusted boot mechanism of RISC-V systems.
+
+## Related Links
+
+[1] openRuyi Secure Boot Guide: https://openruyi.cn/zh-Hans/docs/guide/enable-secure-boot/
+
+[2] openRuyi Package Repository: https://boat.openruyi.cn/stable/rva23/
+
+[3] openRuyi Releases: https://releases.openruyi.cn/
+
+## Contact Us
+
+If you are interested in openRuyi, follow the project on GitHub, visit the openRuyi Documentation Center for more information, or join the Discord community to participate in discussions. The team is continuously recruiting full-time employees, part-time contributors, and interns. Please send your resume to Jingwei Wang at wangjingwei@iscas.ac.cn.
\ No newline at end of file
diff --git a/news/ecosystem/2026-05/dpdk-riscv-maintainer.mdx b/news/ecosystem/2026-05/dpdk-riscv-maintainer.mdx
new file mode 100644
index 0000000..e5bc37c
--- /dev/null
+++ b/news/ecosystem/2026-05/dpdk-riscv-maintainer.mdx
@@ -0,0 +1,60 @@
+---
+title: ISCAS Engineer Yuechi Sun Becomes DPDK RISC-V Architecture Maintainer, Advancing the Ecosystem of openRuyi’s High-Performance Networking and Storage Stack
+tags: [ecosystem]
+date: 2026-05-15
+slug: 2026-05/dpdk-riscv-maintainer
+---
+
+Recently, Yuechi Sun, an engineer at the Institute of Software, Chinese Academy of Sciences, became the RISC-V architecture maintainer for DPDK (Data Plane Development Kit). His maintenance scope has expanded from the previous RVV (RISC-V Vector Extension) subsystem to the entire RISC-V architecture.
+<!-- truncate -->
+![DPDK MAINTAINERS update](/article-images/2026-05/DPDK-1.png)
+<p align="center">DPDK MAINTAINERS update</p>
+
+> DPDK is a widely deployed user-space high-speed data plane framework, covering key scenarios such as telecommunications networks, cloud data centers, virtual switching, and load balancing. It is also a core dependency of high-performance networking and storage projects such as SPDK, OVS-DPDK, and VPP. Having long-term contributors to RISC-V optimization take on architecture maintenance means that patch review, CI maintenance, and release work for this architecture will move into a more stable cadence, further promoting the large-scale adoption of RISC-V in data center and network infrastructure scenarios.
+
+## Long-Term Investment in RISC-V and Deeper Involvement in the Maintenance Framework
+
+Since the second half of 2023, RISC-V-related submissions in the DPDK community had, for a time, remained under review for a prolonged period, and the overall merge pace slowed down. Since 2025, Yuechi Sun has promoted a series of patches around V extension detection, runtime dispatching, and RVV vectorization of core lookup data structures such as lpm and fib. This work became the first batch of RISC-V optimization achievements to enter the DPDK mainline in nearly three years.
+
+During the same period, he joined DPDK MAINTAINERS as the RVV subsystem maintainer. As his continued investment and community collaboration deepened, he further took on maintenance responsibilities for the entire RISC-V architecture.
+
+## openRuyi’s Plan to Advance DPDK
+
+DPDK support for RISC-V is a key part of openRuyi’s systematic efforts to advance the high-performance software stack. In addition to promoting the upstreaming of RVV optimizations into DPDK, the RuyiSDS initiative is also building distribution packaging, runtime validation, and continuous integration capabilities for DPDK in the openRuyi operating system.
+
+These capabilities will allow every RISC-V-related upstream change to receive fast feedback on real RISC-V server hardware, reducing the risk that patches are left pending or maintenance stalls due to insufficient hardware resources.
+
+Around RISC-V optimization for DPDK, openRuyi has carried out and will continue to advance the following work:
+
+- **Instruction extension detection framework**: Unified detection of extension capabilities such as V at both compile time and runtime, laying the foundation for future optimized dispatch.
+- **RVV optimization of core data structures**: RVV vectorization has been completed for lookup and routing hot paths such as fib and lpm, with notable performance improvements.
+- **Build and test infrastructure**: Improvements to build and unit testing related to the V extension on RISC-V platforms, ensuring DPDK stability on RISC-V.
+- **Continuous expansion**: Exploration of RVV optimizations for modules such as mem, node, and acl is underway and will be gradually pushed upstream.
+
+At the same time, an increasing number of developers from China and abroad, including contributors from ZTE and ByteDance, have been participating in RISC-V adaptation in the DPDK community. Related work currently under review and discussion covers multiple areas, including support for Z-series extensions such as Zbc and Zicbop, hwprobe detection, RVV vectorization of core libraries such as hash, rte_memcpy optimization, and memory and prefetch operations for I/O devices. Yuechi Sun will work with community contributors to advance the review and merging of this work, continuously expanding the scope of RISC-V optimization in DPDK.
+
+## The RISC-V Storage Stack Around Ceph: openRuyi’s Next Step
+
+On the RISC-V platform, storage stack optimization depends on a bottom-up component chain: the upper-layer Ceph distributed storage system depends on foundational components such as the SPDK user-space block storage stack, the ISA-L data acceleration library, OpenSSL, and zstd; SPDK, in turn, depends on DPDK for runtime facilities such as high-performance memory pools, polling, and lock-free queues.
+
+The main line of work in the RuyiSDS initiative is to systematically advance along this dependency chain:
+
+- **Low-level acceleration libraries**: Working with upstream communities to promote RVV vectorization and riscv64 adaptation for Ceph dependencies such as ISA-L, zstd, and OpenSSL. For example, ISA-L v2.32, released earlier this year, officially supports riscv64 and covers RVV implementations of core operators such as erasure coding, CRC, and compression checks.
+- **Runtime and block storage**: Using DPDK maintenance work as a foothold to further advance the adaptation and improvement of SPDK on RISC-V, and gradually enable the DPDK/SPDK path for Ceph on RISC-V platforms.
+- **Integration validation**: After the related work is completed, the full Ceph CI will first be run in openRuyi, with the goal of making openRuyi the industry’s first RISC-V distribution with complete Ceph support.
+- **Performance tuning**: On the basis of functional completeness, openRuyi will gradually integrate and validate the high-performance and next-generation OSD paths in Ceph that depend on DPDK/SPDK. Some of these capabilities are still experimental upstream, and openRuyi will continue to track their progress.
+
+![openRuyi RISC-V software stack](/article-images/2026-05/DPDK-2.png)
+<p align="center">openRuyi RISC-V software stack</p>
+
+As the RVA23 standard is officially implemented and server-class RISC-V platforms gradually mature, system-level optimization of networking and storage stacks is moving from “point-by-point adaptation” to a new stage of “end-to-end collaboration.” With DPDK maintenance as a foothold, openRuyi will collaborate with upstream and downstream components such as SPDK, ISA-L, Ceph, and OVS to build a RISC-V software stack that connects infrastructure and distributed applications.
+
+## Building the Ecosystem Together
+
+In the future, the RuyiSDS initiative will continue to invest in upstream collaboration for RISC-V in high-performance networking and distributed storage, promote more optimizations into core projects such as DPDK, SPDK, and Ceph, and rely on openRuyi to provide a stable development, build, and validation environment. These efforts will help key infrastructure software in the RISC-V server ecosystem reach production readiness sooner.
+
+We sincerely invite more developers, chip vendors, and system vendors to join us and work with openRuyi to advance the evolution of the RISC-V networking and storage software stack.
+
+## Contact Us
+
+If you are interested in openRuyi, you can follow our GitHub open-source project, visit the openRuyi documentation center for more information, and join our Discord community for discussion. The team is continuously recruiting full-time employees, part-time contributors, and interns. Please send your resume to [wangjingwei@iscas.ac.cn](mailto:wangjingwei@iscas.ac.cn) (Jingwei Wang).
\ No newline at end of file
diff --git a/news/tags.yml b/news/tags.yml
index a59712b..0f260ef 100644
--- a/news/tags.yml
+++ b/news/tags.yml
@@ -2,4 +2,11 @@ release:
   label: Release
   permalink: /release
   description: Release tag description
-blog:
+ecosystem:
+  label: Ecosystem
+  permalink: /ecosystem
+  description: Ecosystem tag description
+development:
+  label: Development
+  permalink: /development
+  description: Development tag description
diff --git a/static/article-images/2026-05/DPDK-1.png b/static/article-images/2026-05/DPDK-1.png
new file mode 100644
index 0000000..6760060
Binary files /dev/null and b/static/article-images/2026-05/DPDK-1.png differ
diff --git a/static/article-images/2026-05/DPDK-2.png b/static/article-images/2026-05/DPDK-2.png
new file mode 100644
index 0000000..fa4af83
Binary files /dev/null and b/static/article-images/2026-05/DPDK-2.png differ
diff --git a/static/article-images/2026-05/deepseek-r1.webp b/static/article-images/2026-05/deepseek-r1.webp
new file mode 100644
index 0000000..93a4c72
Binary files /dev/null and b/static/article-images/2026-05/deepseek-r1.webp differ
diff --git a/static/article-images/2026-05/picoclaw.png b/static/article-images/2026-05/picoclaw.png
new file mode 100644
index 0000000..ae01b3c
Binary files /dev/null and b/static/article-images/2026-05/picoclaw.png differ