• 原文链接：https://riscv.org/blog-chinese/2024/09/eclipse-riscv64-support-upstreamed/
• 日期: September 30, 2024
• 作者：陈璇

Eclipse 是一款开源且功能强大的集成开发环境（IDE），广泛支持多种编程语言，为开发者提供了一个统一的平台，用于编写、调试和管理代码。同时，Eclipse 还具备强大的插件系统，可根据需求灵活扩展功能。

近期，来自中国科学院软件研究所（ISCAS）的 RevyOS 小队的工程师联合其他开源社区开发者，成功为 Eclipse 上游代码仓库引入了对 riscv64 架构的初步支持。期间创建了二十余个 Issue/PR，涵盖了包括 SWT、Equinox 在内的关键组件。目前，Eclipse 已支持在 riscv64 平台上基于 OpenJDK 开发 Java 项目。

图1-Eclipse upstream 涉及到几十个不同的组建和支持过程，许多开发者都进行了贡献

相关改动已被合入上游，感兴趣的朋友可通过下方链接，建议选择 Integration Builds 板块中的最新构建日期（20240929以后每日构建支持riscv）进入每日构建资源页面，选择“Eclipse SDK -> Linux (64 bit version for RISC-V)”下载后进行体验。

https://download.eclipse.org/eclipse/downloads/index.html

图2-在安装了 Debian 操作系统的 SiFive Unmatched 上测试运行 Eclipse SDK IDE

接下来，RevyOS 小队将继续完善 Eclipse riscv64 的支持，敬请期待更多优化与改进！

中国科学院软件研究所诚邀对开源技术充满热情的开源软件贡献者加入进来，助力 Eclipse 在 riscv64 平台上的发展。

关于 ISCAS、RevyOS小队

RevyOS小队隶属于 PLCT Lab, ISCAS。ISCAS 是 RISC-V International 的 Development Partner、Training Partner，同时在2024年8月获得了 RISC-V Ecosystem Labs 认证。

特别致谢以下贡献者

于波、陈璇、Hannes Wellmann、Alexander Kurtakov、Ed Merks、Pawel Stankiewicz、Frederic Gurr

如有遗漏，请联系作者

在上期文章中，向大家介绍了《玄铁团队与PLCT实验室联合发布：新32位产品级开源工具链及Linux内核》，本期为大家带来新32位（RV64ILP32）产品化的最新进展：嘉楠勘智K230D。去年，嘉楠推出 K230，它基于玄铁c908 打造，是世界上第一款带有 VECTOR 1.0 的 RISC-V 64位 AIOT 芯片。今年，嘉楠勘智推出更高集成度的 K230D AIoT 芯片，内存由原来外挂 256MB/512MB 改为内封 128MB。原先基于 LP64 ABI 的软件内存开销过大，不再适合 K230D，而新32位技术可同时提升内存与缓存的效率。PLCT实验室联合玄铁团队，一起为 K230D 打造基于新32位的 RuyiSDK，第一次实现新32位 AIoT 产品的落地。相比原先基于 LP64 ABI 的 SDK，新32位 SDK 内存开销下降 30%，同时链表遍历性能提升 20%，兼顾成本和性能。

达摩院玄铁团队联手嘉楠科技和中科院软件所PLCT实验室，将新32位落地到Banana Pi开源社区的BPI-CANMV-K230D-Zero 开发板，并与PLCT实验室的 RuyiSDK 集成，一起为用户提供便捷的使用体验：

• 升级 Linux 内核至 6.6、升级工具链

• 新增32位根系统 和 LVGL

• 基于 VECTOR 的图形加速

• 支持 Linux + Nuttx 双系统，大小核任意切换

• 支持传统64位和新32位，两种系统配置

内核配置：​

默认配置差异仅2行：

CONFIG_ARCH_RV64ILP32=y

CONFIG_32BIT=y

内存对比​

下面的视频和图片展示了，传统64位（左）与新32位（右）对比 LVGL 的运行：

