GUI
GUI
@Rbb666
一步步来解释。 首先这个 PR 肯定不会是直接以这样的方式申请合并，上面 `Plan` 中仍有部分事项没有进行验证，比如 M 模式的测试，无 DM 模式的测试，无 MMU 的测试，以及对已有的 BSP（比如提到的 T-Head 产品）进行验证和重新适配。同时这个 PR 部分依赖的模块并没有合并到主线上。 更多是希望和相关人员探讨这么改（仅从技术角度讨论）是否可以接受，PR 会一直根据大家的意见进行改进，等到相关依赖都合并，相关验证、重新适配完成，以及大家意见统一为止。 # WHY 本次提交目的很简单： 1. SMP 支持。 2. 统一 32/64 适配。 3....
重点看护的 BSP 肯定是要保证正常运行的，这个 PR 显然提交之前也清楚难以一两个人就能 review 好，但是目前据我认识的相关 RISC-V 前维护者已经不在 RT-Thread 社区活跃，如果是这样的话也还有个比较好的办法，那就是先提交到开发分支，在该分支上进行长期（显然时间肯定不会太长，因为近期可能也会有新的 Vendor 和 BSP 引入）的验证和重新适配，最后再变基并一次性合并到主线也可以。
> 确定需要把rv32、rv64融合起来？确定以这种方式，后续各个riscv芯片厂商间可以融合在一起，可以统一在一起？ 理论上可以，涉及到用户态和虚拟内存可能要注意下
这块目前还没做完整测试，社区目前对 RV 架构的组成可能还需要进一步确认，因为这个 PR 拆出来不是那么容易的，有些东西是存在耦合的，还有些东西的实现只能是 0 到 1，不能是 0.1，0.2 这样。
在这份修改中 no-mmu 和 mmu 版本是同时支持的，也就是系统可以在早期通过动态设置 `rt_hw_arch_vaddr_width`，这个特性是为了支持设备树版本支持的，其次就是干脆关闭 libcpu 中内置的 `ARCH_MM_MMU` 直接不编译相关代码。如果是这样的话，那目录建议改成这样： ```shell └─risc-v ├─mcu（always no-mmu） ├─common（mmu and no-mmu） ├─vendor-A └─vendor-B ```
因为设备树支持 no-mmu 和 mmu 版本，举个例子： k210： ```c cpus { #address-cells = ; #size-cells = ; timebase-frequency = ; cpu0: cpu@0 { device_type = "cpu"; compatible = "canaan,k210", "riscv"; reg =...
上面 @BernardXiong 说了要把 RISC-V32 也拆分了：no-mmu 和 mmu 版本，RISC-V64 之前也是拆分 no-mmu 和 mmu 版本，那既然这样的话，那就是整体要拆分 no-mmu 和 mmu，那还要考虑 no-mmu 的一种情况，就是 MCU，可能偏 32E 的版本，也就是不打算跑 Linux 的那些 RISC-V 板子 按照 common 合并的初衷，这些板子设计的不是很离谱也可以复用 common 的代码，但是鉴于目前测试还不够充分，涉及...
> @GuEe-GUI 您好，我手头有一块 Spacemit K1的开发板，正计划为它适配一个 BSP。 但我看到next_riscv 分支已经很久没更新了，我不确定我是否应该在该分支上进行开发，并且我尝试在本地编译 qemu-virt64-riscv BSP也遇到了一些问题，比如我发现 libcpu/risc-v/common/mmu.h 中似乎硬编码了对 mm_aspace.h（一个 lwp 组件）的包含。 这似乎使 libcpu 这个核心库错误地依赖了 lwp 这个可选组件，导致任何“非 SMART”的配置都无法编译通过。 请问该分支后续有更新计划嘛。 由于前面的仍留下部分疑问，因此这个 PR 的内容没有继续更新（有定期同步主线继续开发）。 对于 K1 的支持，我这边已经支持得差不多了（部分驱动编写完成但并未跑通），目前 SMP 方面有一些问题需要排查，如果你这边愿意一起维护或者支持，我会将...
> @GuEe-GUI 感谢您的回复！我非常乐意与您一起维护和支持 K1 的适配工作。我手头有 K1 的物理开发板（香蕉派开发板Banana Pi BPI-F3），可以立即开始帮您进行测试，特别是您提到的 SMP 问题。 太好了，我也是这个 SBC，晚些我整理代码提交上来