可能的解决方案：

• 方案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需求，如果没有定制需求可以采用方案2

即使有定制 bootloader 的需求，建议最好把 cvitek_bootloader 这种目录放在 RTT 仓库之外维护，有时候看见有人会删掉原来的 RTT 仓库重新 clone，如果用户不知道我们会下载一个 cvitek_bootloader 目录那么每次 clone 后就需要再重新下载一次 cvitek_bootloader。 有些人知道 cvitek_bootloader 这个目录后，为了避免反复下载（可能是网络不好的原因）会将这个目录复制出来，然后重新 clone 后再复制回去，这些操作看上去挺别扭的。感觉把 RTT 仓库和 sophgo 的这些仓库给耦合在一起了，所以放在外面维护就是希望解耦。

再说，定制 bootloader 的需求应该不多吧？

可以考虑方案2的，而且关于额外的文件可以放入到软件包中，单独来进行维护。

软件包部分可以是纯文件（包括二进制文件），因为软件包也会做自动镜像，在国内可以加速。