一些意见和建议

[matianfu]

瑞芯提供了upgrade_tool和rkdeveloptool两个工具，用于通过rkusb下载emmc固件。

upgrade_tool实现了一个类似repl的界面，这个对于scripting很麻烦，需要动用expect或者对tty编程。

相对而言rkdeveloptool简单一点，但是仍然有这样一些问题：

1. exit code，比如ld命令即使没有枚举到设备，仍然返回0，这对scripting来说是个糟糕的设计。
2. gpt代码有bug，在rk3328上，8GB emmc，使用缺省的parameters写入的分区表，在linux内核启动后最后一个分区（rootfs分区）丢失；
3. ReadFlashInfo返回的emmc容量是MB单位的，不是以Byte为单位的；
4. 命令不接受pipe；

以上问题说明该工具设计上没有清晰分离机制和策略。仅仅针对emmc操作而言，必须的操作仅有：

1. 枚举；
2. 下载最初的bootloader；
3. 读取emmc信息，主要是容量；
4. LBA读写
5. RESET设备

应该有一个工具仅支持这几个操作的，有正确的exit code定义，支持pipe，其他的功能可以再写一层bash或其他语言脚本实现，这样使用上灵活很多。

需要支持pipe的一个原因是这样：

写入gpt是写入emmc的头部和尾部，但是rootfs的镜像，常见的情况是在某个LBA之后都是空的；对于写入的程序而言它可以先读一遍镜像文件找到最后一个非空的sector，然后只把这些pipe给rkdeveloptool即可，在使用A/B分区或者rootfs内系统较小的时候可节省不少烧录时间；当然目前也可以先把rootfs.img后面的0给trunc掉，但是这需要复制一大块文件，如果有pipe支持这个中间步骤是可以省掉的。

既然瑞芯已经提供了基于Linux平台的工具，在工具的设计上应该符合Linux命令的实现习惯，这样对社区开发者方便很多。在Linux上分区和文件系统的使用方式多种多样，只要提供机制，开发者可以自己实现烧录脚本和量产工具，对于瑞芯的BROM和boot-loader的设计来说，仅有idbloader, u-boot和trust是固定的，其他的分区和文件系统使用自由可以留给产品开发者。

一点建议，供参考。

[shineseth]

感谢你的建议： 1.退出代码定义上，我们会重新归划 2.gpt使用缺省的parameter写入，会丢失rootfs分区，这要看一下是不是parameter定义的问题，比如rootfs 有没有加:grow标识，表示它是最后一个分区 3.readflashinfo返回的容量MB会直观点，Byte单位显示有哪些原因需要吗 4.rkdevloptool支持console下调用，pipe功能解决rootfs烧录慢的问题，可以去rootfs进行sparse转换，我们的工具支持sparse镜像烧录，它可以省去全零块的写操作时间。