相比传统64位，新32位 RuyiSDK 大幅提升内存使用效率，避免了 K230D 产品化中的内存浪费。

性能对比​

由于 LP64 的指针数据类型比 ILP32 大一倍，导致 LP64 的缓存利用率偏低。下面，基于 K230D 对比二者的双向链表遍历性能：

双向链表遍历 （链表节点为4000，遍历50000次结果）​

结果显示，ILP32 的链表遍历性能显著优于 LP64。

相关资料：​

K230D RuyiSDK：https://github.com/ruyisdk/k230_linux_sdk

（镜像构建详见文档 https://github.com/ruyisdk/k230_linux_sdk/blob/dev/README_zh.md）

K230D 使用说明：https://ruyisdk.org/docs/k230d/intro

结束语

与过往的架构（ARM、x86、MIPS、Sparc）聚焦用户态的思路不同，当前新32位的方案是：基于 RVA20/22/23 Profiles 为 RV64 架构的特权态提供 ILP32 ABI 能力，这是前人未曾走过的新路。自 2024 年 3 月推出新 32 位工具链和 Linux 内核以来，这次终于在 K230D 上实现了产品化，降低了 30% 的内存开销，大幅提升缓存性能，这些成果进一步揭示了新 32 位的产业化价值。我们热切期待开发者们积极参与新32位的开发和完善中，共同提出宝贵的建议和意见，推动新 32 位不断发展。我们致力于建立一个健康和活跃的开源社区，将持续投入资源和精力，确保新32位软件的稳定和可靠，并不断改进和完善其功能和性能。在此，我们也呼吁更多的硬件厂商加入我们的阵营，共同推动新32位嵌入式系统的发展和创新，为行业带来更多机遇。

关于我们​

●   RuyiSDK 是一个由 PLCT Lab 所启动的开源项目，该项目旨在为 RISC-V 开发者提供一个完整的、全家桶式的全功能开发环境，包含从编译、调试到仿真的全套工具，并计划支持市面上主流的 RISC-V 硬件。

●   达摩院玄铁团队持续深耕 RISC-V 技术研发及生态建设，并陆续推出了一系列玄铁处理器，可满足高中低全系列性能需求。玄铁积极拥抱开源，坚持开放创新，已逐渐构建起以 RISC-V 为核心的生态体系，与生态伙伴协同推动 RISC-V 芯片、开发工具、操作系统、应用解决方案等不同层面的软硬一体化发展。全力推动 RISC-V 软硬全栈技术多领域发展落地，加速实现智能时代的万物互联!

●   嘉楠科技（Canaan Inc.）（纳斯达克股票代码：CAN）是一家领先的高性能ASIC芯片设计公司，以“区块链+AI”为多元化经营战略，业务范围涵盖高性能ASIC计算芯片及设备研发、AI芯片及产品开发。作为一家纳斯达克上市公司，嘉楠科技是全球“区块链第一股”，也是第一家在美国上市的中国自主知识产权AI芯片公司。公司愿景：提升社会运行效率，改善人类生活方式。

RuyiSDK 0.15 is now released. The corresponding package manager version is also 0.15. You can download the RuyiSDK package manager from one of the following locations:

• https://github.com/ruyisdk/ruyi/releases/tag/0.15.0
• https://mirror.iscas.ac.cn/ruyisdk/ruyi/releases/0.15.0/

This update mainly consists of the following changes. Happy hacking!

RuyiSDK Package Manager​

• Getting prepared for multi-language support: in cases localized content is requested, such as manual download instructions for software packages, ruyi will now try to choose an appropriate locale if your system locale does not exactly match one of the available locales for the given content.

  For example: if you configure your system locale as Singaporean English (en_SG), but one piece of content is only available in U.S. English (en_US) and China Mainland Chinese (zh_CN), then in this case ruyi 0.15.0 will show you the en_US version instead of crash.

