TASK: 为 duo 产品的 RT-smart 开发打包工具

[unicornx]

Describe problem solved by the proposed feature

任务背景 ：RT-Thread#9623

任务描述：这是一个内部的研究项目，具体目标参考 ”任务背景“。

注意事项，由于目前 RT-smart 针对 duo 还不完善，具体参考 RT-Thread#9622。目前 RTT 对 duo 已经支持了 RT-standard 版本，可以先拿 RT-standard 为基础先做起来。

RTT 上 duo 的 bsp 路径是 bsp/cvitek

我们只考虑 riscv 的 c906_little (c906 小核) 和 cv18xx_risc-v (c906 大核)，暂不考虑 ARM 的核。

Describe your preferred solution

• 总体设计方案图：
• 详细设计描述
  • duo-pkgtool 仓库布局设计
  • 期望的用户操作如下：
  • prebuild 的制作
• 有关 RT-Thread 仓库的清理工作

总体设计方案图

详细设计描述

该工具命名为：duo-pkgtool，注意以前叫 duo-sdk，但是 sdk 这个概念太大了，本质上我们只是一个打包工具。prebuild 部分依赖于 milkv-buildroot-sdk。

1. rthread 内核的构建不属于 duo-pkgtool 的工作范围，rthread.bin 的构建依然按照目前的操作习惯在 rt-thread 仓库中执行 scons 完成。同理，文件系统的构建也是在 userapps 中执行 xmake 完成，和目前习惯保持不变。
2. duo-pkgtool 只负责将 prebuild 的固件部分和 rthread.bin 打包生成 fip.bin 和 boot.sd。第二期可能还会负责将 fip.bin, boot.sd 以及文件系统的 image 文件整体再打包成一个 sd-card 的烧录镜像文件（包含两个分区）。

duo-pkgtool 仓库布局设计

综上所述，我觉得整个 duo-pkgtool 的仓库也可以做得很简单，

duo-pkgtool
|__prebuild
|  |_duo
|  |_duo256m
|  |_...
|__script
|__LICENSE
|__README.md

执行构建后多一个 output 目录（但具体的输出路径我们是支持可配置的，这里的例子只是假设默认放在 duo-pkgtool
下），如下：

duo-pkgtool
|__output
|  |_duo
|  |_duo256m
|  |_...
|__prebuild
|  |_duo
|  |_duo256m
|  |_...
|__script
|__LICENSE
|__README.md

期望的用户操作如下

• 第一步：clone duo-pkgtool 到工作目录

• 第二步：进入 duo-pkgtool 仓库所在目录

• 第三步：执行配置命令，目前对 duo-pkgtool 需要设置一个环境变量，记住 rt-thread 仓库的 bsp 所在路径就好了，假设这个环境变量名为 DPT_PATH_KERNEL（DPT 是 Duo Package Tool 的缩写），并且这个路径可以直接到 bsp/cvitek 这一级。这样 duo-pkgtool 就知道去哪里取 rtthread.bin 了。完整的路径是：

  • 小核：$DPT_PATH_KERNEL/c906_little/rtthread.bin
  • 大核：$DPT_PATH_KERNEL/cv18xx_risc-v/rtthread.bin
    目前配置可以做的很简单，用环境变量方式导出即可
    未来可能还需要设置 userapps 仓库中存放根文件系统文件的路径 DPT_PATH_ROOTFS。

  配置命令可以带一个参数 ，指定 duo 的型号（duo/duo256m/duos)。指定板子的类型决定了 duo-pkgtool 中获取 prebuild 的类型，因为我们的 prebuild 是按照板子的类型分目录存放的。同时这也决定了 duo-pkgtool 中生成的输出文件的路径，也是按照板子类型分开存放。

  一般情况下，用户尝尝专注于开发一个板子，所以在设置环境变量时，可以先指定一个，以后在打包时就不用每次指定了。更进一步，可以指定一个默认值，即用户如果执行配置命令没有给出 board type ，我们就默认 duo256m。注：据我了解 duo256m 也是 duo fanily 中算能比较推荐的一款。

  总结一下，总体上配置阶段涉及的环境变量目前至少有三个：

  • 内核的路径：DPT_PATH_KERNEL
  • 板子的类型: DPT_BOARD_TYPE
  • 输出的路径: DPT_PATH_OUTPUT, 各个板子的输出再按照子目录存放在 DPT_PATH_OUTPUT 下。

