[ARCH/RISC-V] Next RISC-V

[GuEe-GUI]

拉取/合并请求描述：(PR description)

[

1. ISA manager interface.
2. Merge 32E/32I/64I.
3. Cache by CBOM ISA.
4. MMU support Sv32/Sv39/Sv48/Sv57/Sv64, SVPBMT ISA.
5. Merge M-mode, S-mode CSR ops.
6. Support SMP.
7. Support APLIC & IMSIC (AIA), CLIC, ACLINT/CLINT, INTC, PLIC.
8. Support DM (only by OFW) or not DM.
9. Merge T-HEAD vendor.
10. Port DM in qemu-virt64-riscv64
11. Kernel support boot in not CPU#0

Plan:

• S-mode RT-Thread
• S-mode RT-Smart
• S-mode RT-Smart + APP
• S-Mode (DM)
• S-Mode (No MMU)
• S-Mode (No DM)
• M-Mode (DM)
• M-Mode (No DM)
• BSP

Depend on:

• Full DM
• DTC

]

当前拉取/合并请求的状态 Intent for your PR

必须选择一项 Choose one (Mandatory):

• 本拉取/合并请求是一个草稿版本 This PR is for a code-review and is intended to get feedback
• 本拉取/合并请求是一个成熟版本 This PR is mature, and ready to be integrated into the repo

代码质量 Code Quality：

我在这个拉取/合并请求中已经考虑了 As part of this pull request, I've considered the following:

• 已经仔细查看过代码改动的对比 Already check the difference between PR and old code
• 代码风格正确，包括缩进空格，命名及其他风格 Style guide is adhered to, including spacing, naming and other styles
• 没有垃圾代码，代码尽量精简，不包含#if 0代码，不包含已经被注释了的代码 All redundant code is removed and cleaned up
• 所有变更均有原因及合理的，并且不会影响到其他软件组件代码或BSP All modifications are justified and not affect other components or BSP
• 对难懂代码均提供对应的注释 I've commented appropriately where code is tricky
• 代码是高质量的 Code in this PR is of high quality
• 已经使用formatting 等源码格式化工具确保格式符合RT-Thread代码规范 This PR complies with RT-Thread code specification
• 如果是新增bsp, 已经添加ci检查到.github/workflows/bsp_buildings.yml 详细请参考链接BSP自查

[GuEe-GUI]

@Rbb666

[unicornx]

这个 PR 改动也太大了，我感觉很难 review。有没有更好的分解方式，按照子模块，或者 feature 改进分步进行 PR？

如果正如 PR 上的如下描述改动了 10 个点，这些点看上去是独立的，那也应该要有至少 10 个 PR。

ISA manager interface.
Merge 32E/32I/64I.
Cache by CBOM ISA.
MMU support Sv32/Sv39/Sv48/Sv57/Sv64, SVPBMT ISA.
Merge M-mode, S-mode CSR ops.
Support SMP.
Support APLIC & IMSIC (AIA), CLIC, ACLINT/CLINT, INTC, PLIC.
Support DM (only by OFW) or not DM.
Merge T-HEAD vendor.
Port DM in qemu-virt64-riscv64

另外为啥要改动，原因请详细列出来，也为我们 review 提供帮助，对于重大修改，PR 描述中至少应该包括：

• why
• how

最后，只验证一个 virt64 恐怕是不够的，对其他产品，这么大的改动一次合入主线能保证其他 RISC-V 产品（特别是 T-head）的 BSP 工作不受影响吗？有没有更好的规划？

总之，我建议小步快跑方式，越是大的改动，越需要谨慎。

[GuEe-GUI]

一步步来解释。

首先这个 PR 肯定不会是直接以这样的方式申请合并，上面 Plan 中仍有部分事项没有进行验证，比如 M 模式的测试，无 DM 模式的测试，无 MMU 的测试，以及对已有的 BSP（比如提到的 T-Head 产品）进行验证和重新适配。同时这个 PR 部分依赖的模块并没有合并到主线上。

更多是希望和相关人员探讨这么改（仅从技术角度讨论）是否可以接受，PR 会一直根据大家的意见进行改进，等到相关依赖都合并，相关验证、重新适配完成，以及大家意见统一为止。

WHY

本次提交目的很简单：