• ruyi can now be built without a Docker dependency, for distribution packagers' convenience, and for those users wanting to try out ruyi but are not running officially supported architecture and/or OS.

  Please note that as the majority of official RuyiSDK Software Repository packages are distributed in binary form, users who want to run ruyi on non-officially-supported systems have to get organized, and maintain their own software repository. The RuyiSDK team cannot guarantee user experience under such circumstance.

RuyiSDK Software Repository​

• The repository layout is no longer compatible with ruyi 0.7.0 or lower; such users should upgrade right now.
• Version 0.3.0 of emulator/box64-upstream is now packaged.
• The guide for running WPS Office with Box64 has been revised.
• The Ruyi Device Provisioner (ruyi device provision) now supports the following device model and system:
  • Canaan Kendryte K230D: CanMV Linux SDK image packaged by RuyiSDK with permission, with demo programs, available in two ABIs -- LP64 and RV64ILP32.

RuyiSDK 0.14 is now released. The corresponding package manager version is also 0.14. You can download the RuyiSDK package manager from one of the following locations:

• https://github.com/ruyisdk/ruyi/releases/tag/0.14.0
• https://mirror.iscas.ac.cn/ruyisdk/ruyi/releases/0.14.0/

This update mainly consists of the following changes. Happy hacking!

RuyiSDK Package Manager​

• An plugin architecture is officially introduced into ruyi: profile-related handling for ruyi virtual environments are now entirely taken care of by plugins.
• Unpacking of Debian package archives -- *.deb files is now supported.
• Improved handling of "pre-release versions" again: previously ruyi will mistreat versions that contain non-digit character(s) in their suffixes. The bug has not had a chance to trigger with the current content of RuyiSDK repository though.
• Fixed pygit2 build failure on riscv64 Python 3.12: previously one would have to manually intervene after pygit2 started to build, but before it tried to invoke setup.py inside its virtual environment, by installing setuptools inside the venv -- the package is no longer automatically installed in venvs from Python 3.12 on.

RuyiSDK Software Repository​

• The architecture simulator Box64 built from upstream sources is added: emulator/box64-upstream.
• The office suite extra/wps-office is added. Attention: due to its commercial nature, you will have to accept an EULA on the first use of the software.
• You can now run WPS Office on your RISC-V desktop with the help of Box64. Please follow the guide available via ruyi news for trying out.

Please run ruyi update to pull in the update after upgrading the RuyiSDK package manager.

To support devices that require manual intervention during provisioning, and whose images have to be downloaded manually, the RuyiSDK Device Provisioner is now being refactored into a plugin-based architecture. However in this development cycle we had to prioritize the Box64 & WPS Office PoC work; we still expect to finish the device provisioner refactoring in a future release. Older versions of the device provisioner will stop working at that time; please upgrade before you test.

得益于 Box64 RISC-V 移植工作的进展，在 RISC-V Linux 桌面发行版上运行 WPS Office 等常见 x86 二进制软件已成为可能。RuyiSDK 正在开展此方面的集成工作； 按以下的步骤操作，您将能先行一步感受 RISC-V 办公体验。

我们假定您在进行以下操作之前，已经升级到了 ruyi 0.14.0 或更高的版本， 并执行了 ruyi update 以将软件源信息同步到最新。

操作步骤​

为叙述方便，设您的 $HOME 为 /home/foo，架构（uname -m 输出）为 riscv64，使用 sudo 提权。

允许安装预发布版本的软件包​

由于 Box64 RISC-V 支持进展迅速，目前（2024 年 7 月初）很多功能改进没有在 其最新稳定版本得到体现。我们打包了 Box64 的开发快照版本；为了能够安装此版本， 您需要配置 ruyi 以使其在安装软件包时考虑预发布版本。

• 如果 ~/.config/ruyi 目录不存在，则创建之。
• 编辑 ~/.config/ruyi/config.toml。

[packages]
prereleases = true

安装 Box64​