• 第四步：执行构建命令。建议打包命令简化设计成一个，大概如下：
  mkpkg [board_type] [-a]

  • board_type: 可选选项，和配置命令的那个参数类似，默认不给就是 duo256m，增加这个参数的目的主要是考虑用户可能会切换打包的 board type，增加这个选项后，可以在打包时覆盖配置时设置的 board type。一个可能的使用场景是测试团队或者发行版团队可能会用我们这个工具批量对duo 的不同产品批处理打包，这样只要一次配置，多次 mkpkg 就好了。
  • -a：可选项，如果指定了就同时生成 fip.bin 和 boot.sd。默认不要 -a，即只做 boot.sd。因为考虑用户使用场景，这个打包其实更多是为 RT-smart 服务，所以频繁更换的会是 boot.sd

如果是第一次构建或者 rt-thread 仓库的路径发生了变化，则执行第三步和第四步都需要，
如果是第二次构建，且 rt-thread 仓库的路径没有发生变化，则第三步不需要

prebuild 的制作

duo-pkgtool 中的 prebuild 部分是执行 duo-buildroot-sdk 的脚本制作出来，预先放在 duo-pkgtool 中方便打包。对 prebuild 的制作希望通过脚本管理起来，这个工作单独创建一个新的 TASK 进行跟踪，具体见：

• TASK: 为 duo-pkgtool 制作 prebuild 实现自动化 #6

有关 RT-Thread 仓库的清理工作

duo-pkgtool 完成后，现有 RT-Thread 仓库的 bsp/cvitek 下的打包脚本和 prebuild 文件应该相应清理掉。以后 RTT 里只负责生成 rtthread.bin 为止。

考虑兼容现有用户习惯可以在构建 RTT 内核的 scons 的最后尝试自动下载 duo-pkgtool 后完成打包（替换了原有的打包逻辑），下载位置可以让用户自己定，不指定就默认下载在现在 cvitek_bootloaer 的位置。这样对用户使用习惯是无感的，但是仓库解耦了，同样达到并解决了 RT-Thread#9060 当初提出的问题。这样老用户（主要是 rtt 的开发人员）其实并不需要自己去额外下载 duo-pkgtool, 使用习惯和现在没有多大区别。而新用户，包括未来设想的那些只负责测试和发布版本的用户来说，更关注的是 duo-pkgtool 的使用，可以按照我们设计的方式去使用。

rtt 的仓库清理工作复用现有的 RT-Thread#9060 跟踪，不在本 TASK 的设计范围内。

[koikky]

https://github.com/koikky/duo-sdk

目前只做了标准版部分。我看到今天rt源码仓库才更新，duo大核改为默认smart版本之前是默认标准版，所以用这个的话现在需要改成标准版

[unicornx]

https://github.com/koikky/duo-sdk

目前只做了标准版部分。我看到今天rt源码仓库才更新，duo大核改为默认smart版本之前是默认标准版，所以用这个的话现在需要改成标准版

第二次 review 的评审意见：
duosdk-2nd-review-comments.md

[jiuyueshenhua]

https://github.com/jiuyueshenhua/rtt-duo-sdk
目前做了一个初步的打包工具。望指点。

[koikky]

好的

[koikky]

老师，目前已完成duo-pkgtool的制作，有什么不足希望指出。https://github.com/koikky/duo-pkgtool