1. SMP 支持。
2. 统一 32/64 适配。
3. 统一 Vendor 操作。
4. 支持 DM。
5. 改进现有代码结构，某些程度上，提高代码可读性。

根据对已有的操作系统和 RISC-V 目前标准来看，RT-Thread 在 RISC-V 支持上存在技术支持落后，代码维护性差，以及新平台适配没有统一标准等问题，因此根据这些问题提出的解决方案只有重写。

很遗憾，本次 PR 无法再进行拆分，否则将会陷入长期的 Kernel 跟进 BSP -> BSP 跟进 Kernel -> Kernel 跟进 BSP -> 新 BSP 插入 -> 新 BSP 重新支持 等无穷无尽的拉锯战；一次性把问题解决掉、将不积极跟进主线的 BSP 踢掉或者放弃，才是目前让 Kernel 得以快速发展的唯一解。

同时上述提到的各种新的点，仅是对改进的一个总结，并不是说代码真的可以分成这么多个模块，有的模块之间存在依赖，在已有代码基础上拆分提交，（从 AArch64 的统一经验来看）这种工作量就干脆不要搞了。

HOW

ISA manager interface.

增加对目前 RISC-V ISA 位说明，使用位图进行管理，便于代码动态监测 ISA 状况，平台可以自行设置 ISA 支持情况（可参考libcpu/risc-v/common/README.md），设备树平台将自动扫描 ISA 属性进行设置。

Merge 32E/32I/64I.

32 位和 64 位只有访存指令，部分浮点数据位长度不一样，其他都是兼容的，因此相关差异用宏进行封装编程就可以，相关文件位于 libcpu/risc-v/common/include/asm-generic.h 中。

至于 32E，仅是支持的寄存器更少，在上下文管理中使用 ARCH_RISCV_32E 宏隔开，同时工程师后续代码中注意寄存器的使用即可，一般来说 32E 范围下的寄存器已经够编程使用。

Cache by CBOM ISA.

该 ISA 就是标准的 D-Cache 操作，只有 T-Head 平台没支持该 ISA，而且还提供了 DM 版本的 HWCache 支持，Cache 操作完全可以统一，至于 T-Head 平台，Common 中的 Cache 实现均为 weak 声明，T-Head 重新实现相关接口即可。

设备树平台将自动扫描 CPU 节点中 riscv,cbom-block-size 设置 CBOM 大小。

MMU support Sv32/Sv39/Sv48/Sv57/Sv64, SVPBMT ISA.

各种页表翻译模式本身就是统一的，只有相关 PTE 位允许厂商自己修改实现，以支持 PMA，NOCACHE，IO 属性，ISA SVPBMT 中已经对前面提到的属性进行了统一，只有 T-Head 平台没支持该 ISA，直接使用 Vendor 声明的 PTE_VENDOR_ 前缀声明的属性进行覆盖即可。

同时对于 MMU 配置，Vendor 可以使用 MMU_VENDOR_ 前缀声明的宏进行平台针对性的设置。

为了考虑不同平台支持的 Sv 模式不同，提供了 rt_hw_arch_vaddr_width 进行静态设置，详情可参考 libcpu/risc-v/common/README.md，设备树平台将自动扫描 CPU 节点中 mmu-type 进行识别。

Merge M-mode, S-mode CSR ops.

重新提供统一的 CSR 寄存器描述表，其中 M-mode，S-mode 大部分寄存器仅是前缀不一样，使用 ARCH_RISCV_M_MODE 进行区分即可。

Support SMP.

这块支持最大的问题就是，CPU ID 的获取。

在其他操作系统上，多任务和多核会非常早启动，其使用了进程中的 CPU 成员来获取 CPU ID，进程的信息存放在 TP 寄存器中，而这种方案在 RT-Thread 上显然不合适，早期是没有任何线程和进程的。

RT-Thread 上的 TP 寄存器，在 S-mode 的 LWP 中已经被用于保存 LWP 结构，因此使用 per-CPU 方式对将 HART ID 进行 CPU 内存分区映射，以支持当前 HART 获取，HART 表再转 CPU ID，该做法要求平台使用 MMU，目前打开 MMU 就会启动该功能，后期可以考虑改进为 RT-SMART 版本才使用该功能。