按照 RuyiSDK 软件包的命名习惯，从 Box64 的上游（而非 PLCT 或某些厂商的 fork） 构建的 Box64 二进制包，名字叫 box64-upstream。

ruyi install box64-upstream
# ...
# info: package box64-upstream-0.2.8-ruyi.20240702 installed to /home/foo/.local/share/ruyi/binaries/riscv64/box64-upstream-0.2.8-ruyi.20240702

记下安装路径。

配置 Linux binfmt_misc 机制​

由于 WPS Office 的打包方式特殊，它只能从开发商提供的启动器脚本被间接拉起， 而不能直接交由 Box64 启动。因此您需要确保您的系统支持 binfmt_misc： 如果不支持，接下来的操作会失败。

不同 Linux 发行版的 binfmt_misc 配置方式不尽相同，以下针对采用 systemd 的系统叙述。您可以根据自身情况自行调整。

# 确认 Box64 可执行文件的位置
ls /home/foo/.local/share/ruyi/binaries/riscv64/box64-upstream-0.2.8-ruyi.20240702/bin/box64

# 调整 Box64 `binfmt.d` 配置文件的路径
# 假设您使用 nano 编辑器
nano /home/foo/.local/share/ruyi/binaries/riscv64/box64-upstream-0.2.8-ruyi.20240702/etc/binfmt.d/box64.conf
# 将行尾的 //bin/box64 改为先前验证过的绝对路径

# 将其部署到系统
sudo cp /home/foo/.local/share/ruyi/binaries/riscv64/box64-upstream-0.2.8-ruyi.20240702/etc/binfmt.d/box64.conf /etc/binfmt.d/box64.conf
sudo systemctl restart systemd-binfmt

# 检查部署结果
cat /proc/sys/fs/binfmt_misc/box64

安装 x86 sysroot​

由于 Box64 主要面向游戏等软件的模拟，而这些软件基本都自带所有依赖，所以 Box64 本身基本没有自带什么 x86 运行时库。WPS Office 作为一个预期被系统包管理器管理的 桌面应用，Box64 自带的少量 x86 运行时库无法满足它的需求，因此我们需要自行准备 x86 环境。

# 下载预制的 x86 sysroot
# 此为临时性的链接。后续待本功能迭代稳定之后，操作方式将改变，此链接也将失效
# 假设此文件放在了 ~/Downloads 目录下
wget https://mirror.iscas.ac.cn/ruyisdk/dist/temp/debian-bookworm.gui.20240705.amd64.tar.zst

# 假设安装到 /opt/debian-bookworm.amd64
sudo mkdir /opt/debian-bookworm.amd64
pushd /opt/debian-bookworm.amd64
tar -xf ~/Downloads/debian-bookworm.gui.20240705.amd64.tar.zst
popd

安装 WPS Office​

强制安装 x86_64 架构的 WPS Office 软件包：

ruyi install --host x86_64 wps-office
# ...
# info: package wps-office-11.1.0-r.11719 installed to /home/foo/.local/share/ruyi/binaries/x86_64/wps-office-11.1.0-r.11719

由于 WPS Office 官方下载页面的限制，ruyi 无法自动下载安装包。 请按照提示信息操作，之后重新执行该命令以安装。

调整 WPS Office 启动器脚本​

由于 WPS Office 预期自身被系统包管理器管理，它的启动器脚本假定了自身的安装路径 为 /opt/kingsoft/wps-office，需要为它们打补丁。

pushd /home/foo/.local/share/ruyi/binaries/x86_64/wps-office-11.1.0-r.11719

