Open matianfu opened 5 years ago
感谢你的建议: 1.退出代码定义上,我们会重新归划 2.gpt使用缺省的parameter写入,会丢失rootfs分区,这要看一下是不是parameter定义的问题,比如rootfs 有没有加:grow标识,表示它是最后一个分区 3.readflashinfo返回的容量MB会直观点,Byte单位显示有哪些原因需要吗 4.rkdevloptool支持console下调用,pipe功能解决rootfs烧录慢的问题,可以去rootfs进行sparse转换,我们的工具支持sparse镜像烧录,它可以省去全零块的写操作时间。
瑞芯提供了upgrade_tool和rkdeveloptool两个工具,用于通过rkusb下载emmc固件。
upgrade_tool实现了一个类似repl的界面,这个对于scripting很麻烦,需要动用expect或者对tty编程。
相对而言rkdeveloptool简单一点,但是仍然有这样一些问题:
以上问题说明该工具设计上没有清晰分离机制和策略。仅仅针对emmc操作而言,必须的操作仅有:
应该有一个工具仅支持这几个操作的,有正确的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是固定的,其他的分区和文件系统使用自由可以留给产品开发者。
一点建议,供参考。