M-mode 下无 MMU 不能支持 LWP，因此在该模式下，TP 就是 CPU ID。

支持 CPU 身份识别后，对于 SMP 上下文调度支持，参考架构 SMP 移植要求即可。

Support APLIC & IMSIC (AIA), CLIC, ACLINT/CLINT, INTC, PLIC.

这个是刚需，这个外设 IP 就是统一的，代码也应该只有一份，对于一些平台有 quirk 的情况，代码里面已经使用 quirk bitmap 管理以支持不同特性的平台。

对于 AIA 架构，要求强制使用 DM 模式，而 CLIC, ACLINT/CLINT, INTC, PLIC 则使用与 DM 版本代码对具体硬件操作进行 API 封装，在 interrupt.c 中直接使用，详情可参考 libcpu/risc-v/common/README.md

Support DM (only by OFW) or not DM.

RISC-V 在其他较先进的 OS 中本身就支持设备树 DM 模式，只要平台支持好 DM 要求的资源管理接口即可。

由于 RISC-V 存在资源紧张的平台，代码重构早期就考虑到了部分代码与 DM 版本共享，以及相关属性使用静态配置的方式实现支持，前面的描述已经讲清楚支持方式。

Merge T-HEAD vendor.

T-HEAD 本身大部分硬件特性就是固定的，没必要拆成 C906 和 C908，而且该 Vendor 遵守大部分 ISA，只要保留部分细微的差异即可，前面的描述已经讲清楚支持方式。

Kernel support boot in not CPU#0

这是一个历史遗留问题，并不是所有平台上，CPU 总是会从 0 核启动，这种限制本来就是偏激的，何况在 AMP 场景中这种情况更多，而 RISC-V 部分平台依然采用彩票机制随机启动一个 HART，如果不支持这个特性本身就是玩不了这个架构的。

RT-Thread 对 CPU#0 依赖的代码很明显，主要是系统 tick 管理，以及 idle 线程的主核心任务，修改相关对 CPU#0 的显示指定即可。

以上的描述可能不够清晰，如果有疑问可以进一步讨论。

[unicornx]

我有如下想法，供大家参考：

• 这么大的改动一次合入光依赖人工 review 我觉得很难找出所有问题，所以估计大部分要靠测试。这个 PR 应该只测试了 virt。
• 一旦合入造成当前积极维护中的 bsp 无法工作，而且可能 block 一些仍在基于 master 添加新功能的 bsp 的开发。对于 bsp 的维护人员和开发者来说同样会进入长期的拉锯战，只是把问题推迟到 merge 之后而已，并无多大区别。

所以如果从 kernel 的角度确定无法循序渐进地 pr（即只能一次性 merge），我觉得一种可行的办法就是需要确定与 riscv 相关的需要重点看护的 bsp，至少在 review 过程中做好充分的测试，并保证这些重点看护 bsp 可以基本正常工作后该 pr 才可以合入。

我这里目前维护的 riscv board 有两个：

• bsp/cvitek： 这个 bsp 目前已基本稳定，只是维护。
• bsp/k230：这个 bsp 还在添加新功能。

其他关心这个 PR 的 bsp 有哪些，欢迎补充。

另外，我也看到 PR 说：

更多是希望和相关人员探讨这么改（仅从技术角度讨论）是否可以接受，PR 会一直根据大家的意见进行改进，等到相关依赖都合并，相关验证、重新适配完成，以及大家意见统一为止。

所以我理解这个 PR 并没有急着要合入，所以不妨在上面我提的第一个思路，即拉入更多关心此 PR 的 reviewer 基础上，我们在 review 这个 PR 的同时也考虑拆分的问题。我相信经过大家的努力，或许也是有可能拆分的（其实我大概看了一下 作者 上面的详细的描述，感觉有些功能点还是比较独立的，有很大可能性可以拆分出来先提交进 master， 我也有意愿参与这份工作）。

最后顺便提一下，我建议再找一些原先做 libcpu 下的人来一起 review，我参与 rtt 工作以来主要也是在 bsp 上多一些，有些 kenrel 公共部分还希望有更多有经验的人来一起 review。

[GuEe-GUI]