# 当前工作目录路径中应当不含特殊字符。
# 如果含有，请自行适当调整 sed 命令的参数
sed -i "s@gInstallPath=/@gInstallPath=$(pwd)/@" ./usr/bin/*

popd

运行 WPS Office​

准备工作终于完成，现在将所有部分串起来：

# 此动态链接库的原生转发仍有些问题，因此强制以模拟方式执行
export BOX64_EMULATED_LIBS=libsqlite3.so.0
# 配置 Box64 库搜索路径
export BOX64_LD_LIBRARY_PATH=/opt/debian-bookworm.amd64/usr/lib/x86_64-linux-gnu

# 现在可以执行了！
/home/foo/.local/share/ruyi/binaries/x86_64/wps-office-11.1.0-r.11719/usr/bin/wps

结语​

以上是 RuyiSDK 对 RISC-V 二进制翻译 x86 软件的初步集成成果。 今后我们仍将迭代这一过程的用户体验，以期用户在 RISC-V 系统上运行需要的应用 更加方便。

RuyiSDK 0.12 is now released. The corresponding package manager version is also 0.12. You can download the RuyiSDK package manager from one of the following locations:

• https://github.com/ruyisdk/ruyi/releases/tag/0.12.0
• https://mirror.iscas.ac.cn/ruyisdk/ruyi/releases/0.12.0/

This update mainly consists of the following changes. Happy hacking!

RuyiSDK Package Manager​

• The Pine64 Star64 Armbian image can now be correctly downloaded.
• The user experience for downloading fetch-restricted files is implemented. A hint message will be rendered according to the current system locale setting when such a file is requested.
• pygit2 has been upgraded to 1.5.0 to support libgit2 1.8.
• The XDG_STATE_HOME environment variable is now correctly respected.

To support devices that require manual intervention during provisioning, and whose images have to be downloaded manually, the RuyiSDK Device Provisioner is now being refactored to handle those complex situations, with the next version expected to be fit for testing. Older versions of the device provisioner will stop working at that time; please upgrade before you test.

RuyiSDK 0.11 is now released. The corresponding package manager version is also 0.11. You can download the RuyiSDK package manager from one of the following locations:

• https://github.com/ruyisdk/ruyi/releases/tag/0.11.0
• https://mirror.iscas.ac.cn/ruyisdk/ruyi/releases/0.11.0/

This update mainly consists of the following changes. Happy hacking!

RuyiSDK Package Manager​

• Removed the only LGPL dependency so far. The entirety of RuyiSDK Package Manager and its dependencies are now permissively licensed, which means downstream users are free to use the RuyiSDK Package Manager in a commercial fashion from now on.

RuyiSDK Software Repository​

• The Ruyi Device Provisioner (ruyi device provision) now supports the following device models:
  • Pine64 Star64

Please run ruyi update to pull in the update after upgrading the RuyiSDK package manager.

We have noticed that more and more device models (even including the newly announced BananaPi BPI-F3) are having their system images distributed by means of net-disks only, such as Baidu Netdisk, Google Drive or MEGA. It is a challenge to support such models due to this; we will attempt to do so nevertheless in the coming releases. Stay tuned and your contribution is welcome!

RuyiSDK 0.10 is now released. The corresponding package manager version is also 0.10. You can download the RuyiSDK package manager from one of the following locations:

• https://github.com/ruyisdk/ruyi/releases/tag/0.10.0
• https://mirror.iscas.ac.cn/ruyisdk/ruyi/releases/0.10.0/

This update mainly consists of the following changes. Happy hacking!

RuyiSDK Package Manager​

• A global command-line option --porcelain is now supported for external programs to conveniently interact with ruyi. ruyi list and ruyi news list are the first to gain a porcelain output format.
• ruyi news list now prefers to present a news item in the system's current language if a translation is available.

RuyiSDK Software Repository​

RuyiSDK begins to support WinChipHead (WCH) RISC-V products from version 0.10 on.

• The LLVM toolchain maintained by PLCT is now packaged: toolchain/llvm-plct, whose main feature is support for the XTHeadVector extension.
• The Ruyi Device Provisioner (ruyi device provision) now supports the following device models:
  • WCH CH32V103 EVB
  • WCH CH32V203 EVB
  • WCH CH32V208 EVB
  • WCH CH32V303 EVB
  • WCH CH32V305 EVB
  • WCH CH32V307 EVB
  • WCH CH582F EVB
  • WCH CH592X EVB

Please run ruyi update to pull in the update after upgrading the RuyiSDK package manager.

RuyiSDK 0.9 is now released. The corresponding package manager version is also 0.9. You can download the RuyiSDK package manager from one of the following locations:

• https://github.com/ruyisdk/ruyi/releases/tag/0.9.0
• https://mirror.iscas.ac.cn/ruyisdk/ruyi/releases/0.9.0/

This update mainly consists of the following changes. Happy hacking!

RuyiSDK Package Manager​

• Unpacking of LZ4-compressed files is now supported.

RuyiSDK Software Repository​

RuyiSDK supports the entire Sipeed RISC-V product line from version 0.9 on.

The Ruyi Device Provisioner (ruyi device provision) now supports the following device models:

• Sipeed LicheeRV Nano
• Sipeed Lichee Cluster 4A
• Sipeed Lichee Console 4A
• Sipeed Maix-I
• Sipeed Tang Mega 138K Pro

In addition to the following models for whose support is already present:

• Sipeed LicheePi 4A
• Sipeed LicheeRV

Please run ruyi update to pull in the update after upgrading the RuyiSDK package manager.

For your convenience following bleeding-edge development, the RuyiSDK team has packaged a bare-metal toolchain targetting the experimental RV64ILP32 ABI. Because this is a bare-metal toolchain, no sysroot is provided, and multilib is not enabled: the ABI to use is ilp32d.

Usage example​

Given the following C program:

// test.c
long long add(long long *a, long long b)
{
    return *a + b;  // Should be realized with `ld` and `add`
}

void check(int);

void check_sizes(void)
{
    check(sizeof(int));        // a0 should be 4
    check(sizeof(long));       // a0 should be 4
    check(sizeof(long long));  // a0 should be 8
    check(sizeof(void *));     // a0 should be 4
}

We can now build object code conforming to the RV64ILP32 ABI with the proper toolchain package and profile:

$ ruyi update
$ ruyi install gnu-plct-rv64ilp32-elf
$ ruyi venv -t gnu-plct-rv64ilp32-elf --without-sysroot baremetal-rv64ilp32 /tmp/venv
$ source /tmp/venv/bin/ruyi-activate
$ /tmp/venv11/bin/riscv64-plct-elf-gcc -O2 -c -o test.o test.c

Checking that everything works as intended:

$ riscv64-plct-elf-readelf -h test.o | grep 32
  Class:                             ELF32
  Flags:                             0x25, RVC, X32, double-float ABI

$ riscv64-plct-elf-objdump -dw test.o

test.o:     file format elf32-littleriscv


Disassembly of section .text:

00000000 <add>:
   0:   6108                    ld      a0,0(a0)
   2:   952e                    add     a0,a0,a1
   4:   8082                    ret

00000006 <check_sizes>:
   6:   3141                    addiw   sp,sp,-16
   8:   4511                    li      a0,4
   a:   e406                    sd      ra,8(sp)
   c:   00000097                auipc   ra,0x0
  10:   000080e7                jalr    ra # c <check_sizes+0x6>
  14:   4511                    li      a0,4
  16:   00000097                auipc   ra,0x0
  1a:   000080e7                jalr    ra # 16 <check_sizes+0x10>
  1e:   4521                    li      a0,8
  20:   00000097                auipc   ra,0x0
  24:   000080e7                jalr    ra # 20 <check_sizes+0x1a>
  28:   60a2                    ld      ra,8(sp)
  2a:   4511                    li      a0,4
  2c:   2141                    addiw   sp,sp,16
  2e:   00000317                auipc   t1,0x0
  32:   00030067                jr      t1 # 2e <check_sizes+0x28>

It can thus be shown that the toolchain indeed generates object code with 32-bit pointer width, but also leveraging RV64 capabilities.