Chen Wang comments

Results 125 comments of


                                            Chen Wang

[ARCH/RISC-V] Next RISC-V

这个 PR 改动也太大了，我感觉很难 review。有没有更好的分解方式，按照子模块，或者 feature 改进分步进行 PR？如果正如 PR 上的如下描述改动了 10 个点，这些点看上去是独立的，那也应该要有至少 10 个 PR。 > ISA manager interface. > Merge 32E/32I/64I. > Cache by CBOM ISA. > MMU support...

[ARCH/RISC-V] Next RISC-V

我有如下想法，供大家参考： - 这么大的改动一次合入光依赖人工 review 我觉得很难找出所有问题，所以估计大部分要靠测试。这个 PR 应该只测试了 virt。 - 一旦合入造成当前积极维护中的 bsp 无法工作，而且可能 block 一些仍在基于 master 添加新功能的 bsp 的开发。对于 bsp 的维护人员和开发者来说同样会进入长期的拉锯战，只是把问题推迟到 merge 之后而已，并无多大区别。所以如果从 kernel 的角度确定无法循序渐进地 pr（即只能一次性 merge），我觉得一种可行的办法就是需要确定与 riscv 相关的需要重点看护的 bsp，至少在...

[ARCH/RISC-V] Next RISC-V

> 重点看护的 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...

[ARCH/RISC-V] Next RISC-V

> ## RTT主线需要维护的RISCV BSP列表 > 32位： > > * [ ] [bluetrum](https://github.com/RT-Thread/rt-thread/tree/master/bsp/bluetrum) > * [ ] [bouffalo_lab](https://github.com/RT-Thread/rt-thread/tree/master/bsp/bouffalo_lab) > * [ ] [hpmicro](https://github.com/RT-Thread/rt-thread/tree/master/bsp/hpmicro) > * [ ] [nuclei-gd32vf103r-start](https://github.com/RT-Thread/rt-thread/tree/master/bsp/gd32/risc-v/gd32vf103r-start) > * [...

[ARCH/RISC-V] Next RISC-V

> 在这份修改中 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 > ``` 比较好奇，mmu...

[ARCH/RISC-V] Next RISC-V

> 因为设备树支持 no-mmu 和 mmu 版本，举个例子：这是在回答我的问题吗。我的问题是 ”为啥要做成 mcu 和 common 两个目录“ 如果是回答的我的问题，其实我反而更加感觉奇怪了，难道因为设备树要支持 no-mmu 和 mmu 两个版本，内核源码树就要分 mcu 和 common 两个目录？其实我理想中的源码目录 layout 就是： ``` riscv |- common |- vendors |-...

[Feature] [risc-v] RISC-V 的toolchain 讨论

这个议题是不是没有考虑 RT-smart 的情况？

[Feature] [risc-v] RISC-V 的toolchain 讨论

补充一些我这边维护比较多的 riscv 相关 bsp 使用的 toolchain 信息(包括了 RT-standard 和 RT-smart)： cvitek（milkv-duo 系列）: https://github.com/RT-Thread/rt-thread/blob/master/bsp/cvitek/README.md#41-toolchain-%E4%B8%8B%E8%BD%BD virt64-riscv: https://github.com/RT-Thread/rt-thread/blob/master/bsp/qemu-virt64-riscv/README_cn.md#21-%E5%AE%89%E8%A3%85%E5%B7%A5%E5%85%B7%E9%93%BE 另外，我一直在跟踪的 riscv 工具链不统一的问题，提的相关 issue: - https://github.com/RT-Thread/rt-thread/issues/10028 - https://github.com/RT-Thread/rt-thread/issues/9812 感觉推动很困难，拖了很长时间了。

[Feature] [risc-v] RISC-V 的toolchain 讨论

> SMART 版本可以尝试下下面的链接： https://github.com/riscv-collab/riscv-gnu-toolchain/releases/download/2025.01.20/riscv64-musl-ubuntu-22.04-gcc-nightly-2025.01.20-nightly.tar.xz 选择musl版本，这块没经验，不确定，只能建议尝试，后面会出一些文章介绍相关术语这个估计不行，rt-smart 用的 musl gcc 听说是定制了 rtt 自己的什么东西，具体要问睿赛德了。

[Feature] [risc-v] RISC-V 的toolchain 讨论

> > 补充一些我这边维护比较多的 riscv 相关 bsp 使用的 toolchain 信息(包括了 RT-standard 和 RT-smart)： > > cvitek（milkv-duo 系列）: https://github.com/RT-Thread/rt-thread/blob/master/bsp/cvitek/README.md#41-toolchain-%E4%B8%8B%E8%BD%BD > > virt64-riscv: https://github.com/RT-Thread/rt-thread/blob/master/bsp/qemu-virt64-riscv/README_cn.md#21-%E5%AE%89%E8%A3%85%E5%B7%A5%E5%85%B7%E9%93%BE > > 另外，我一直在跟踪的 riscv 工具链不统一的问题，提的相关 issue: > > >...