重点看护的 BSP 肯定是要保证正常运行的，这个 PR 显然提交之前也清楚难以一两个人就能 review 好，但是目前据我认识的相关 RISC-V 前维护者已经不在 RT-Thread 社区活跃，如果是这样的话也还有个比较好的办法，那就是先提交到开发分支，在该分支上进行长期（显然时间肯定不会太长，因为近期可能也会有新的 Vendor 和 BSP 引入）的验证和重新适配，最后再变基并一次性合并到主线也可以。

[unicornx]

重点看护的 BSP 肯定是要保证正常运行的，这个 PR 显然提交之前也清楚难以一两个人就能 review 好，但是目前据我认识的相关 RISC-V 前维护者已经不在 RT-Thread 社区活跃，如果是这样的话也还有个比较好的办法，那就是先提交到开发分支，在该分支上进行长期（显然时间肯定不会太长，因为近期可能也会有新的 Vendor 和 BSP 引入）的验证和重新适配，最后再变基并一次性合并到主线也可以。

也可以，如果能确保你这个 pr 的关联开发分支 https://github.com/GuEe-GUI/rt-thread/tree/next_riscv 不定期 rebase 到最新的 master 就行。

Review 过程中如果发现一些可以单独摘出来的 feature 也可以随时拿出来单独提 pr 先合入 master，然后 next_riscv 继续 rebase 到最新的 master。如此循环几次就可以实现化整为零，分批次提交了。

[zhangjing0303]

pr里提到的功能，比如cbo指令支持、smp功能支持、M mode支持、DM支持这些确实是目前riscv 平台需要实现的，这个pr相当于是对目前riscv平台相关代码的重构。个人同意@unicornx的观点，尽可能将pr内容拆开，cbo指令支持等这些相对独立的功能可以单独merge。我在rtt 5.2.0版本上基于我们的dp1000 平台目前也实现了pr里的部分功能，后续我可以参与该pr的review。

[BernardXiong]

确定需要把rv32、rv64融合起来？确定以这种方式，后续各个riscv芯片厂商间可以融合在一起，可以统一在一起？

[htl5241]

我的小pr 啥时融入

[GuEe-GUI]

确定需要把rv32、rv64融合起来？确定以这种方式，后续各个riscv芯片厂商间可以融合在一起，可以统一在一起？

理论上可以，涉及到用户态和虚拟内存可能要注意下

[supperthomas]

CI 有问题

[Rbb666]

RTT主线需要维护的RISCV BSP列表

32位：

• bluetrum
• bouffalo_lab
• hpmicro
• nuclei-gd32vf103r-start
• xuantie(E)
• wch
• ESP32_C3

64位：

• allwinner
• cvitek
• k210
• k230
• qemu-virt64-riscv
• xuantie(C,R)

@GuEe-GUI @unicornx @supperthomas 我这边列了一份主线上需要维护的RISCV BSP列表，看下是否还有补充？

[unicornx]

RTT主线需要维护的RISCV BSP列表

32位：

• bluetrum
• bouffalo_lab
• hpmicro
• nuclei-gd32vf103r-start
• xuantie(E)
• wch
• ESP32_C3

64位：

• allwinner
• cvitek
• k210
• k230
• qemu-virt64-riscv
• xuantie(C,R)

@GuEe-GUI @unicornx @supperthomas 我这边列了一份主线上需要维护的RISCV BSP列表，看下是否还有补充？

我没有补充，我只是一直没搞明白 bsp/xuantie 和其他基于玄铁的 bsp，例如 cvitek/k230/... 是啥关系？

[Rbb666]

RTT主线需要维护的RISCV BSP列表

32位：

• bluetrum
• bouffalo_lab
• hpmicro
• nuclei-gd32vf103r-start
• xuantie(E)
• wch
• ESP32_C3

64位：

• allwinner
• cvitek
• k210
• k230
• qemu-virt64-riscv
• xuantie(C,R)

@GuEe-GUI @unicornx @supperthomas 我这边列了一份主线上需要维护的RISCV BSP列表，看下是否还有补充？

我没有补充，我只是一直没搞明白 bsp/xuantie 和其他基于玄铁的 bsp，例如 cvitek/k230/... 是啥关系？

xuantie下面的都是xuantie的qemu平台，包括xiaohui和smart-l两个BSP，架构会覆盖到C/R/E。