Chen Wang


lwn 80911: scheduling domains was created for trimagiccube

从 PR 的title来看，修改应该尽量局限在 bsp/cvitek 内部，但是我发现这个 pr 中修改了很多 common 的逻辑: - components - libcpu 这些是对原来 KERNEK_REMAP 修改 #9067 的补充吗？是不是应该以一个单独的 PR 的形式先行提交，然后再提交 bsp/cvitek 的部分？

@polarvid @BernardXiong ： btw, 目前针对 rtt 的 riscv 的修改是否有工作组在推进？我刚刚参与 RTT 开发，对 rtt 的 riscv 方面的整体状态并不是很清楚，是否有渠道，SIG 等类似的组织在讨论这方面的工作，很想参与一下。这样对我理解 RTT 以及 review 这些 pr 或许会有帮助. Thanks

> > 是不是应该以一个单独的 PR 的形式先行提交，然后再提交 bsp/cvitek 的部分？ > > commit 可以拆成多个。但是部分 commits 是需要联合 PR 的。 > > 因为 libcpu 的修改和 bsp 有些东西是完全关联的。而不是解耦的。否则会导致使用异常。 同意，必要的话，在 一个 pr 中 拆分多个 commit 会更好。 另外建议...

可能的解决方案： - 方案1 ：将生成 fip.bin / boot.sd 的过程和脚本独立到 RTT 工程之外维护，RTT 这边只负责生成 rtthread.bin。好处是不放到 RTT 的仓库代码树下，避免污染工作目录，但这些 sophgo 的组件源码比较多，如果用户的网络不好体验不好。 - 方案2 : 制作 fip.bin 需要 sophgo 的 bl2,fsbl，opensbi, u-boot 等组件，但这些组件对于我们来说是固定的，RTT 的代码不会修改这些内容，所以这些内容可以以 prebuild 的方式做好后放在...

> 之前采用源码在打包阶段自动下载并编译主要考虑到有定制bootloader需求，如果没有定制需求可以采用方案2 即使有定制 bootloader 的需求，建议最好把 cvitek_bootloader 这种目录放在 RTT 仓库之外维护，有时候看见有人会删掉原来的 RTT 仓库重新 clone，如果用户不知道我们会下载一个 cvitek_bootloader 目录那么每次 clone 后就需要再重新下载一次 cvitek_bootloader。 有些人知道 cvitek_bootloader 这个目录后，为了避免反复下载（可能是网络不好的原因）会将这个目录复制出来，然后重新 clone 后再复制回去，这些操作看上去挺别扭的。感觉把 RTT 仓库和 sophgo 的这些仓库给耦合在一起了，所以放在外面维护就是希望解耦。 再说，定制 bootloader 的需求应该不多吧？

已经合入 duo-v5.1.0 https://github.com/flyingcys/rt-thread/pull/42 有待 upstream,但只考虑了 riscv 部分，没有考虑 arm 部分，如何 upstream 有待考虑

 需要加如图所示的默认值，不加默认值得先 menuconfig 下不然就是空值。 建议单独提一个 pr 修改这个问题。

目前的想法是希望尽量不要在 RTT 仓库中加入额外的 BSP 内容，包括 prebuild 的文件，否则如果都按照这个思路去做，RTT 仓库仍然有膨胀的危险。 新建 #9623 ，等 duo-pkgtool 完成后，可以将其代替目前的 cvitek_bootloader （这里称之为”清理“）, 本 issue 用于 track ”清理“ 工作。具体见 [《9623 的详细设计》中”有关 RT-Thread 仓库的清理工作“ 的描述](https://github.com/plctlab/plct-rt-thread/issues/1)。 以下引用部分是旧的方案思路，保留在这里仅作备忘 > 所以是否可以采用熊大的建议，在方案 2...