[Feature] 优化 cvitek 固件打包的处理

[unicornx]

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

我们正在开发一个新的针对 duo 的打包工具，具体参考 "为 duo 产品的 RT-smart 开发打包工具"

这个工具以命令行方式执行，并采用 prebuild 方式提供打包的素材，这样可以避免下载太多的文件和工具。可以用来代替现有的 cvitek_bootloader。具体想法可以参考 "为 duo 产品的 RT-smart 开发打包工具" 的 ”有关 RT-Thread 仓库的清理工作“ 部分的描述。

Describe possible alternatives

No response

[unicornx]

可能的解决方案：

• 方案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 等固件文件。

[flyingcys]

之前采用源码在打包阶段自动下载并编译主要考虑到有定制bootloader需求，如果没有定制需求可以采用方案2

[unicornx]

之前采用源码在打包阶段自动下载并编译主要考虑到有定制bootloader需求，如果没有定制需求可以采用方案2

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

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

[BernardXiong]

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

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

[unicornx]

已经合入 duo-v5.1.0 flyingcys#42 有待 upstream,但只考虑了 riscv 部分，没有考虑 arm 部分，如何 upstream 有待考虑

[unicornx]

需要加如图所示的默认值，不加默认值得先 menuconfig 下不然就是空值。

建议单独提一个 pr 修改这个问题。

[unicornx]

目前的想法是希望尽量不要在 RTT 仓库中加入额外的 BSP 内容，包括 prebuild 的文件，否则如果都按照这个思路去做，RTT 仓库仍然有膨胀的危险。

新建 #9623 ，等 duo-pkgtool 完成后，可以将其代替目前的 cvitek_bootloader （这里称之为”清理“）, 本 issue 用于 track ”清理“ 工作。具体见 《9623 的详细设计》中”有关 RT-Thread 仓库的清理工作“ 的描述。

以下引用部分是旧的方案思路，保留在这里仅作备忘

所以是否可以采用熊大的建议，在方案 2 的基础上进一步采用软件包的方式来提供 prebuild 文件。还有待研究。

或者依然采用下载 cvitek_bootloader 的方式（本身也可以理解成是一种软件包），只是避免下载在 RTT 源码树下，否则会污染工作环境，譬如 “对代码搜索等操作不友好”。附加：这个污染的问题在实际操作中影响不算大，譬如在 VSCode 中可以通过过滤排除这个路径。

[jiuyueshenhua]

我来做吧。

[unicornx]

I will take this issue over.