网络升级探讨-2种基本可行的思路

本帖最后由 ngswfx 于 2017-3-3 11:21 编辑

第一种思路就是我现在使用的：

直接在ARM APP里面建立和PC客户端SDK网络交互，将整体升级包，或者各个模块的升级包发送到arm嵌入式端，然后在嵌入式arm端，通过dd,或者flashcp程序，或者通过mtd直接操作，写入相关模块，目前遇到的最大问题就是rootfs部分总失败，考虑原因可能是因为，linux系统对于rootfs分区正在占用，正在使用的原因，其他部分，例如uboot,ENV,kernel,setting,logo等分区都可以实现升级，失败的几率很小。但rootfs失败的几率有些大，为此，这种思路的升级方式一直没敢公开使用。


第二思路：通过tftp方式，让uboot自动实现升级。
PC客户端向远端arm发出升级需求，并且准备好升级包，远端arm端，检查版本等信息是否正常，如果可以升级，PC客户端将升级包拆分抛弃掉升级头结构（升级包升级头结构，里面有芯片型号，内存大小，flash大小，版本等信息），准备好和flash内存一一对应的升级包，另外准备好tftp32程序，将最终升级包拷贝到tftp32程序所在目录，开启tftp32程序服务，将当前机器IP地址发送给远端arm端，远端arm端，检查自己的IP,以及tftp32服务器端IP，（当然可以顺便检查一下tftp32服务器是否基本正常）,读取uboot后面的ENV环境变量，修改写入arm本地IP地址以及远端Tftp32服务器IP地址，并且设置升级标志bTftpUpdate=1，远端arm控制重启,本地升级工具进入300秒倒计时，并探测尝试APP连接状态（升级如果完全成功，arm启动后，会自动开启APP），用以标记升级是否成功。

远端uboot如果发现需要网络升级的标志bTftpUpdate=1，就开始组建升级包名称，然后到env里面读取tftp32服务器IP地址，然后通过tftp网络获取数据包，得到数据包以后，开始升级过程，升级结束并且成功以后，修改网络升级的标志bTftpUpdate=2,然后控制重新启动，当uboot再次启动时，发现升级标志是2，忽略,不进行其他动作，等进入操作系统rootfs系统以后，由APP程序接管，读取env环境变量，如果发现bTftpUpdate=2或者大于2，将其设置为0,升级正式结束。

第三种思路，超级疯狂的模式:lol （没戏可能性非常大），就是在APP下，将准备好的升级包放到内存的某个位置（例如海思占用的那部分内存空间，先把海思的驱动卸载了，然后放到内存后面那一部分，因为前面一些部分，再次开机，uboot可能要用到），然后重启系统，如果系统重启过程中，这部分内存不会被破坏，uboot重启接管后，直接使用这部分内存中的数据进行升级。不过我估计既然是重启，这些内存很可能被破坏掉了。


/////////////目前考虑采用第二种模式，这种方法的好处也是显而易见的，就是如果rootfs等大小即便发生明显改变,甚至是分区个数发生改变，升级依然正常（类似于u盘升级模式），另外的好处就是可以不同版本同时升级，只需要对PC客户端流程少许修改即可，而且升级出错的可能性很小，只需要控制好，实际升级时，单独对uboot以及env变量部分先升级，升级彻底失败的，报废返厂的可能性是很小的，是可控的，可以恢复的，即便失败，也可以再次通过u盘升级补救。当然这种升级模式，也可以让整个系统支持自动升级，甚至是无须技术员人为干预，只要升级服务器有升级包，就自动更新升级了，最根本还是因为这种升级模式类以u盘升级，不用过多考虑分区问题。

第一种模式由于和mtd相关，除非每个mtd最早规划都考虑了增容需求，否则，在系统环境下，写mtd，如果升级包内当前mtd空间需求比现在的大，就不好处理了。例如kernel等分区，如果加入某些项目支持，大小发生明显改变，超过了以前的值，并考虑到spi 64K  NAND 128K问题，整体大小发生明显改变。此时当前系统的mtd操作，应该无法应对这种情况吧（除非以前的kernel分区本身就有64K或者128K的富余）。

///不知道大家目前采用的何种模式进行网络升级。如果是第一种方式，又怎么去处理rootfs升级容易失败的问题。

最大的困惑就是，现在这些厂家做的都是IE升级，在IE里面有一个网络升级功能，从升级动作的流程来看，好像就是第一种思路，因为点击完升级，立刻就开始发送数据了。只不过不知道他们是怎么处理rootfs等系统占用分区的问题的。