RT-Thread
[Feature] 优化 cvitek 固件打包的处理
Describe problem solved by the proposed feature
目前针对 bsp/cvitek 的固件 (fip.bin) 制作过程中，第一次编译时会下载大量的来自 sophgo 的仓库到本地 RTT 仓库中，包括：
rt-thread/bsp/cvitek/cvitek_bootloader$ ls -l
total 40
drwxrwxr-x 8 u u 4096 6月 12 08:56 build
-rwxrwxr-x 1 u u 350 5月 8 15:48 build.sh
drwxrwxr-x 10 u u 4096 5月 8 15:48 device
-rw-rw-r-- 1 u u 4728 5月 8 15:48 env.sh
drwxrwxr-x 8 u u 4096 5月 8 15:51 fsbl
drwxrwxr-x 3 u u 4096 3月 7 2023 host-tools
drwxrwxr-x 4 u u 4096 5月 9 16:30 install
drwxrwxr-x 9 u u 4096 5月 10 21:44 opensbi
drwxrwxr-x 24 u u 4096 5月 8 15:51 u-boot-2021.10
然后从源码开始制作所有的相关模块，
这个操作存在以下缺点：
- 过程比较漫长，特别是网络不好时对用户并不友好
- 目前这些目录都放在 RTT 仓库目录下，污染了 RTT 仓库，对代码搜索等操作不友好。
建议改进
Describe your preferred solution
No response
Describe possible alternatives
No response
可能的解决方案：
-
方案1 ：将生成 fip.bin / boot.sd 的过程和脚本独立到 RTT 工程之外维护，RTT 这边只负责生成 rtthread.bin。好处是不放到 RTT 的仓库代码树下，避免污染工作目录，但这些 sophgo 的组件源码比较多，如果用户的网络不好体验不好。
-
方案2 : 制作 fip.bin 需要 sophgo 的 bl2,fsbl，opensbi, u-boot 等组件，但这些组件对于我们来说是固定的，RTT 的代码不会修改这些内容，所以这些内容可以以 prebuild 的方式做好后放在 RTT 的 bsp/cvitek 下，size 都不大，虽然可能针对不同的 board，需要各提供一份。目前采用这种方式的可以参考 https://github.com/unicornx/riscv-operating-system-mooc/tree/rvos4duo/code/os, 以及相关文章介绍："将 RVOS 移植到 MilkV-Duo 上"。和方案 1 比较，对 RTT 源码树污染不大，用户只要能下载 RTT 源码就能很快构建 fip 等固件文件。
之前采用源码在打包阶段自动下载并编译主要考虑到有定制bootloader需求，如果没有定制需求可以采用方案2
即使有定制 bootloader 的需求，建议最好把 cvitek_bootloader 这种目录放在 RTT 仓库之外维护，有时候看见有人会删掉原来的 RTT 仓库重新 clone，如果用户不知道我们会下载一个 cvitek_bootloader 目录那么每次 clone 后就需要再重新下载一次 cvitek_bootloader。 有些人知道 cvitek_bootloader 这个目录后，为了避免反复下载（可能是网络不好的原因）会将这个目录复制出来，然后重新 clone 后再复制回去，这些操作看上去挺别扭的。感觉把 RTT 仓库和 sophgo 的这些仓库给耦合在一起了，所以放在外面维护就是希望解耦。
再说，定制 bootloader 的需求应该不多吧？
可以考虑方案2的，而且关于额外的文件可以放入到软件包中，单独来进行维护。
软件包部分可以是纯文件（包括二进制文件），因为软件包也会做自动镜像，在国内可以加速。
已经合入 duo-v5.1.0 https://github.com/flyingcys/rt-thread/pull/42 有待 upstream,但只考虑了 riscv 部分，没有考虑 arm 部分，如何 upstream 有待考虑
目前的想法是希望尽量不要在 RTT 仓库中加入额外的 BSP 内容，包括 prebuild 的文件，否则如果都按照这个思路去做，RTT 仓库仍然有膨胀的危险。
新建 #9623 ，等 duo-pkgtool 完成后，可以将其代替目前的 cvitek_bootloader （这里称之为”清理“）, 本 issue 用于 track ”清理“ 工作。具体见 《9623 的详细设计》中”有关 RT-Thread 仓库的清理工作“ 的描述。
以下引用部分是旧的方案思路，保留在这里仅作备忘
所以是否可以采用熊大的建议，在方案 2 的基础上进一步采用软件包的方式来提供 prebuild 文件。还有待研究。
或者依然采用下载 cvitek_bootloader 的方式（本身也可以理解成是一种软件包），只是避免下载在 RTT 源码树下，否则会污染工作环境，譬如 “对代码搜索等操作不友好”。附加：这个污染的问题在实际操作中影响不算大，譬如在 VSCode 中可以通过过滤排除这个路径。
